Possible to reduce/remove the need for old CRT/MSVC/Win SDKs?

[playmer]

This is likely a naive question, and I'm sure I'm missing some pieces of the puzzle, but I'm curious what we actually need from the CRT and MSVC toolchains?

From poking around it does sound like from #51 and #36 that there's some need from the CRT for intrinsics. But maybe that can be sidestepped with the changed mentioned in #51.

We need a way to link against Kernel32 as well as probably a few other Win32 libraries. We don't (I think) need an SDK for this as far as I can tell, knowing the symbols Windows provides should be enough, we can create our own Import lib with that using some of the tools llvm provides.

And I know peeking at the sample that we seem to need a justfile so we can edit the binary after the fact to adjust some of the PE header fields. The latest lld-link seems to be able to make these adjustments itself from my experiments. Would it be possible to adjust the targets to use lld-link and make these adjustments itself to get rid of the justfile complication?

For context I've mostly been experimenting with targeting Win9x with new C++ compilers without needing an old (potentially gray area) CRT/compiler. Part of this is being interested in providing a more modern C Runtime (and eventually STL) and I had some interest in experimenting with Rust for this. I'm not sure how far I'd ever get with finalizing some of my work, but I thought maybe some of my experiments would be helpful for rust9x.

Totally understand though if I'm not on the right path though, sorry if you've tried/thought of some of this and I missed it 😅.

[seritools]

The Rust stdlib uses the msvcrt for at least the following functionality which would need to be reimplemented:

• initialization of statics (necessary pretty early IIRC)
• initialization and destruction of thread locals
• __CxxFrameHandler(3) for SEH, used for panic unwinding
• float functions (Reduce float C99 CRT requirements #51 minimizes the need)

We need a way to link against Kernel32 as well as probably a few other Win32 libraries. We don't (I think) need an SDK for this as far as I can tell, knowing the symbols Windows provides should be enough, we can create our own Import lib with that using some of the tools llvm provides.

Sure, rust provides this with raw-dylib support, generating the import libraries on-demand (the latest windows-rs crate vesion fully switched over to this as well). It does make it harder to integrate with unicows.lib currently as the import order will prevent the wrappers from applying.

And I know peeking at the sample that we seem to need a justfile so we can edit the binary after the fact to adjust some of the PE header fields. The latest lld-link seems to be able to make these adjustments itself from my experiments. Would it be possible to adjust the targets to use lld-link and make these adjustments itself to get rid of the justfile complication?

sounds reasonable, created #55 for that, thanks!

[playmer]

Appreciate the reply! Before I headed to sleep last night I found this pre-rfc post that went into fairly excruciating detail on those msvcrt dependencies, but hadn't gotten around to updating this post. I didn't realize Rust was relying on the SEH or atexit stuff, but I suppose it all makes sense. Unfortunate! Also seems like the STL/MSVC folks have given up on open sourcing VCRuntime, which would've made something like this far easier.

It does make it harder to integrate with unicows.lib currently as the import order will prevent the wrappers from applying.

Yeah I'll need to spend some time more fully understanding the unicows stuff, I wonder if there's some way we can make that easier to deal with. I'd heard of the raw-dylib work, but I didn't realize that's what it was doing, pretty neat! (Even if unicows throws a wrench into things.)

sounds reasonable, created #55 for that, thanks!

Awesome, this is what I was most interested in, that seemed like a rather annoying thing to deal with!

[seritools]

Yeah I'll need to spend some time more fully understanding the unicows stuff, I wonder if there's some way we can make that easier to deal with. I'd heard of the raw-dylib work, but I didn't realize that's what it was doing, pretty neat! (Even if unicows throws a wrench into things.)

The basic principle: link unicows.lib before kernel32.lib and others, so that whenever the linker resolves one of the SomeWindowsUnicodeFunctionW functions, the converter implementation from unicows is found first, which does an is_nt check, and then either passes the call along to the true W function if it is NT-based, or uses MultiByteToWideChar/WideCharToMultiByte to to the conversion from/to the active code page on 9x/ME.

---

Last time I looked into this I think the compiler passed the raw-dylib import libraries directly with the object files to the linker, meaning that we get the following link order:

1. object files for compilation unit a
2. raw-dylib-generated import libraries for a
3. object files for compilation unit b
4. raw-dylib-generated import libraries for b
5. unicows.lib and other link args and libraries
6. linker default libraries (if not /NODEFAULTLIB)

Note that any object file only searches entries after it (= or lower in the list).

For unicows.lib to work, it must be searched before any other libs exporting those symbols, however raw-dylib makes it hard to get the order right. The ideal order would be

1. object files for compilation unit a
2. unicows.lib
3. raw-dylib-generated import libraries for a
4. object files for compilation unit b
5. unicows.lib
6. raw-dylib-generated import libraries for b
7. other link args and libraries
8. linker default libraries (if not /NODEFAULTLIB)

A hacky way to make raw-dylib "work" in the presence of and SDK with import libraries would be to silently ignore raw-dylib for any of the wrapped dlls and let the normal import libraries fill those in, but that's certainly not the proper solution :)

[playmer]

Ah, thanks for the explanation, that all makes sense. I'll have to think on it.

I suppose the "easiest" solution (for some wide definition of easy) might be to adjust the macros it seems like Windows-rs is using to add raw-dylib attributes and conditionally point to unicows instead, depending on the symbol and a feature test. But that'd also likely wildly slow down compile times of the crate...

Of course, that's assuming that's even possible, I've never really touched Rust macros before. So I don't fully understand whats going on in there and that may also be a naive idea.

[seritools]

windows-rs is pretty easy -- just patch the linking style to not use raw-dylib, and just link the local/SDK versions of kernel32.lib etc.

I do want a solution that works with any raw-dylib import though, without additional patching ^^

[playmer]

Hmm, this is just from perusing the source, I need to get around to building and debugging rust9x on this machine, have you tried adjusting the pre_link_objects target property? I'd think that would increase the priority of unicows?

[seritools]

Pre-link comes before the crate code; it'd need so be somewhere before https://doc.rust-lang.org/beta/nightly-rustc/src/rustc_codegen_ssa/back/link.rs.html#2317