Windows is not a Microsoft Visual C/C++ Run-Time delivery channel • Hacker News Board

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#91

Post by vetinari » Sat, Apr 12, 2014, 8:48 PM UTC

malkia wrote: post #24

userbinator wrote: post #4

Sorry, but I'm not going to link to a huge convoluted mess of variously versioned DLLs just to get standard C library functions. Maybe the situation is different with C++ (probably due to no real ABI standard), but the C library functions shouldn't change since they were standardised. If an application breaks because the internals of a library were changed, that's none other than the applications' fault.

What if your application is a plugin. Or SDK?

It enough, when you application uses several third party SDKs or plugins, each built with different MSVC version.

Sometimes, it has interesting impact. For example, you aren't going to get PyQt5 for Python 2.x, because binaries (builds from python.org and ActiveState) for Python 2.x are built with MSVC9 and Qt5 requires MSVC10 at minimum.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#92

Post by dredmorbius » Sat, Apr 12, 2014, 9:42 PM UTC

vetinari wrote: post #85

dredmorbius wrote: post #65

Earlier quoted context omitted.

Without recompiling or hunting for old libs? I know there were a couple of pretty significant glibc upgrades, and IIRC the binary format changed at some point from something earlier to ELF. Hrm. "something earlier" seems to have been the a.out format, based on Eric Youngdale's 1995 Linux Journal article: The ELF Object File Format: Introduction http://www.linuxjournal.com/article/1059

Yes, without recompiling. That's the point, a.out is a binary format and if you recompile with current toolchain, you will get ELF. You will need the original shared libraries and linker, though. They will run.

Thanks.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#93

Post by coldtea » Sat, Apr 12, 2014, 9:55 PM UTC

doctorwho wrote: post #25

ryandrake wrote: post #5

Earlier quoted context omitted.

Yea, you can't simultaneously say "Developer, don't do this!" and then "Well, to maintain backwards compatibility with developers who did it, we're going to let you do it. BUT DON'T DO IT!" MS is in a tight spot. They have this maintanance mess because of their otherwise admirable dedication to backwards compatibility.

Microsoft's dedication to backward compatibility is why Windows ruled the desktop world for several decades. Apple's utter contempt for backward compatibility is why people who care about their sanity hate developing products for OSX. Which API is Apple going to deprecate and screw me over with today? Microsoft always went above and beyond the call of duty to support hardware and software (with runtime code modificat…

>Apple's utter contempt for backward compatibility is why people who care about their sanity hate developing products for OSX. Which API is Apple going to deprecate and screw me over with today?

You mean like they countless new API versions and frameworks that MS introduces year over year as "THE" way to write Windows programs?

Sure, they might retain binary compatibility, but if you want future-proof your stuff and continue to get updates and changes you have to jump to the new shiny.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#94

Post by stormbrew » Sun, Apr 13, 2014, 3:00 AM UTC

e12e wrote: post #54

stormbrew wrote: post #44

Earlier quoted context omitted.

IE didn't start that, it had to accept that shit because everything else did long before it. I'm not even sure what browser started it. I'm positive that the first graphical browser I used (Cello) did, though. I'm not even sure it was really considered a bad thing at the time.

Have a look at the paragraph (and list) section(s) of: http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt P: Paragraph mark The empty P element indicates a paragraph break. The exact rendering of this (indentation, leading, etc) is not defined here, and may be a function of other tags, style sheets etc. To whit, the well-formed , "good" example: What to do This is a one paragraph. This is a second. This is a third.…

Oh yeah, I'm not saying IE6 didn't do a lot wrong, just that this wasn't one of them.

But I also think it's worth remembering that IE5/6 also featured a lot of early experiments in things that are now considered essential components in the web. XMLHttpRequest was a huge advancement, and while ActiveX was obviously crappy it was at least part of an attempt at creating a more dynamic web.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#95

Post by mattgreenrocks » Sun, Apr 13, 2014, 5:55 AM UTC

jodrellblank wrote: post #89

mattgreenrocks wrote: post #3

A lot of 'real' ( cough ) hackers like to look down at MS, but Raymond Chen is one of those guys I'd hate to get into a technical argument with: he has experience, is extremely sharp, and very sarcastic. Those three attributes make Old New Thing my favorite MS blog even if I don't write Win32 anymore. If anything, Windows' level of backward compatibility is a giant cautionary tale: enable poor behavior from devs, and…

Whether it's inane programs inserting themselves into the systray You mean the taskbar notification area? - http://blogs.msdn.com/b/oldnewthing/archive/2003/09/10/54831... You could try arguing - Mr Chen appears to be active on StackOverflow http://stackoverflow.com/users/902497/raymond-chen This is why it's a bit of a blessing that webapps can't do much; because the more powerful they become, the more annoying and i…

I was thinking of that taskbar notification area article when I was writing, but I left it as is; colloquial usage trumps most everything nowadays. :)

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#96

Post by dblohm7 » Sun, Apr 13, 2014, 6:39 AM UTC

rwallace wrote: post #15

Microsoft C++ supports static linking with the standard library, which you should be using for release builds. That way, your program will always be using the exact version of the standard library that it was tested with, and it's guaranteed not to interfere with anything else on the target system.

OTOH by linking statically you cannot distribute CRT bug fixes without building new binaries. Ideally the CRT DLLs are installed with Windows Installer and can then be updated via Windows Update.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#97

Post by bananas » Sun, Apr 13, 2014, 8:43 AM UTC

userbinator wrote: post #80

bananas wrote: post #31

Earlier quoted context omitted.

What's wrong with an installer? An unattended installer or even a click through one is no obstacle these days.

- I write my applications to run anywhere and not require any installation. There is a huge convenience factor in this. As a collorary, they also don't require un installation since they do not "embed" themselves into the system (registry, config files, additional files elsewhere, etc.) - It makes for a bigger download, of code and data that would never be used again, with one extra step the user has to do before use…

The problem with that is that your software is a bad citizen in the windows ecosystem. Even a one shot can be pushed out or run via an msi package with no install. And you get the benefit of being able to easy throw it out via GPO, pull dependencies like VCRT versions etc. MSI packages are pretty small as well - our current VSTO package which has about 25,000 LoC in it is only 400k.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#98

Post by userbinator » Mon, Apr 14, 2014, 3:56 AM UTC

bananas wrote: post #97

userbinator wrote: post #80

Earlier quoted context omitted.

- I write my applications to run anywhere and not require any installation. There is a huge convenience factor in this. As a collorary, they also don't require un installation since they do not "embed" themselves into the system (registry, config files, additional files elsewhere, etc.) - It makes for a bigger download, of code and data that would never be used again, with one extra step the user has to do before use…

The problem with that is that your software is a bad citizen in the windows ecosystem. Even a one shot can be pushed out or run via an msi package with no install. And you get the benefit of being able to easy throw it out via GPO, pull dependencies like VCRT versions etc. MSI packages are pretty small as well - our current VSTO package which has about 25,000 LoC in it is only 400k.

> your software is a bad citizen in the windows ecosystem

According to MS who seem to be trying to force the idea that all software needs to be "installed" and have an overly complex installer/uninstaller. I care more about the flexibility and convenience for my users than what MS thinks (which is ultimately heading towards locking users in a walled garden, so no surprise that "just download and run a self-contained executable anywhere" is perceived as somewhat of a threat.)

> And you get the benefit of being able to easy throw it out via GPO, pull dependencies like VCRT versions etc.

Those are not needed for what I'm doing, so they're not benefits to me. But I guess if your idea of "pretty small" is 400k, then that's not really a concern...