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.
Related
I have installed VSCode and GO extension with defaults packages.
My project need to load a 32-bit DLL. When I launch project with F5, I get error 193 on syscall.LoadLibrary().
I found on internet that error usually occurs when someone try to load a 32-bit DLL on a 64-bit arch.
I think if I debug with GOARCH=386 I would be able to load the DLL. But every time that I try to execute with GOARCH=386 I get error on VSCode saying that this architecture is unsupported.
Need help.
(I assume that a 64-bit DLL is out of reach)
64-bit process cannot load a 32-bit module into its process space, and a 32-bit processes cannot load a 64-bit module into its process space. The only way that communication can happen between 32-bit and 64-bit modules is through inter-process communication (IPC). Microsoft recommends that you use inter-process COM to use 32 bit code with a 64 bit application. Here's an article explaining the process. It's ugly.
If it's OK on your end, build your project to X86 platform (32-bit). In that way ehlapi32.dll is compatible & problem solved. Your 32-bit software is still supported on a 64-bit platform as 32-bit processes can be executed on 64-bit Windows operating system.
--
I familiar with C++ & not at all with GO. I have no idea how (or if at all) that technique can be implemented in GO.
The issue is because you are trying to load 32bit dll on 64bit architecture. Use 64 bit dll file. Along with that Install using 64bit dll for golang.
Just if you try to install delve from 32bit dll on 64 bit OS. This is also mentioned in the issues on github:
https://github.com/derekparker/delve/issues/20
VS Code complains if you want to run 32bit dll on 64 bit OS.
If you have 32bit dll for golang Uninstall that and install from 64bit dll again.
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.
For any VS project it is possible to set the platform target in the build properties of that project. You can set this to Any CPU, x86, x64 or Itanium. My question is, if I set this value to x86 does that mean I cannot run that project on a x64 machine? If so, why is this even used? Is it not better to just always use Any CPU?
if I set this value to x86 does that mean I cannot run that project on a x64 machine?
No, 32-bit applications (x86) run just fine on 64-bit Windows (x64). All 64-bit versions of Windows include a 32-bit compatibility layer called Windows on Windows 64 (WOW64). This is usually what you want, in fact, as most applications do not benefit from being complied for 64-bit.
However, compiling for 64-bit (x64) does mean that your app will not run on a 32-bit (x86) machine. You can go backwards (64-bit can run 32-bit), but you cannot go forwards (32-bit cannot run 64-bit).
Compiling for Any CPU is always an option, as you point out. That will allow the application to run as a 32-bit application (x86) on a 32-bit machine, and as a 64-bit application (x64) on a 64-bit machine. This sounds like a panacea, but there are costs. Most notably, you'll need to test your application extensively in both 32-bit and 64-bit environments, whereas if you only target 32-bit environments (including 32-bit environments on a 64-bit host), you only have to test one build. And the additional workload is rarely worth it—most business applications do not benefit from the extra memory space of a 64-bit environment, and probably end up defeating any potential gains by the increased overhead of 64-bit pointers.
Visual Studio itself is a good example of an application that is fully 32-bit. There is no 64-bit version, yet it runs fine on a 64-bit host. This blog post helps to shed some light on why the decision has been made to keep VS 32-bit. You might find the reasoning helpful in making the decision yourself.
Likewise, although Microsoft Office is now available in a 64-bit package, Microsoft is still recommending that most customers stick with the 32-bit version. There are compatibility problems with the 64-bit version, and there just isn't much benefit.
If you do not specify 32 bit platform the Microsoft application compatibility toolkit cannot determine the app is 32 bit and will not allow you to create a 32 bit solution file to allow an application to run without requiring admin credentials when user account control is turned on
In Windows 2008 R2 server (server core installation) wow64 is no longer a required component.
I can compile a 32 bit application using the same source code as a 64 bit application (with a few ifdefs here and there).
Is there a tool that puts both versions of my app in one executable so that my 32+64 bit application will run on a pure 32-bit Windows and a 64-bit only Windows?
Note that I am not talking about a packer because the packer itself will be either 32 or 64 bit.
No. An EXE's header is marked with the processor architecture supported by the code contained in the EXE. Use DUMPBIN.EXE -HEADERS to explore.
EXE's report the "machine" type as:
x86: 0x14C
x64: 0x8664
ARM: 0x1C4
If you want to deploy your app, build a version for x86, a version for x64 (ARM comes later with Win8) and author a setup package (MSI) that can dynamically examine the architecture of the machine onto which you're installing the app, and lay down one or both of the apps. This is how, for example, Adobe are now distributing Flash x86 and Flash x64 in the latest Flash player download.
If you want to build a truly universal binary, build it in .NET and mark it as targetting "Any" CPU. Your app will then be JITted to the architecture of your machine (or the hosting process in the case of an add-in component).
I have seen that some programs which were written by me and assembled for x86 using ml.exe run fine on my Win 7 x64. I believe this is because of Wow technology.
However, there are some programs (not written by me) which don't run. They give the error that:
The version of this file is not compatible with the version of Windows you're running. Check you computer system infromation to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher
Is there any way I can modify the EXE of these programs to make it run on Win 7 x64. What is the fundamental difference in these programs which make it different from other programs which run transparently.
They're actually 8- or 16-bit programs. Windows x64 runs in Long Mode, which does not support Virtual 8086 Mode, required for such programs. There is no way to make them work short of recompiling them from source or running them in a virtual machine.
One reason can be combination of .NET and native libraries. .NET libraries are compiled in runtime as x64 (if you don't specify explicitly x86) and native libraries run in x86 mode. it cannot run togehther.
Another reason is access to registry. Depending on used API, x86app in wow64 mode can be forwarded to another part of registry. If the registry access API is inconsistent, it can make a problem.