Any compiled applications from Rust does not work on Windows 7/10 on VM

Just a simple hello_world program may work on my host machine but in virtualbox for both Windows 7 and 10, it fails to execute.

This is the source code:

fn main()
{
    println!("Hello, world!");
}

I compiled it via this command cargo build --release. I copied the file and pasted in both Windows 7 and 10 and I get the exact same messages:

I made a simple C equivalent program, compiled it using gcc via this command gcc learning.c -o learning.exe and it worked just fine on both Windows 7 and Windows 10 on VM.

here is the source code for C:

#include <stdio.h>

int main()
{
    printf("Hello world");
}

How would I compile without needing such dependencies or something to avoid getting such errors?

2 Likes

No idea really but I bet that VCRUNTIM140.dll is part of the Microsoft C compiler MSVC installation.
Suggest installing MSVC to some Windows machine then copying it to you VMs.

1 Like

What if I want to run my applications without getting the user to install MSVC? Like with other languages? Its quite weird why Rust doesn't work but C works just fine?

I'm not totally sure but GCC also has a "run time" C library, libcrt, which I gets linked statically into the executable. I have no idea what Windows does with a dynamically loaded crt.

In case anyone is wondering, the C "run time" is hardly worthy of the name, it only sets up the stack and such before calling your main. Soo how small it can be: crt0 - Wikipedia

A bit of a misnomer really as it does not actually do anything whilst your code is running, only waits for it to return!

As far as I understand typically Windows programs come as a package containing all the DLLs they need, presumably including that one, just so they get the versions of the DLL's they need. This package being a self extracting installer. Think of what happens every time you have installed a Windows application from a downloaded install.exe.

It used to be called "DLL Hell".

2 Likes

What you want to do is statically link vcruntime. You can do that by making a .cargo/config.toml configuration file and putting something like this in to it:

# Windows 64 bit programs
[target.x86_64-pc-windows-msvc]
rustflags = [
	"-C", "link-arg=libvcruntime.lib"
]

# Windows 32 bit programs
[target.i686-pc-windows-msvc]
rustflags = [
	"-C", "link-arg=libvcruntime.lib"
]

Edit: You can make this configuration the default for all your programs by putting the config.toml into the %USERPROFILE%\.cargo\ folder.

See Configuration - The Cargo Book

7 Likes

Does C do this automatically, whereas with Rust I have to tell it explicitly?

It doesn't seem to do anything as I just tried that and still the same issue.

When I was compiling (via cargo build --release) after adding the thing you suggested in my cargo.toml file, I got these warning messages

warning: unused manifest key: target.i686-pc-windows-msvc.rustflags
warning: unused manifest key: target.x86_64-pc-windows-msvc.rustflags

This is normal for Windows. Visual Studio by design produces binaries that do not work on stock installation of Windows! Instead, you're supposed to bundle "VS Redistributable" with your application's installer, like this one:

You can work around it in Rust by requiring static linking with the Visual Studio runtime:

https://rust-lang.github.io/rfcs/1721-crt-static.html

but this in theory is was not supported by Microsoft!

4 Likes

Your information is pretty out of date. See CRT Library Features. ucrt.dll is now part of Windows 7+. vcruntime.dll can be statically linked.

You need to add it to config.toml in a .cargo folder in the root of your project. Edit: So the directory structure is:

.cargo
|  config.toml
src
|  main.rs
Cargo.toml
1 Like

Isn't it possible to have Rust dependent on g++ instead of Visual Studio C++?

What if I wrote my application on Linux instead and compile it for Windows, would I get the same issue then?

If you want to compile on Linux for Windows, you will have to use the Mingw toolchain instead of MSVC toolchain. This toolchain is also available on Windows. (x86_64-pc-windows-gnu and i686-pc-windows-gnu)

I see, would it need to be dependent on VCrun (as currently I do need this installed to get my
applicatins to work) or would it work without the installation of such programs?

It is not dependent on msvcrt.dll. I don't know if it statically or dynamically links to the Mingw libc though.

1 Like

So that means it won't have issues running on fresh installs of Windows?

1 Like

Like @ZiCog said, C doesn't really have a "runtime", but Rust does have a comprehensive standard library and maybe that is what depends on libvcruntime.dll. I don't know. :man_shrugging:

That's great!

No, in the case of C it just doesn't depend on VCRuntime at all.

I'm pretty sure that if you install MingW and then compile with cargo build --target x86_64-pc-windows-gnu that it won't depend on any external DLLs.

On Linux I install MingW and cross-compile for windows with the --target x86_64-pc-windows-gnu and it works on a completely fresh Windows VM. I'm assuming that if you compile for x86_64-pc-windows-gnu on Windows the result should be similar.

1 Like

Ah I see.

To be precise, Rust uses vcruntime for its implementations of memcmp, memcpy, memmove and memset. It also uses some of the exception handling infrastructure (i.e. __CxxFrameHandler3 and _CxxThrowException) to implement panics. These could all be rewritten in Rust but they tend to be highly optimized for the platform so it makes sense to use the ones Microsoft gives you.

I'm not sure why it isn't static linked by default, at least on release builds. Maybe it mess with someone's workflow. Though it would at least be helpful to copy the necessary dll to the output folder.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.