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.
Related
Alright so my idea was some way to bind both 64-bit and 32-bit Windows executables into one application so if it doesn't run the 64-bit version it would then try the 32-bit one.
I was reading up about PE's and learned a little about MS-DOS Real Mode Stub and it says how it invokes an application (usually an error message). But every time I tried to do research about MS-DOS Real Mode Stub it seemed to only show error messages. So my idea was to overwrite the STUB with my 32-bit application.
My self being naive figured when the 32-bit operating system would run the the 64-bit executable it would fail and then run the stub file.
Is there any way to make my executable 32-bit/64-bit independent?
You could not create a single executable file, containing both x86 and x64 code. However you could create separate 32bit and 64bit applications, pack x64 app into the x86 app resources. On the program start you could check, that you are running x64 environment using IsWow64Process then if needed, unpack your x64 version and run it instead
There are fat binaries in MacOS, Linux and DOS (or hybrid DOS-Windows) but not 32 and 64-bit Windows
You can simply compile separate versions of the program, distribute both and then select the required version at run time by a script or another executable
Another way is installing only the desired version at install time. This is used by many programs like CCleaner. The installer is a 32-bit app or a universal one like .NET so that it can run anywhere. If it detects 64-bit Windows then it only installs the 64-bit version, and in the other case only the 32-bit version.
Read more:
Universal binary
Windows 8 fat binary (exe for x86 & ARM)
Windows NT has always been a multi-platform OS, but the binaries are not
I downloaded, what i thought, would be the 64-bit version of Lazarus:
Although it downloads a 32-bit build:
And after installing it, the IDE is 32-bits:
And it builds 32-bit binaries:
Changing the targeting options to win64, win64, win64:
Gives an error that Lazarus doesn't support 64-bit:
Reading the somewhat dated Cross compiling Wiki page gives the instructions on how to make the 64-bit Lazarus work on 64-bit machines:
From win32 to win64
If you are compiling the 2.1.1 or greater branch of fpc you can just do:
$ make all OS_TARGET=win64 CPU_TARGET=x86_64
and then
$ make crossinstall OS_TARGET=win64 CPU_TARGET=x86_64
which, if you follow, just gives a few thousand errors:
The common suggestion is to abandon the Lazarus IDE, altogether, and use a fork known as CodeTyphoon. Downloading that 500 MB, and installing it, i couldn't find an IDE anywhere:
Which is confusing, because i thought CodeTyphoon was a Pascal Visual Programming Environment.
Before i go on
Before i go randomly stumbling around, downloading gigabytes of stuff, let me just ask straight out:
Can Lazarus 64-bit for Windows compile to 64-bit for Windows?
Is there a 64-bit Lazarus for Windows, that can create 64-bit Windows binaries? Am i missing something, or is that functionality not in there yet?
And if the ability is in there, at least could someone commiserate that my confusion is understandable?
The following is from README.txt files on the SourceForge download pages (http://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Lazarus%201.2/ and http://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Lazarus%201.2/). However, those readme.txt files are apparently not included in the actual installation.
I have verified that installing the plug-in allows you to build a 64-bit application.
Two things:
there is an add-on for building Win64 applications in the 32-bit Lazarus IDE:
Add-On for building 64bit Windows applications:
lazarus-1.2.0-fpc-2.6.2-cross-x86_64-win64-win32.exe
This file can be installed as add-on to the 32 bit Lazarus IDE (on Systems with Windows 32 or 64 bit), if you wish to develop for
64bit Windows too. If you install this on a 64bit Windows PC together
with the 32 bit Lazarus IDE, you will also able to debug 64 bit
applications.
the link to the 64-bit Lazarus IDE on the Lazarus homepage is incorrect (it points to the Win32 version). The link should be:
http://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Lazarus%201.2/lazarus-1.2.0-fpc-2.6.2-win64.exe/download
If you use the 64-bit IDE you'll need a similar (but different) plugin to build 32-bit binaries.
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.
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.
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.