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

61–70 of 98 posts

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

#61

Post by rwallace »

stinos wrote: post #41
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.

on the other hand there's the issue as stated in one of the other comments: If an application breaks because the internals of a library were changed, that's none other than the applications' fault. All the occasions we had an application only crash on client's machine where alway due to bugs in our code, not in the platform. (not saying that it can't happen, but it seems rare for the type of app we do) So I'd rather…

As Raymond Chen explains at length in a few of his posts, this does not matter. Sure, there's a sense in which the bug is your fault for not being infallible, but what of that? We already knew we aren't infallible. The point is, that kind of live fire debugging punishes your users, not you. And as long as you keep doing it that way, it's going to end up hitting your users in a situation where you aren't around to fix the bug.

I did say you should use static linking in the release build. If you want to keep virtual machines with every version of Windows and/or the run-time library you can lay hands on in order to test debug builds of your program against them so you can find the bugs instead of letting users trip over them, there's certainly nothing wrong with that.

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

#62

Post by rwallace »

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…

The way to know which principle you should follow is to ask yourself: am I in the position to set a de facto standard?

If you are, then be conservative in what you accept, and prevent whole categories of problems in the future.

If you're not, then it's too late for that. The damage is already done. Be liberal in what you accept, and try to mitigate the resulting harm.

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

#63

Post by leaveyou »

I grew up with windows & windows dev tools and I always had a pragmatic appreciation for them, but lately I became quite bitter and cold towards Windows and Windows developers and this happened long before I started using alternatives. At one point it was very hard to avoid the feeling that something, somewhere deep in windows is rotten. With every new windows version from winXP on, I had the feeling that I'm being sold a slightly improved technological improvisation with a slightly better theme applied on it. Visual Studio and .Net framework tried hard and nearly succeeded to hide the messy roots of the problem but the stench of thousands of leaky abstractions can still be felt every time you open one of the many doors leading to Windows basement. The C/C++ foundation of windows (the shaky ABI) is only making it worse and in my opinion many major problems of modern software can be traced to unsolved problems in C/C++. I have a dream (a delusion :D) that despite the accelerating patches applied to both(coincidence?) of these technologies (C89,99,11,1X C++98,03,11,17 Win Vista,7,8,8.1,9) they will both end in the greatest "oh, f*ck it!!" in the history of software and be abandoned for something much better, which I hope will crystallize out of these ~70 years of computer science.

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

#64

Post by rwallace »

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 relies on dynamic linking? I'm surprised at that because when I ran a test just now, Microsoft C++ compiles Hello World to an 84k executable whereas MinGW generates a 261k executable. I always assumed MinGW was doing the right thing and linking statically against (its own version of) the standard library; if not, where does the extra file size come from?

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

#65

Post by dredmorbius »

antocv wrote: post #45
ido wrote: post #39

Earlier quoted context omitted.

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.

You can run a.out files from 1992 on Linux too, so what.

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

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

#66

Post by MichaelGG »

TwoBit wrote: post #36
Too wrote: post #35

Earlier quoted context omitted.

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.

IETF groups continue to perpetuate this junk, too. It opens up security holes, as you can end up with a "confused deputy" situation. A proxy might read certain header fields one way because the spec encourages the proxy to "infer" the "meaning" of creative headers. But a server behind the proxy might interpret things differently.

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

#67

Post by cesarb »

deniska wrote: post #55
csense wrote: post #30

Does Linux suffer from this problem? I think the answer is "no" because Linux distros generally recompile the world with each new major standard library version. If any C standard library gurus are reading this, feel free to chime in!

When glibc guys changed memcpy implementation which changed its undefined behavior, it broke Flash Player and Linus got pissed off. Afair they reverted the change. https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

IIRC, they later used symbol versioning so that only newly compiled programs get the real memcpy. Older programs get a fake memcpy which simply calls memmove, which is what Flash should have been calling instead of memcpy.

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

#68

Post by rbanffy »

"This meant not changing the size of the class (because somebody may have derived from it) and not changing the offsets of any members, and being careful which virtual methods you call" scares me.

I understand DLL technology have been around for a couple decades now and that it solved many difficult problems when introduced, but, still, this looks insanely fragile.

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

#69

Post by maxerickson »

Aardwolf wrote: post #58

Why does a program compiled with VS need a specific DLL anyway? Can't VS compile FOR Windows, with only the DLLs Windows provides by default?

That's what the article is about, why they decided to not have VS link against the OS runtime.

At some point, the decision was made to just give up and declare it an operating system DLL, to be used only by operating system components.

Makes it clear enough that it was a choice they made, with the big reason being the effort required to maintain compatibility across so many systems and compilers. My knowledge of it never really got past the poking-with-a-stick stage, but apparently (at least some of) the windows SDK compilers were able to link to the system runtime well after they made the switch in VS.

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

#70

Post by to3m »

ygra wrote: post #59
Aardwolf wrote: post #58

Why does a program compiled with VS need a specific DLL anyway? Can't VS compile FOR Windows, with only the DLLs Windows provides by default?

Sure, just don't link against the C++ runtime library and you're good. Of course, you won't have anything said runtime lib provides, then. Or link the runtime statically, as suggested in a few other posts. Your binary size will increase then, though.

Here's an article about it: http://www.drdobbs.com/avoiding-the-visual-c-runtime-library...

Without the runtime library, strictly speaking you're no longer programming C or C++, hence the surprises...

Post reply on HN