When compiling my Rust app in Windows 10, it is linked against ucrtbase.dll; however, this dll does not exist on some editions of Windows Server 2008 R2 Datacenter, making my app impossible to execute.
I tried setting -Ctarget-feature=+crt-static as found here, but it did not do anything; ldd app.exe still shows this dll.
Is there a way of removing the dependency on this dll?
If your Rust app does not depend on C libraries that specifically require the MSVC toolchain, you can build it for the x86_64-pc-windows-gnu (or i686-pc-windows-gnu, to build for 32-bit CPUs) target instead. This target links to DLLs that are available in all Windows versions.
For more information about the different Windows ABIs, you can check out this documentation page.
Related
I'm working with a native C++/Win32/MFC application built using Visual Studio 2010 Pro on Windows 7 x64. The application is linked with some other DLLs using their .lib files.
I'd like to be able to run this application and have it find the DLLs in their respective directories without 1) having to put the DLLs in the application directory or 2) add the DLL directories to the PATH or 3) resort to dynamically loading the DLLs and having to lookup stuff at runtime.
Is this even possible? Is there some way to direct the OS loader to go find the DLLs in an arbitrary location I specify without having to add that to the PATH?
Basics:
In Visual Studio project settings, keep everything default specially in Release configuration.
Ensure that you give Release build to the client (Where VS wouldn't have been installed).
If client OS is 32-bit, you must give 32-bit. Otherwise you can give 64-bit (Release build in any case).
Now comes distribution and VC++ runtime library.
You must install appropriate Visual C++ Runtime on client's machine,
ensuring that:
The version should match (VC7, VC8,.. VC14 etc.)
The bit-ness should match. If your application is 32-bit, you need 32-bit
redistributable, and same for x64.
The service pack version must also
match!
It should be noted that all of them can co-exist! VC10 RTM, VC10 SP2, VC10 x64 RTM.. all can co-exist
UPDATE: This is all essentially bogus. It turns out the version of Depends.exe on the machine where the application runs was the 32 bit version. Upon fixing that, both machines show the system DLLs as 64bit, so that is not the source of the problem. Not sure why depends shows them that way in a 32 bit exe.
FURTHER UPDATE: Ultimately the problem was one 64 bit DLL. This was easier to find after using the correct version of Dependency Walker. Selecting the 32 vs 64 bit version is not based on the platform you're running on. From the FAQ:
Dependency Walker will work with any 32-bit or 64-bit Windows module.
There are 32-bit and 64-bit versions Dependency Walker. All versions
are capable or opening 32-bit and 64-bit modules. However, there are
major advantages to using the 32-bit Dependency Walker to process
32-bit modules and the 64-bit Dependency Walker to process 64-bit
modules. This is especially true when running on a 64-bit version of
Windows, which allows execution of both 32-bit and 64-bit programs.
The 32-bit subsystem on 64-bit Windows (known as "WOW64") has its own
private registry, "AppPaths", "KnownDlls", system folders, and
manifest processing. Only the 32-bit version of Dependency Walker can
access this 32-bit environment, which is needed to accurately process
a 32-bit module. Likewise, only the 64-bit version of Dependency
Walker can fully access the 64-bit environment, so it should always be
used for processing 64-bit modules.
I have an application that builds correctly on one machine and incorrectly on another one. Both are MacBook Pros running Windows 7 via BootCamp. They are being built via QtCreator with VS2010 as the compile/link tool.
On Machine A it compiles and links without any reported errors. However, when run it fails with a 0xc000007b error (STATUS_INVALID_IMAGE_FORMAT). Depends.exe confirms that the exe is a 32-bit exe but that all of the Windows DLLs (advapi32.dll etc.) are linked as 64 bit DLLs. It seems as though this would be a link time error but apparently not.
On Machine B, everything compiles and runs correctly. Depends.exe confirms that the exe and all linked DLLs are 32-bit.
My Qt project is configured as follows:
qmake: qmake.exe PROJECT.pro -r -spec win32-msvc2010 "CONFIG+=declarative_debug"
I believe the -spec win32-msvc2010 part is sufficient to specify a 32 bit build.
The project file explicitly links to the Windows import lib files located in:
C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Lib
I have confirmed these are 32 bit import libs. An explicit LIB+= line in the project file calls out this path. If this line is removed from the project file, the link succeeds anyway. So I am not sure how the location of the Windows system import libs is specified in that case.
I verified with dumpbin that import .libs are tagged as either 32 or 64 bit. We are specifiying locations with 32 import libs.
Because one machine works and another doesn't, I believe the problem is one of machine configuration. Therefore, I removed and re-installed the MS tools from Machine A:
Uninstalled VS2010, Windows 8 SDK, .NET Framework 4.5, QT Libraries and QtCreator.
Reinstalled all of the above, in this order:
VS2010
VS2010 SP1
.NET Framework 4.5
Windows 8 SDK
Qt Libraries 4.8.4
QtCreator 2.7.1
I still get a 32 bit exe linked to 64 bit DLLs.
What could be causing the strange linking? And/or how can I determine more precisely why it thinks it should link to 64 bit DLLs?
It is not.
Answer from question text:
This is all essentially bogus. It turns out the version of Depends.exe
on the machine where the application runs was the 32 bit version. Upon
fixing that, both machines show the system DLLs as 64bit, so that is
not the source of the problem.
Ultimately the problem was one 64 bit DLL. This was easier to find
after using the correct version of Dependency Walker. Selecting the 32
vs 64 bit version is not based on the platform you're running on. From
the FAQ:
Dependency Walker will work with any 32-bit or 64-bit Windows module.
There are 32-bit and 64-bit versions Dependency Walker. All versions
are capable or opening 32-bit and 64-bit modules. However, there are
major advantages to using the 32-bit Dependency Walker to process
32-bit modules and the 64-bit Dependency Walker to process 64-bit
modules. This is especially true when running on a 64-bit version of
Windows, which allows execution of both 32-bit and 64-bit programs.
The 32-bit subsystem on 64-bit Windows (known as "WOW64") has its own
private registry, "AppPaths", "KnownDlls", system folders, and
manifest processing. Only the 32-bit version of Dependency Walker can
access this 32-bit environment, which is needed to accurately process
a 32-bit module. Likewise, only the 64-bit version of Dependency
Walker can fully access the 64-bit environment, so it should always be
used for processing 64-bit modules.
We are developing a DLL, which calls generic WinUsb functions from WinDDK. This DLL needs to work in 32-bit and 64-bit versions of Windows, including xp, vista, win7, and possibly win8.
My question is, how can we manage the Visual Studio 2010 solution by targeting all these platforms? WinDDK libraries are different for each OS, so if I reference a library from the code:
#### #pragma comment (lib , "C:\\WinDDK\\7600.16385.1\\lib\\wlh\\i386\\winmm.lib" )
Or by referencing the library from the project options->includes section, this project only becomes correct for a particular target architecture. (In this example, Vista 32-bits, since I am including 'wlh').
Are we supposed to create a different project for each different OS target?
The WDK/DDK version does not constrain the OS version for which you build. You can pass the target OS as a build environment/compile parameter.
I think you should build DLL through DDK and use that in your VS project.
You can write pre-build event for your VS project to run a batch file which will build the DLL and put it in some well-known place for the project.
Also, you may have to create different project configurations for each platform you want to build for (at least different for 32-bit and 64-bit) and run appropriate build command for DLL.
What are the different platforms/languages in which an app can be compiled and run on Windows without any prerequisites? I know of .NET but it requires the specific version of .NET to be present in the Windows installation.
C and C++, but Visual Studio defaults to dynamically linked library. Change the default to static and you will be fine.
That being said, ther are no compilers that come with windows. You must install a compiler to build the a program that will run everywhere after that. There are free version of the compiler in the Platform SDK and in mingw (Cygwin requires a dll).
If you are using Visual C++ as language and development tool, you may switch to Statically bound DLLs, which would produce larger binaries, but would run without any runtime-prerequisites. Visual C++ Runtimes are easily installable, can be distributed, or users may be asked to install them directly. If users are using Windows Update, they would anyhow get the latest VC runtimes.
I have a problem related to this question. Two players:
C# application
Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.