Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove dependency on shell32.dll #56568

Merged
merged 7 commits into from
Dec 14, 2018
Merged

Remove dependency on shell32.dll #56568

merged 7 commits into from
Dec 14, 2018

Conversation

notriddle
Copy link
Contributor

Closes #56510 if it works on MinGW (I've only tested it on MSVC).

@rust-highfive
Copy link
Collaborator

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 6, 2018
@Mark-Simulacrum
Copy link
Member

It'd be good to also run this on Windows a couple times to attempt to ascertain performance impact on our tests, though we could also just land it and see what AppVeyor looks like over the next dozen builds.

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned dtolnay Dec 6, 2018
@notriddle
Copy link
Contributor Author

notriddle commented Dec 6, 2018

micha@DESKTOP-IIQA1VP MINGW64 ~/IdeaProjects/rust (master)
$ ldd build/x86_64-pc-windows-msvc/stage1-std/x86_64-pc-windows-msvc/release/std.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffaa7f10000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffaa6cc0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffaa44d0000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffaa7510000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffaa56b0000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffaa7620000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffaa5750000)
        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ffaa6ef0000)
        USERENV.dll => /c/WINDOWS/SYSTEM32/USERENV.dll (0x7ffaa4150000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffaa52a0000)
        profapi.dll => /c/WINDOWS/System32/profapi.dll (0x7ffaa4240000)
        CRYPTBASE.DLL => /c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ffaa3b50000)
        bcryptPrimitives.dll => /c/WINDOWS/System32/bcryptPrimitives.dll (0x7ffaa4970000)

micha@DESKTOP-IIQA1VP MINGW64 ~/IdeaProjects/rust (master)
$ ldd ~/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/x86_64-pc-windows-msvc/lib/std-66ce4ddf5a45ca83.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffaa7f10000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffaa6cc0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffaa44d0000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffaa7510000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffaa56b0000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffaa7620000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffaa5750000)
        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ffaa6ef0000)
        SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x7ffaa5880000)
        cfgmgr32.dll => /c/WINDOWS/System32/cfgmgr32.dll (0x7ffaa47b0000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffaa52a0000)
        USERENV.dll => /c/WINDOWS/SYSTEM32/USERENV.dll (0x7ffaa4150000)
        shcore.dll => /c/WINDOWS/System32/shcore.dll (0x7ffaa5530000)
        combase.dll => /c/WINDOWS/System32/combase.dll (0x7ffaa7b90000)
        bcryptPrimitives.dll => /c/WINDOWS/System32/bcryptPrimitives.dll (0x7ffaa4970000)
        windows.storage.dll => /c/WINDOWS/System32/windows.storage.dll (0x7ffaa49f0000)
        shlwapi.dll => /c/WINDOWS/System32/shlwapi.dll (0x7ffaa7aa0000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ffaa6e40000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ffaa5100000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ffaa48d0000)
        profapi.dll => /c/WINDOWS/System32/profapi.dll (0x7ffaa4240000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ffaa53a0000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ffaa4800000)
        kernel.appcore.dll => /c/WINDOWS/System32/kernel.appcore.dll (0x7ffaa4270000)
        powrprof.dll => /c/WINDOWS/System32/powrprof.dll (0x7ffaa4290000)
        FLTLIB.DLL => /c/WINDOWS/System32/FLTLIB.DLL (0x7ffaa4260000)
        CRYPTBASE.DLL => /c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ffaa3b50000)
        IMM32.DLL => /c/WINDOWS/System32/IMM32.DLL (0x7ffaa7b00000)

@rust-highfive

This comment has been minimized.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! Naturally my biggest worry here is that this may not be compatible with the previous API call, so we need to be super careful. The documentation for CommandLineToArgvW says some things like:

However, if lpCmdLine starts with any amount of whitespace, CommandLineToArgvW will consider the first argument to be an empty string. Excess whitespace at the end of lpCmdLine is ignored.

but that may not be handled here?

I think this otherwise looks pretty equivalent though. Could this perhaps be tested locally more rigorously? Could the output of CommandLineToArgvW be compared to this implementation for a number of procedurally generated inputs?

src/libstd/sys/windows/args.rs Outdated Show resolved Hide resolved
src/libstd/sys/windows/args.rs Outdated Show resolved Hide resolved
src/libstd/sys/windows/args.rs Outdated Show resolved Hide resolved
src/libstd/sys/windows/args.rs Outdated Show resolved Hide resolved
src/libstd/sys/windows/args.rs Outdated Show resolved Hide resolved
@pitdicker
Copy link
Contributor

Does it help to compare the implementation in Wine and ReactOS? https://doxygen.reactos.org/da/da5/shell32__main_8c_source.html

@nagisa
Copy link
Member

nagisa commented Dec 7, 2018

Seems like a great thing to throw at a fuzzer of some sort for a day or two, before it is merged.

Among other things this would not only verify the correctness of the code, but also give considerable degree of confidence about the equivalence of the function(s).

@rust-highfive

This comment has been minimized.

