Rust, Windows, and MSVC

[retep998]

High priority tasks

• Either make kind=static-nobundle stable, or change kind=static to behave like kind=static-nobundle.
• Add support for linking the debug CRT.
• Handle linking in a manifest. Need to re-fix Windows manifest embedding. rust#11207
• Support linking to object files, and resource files. Extended linking kinds #1489
• Allow rustc to emit idata sections instead of depending on import libraries. Produce idata content for dll/dylib import on windows rust#30027
• Mechanism for dealing with Structured Exception Handling. Add some mechanism for catching structured exceptions on Windows  rust#38963
• Improve handle inheritance when spawning processes. Consider different way of inheriting handles in child processes on Windows rust#38227
• Make env_clear actually work. env_clear does not work on Windows rust#31259
• Stop messing up console handling. Windows / Colors are displayed as codes cargo#4722 WinConsole's tty check is inaccurate Stebalien/term#62

Lower priority tasks

• Improve the quality of PDB debug info. https://github.com/Microsoft/microsoft-pdb
• Support inter-crate dllimport properly, or just get rid of the dylib crate type. Correctly handle dllimport on Windows rust#27438
• Fix library creation so that libraries compiled by cl with /GL can be linked properly. Or just stop kind=static from bundling. MSVC: support LTCG native libraries in rlibs rust#26003
• Improve the location of metadata for DLLs. Metadata for DLLs should actually go in the LIB import library on Windows rust#29511
• Removed unused import libraries in the -msvc distribution. -msvc distribution has unused import libraries rust#31816
• Support the calling convention for methods, which is different than the calling convention for functions. Need calling convention for stdcall methods (different from functions!) #1342
• Provide an option to choose the target NT version.
• Support targeting drivers.
• Support targeting store apps.
• Deprecate the old makefiles. run-make is still hanging around.
• Use the correct extension for msvc object files. --emit=obj for Windows msvc producing .o instead of .obj rust#37207
• Make cross compilation to Windows, or between Windows architectures easier.
• Make MinGW static libraries use the correct extension. Windows: Static libraries should end with .a not .lib when using MinGW/GCC rust#43749
• Make Command work better. Command::spawn has weird rules for finding binaries on Windows rust#37519
• Automatic long path handling. Automatically insert \\?\ where needed on Windows rust#32689
• Add way to re-export C symbols. https://github.com/rust-lang/rust/issues/36342

Completed tasks

• Support linking to system static libraries. Implement kind="static-nobundle" (RFC 1717) rust#38426
• Add support for statically linking the CRT. Can't statically link MSVC runtime libc#290 Choosing which CRT to link to #1684 Enable customizing the linkage of a platform's C runtime #1721
• Provide an option to choose the subsystem. Windows subsystem support #1665
• Support FFI dllimport properly. Use #[link(kind)] to fix imports from native libs on Windows #1717
• Variable and type information in PDB debug info.
• Support dllexport. Add support for DllExport on Windows rust#7196
• Emit PDB debug info on msvc. Emit windows-specific debug info rust#19533
• Get rid of the dependency on libgcc and use native/llvm unwinding stuff.
• Teach librustc_back how to invoke link.exe.
• Add code to figure out where MSVC and the Windows SDK is installed.
• Upgrade the Rust build system to be able to build code using the MSVC toolchain rather than the GNU toolchain.
• Add code so that the Rust standard library can be built using only APIs available on XP or Vista. Rethink supporting Windows XP rust#12842
• Do all IO using WinAPI rather than libc, since libc is just a layer of overhead on top of WinAPI anyway.
• Fix the naming of static libraries. Windows: Static libraries should end with .lib not .a when using the MSVC ABI install rust#29508
• Eliminate dependency on gcc for building compiler-rt for msvc targets.
• Implement unwinding MSVC: Implement 32-bit Unwinding rust#25869
• Make it easy to install multiple targets. Handled by rustup.rs.
• Upload Rust docs for Windows to the website, so it isn't just linux docs up there. std::os::windows missing on http://doc.rust-lang.org/nightly/std/os/ rust#24658
• Provide fallback implementations to missing APIs on XP/Vista so that code will still run correctly and not panic. Investigate fallback implementations on Windows XP rust#26654
• Make ASLR work on mingw. use ASLR on Windows rust#16514 use high entropy ASLR on 64-bit Windows rust#16593

Wishlist

• Use lld for cross compilation to Windows with a new pure Rust target without any CRT bits at all. migrate to the LLVM toolchain rust#9367

Related links

• Make Command behave better. Command::spawn has weird rules for finding binaries on Windows rust#37519

rust-lang/rust#1768

[retep998]

cc @brson @ricky26 @vadimcn

[brson]

Thanks @retep998. This is going to be a big focus this year and we need to get clear on what the goals are.

[Manishearth]

cc me

[alexchandel]

The best solution for msvcrt.dll may be to statically link a CRT.

[Diggsey]

Why does rust require a CRT at all on windows? It's rust not C, it can (and AFAIK, does in most places) just call windows APIs directly?

Also, which license prevents open source projects from using the redistributable msvcrt.dlls?

[retep998]

@Diggsey GPL does not allow you to link GPL code with proprietary code, unless it is a system library in which case there is an exception for that. Since there's no GPL compatible CRTs on Windows, this means the only option for such software is to link dynamically to the system msvcrt.dll which is a system library and thus falls under the exception. Even though Rust is not C, if it statically links to any C code that relies on the CRT, like jemalloc, then it needs to link to the CRT and use the CRT entry points.

[Diggsey]

@retep998 Thanks for the explanation, although after doing some reading, it seems that the "system library" exception explicitly includes compiler runtimes, from the GPL:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

And apparantly other people are interpretting it this way:
http://lists.gnu.org/archive/html/bug-gnu-utils/2004-01/msg00124.html

So as long as you aren't actually distributing msvcrt.dll you could still be GPL compatible.

Since the redistributable can be freely downloaded from the microsoft site, it should be possible to prompt the user to install that first as part of any install process?

[retep998]

@Diggsey Given that, then we should at least be able to use other versions of the CRT so long as we link dynamically.
I'd still like to have the option to statically link to the CRT for software that isn't tied down by GPL though.

[vadimcn]

I am getting very confused here... What does msvcrt.dll have to do with GPL??

[retep998]

@vadimcn GPL forbids distribution of software that falls under GPL if it has any components which are not GPL-compatible, unless they are system libraries which are not distributed with the software. Which means GPL software has to be dynamically linked to msvcrt and cannot be distributed with the CRT redistributable.

[Diggsey]

@vadimcn Programs built using VC++ link to msvcrt.dll for their C runtime library, which is the "correct" runtime library to use for new programs: because it's versioned it means microsoft can release new versions without breaking all existing programs.

However, programs built using the mingw toolchain link to msvcrt.dll, which is unversioned and only exists for backwards compatibility reasons. The reason is that msvcrt.dll comes preinstalled on all windows machines, whereas versioned crts must be installed separately, and the GPL prohibits you from distributing the proprietary msvcrt.dll with GPL software.

Ideally there would be an open source C runtime for windows which would solve all the problems, but AFAIK that doesn't exist.

[vadimcn]

@retep998: I kinda doubt that's the reason. All GCC libs, that Rust binaries are linked with, are covered by the GCC runtime library linking exception.
Edit: And I think the same goes for a lot of c++ programs compiled with GCC.