Windows library loading #3493

ChrisDenton · 2023-09-28T14:34:19Z

When loading DLLs, the loader uses a standard search order that may include the application directory. To ensure the right DLLs get loaded, this PR makes sure to force DLLs to be loaded from system32. This is done using /DEPENDENTLOADFLAG msvc linker option. However this only works for Windows 10 RS1 and higher (which admittedly is almost all Windows 10 users) and will have no effect on earlier OSes. So as a fallback we use the delay load mechanism to get the DLLs loaded at runtime so that we can use SetDefaultDllDirectories to affect DLL loading. Note that DLLs on the system's list of "Known DLLs" are always loaded from system32 so don't need to be delay loaded this way.

cuviper · 2023-09-28T17:31:33Z

src/bin/rustup-init.rs

+    use winapi::um::libloaderapi::{SetDefaultDllDirectories, LOAD_LIBRARY_SEARCH_SYSTEM32};
+    // Default to loading delay loaded DLLs from the system directory.
+    unsafe {
+        let result = SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32);


The docs for this function seem to say that it's not directly available on Win7:

Windows 7, Windows Server 2008 R2, Windows Vista and Windows Server 2008: To call this function in an application, use the GetProcAddress function to retrieve its address from Kernel32.dll. KB2533623 must be installed on the target platform.

So... how did this call work? Are we not setting up the build in a Win7 mode? (until we actually drop that support)

Hm, this works in my Win7 VM. Presumably the advice to use GetProcAddress is because the old SDK libraries didn't include them and they require an OS update to work. You get an error message if the OS update is not installed but it's quite easy to find answers on the web pointing to the necessary update. I think it's ok to require users to have installed security updates, especially for such an old OS.

But yes, Windows 7 hasn't been tested in CI in a long time. The same goes for all rustlang repos I'm aware of.

So the Rust 1.72 blog post had this text:

In a future release we're planning to increase the minimum supported Windows version to 10. The accepted proposal in compiler MCP 651 is that Rust 1.75 will be the last to officially support Windows 7, 8, and 8.1. When Rust 1.76 is released in February 2024, only Windows 10 and later will be supported as tier-1 targets. This change will apply both as a host compiler and as a compilation target.

How do you think those changes (5 months from now) should interact with this code?

It won't change anything until rust's minimum supported version is Windows 10 RS1 (aka 1607). I can add a similar comment to the one in the build script and note how they're related.

djc

I'm curious, is there a particular motivation for doing this now?

(The rustup project isn't doing great on institutional memory right now, so sorry if I'm asking dumb questions, just trying to make sure we have -- and document -- sufficient state for this going forward.)

djc · 2023-09-29T07:31:56Z

build.rs

