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. rust-lang/rust#11207
• Support linking to object files, and resource files. #1489
• Allow rustc to emit idata sections instead of depending on import libraries. rust-lang/rust#30027
• Mechanism for dealing with Structured Exception Handling. rust-lang/rust#38963
• Improve handle inheritance when spawning processes. rust-lang/rust#38227
• Make env_clear actually work. rust-lang/rust#31259
• Stop messing up console handling. rust-lang/cargo#4722 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. rust-lang/rust#27438
• Fix library creation so that libraries compiled by cl with /GL can be linked properly. Or just stop kind=static from bundling. rust-lang/rust#26003
• Provide fallback implementations to missing APIs on XP/Vista so that code will still run correctly and not panic. rust-lang/rust#26654
• Improve the location of metadata for DLLs. rust-lang/rust#29511
• Removed unused import libraries in the -msvc distribution. rust-lang/rust#31816
• Support the calling convention for methods, which is different than the calling convention for 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.
• Make ASLR work on mingw. rust-lang/rust#16514 rust-lang/rust#16593
• Use the correct extension for msvc object files. rust-lang/rust#37207
• Make cross compilation to Windows, or between Windows architectures easier.
• Make MinGW static libraries use the correct extension. rust-lang/rust#43749
• Make Command work better. rust-lang/rust#37519
• Automatic long path handling. rust-lang/rust#32689
• Add way to re-export C symbols. rust-lang/rust#36342

Completed tasks

• Support linking to system static libraries. rust-lang/rust#38426
• Add support for statically linking the CRT. rust-lang/libc#290 #1684 #1721
• Provide an option to choose the subsystem. #1665
• Support FFI dllimport properly. #1717
• Variable and type information in PDB debug info.
• Support dllexport. rust-lang/rust#7196
• Emit PDB debug info on msvc. rust-lang/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. rust-lang/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. rust-lang/rust#29508
• Eliminate dependency on gcc for building compiler-rt for msvc targets.
• Implement unwinding rust-lang/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. rust-lang/rust#24658

Wishlist

• Use lld for cross compilation to Windows with a new pure Rust target without any CRT bits at all. rust-lang/rust#9367

Related links

• Make Command behave better. rust-lang/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.

[retep998]

@vadimcn The problem is not the GCC libraries we use, but rather if someone wants to build GPL software on Windows using Rust.

[gkoz]

@retep998

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.

Where does it make any distinction about whether you distribute the "system libraries"?

[kini]

IIRC in this context the term "system library" is just conservatively interpreted to mean "library that is so prevalent on systems that it need not be shipped", so shipping a library might cause it to be viewed as not being a "system library" and therefore not subject to the exemption.

[gkoz]

I can see it in the GPLv2 now. So discussing the GPL isn't very meaningful without specifying its version it seems... The language there is a bit ambiguous (is the second "component" the same as the first?):

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.

[alexchandel]

@retep998 Just to be clear, it is jemalloc that drags in the msvcrt dependency?

[Manishearth]

Perhaps we should break the issue into chunks? I believe jemalloc can be disabled, so we can try to get a working version of MSVC Rust sans jemalloc and debuginfo, then go on to jemalloc, then debuginfo.

[ricky26]

From a technical point of view I managed to build a rust program into an exe using link.exe and the MSVC toolchain in LLVM (it's a hack, but it's in my branch listed above) - there were a couple of things I didn't expect going in:

• The build system needs some serious adaptation to support MSVC - my hacked branch still uses a compiler built with MinGW which uses the LLVM toolchain in MSVC mode (which is more than a little convoluted, but not too detrimental to an end user). At the moment I've been compiling the bits of the rust runtime with cl.exe on the command-line by hand.
• The exception handling support for LLVMxMSVC at the moment results in calls to libunwind-style personality functions - I think ldc has a hack for this which involves walking the DWARF exception records manually at runtime and then dispatching via Win32 exception handling but I've not had any luck (or much time) getting it working in my hacked branch.

[retep998]

In VS 2015, the CRT is being refactored into a VC runtime and a Universal CRT.
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

[abonander]

I have already found a need for integration with Windows resource scripts. When creating executables that link to Common Controls, it's necessary to create a manifest file that tells what version of the comctl32.dll assembly to load. This can be done manually, but it would be a lot more convenient to automate it with a resource script. However, it may be a more appropriate feature for Cargo than the Rust compiler itself.

Also, it would be nice to be able to add icon files directly to executables in Windows, which I believe is facilitated by resource scripts as well.

[alexcrichton]

I've reorganized the description of this issue slightly and am going to be using it as a sort of metabug to track sub-bugs.

[retep998]