@notriddle
Copy link
Contributor Author

notriddle commented Dec 8, 2018

Okay, here's a test harness that I put together to compare the behavior of the two (it is exhaustive, rather than random, so it should be pretty thorough).

https://gist.github.com/notriddle/dde431930c392e428055b2dc22e638f5

https://paste.gg/p/anonymous/47d6ed5f5bd549168b1c69c799825223

And, yeah, I've found several inconsistencies. The ReactOS code was also helpful for figuring out what was wrong; thanks @pitdicker !

@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@notriddle
Copy link
Contributor Author

ucs_2=[97, 32, 34, 1, 34, 34, 0]
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `["a", "\u{1}\""]`,
 right: `["a", "\u{1}"]`', .\test_parser.rs:215:25

Well, there's another thing I need to figure out.

@notriddle notriddle force-pushed the master branch 2 times, most recently from 2de79c1 to f6e7c37 Compare December 9, 2018 22:41
@bors

This comment has been minimized.

@notriddle
Copy link
Contributor Author

The exhaustive test now finishes without producing any errors!

@alexcrichton
Copy link
Member

It looks like some submodule updates may have snuck in here by accident? Otherwise this seems like it's likely good to go perhaps?

@notriddle
Copy link
Contributor Author

@alexcrichton Fixed.

@alexcrichton
Copy link
Member

@bors: r+

💯

@bors
Copy link
Contributor

bors commented Dec 11, 2018

📌 Commit 83fe6e4 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 11, 2018
@bors
Copy link
Contributor

bors commented Dec 11, 2018

⌛ Testing commit 83fe6e4 with merge a8aa87621b2bb1f806793c93b5eea25649b7e651...

@bors
Copy link
Contributor

bors commented Dec 11, 2018

💔 Test failed - status-appveyor

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 11, 2018
@rust-highfive

This comment has been minimized.

@alexcrichton
Copy link
Member

@bors: retry

  • CI automation hiccup

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 11, 2018
@kennytm
Copy link
Member

kennytm commented Dec 14, 2018

@bors p=1 retry

@bors
Copy link
Contributor

bors commented Dec 14, 2018

⌛ Testing commit 83fe6e4 with merge 7d03617...

bors added a commit that referenced this pull request Dec 14, 2018
Remove dependency on shell32.dll

Closes #56510 if it works on MinGW (I've only tested it on MSVC).
@bors
Copy link
Contributor

bors commented Dec 14, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 7d03617 to master...

@bors bors merged commit 83fe6e4 into rust-lang:master Dec 14, 2018
@arsing
Copy link

arsing commented Feb 22, 2019

Just wanted to say this is also useful for getting Rust binaries running inside nanoserver containers, since those don't have shell32.dll. Thanks!

(Might be worth advertising this in the 1.33 release post :) )

end += 1;
}
slice::from_raw_parts(lp_cmd_line, end as usize)
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to split this pointer manipulation into a separate function?

It looks like there's no actual unsafe code below this point, but you wouldn't know that without digging through the whole implementation.

MaximilianKoestler added a commit to MaximilianKoestler/druid that referenced this pull request Dec 11, 2020
Before this change, FileDialogOptions::starting_directory had not been
used on Windows and therefore had no influence on the starting directory
of a FileDialog window.

This has now been fixed.

The use of `SHCreateItemFromParsingName` makes it mandatory to
explicitly link against shell32.lib because this is not done
automatically since Rust 1.33.0.

See rust-lang/rust#56568 for details.
MaximilianKoestler added a commit to MaximilianKoestler/druid that referenced this pull request Dec 11, 2020
Before this change, FileDialogOptions::starting_directory had not been
used on Windows and therefore had no influence on the starting directory
of a FileDialog window.

This has now been fixed.

The use of `SHCreateItemFromParsingName` makes it mandatory to
explicitly link against shell32.lib because this is not done
automatically since Rust 1.33.0.

See rust-lang/rust#56568 for details.
MaximilianKoestler added a commit to MaximilianKoestler/druid that referenced this pull request Dec 11, 2020
Before this change, FileDialogOptions::starting_directory had not been
used on Windows and therefore had no influence on the starting directory
of a FileDialog window.

This has now been fixed.

The use of `SHCreateItemFromParsingName` makes it mandatory to
explicitly link against shell32.lib because this is not done
automatically since Rust 1.33.0.

See rust-lang/rust#56568 for details.
cmyr pushed a commit to linebender/druid that referenced this pull request Dec 16, 2020
* Respect starting directory for dialogs on Windows

Before this change, FileDialogOptions::starting_directory had not been
used on Windows and therefore had no influence on the starting directory
of a FileDialog window.

This has now been fixed.

The use of `SHCreateItemFromParsingName` makes it mandatory to
explicitly link against shell32.lib because this is not done
automatically since Rust 1.33.0.

See rust-lang/rust#56568 for details.

* Fix: Use winapi feature instead of build.rs

As it turns out, the winapi crate already exposes shell32.lib via a
cargo feature, so there is no need to link it manually.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.