Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blogs.msdn.com

Post reply on HN
Print view View original

31–40 of 98 posts

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

#31

Post by bananas »

userbinator wrote: post #12
greenyoda wrote: post #8

Earlier quoted context omitted.

"If an application breaks because the internals of a library were changed, that's none other than the applications' fault." I agree 100%, it's certainly the application's fault, but Microsoft has some very large corporate customers that it wants to keep happy, so in some cases it will eat the cost of cleaning up after sloppy developers. I don't work for Microsoft, but the company I work for (we write expensive enterp…

> and your application's installer installs the redistributable DLL for that version I don't want an installer, nor to include the redistributable which is around 2 orders of magnitude larger than the application itself! I want a single tiny binary, just download and run on any system, and that's what using MSVCRT allows.

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

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

#32

Post by tanzam75 »

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…

> This allows programs should have failed epically to run flawlessly on everything from Windows 95 to Windows 7.

The "upgrade through every version of Windows" videos show Reversi and MS-DOS Executive running on Windows 8. You do have to run 32-bit Windows, though, to get 16-bit compatibility.

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

#33

Post by derefr »

ryandrake wrote: post #5
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…

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.

They could set up Visual Studio to not compile code that does X, so that current binaries that do X still work, but you can't ship any new versions of your product until you stop doing X in it.

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

#34

Post by derefr »

pjmlp wrote: post #29
gilgoomesh wrote: post #14

Why can't Windows officially include standard versions of this library? You know, like Windows already does with .NET versions since Vista or every other OS does with libstc++ or libc++? Forcing every C/C++ program to bundle their own MSVCRTXX.dll is pretty silly.

Because .NET has version mechanisms built in. The code will make use of the right version if available. You can do the same with WinSxS and manifests, but again too many lazy developers. Doing that would be the same as .so hell in GNU/Linux regarding libc versions.

> You can do the same with WinSxS and manifests, but again too many lazy developers.

I'm surprised Microsoft hasn't put a feature in the "Customer Experience Improvement Program" that scans the applications installed on a system for what versions of DLLs they try to load, collates all that data together, and then automatically generates "default" manifests for those apps, locking them to the specific versions of DLLs they were already requesting+using anyway. It'd be like wrapping each installed app in a Docker container based on the current working system config.

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

#35

Post by Too »

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…

This is why I'm against the commonly praised "Be conservative in what you send, be liberal in what you accept" principle. Being liberal in what you accept only gives you compatibility nightmares in the future. Another perfect example of this is html and is the reason why every browser has to reimplement all the bugs of internet explorer 6 in order to not "break the internet". Really, why should a browser try to correct a corrupt document with trailing tags and open attributes. Beginner developers/designers will simply think "looks good on my machine, deploy and forget" and then we are stuck supporting that kind of corruptness forever.

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

#36

Post by TwoBit »

Too wrote: post #35
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…

This is why I'm against the commonly praised "Be conservative in what you send, be liberal in what you accept" principle. Being liberal in what you accept only gives you compatibility nightmares in the future. Another perfect example of this is html and is the reason why every browser has to reimplement all the bugs of internet explorer 6 in order to not "break the internet". Really, why should a browser try to corre…

You must be my doppelganger, because I've been saying exactly this for some time. Internet Explorer caused so much trouble partly because it accepted so much bad HTML. It would close tags for you, even.

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

#37

Post by slashdotaccount »

api wrote: post #19
gilgoomesh wrote: post #14

Why can't Windows officially include standard versions of this library? You know, like Windows already does with .NET versions since Vista or every other OS does with libstc++ or libc++? Forcing every C/C++ program to bundle their own MSVCRTXX.dll is pretty silly.

I must confess to statically linking my Windows binaries. It's better than making the user click through extra installers-within-installers to install the right MSVC redistributable. It also seems to paradoxically improve load times. Shrug.

How do you track and fix security issues in the libraries that you statically link?

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

#38

Post by mabhatter »

api wrote: post #18
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…

This is part of what's driving the rise of feudal app store models. Users like them too-- at least most users who aren't concerned with (or don't understand) things like openness and freedom. They prune the ecosystem of shitware to at least some extent. Personally I think OSes need to evolve toward a model where apps are more strictly containerized, something like Docker (Linux) but for everything. The user should st…

That's the way OSX is RIGHT NOW. As a User I can run any program I want and mucky-muck my crap up. But Apps from the Mac App Store live in neat little bundles and are forbidden to do the mucking around in OS bits. So the OS is an "appliance" that I can just replace at a whim. If I go off the tracks to load apps that NEED to overwrite OS space, then I know who did it.

Personally, I but App Store versions whenever possible and I have next to zero problems with my Macs an order of magnitude less than my locked down PC at work even. VERY few apps need to color outside the lines and I like the push for them to explain themselves or get blasted by the next OS update.

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

#39

Post by ido »

tanzam75 wrote: post #32
doctorwho wrote: post #25

Earlier quoted context omitted.

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…

> This allows programs should have failed epically to run flawlessly on everything from Windows 95 to Windows 7. The "upgrade through every version of Windows" videos show Reversi and MS-DOS Executive running on Windows 8. You do have to run 32-bit Windows, though, to get 16-bit compatibility.

You can still run honest-to-goodness PC DOS 1.0 .com files from 1981 designed to run on the original PC out of the box in 32 bit windows 8.

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

#40

Post by stinos »

api wrote: post #19
gilgoomesh wrote: post #14

Why can't Windows officially include standard versions of this library? You know, like Windows already does with .NET versions since Vista or every other OS does with libstc++ or libc++? Forcing every C/C++ program to bundle their own MSVCRTXX.dll is pretty silly.

I must confess to statically linking my Windows binaries. It's better than making the user click through extra installers-within-installers to install the right MSVC redistributable. It also seems to paradoxically improve load times. Shrug.

click through extra installers-within-installers

the crt can be installed silently just like any other self-respecting installer out there, and normally the tool you use to create installers does support this as well. I mean, even something basic as WinRar allows you to create silent extract-install combos.

Post reply on HN