Based on a binary that @alexcrichton sent me that was built using the new msvc target, it seems that the CRT is being statically linked. Considering we are explicitly linking msvcrt.lib which should be a dynamically linked CRT, something is weird.

[retep998]

I just disassembled both msvcr120.dll and msvcrt.dll and both of them had a memcpy which was defined in terms of memmove which was not just a shim to some other DLL but had the full fancy implementation with the vectorized branches and whatnot.

[retep998]

Regarding the universal CRT on Windows XP, it should entirely be possible to install the universal CRT on XP and then run programs that link against it on XP (so long as they passed the correct /SUBSYSTEM to the linker and don't reference symbols that don't exist on XP).

[alexchandel]

@retep998 Yeah it's quite possible this DLL is ancient, and unlike the others.

VC6 is the least common denominator, though it's only 17 years old. Sadly it still sees widespread use in certain areas, thanks to the fact that MS goes out of their way not to break it. I don't plan on compiling LLVM with it; I'm using it only for its libraries, because LLD is capable of cross-linking rustc output against it. But I'm trying with the Win10 ones again.

So it's possible to successfully link against missing symbols from Rust when targeting XP, using MS's currently supported libraries?

GetUserProfileDirectory hasn't given me trouble, just the two I mentioned. But it's possible they're just not in VC6's kernel32.lib.

Update: so, linking rustc's output with VC6's msvcrt.dll and Win10's kernel32.lib & friends worked and produces an executable that runs on XP & win10. I'm running this on OS X 10.10, and link.exe is just a symlink to lld, so if would could fix rust-lang/rust#29126 (as in just pass "/OPT:REF" "/OPT:ICF" instead of "/OPT:REF,ICF") then that would mean rustc + lld can natively cross-compile (at least something) from OSX to Windows.

[retep998]

So it's possible to successfully link against missing symbols from Rust when targeting XP, using MS's currently supported libraries?

You can successfully link against any symbol so long as some import library exports it. The program will still crash at runtime if the specified DLL doesn't exist or it doesn't have that symbol. Telling link to target XP via /SUBSYSTEM:CONSOLE,5.01 or /SUBSYSTEM:CONSOLE,5.02 just tells it to not use newer PE features which XP doesn't support. You can still reference symbols that XP doesn't have and crash at runtime. Rust's libstd does not link against any symbols which XP does not have, however it still depends on some symbols for some functionality, so it dynamically loads them using LoadLibrary and panics or resorts to a fallback implementation if it fails to load the symbol.

The recommended way to cross-compile to Windows is using the MinGW toolchain as several people have done it successfully, although it is poorly documented. Feel free to talk to @steveklabnik about getting better documentation on the cross-compiling fiasco.

[Diggsey]

@alexchandel

@Diggsey Actually I'm having trouble statically linking the crt with i686-pc-windows-msvc; it defaults to dynamically linking msvcrt even though I didn't specify -C prefer-dynamic, and rustc doesn't accept a -C prefer-static to prefer static system libraries.

You can distribute the universal CRT without statically linking: Microsoft recently caved to popular demand and added support for distributing the universal CRT in DLL form alongside your application, in addition to the other methods (windows update or separate UCRT installer). The only requirement is that the DLLs be in the same directory as your executable.

[alexchandel]

