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

21–30 of 98 posts

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

#21

Post by jevinskie »

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.

Yes, resorting to static linking is a pretty good solution for executables. Pitty about the bloat, but it works! How would static linking work with libraries? Would you get multiple heaps?

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

#22

Post by jevinskie »

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.

What can you do for the situation where you ship a library instead of an executable?

My team's product is moving to statically link libstdc++ and libgcc thanks to the runtime linking exception in GCC. It will allow us to use C++11 on old systems. We are grateful that libstdc++ is backwards compatible to GCC 3.4 (other libstdc++'s can link against us)!

I'm looking into statically linking musl libc so our product could (in theory) run on any 2.6/3.0 kernel. =)

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

#23

Post by malkia »

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…

I love Raymond Chen's old new thing, also Mark Russinovich's SysInternals - because of these two (and real job involving Windows) - I actually enjoy it when I can solve the next "weird" windows problems some of my coworkers would have (but then again I don't know as much as I wish - but it's fun time overall).

And while I disagree with Raymond on the MSVCRT.DLL topic, I can also see his point (and I might've took it, if I was working for Microsoft)

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

#24

Post by malkia »

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?

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

#25

Post by doctorwho »

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.

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 modification and more). This allows programs should have failed epically to run flawlessly on everything from Windows 95 to Windows 7.

If Android even attempted a fraction of what Windows did, fragmentation would not be a problem. Android is a perverse mix of Apple and Microsoft though. It's a pain in the ass to maintain products for Android and it's even worse for iOS.

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

#26

Post by delhanty »

jevinskie wrote: post #21
api wrote: post #19

Earlier quoted context omitted.

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.

Yes, resorting to static linking is a pretty good solution for executables. Pitty about the bloat, but it works! How would static linking work with libraries? Would you get multiple heaps?

Sometimes you do get multiple heaps, but it can be made to work if one is careful not to allocate on one heap and then free on the other heap. One example is a C/C++ COM addin for Excel say - instead of freeing the Excel allocated memory directly the addin DLL invokes addRef/Release appropriately on the IUnknown interfaces to the various objects it gets handed by Excel. That can be automated a bit with ATL and CComPtr. A similar factory / smart pointer API can be made to work for any DLL that wants to maintain its own heap.

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

#27

Post by amaks »

brianpgordon wrote: post #16
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…

I'm really amazed that Windows has maintained substantial binary compatibility for so long. To be honest, when I see "one way they could've done it was by squeezing the flag into the one byte of padding between widgetLevel and needs_more_time" I think nooope , nonstandard, can't do it, not my problem. Worrying about such things constantly throughout huge projects like MSVC over decades of time must add a whole new le…

That's Windows strength as well as its weakness. For example, I've heard that Windows Shell (whose proud team member is Raymond Chen) has to carry the baggage of backward compatibility, heritage code base and stuff like that simply because some forsaken customer might be using a particular feature. It's really hard to innovate in the environment like that.

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

#28

Post by jbk »

rossy wrote: post #10

The discussion in the comments is interesting. MinGW, the compiler for VLC, LibreOffice and most other FOSS projects on Windows does exactly what Raymond says not to do. In fact, the entire purpose of MinGW is to make GCC able to target msvcrt.dll. Developers and users love this, since they don't have to distribute and install the CRT with the program. Developers following the GPL aren't even allowed to distribute th…

> MinGW, the compiler for VLC, LibreOffice and most other FOSS projects on Windows does exactly what Raymond says not to do.

While this is mostly true, and because of the project of VLC on WinRT (Windows Metro), VLC can now link, in a MinGW environment, to MSVCR80, 90, 100 and 110.

The main problem with all those, is that we cannot redistribute MSVCR*.dll for licensing reasons.

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

#29

Post by pjmlp »

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.

Post reply on HN