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.
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.
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...
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.
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.
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.
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.
It also seems to paradoxically improve load times. Shrug.