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

51–60 of 98 posts

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

#51

Post by anon4 »

ygra wrote: post #48
anon4 wrote: post #47

Earlier quoted context omitted.

This is compounded by the strange fact that Microsoft's own development tools produce programs which you cannot give to other people to run on a standard Windows install. If I compile on Linux, I link against libstdc++ version du jour and the binary will just run on a recent distro. If it doesn't you end up in the same spot - you need to install the appropriate .so version, but most of the time things just work. So M…

Just imagine you're linking against the MSVC10 runtime and want to distribute your program to people who run Vista. How could the runtime even be part of the system? It didn't exist back then. So you have to bundle your dependencies anyway and you need to do that with everything else you use as well. The OS does nothing else: It ships with the dependencies it needs. If there was no program in a standard Windows insta…

So why do I need to distribute it? Why can't it be part of the standard install machinery "oh btw my program needs MSVCR10.DLL be a dear and fetch it from Windows Update"? Heck, this could be embedded in a manifest inside the .exe - "I need these MS libs with these versions" and when you double-click Explorer could parse that, check that those are installed and if not launch a "this program requires additional components installed from Windows Update, please wait".

And I don't want them to ship future versions of the runtime that don't exist yet, just the current ones. So when I build a .exe and give it to someone on the same OS they can run it.

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

#52

Post by evacchi »

ygra wrote: post #43
TwoBit wrote: post #36

Earlier quoted context omitted.

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.

The automatic tag closing behaviour is even specified now. But look at it another way: imagine browsers accepted only valid HTML and every browser had some bugs in what they consider valid. Writing a document in a way that it displays at all might be a challenge already then. Add to that that not everyone is on the latest browser version (that was probably more true in the 90s as well) and you get all the current pai…

I may be wrong here, but isn't implicit tag closing consequence of html deriving from sgml? mandatory tag closing is something that came with xml AFAIK

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

#53

Post by evacchi »

ygra wrote: post #43
TwoBit wrote: post #36

Earlier quoted context omitted.

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.

The automatic tag closing behaviour is even specified now. But look at it another way: imagine browsers accepted only valid HTML and every browser had some bugs in what they consider valid. Writing a document in a way that it displays at all might be a challenge already then. Add to that that not everyone is on the latest browser version (that was probably more true in the 90s as well) and you get all the current pai…

I may be wrong here, but isn't implicit tag closing consequence of html deriving from sgml? mandatory tag closing is something that came with xml AFAIK

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

#54

Post by e12e »

stormbrew wrote: post #44
TwoBit wrote: post #36

Earlier quoted context omitted.

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.

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.
Yes, with spaces and alternating case. This was the standard before IE6 came out, so it's not that crazy that they closed up some bold and italics tags -- I'm not entirely sure if there were (are?) any other SGML dialects that were quite as loosely defined as early "HTML" was.

I think IE6 did a lot of awful things, but the only real "damage" done was in borking the CSS implementation (especially the box model). The fact that it rendered crap HTML sort-of-ok wasn't all that bad.

It was the crazy things it did with, lets say.... specially crafted HTML that led to a lot of problems. And MS FrontPage's insisting on adding COLOUR="#000000" (black) to all documents, and assuming BACKGROUND was set to white did a lot to break semantic mark-up.

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

#55

Post by deniska »

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

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

#56

Post by e12e »

slashdotaccount wrote: post #37
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.

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

I don't think it's so much how you (as an active developer does it) -- granted having to redistribute your app everytime any of (say) 10 bundled dependencies need an update is an inconvenience -- the biggest problem is when you have some old software (without vendor support) that is statically built with some overflow "built in" from an old version of a library.

Granted, at some point patches probably won't be backported, but it is convenient to be able to upgrade libssl, restart a few services and be done.

Of course, if you bought that software under GPL, you might be able to fix the issue yourself...

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

#57

Post by sourkremlin »

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?

I've used delhanty's example in a large codebase and it worked well.

Another approach is to create a static library that overloads global memory operators (new, delete, and their variations). Link this static library to every DLL that you make, and have the implementation of these overloaded global memory operators use the heap of a single DLL. There may still be multiple heaps, but only one will be used.

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

#59

Post by ygra »

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.

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

#60

Post by emiliobumachar »

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…

"But, of course, if that had happened, maybe the web would never have taken off like it did, and maybe instead, we’d all be using a gigantic Lotus Notes network operated by AT&T. Shudder."

http://www.joelonsoftware.com/items/2008/03/17.html

Post reply on HN