Generate msvcrt_old.lib

[kusma]

Here's something that I think in principle is kinda neat, but the implementation isn't perfect.

So, instead of storing msvcrt_old.lib in the repo, we can store the export-table, and re-create the import lib when compiling. This should allow us to target both x86 and x64 without any magical binary blobs in the repo, which is neat.

But, for some reason, some symbols are missing, and I can't off the top of my head understand why. I'm guessing these are involved in something more complicated than what I currently grasp, so further digging should be done. We might be missing other symbols, which can lead to obscure issues down the road.

Anyway, I thought I'd post it here, in the hopes that someone else knows linking better than me, and points out what the problem is.

[kusma]

OK, I think this approach is better. What I did was instead dump the symbols using DUMPBIN /LINKERMEMBER, and removing obviously bogus symbols instead.

This should result in a complete set of symbols.

[yupferris]

Actually one thing while we're at it - we may not actually want to call it msvcrt_old.lib and instead just msvcrt.lib. Admittedly I'm not sure why I renamed it in the first place.

This would require updates in the dependent projects ofc.

[kusma]

So, I tried renaming it msvcrt.lib, and that actually didn't work for me. I didn't really look into it deeper, so maybe it was something else.

It should also be noted that recent versions of visual studio ship with msvcrt.lib as well. Some googling tells me that this version still links to MSVCRT.dll, but later versions of MSVCRT.dll actually contains more symbols that a production could accidentally use, causing it to not work on older Windows versions.

Oh, and just for the curious: here's what triggered me to try this approach. Their solution doesn't seem to be complete, though.

[kusma]

Just thought I'd let you know, I've renamed to msvcrt.lib in the new version that I'll push out once x64 support has landed. It turns out, it worked fine. Not sure what went wrong last time, but lots of stuff was a bit janky at that point, so I'm not going to obsess about it ;)

[kusma]

OK, so I've updated this, but there's still a few things I need to look more into

• ~Test things a bit (right now I've only compile-tested; I did test before the latest rebase, but not after)~ Things seems to work fine.
• ~Check if stuff like _CRT_DECLARE_GLOBAL_VARIABLES_DIRECTLY is really needed~ Not needed.
• ~..and if so, figure out if it should be set from CMake instead~ Does not apply
• ~Consider setting /NODEFAULTLIB automatically for any projects using the msvcrt library~ Not a big gain in itself. We need to set so many flags, and we set them all at the same time now. This should probably be moved to the top-level CMakeList.txt file, but that's not related to this MR.
• ~See if there's a better way of doing that NEED_MAINCRTSTARTUP-dance. It feels stupid to set a global define just to inject a symbol. Maybe providing it as part of the msvcrt lib when built for x64 is the way to go instead.~ Yep, fixed.

Edit: all of these are fixed now, and I think this is good to go.

[kusma]

@yupferris: humble ping?