+
+    let target_os = env::var("CARGO_CFG_TARGET_OS");
+    let target_env = env::var("CARGO_CFG_TARGET_ENV");
+    if Ok("windows") == target_os.as_deref() && Ok("msvc") == target_env.as_deref() {


Nit: please switch the constants with the run-time values, which seems more idiomatic. I'd also like to the invert the condition here to do an early return for non-Windows-MSVC targets.

Next, please add some comments here similar to the PR description to describe what problem we're trying to solve here.

Do you mean something like:

if target_os.as_deref() != Ok("windows") && target_env.as_deref() != Ok("msvc") { return; }

djc · 2023-09-29T07:34:04Z

build.rs

+
+        // # Turn linker warnings into errors
+        //
+        // Rust hides linker warnings meaning mistakes may go unnoticed.


Are there generally good reasons to hide these warnings "upstream" (I guess in rustc)? Or is there a good reason that rustup's behavior, in particular, should be different from the default?

Personally I think rustc should not be hiding linker warnings but I'm not trying to litigate that here. However, the reason I think it's especially important in this case is that we're directly and explicitly setting some linker arguments and it would not be good if problems with them (e.g. typos) were being silently ignored.

djc · 2023-09-29T07:34:26Z

build.rs

+        // # Delay load
+        //
+        // Delay load dlls that are not "known DLLs".
+        // Known DLLs are always loaded from the system directory whereas other DLLs


Do you have some reference documentation links for this?

Best is https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching which mentions how it affects search order and where to find the list of known DLLs. Unfortunately the list itself is not documented.

djc · 2023-09-29T07:35:23Z

src/bin/rustup-init.rs

+/// rustup-init in the user's download folder.
+#[cfg(windows)]
+pub fn pre_rustup_main_init() {
+    use winapi::um::libloaderapi::{SetDefaultDllDirectories, LOAD_LIBRARY_SEARCH_SYSTEM32};


Maybe orthogonal, but should we start using windows-sys here?

I'm surprised there's not an issue for that already but I do think that's beyond the scope of this PR.

djc · 2023-09-29T07:37:04Z

src/bin/rustup-init.rs

+    use winapi::um::libloaderapi::{SetDefaultDllDirectories, LOAD_LIBRARY_SEARCH_SYSTEM32};
+    // Default to loading delay loaded DLLs from the system directory.
+    unsafe {
+        let result = SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32);


So the Rust 1.72 blog post had this text:

In a future release we're planning to increase the minimum supported Windows version to 10. The accepted proposal in compiler MCP 651 is that Rust 1.75 will be the last to officially support Windows 7, 8, and 8.1. When Rust 1.76 is released in February 2024, only Windows 10 and later will be supported as tier-1 targets. This change will apply both as a host compiler and as a compilation target.

How do you think those changes (5 months from now) should interact with this code?

ChrisDenton · 2023-10-01T15:16:44Z

Ok, I've updated the comments based on the review. To avoid repeating myself, I only added a short comment to src/bin/rustup-init.rs but referenced build.rs for further info.

djc · 2023-10-02T07:45:13Z

build.rs

+    for dll in delay_load_dlls {
+        println!("cargo:rustc-link-arg-bin=rustup-init=/delayload:{dll}.dll");
+    }
+    println!("cargo:rustc-link-arg-bin=rustup-init=delayimp.lib");


AFAICT delayimp.lib is not mentioned on the linked page. Do you have a reference for this/why this is necessary?

Ah, see the documentation for the delayload linker option. I've added a comment that links to it.

ChrisDenton · 2023-10-04T02:57:03Z

I'm not sure why some checks are failing after adding a comment. The failures look entirely unrelated in any case.

djc

LGTM, thanks!

djc · 2023-10-04T08:27:32Z

It looks like the failures happen because we run clippy from beta? It's a little hard to tell because the CI setup is pretty complicated...

djc · 2023-10-05T08:27:04Z

The CI issues should be fixed after merging #3497, would you mind rebasing so we can get a clean CI run?

build.rs

ChrisDenton · 2023-10-05T13:32:18Z

Btw, sorry for the noisy force pushes, I committed the change on github then accidentally overwrote the github state with my local state so had to manually reapply 😳

cuviper reviewed Sep 28, 2023

View reviewed changes

djc reviewed Sep 29, 2023

View reviewed changes

djc reviewed Oct 2, 2023

View reviewed changes

ChrisDenton force-pushed the system32 branch from 5e04541 to 5c44432 Compare October 4, 2023 02:49

djc approved these changes Oct 4, 2023

View reviewed changes

ChrisDenton force-pushed the system32 branch from 5c44432 to 6196475 Compare October 5, 2023 11:37

djc requested a review from rami3l October 5, 2023 13:00

rami3l reviewed Oct 5, 2023

View reviewed changes

build.rs Outdated Show resolved Hide resolved

ChrisDenton force-pushed the system32 branch from 1bc4661 to a1191df Compare October 5, 2023 13:23

Windows: Load DLLs from system32

fd54f3c

ChrisDenton force-pushed the system32 branch from a1191df to fd54f3c Compare October 5, 2023 13:26

rami3l approved these changes Oct 5, 2023

View reviewed changes

rami3l merged commit be2c44c into rust-lang:master Oct 5, 2023
16 checks passed

rami3l mentioned this pull request Jan 29, 2024

dist: bump rustup version to 1.27.0 #3653

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows library loading #3493

Windows library loading #3493

ChrisDenton commented Sep 28, 2023

cuviper Sep 28, 2023

ChrisDenton Sep 28, 2023 •

edited

djc Sep 29, 2023

ChrisDenton Sep 29, 2023

djc left a comment

djc Sep 29, 2023

ChrisDenton Sep 29, 2023

djc Sep 29, 2023

djc Sep 29, 2023

ChrisDenton Sep 29, 2023

djc Sep 29, 2023

ChrisDenton Sep 29, 2023

djc Sep 29, 2023

ChrisDenton Sep 29, 2023

djc Sep 29, 2023

ChrisDenton commented Oct 1, 2023

djc Oct 2, 2023

ChrisDenton Oct 4, 2023

ChrisDenton commented Oct 4, 2023

djc left a comment

djc commented Oct 4, 2023

djc commented Oct 5, 2023 •

edited

ChrisDenton commented Oct 5, 2023

Windows library loading #3493

Windows library loading #3493

Conversation

ChrisDenton commented Sep 28, 2023

Choose a reason for hiding this comment

ChrisDenton Sep 28, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

djc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChrisDenton commented Oct 1, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChrisDenton commented Oct 4, 2023

djc left a comment

Choose a reason for hiding this comment

djc commented Oct 4, 2023

djc commented Oct 5, 2023 • edited

ChrisDenton commented Oct 5, 2023

ChrisDenton Sep 28, 2023 •

edited

djc commented Oct 5, 2023 •

edited