Embed manifest resource using MSVC toolchain, to avoid installer heuristics. #16
Conversation
…istics. See comments on nabijaczleweli#11 for more information. Fixes nabijaczleweli#11 Fixes nabijaczleweli#14
| if cfg!(target_env = "msvc") { | ||
| // We'll create a `.res` file here, but name it as `.lib`, | ||
| // so that it can be found and linked correctly. | ||
| // Yes, `.res` may be linked directly, like `.lib` and `.o`. |
There was a problem hiding this comment.
I don't know why, but I know it works:)
|
Works on GNU too, nice work |
|
By the document, the msvc linker will recognize the binary resource file, convert it to a COFF object file and link it to the final binary automatically. |
|
Another case of counter-intuitive specialcasing by M$, :goodjob: |
|
Well, on Windows, it is a common practice that include the compiled resources inside the final PE binary, so I think what MSVC's link.exe did here makes sense. Yeah, it's a bit anti-intuitive for Unix people since the PE file could include icons (which is binary resource, IMO), but the ELF/Mach-O can't. Reference: Comparison of executable file formats on Wikipedia, note the "Icon" part. |
|
An useful feature, not counter-intuitive, IMHO. |
|
Useful: yes, counter-intuitive: slightly, since you get an object file you can link to/ |
I tested it on Windows 10 + MSVC 2015. The manifest resource was linked into .exe, which don't requires administrator privilege to be run anymore. (I didn't touch existing code for gnu toolchain, it will continue works, if it did works.)
See comments on #11 for more information.
Fixes #11
Fixes #14
@nabijaczleweli r?