News for hackers. Stuff that matters.

A comment on Windows is not a Microsoft Visual C/C++ Run-Time delivery channel.

Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by gilgoomesh on Friday April 11, 2014 @11:58PM (#7576918)
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.
[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by api on Saturday April 12, 2014 @12:51AM (#7577018)
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.

[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by stinos on Saturday April 12, 2014 @03:10AM (#7577223)
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.

[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by slashdotaccount on Saturday April 12, 2014 @03:03AM (#7577207)
How do you track and fix security issues in the libraries that you statically link?
[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by e12e on Saturday April 12, 2014 @06:11AM (#7577472)
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...

[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by _wmd on Saturday April 12, 2014 @11:45AM (#7578132)
There's little paradoxical about it.. if you link against 20 DLLs, that turns into 20 directory lookups and then random paging potentially across the entire drive, whereas a .EXE is more likely to appear contiguously on the drive, and after the first page of it is loaded in, the OS readahead mechanism might opportunistically snarf something like the next 256kb worth of pages for free as part of the same IO.

Ignoring IO, and depending on the size of the app (particularly C++ apps though), the linker might be spending a huge amount of time on symbol fixups.

[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by jevinskie on Saturday April 12, 2014 @01:05AM (#7577040)
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?
[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by delhanty on Saturday April 12, 2014 @01:42AM (#7577093)
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.
[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by CamperBob2 on Saturday April 12, 2014 @04:35PM (#7579093)
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

Agreed, and it's sad to think how much confusion and grief would have been saved if they'd just made this a mandatory policy from day 1.

Windows developers regularly jump through an entire maze of hoops -- and make their users do the same -- just so they can call free() on a pointer they got from some random DLL, or do other goofy things that they shouldn't be allowed to do.

[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by sourkremlin on Saturday April 12, 2014 @06:16AM (#7577481)
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.

[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by pjmlp on Saturday April 12, 2014 @02:01AM (#7577121)
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.

[ Parent | on HN ]
Re:Windows is not a Microsoft Visual C/C++ Run-Time delivery... by derefr on Saturday April 12, 2014 @02:33AM (#7577171)
> 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.

[ Parent | on HN ]