@retep998 I've never had success crossing from OSX to 32bit windows via MinGW. The lack of SEH support (I don't think it's acceptable to pass around a libgcc_s_dw2-1.dll with your executable) combined with people's love for exceptions gives me segfaults, plus I dislike the idea of installing a binutils for every target I need. Moreover, Rust's i686-pc-windows-gnu target ships a Windows binary for gcc.exe which can't be natively run on OSX, and LLD doesn't yet play nicely with MinGW's libraries (this week it's giving the error: -aligncomm:_hInst,2 is not allowed in .drectve).

But this is working well. CPATH="$HOME/i686-pc-windows-msvc-w10/include:$HOME/i686-pc-windows-msvc-vc6/include" clang -target i686-pc-windows-msvc -c ... and LIB="$HOME/i686-pc-windows-msvc-w10/lib;$HOME/i686-pc-windows-msvc-vc6/lib" link.exe ... (where link.exe is a symlink to LLD) can compile a C Win32 GUI application, and the latter LLD invocation can link a console-based Rust program that grabs screenshots and sends keyboard/mouse events.

The trouble was really figuring out which of the infinite permutations would work. I didn't try, but linking against UCRT instead of VC6 may work too. It's too bad Microsoft can't just provide a minimalist zip file that we could redistribute for cross-compiling: the VS2015 download I extracted the Win10 libraries & headers from was multiple gigabytes of bloat.

[alexchandel]

@Diggsey That's pretty amusing. They deserve all the trouble they're enduring and more for not having included a stable C library in their os 30 years ago. It's a "code smell" to me to deliver shared objects alongside executables, especially when they're things like the standard C library, but I managed to link against the evil msvcrt.dll instead via VC6. Although I suspect that manually invoking the linker would let me statically link against the UCRT...

[Diggsey]

@alexchandel

They deserve all the trouble they're enduring and more for not having included a stable C library in their os 30 years ago.

Windows has always included a stable C library, the problems stem from the fact that it must maintain binary compatibility across all versions of windows, and that it combines both the compiler runtime and the language runtime in one.

The compiler runtime must, necessarily, be updated for each new version of the compiler. That means the entire runtime must be versioned according to the compiler version, so frequently you need a runtime that is newer than the version of windows on which you are running. This means you can't rely on it being pre-installed, and that is grounds for discounting it as a "core system component", which makes it incompatible with the GPL.

The UCRT solves the problem by splitting the compiler runtime and C runtime into separate DLLs, which allows the C runtime part to be the same regardless of the compiler version.

Linux doesn't have the problem only because it doesn't attempt to maintain binary compatibility for programs which rely on shared libraries: you can't just copy a program from one linux machine to another and have any guarantee of it working, unless absolutely everything is statically linked and the kernel versions match. For platforms where most software is distributed only in binary form, this obviously can't work.

[alexchandel]

@Diggsey Then it is not stable. It is an incorrect presumption that the compiler runtime "must, necessarily, be updated for each new version". I can use an (x86) crt1 Mach-O crosscompiled for OS X 10.1 with El Capitan's libSystem and a bleeding edge 3.8trunk clang with absolutely no problems whatsoever. In fact I just linked a Rust program with it.

Linux doesn't have the problem only because it doesn't attempt to maintain binary compatibility for programs which rely on shared libraries:
you can't just copy a program from one linux machine to another and have any guarantee of it working, unless Moderately everything is statically linked and the kernel versions match.

This is so false that I don't even. Linux famously does not break userspace, so kernel versions aren't generally a problem. Moreover, except for rare cases, glibc maintains backwards compatibility. As does OS X, which also guarantees libSystem compatibility, and strives for (but does not guarantee) syscall compatibility. You can play the ancient x86 build of StarCraft, linked against 10.2's libSystem.dylib, on 10.11. It actually runs better than the wine version. Obviously there is no guarantee, to use your word, if there are missing sos or if Apple decided not to ship some dylib anymore. But you are quite mistaken to assume that other platforms are as broken as Windows.

[Diggsey]

@alexchandel

Then it is not stable. It is an incorrect presumption that the compiler runtime "must, necessarily, be updated for each new version".

The compiler runtime is completely different from the C runtime... Obviously using an old CRT will work, that's the whole point: the CRT has a stable API, the compiler runtime does not. Windows does have a stable C runtime, because as long as you only use the C runtime parts (of any version of msvcrt) it will continue to work forever. The part that changes is the compiler runtime.

This is so false that I don't even.

Obviously there is no guarantee.

Make up your mind, either there is a guarantee or there's not. If there isn't a guarantee, than what I said is true. Windows does provide backwards compatibility guarantees, to a fault.

You seem to be missing the important distinction between should work, and does work.

[alexchandel]

@Diggsey

Make up your mind, either there is a guarantee or there's not.

If you examine the rest of that sentence, instead of cutting it out for cute rhetorical purposes like "Make up your mind", you'd see I'm referring to dylibs that are not guaranteed, unlike libSystem. libSystem is guaranteed, and does work. (And consulting Apple's dev site suggests that they don't remove dylibs after all; just the headers so new apps can't be compiled against them.) The point stands.

The compiler runtime is completely different from the C runtime...

Wrong for clang/libSystem. There are (non-MS) platforms that do not make these distinctions, and the existence of the former demonstrates that the latter should not be necessary. Binary compatibility does not have to be an issue, and distinguishing "compiler runtimes" from other stable components is meaningless or inconsequential on platforms that don't suffer from the nuanced design flaws of Windows. Not everyone is forced to accept MS's terminology, nor their justifications for instability.

And just to hammer the point home (and because you clearly misunderstood this), the functions in Apple's crt0/crt1 correspond to what MS calls the "compiler runtime", not what MS calls the "CRT" which corresponds to (part of) Apple's libSystem: I compiled an el cap binary against the current "CRT" with a HEAD compiler and a Cretaceous era "compiler runtime", because these libraries are permanently stable on non-broken platforms.

[retep998]

It's worth noting that crt0.o is statically linked and so there's no stability concerns there. Microsoft puts some of the stuff which would typically be in crt0.o in a DLL instead, and as such that ends up having to be versioned with each compiler version. If Microsoft didn't version those bits, then they'd be forced to never change them and maintain them backwards compatibly for a very long time.
Look at these functions that are in vcruntime140.dll. Do they look like the kind of things you'd want to keep stable?

__AdjustPointer
__BuildCatchObject
__BuildCatchObjectHelper
__C_specific_handler
__C_specific_handler_noexcept
_CreateFrameInfo
__current_exception
__current_exception_context
__CxxDetectRethrow
__CxxExceptionFilter
__CxxFrameHandler
__CxxFrameHandler2
__CxxFrameHandler3
__CxxQueryExceptionSize
__CxxRegisterExceptionObject
_CxxThrowException
__CxxUnregisterExceptionObject
__DestructExceptionObject
_FindAndUnlinkFrame
__FrameUnwindFilter
_get_purecall_handler
_get_unexpected
__GetPlatformExceptionInfo
__intrinsic_setjmp
__intrinsic_setjmpex
_is_exception_typeof
_IsExceptionObjectToBeDestroyed
_local_unwind
__NLG_Dispatch2
__NLG_Return2
__processing_throw
_purecall
__report_gsfailure
__RTCastToVoid
__RTDynamicCast
__RTtypeid
_set_purecall_handler
_set_se_translator
set_unexpected
_SetWinRTOutOfMemoryExceptionCallback
__std_exception_copy
__std_exception_destroy
__std_terminate
__std_type_info_compare
__std_type_info_destroy_list
__std_type_info_hash
__std_type_info_name
__telemetry_main_invoke_trigger
__telemetry_main_return_trigger
__TypeMatch
__uncaught_exception
__uncaught_exceptions
__unDName
__unDNameEx
unexpected
__vcrt_GetModuleFileNameW
__vcrt_GetModuleHandleW
__vcrt_InitializeCriticalSectionEx
__vcrt_LoadLibraryExW

[alexchandel]

@retep998 Hah that's quite a good list. But OS X puts all of those in a DLL too. For example for the C++ exception stuff, /usr/lib/system/libunwind.dylib, which is linked behind-the-scenes by libSystem, is permanently stable, and contains similar OS X functions. Who knows how hard it is to keep it stable, but Apple does it. /usr/lib/libc++.dylib also has some exception things too. crt0.o/crt1.o have only a handful of symbols like EH_Frame1, ___keymgr_dwarf2_register_sections, func.eh, and the entry point.

Edit: But crt0.o/crt1.o are never even used on OS X. Since 10.7 it's been part of libSystem.dylib, which is dynamically linked, and executables compiled for 10.7+ simply rely on the (permanently stable) entry point in there. But even so, the fact that I can statically link against an old, pre-10.7 version of crt0.o with a different compiler and a different libSystem shows that it, too, is permanently stable.

There is simply no justifiable reason for what Microsoft did.

[brson]

@retep998 What's the state of this metabug? Looks a bit stale. Can remaining items be moved to rust-lang/rust as individual bugs?

[brson]

I went ahead and dropped the P-high tag since this bug is inactive.

[retep998]

I do update the issue every so often. Feel free to point out anything you feel should be added or was completed and I'll update the list.

[Diggsey]

What's left to do re: the first wishlist item? 😜

[retep998]

I'm not sure. I'll have to try debugging a Rust program and see how good the local variable info is.

[briansmith]

I'm not sure. I'll have to try debugging a Rust program and see how good the local variable info is.

I have noticed when debugging with MSVC's debugger, stepping into any line that uses try!(...) makes MSVC confused until you step again. It seems like it steps into the macro's code, but it does not nagivate the editor to the macro's code. Thus, debugging pretty much everything is a very confusing experience.

[alexchandel]

All of the "Remaining tasks" still appear unfinished, so presumably it's still active. Perhaps the metabug itself could be moved to rust-lang/rust.

[alexchandel]

@retep998 I've heard that the COM ABI is slightly different from the usual Win32 ABI, in ways that resulted in MSVC's C (not C++) compiler historically not being able to call it correctly. Is this true / does rustc need to do anything to support it?

[retep998]

@alexchandel stdcall for C++ methods is slightly different than stdcall for regular functions. Since COM is based on C++ methods, that means that for some of those COM methods, the C equivalent is in fact incorrect. I already opened an issue for this #1342 which is even listed in this meta issue.

[liranringel]

Could someone elaborate in what way the quality of PDB debug info should be improved?

[gnzlbg]

#2625 covers __intrinsic_setjmp .