The problem happens when I try to static load 32bit DLL which is written using Visual C++ from 64bit version of Lazarus compiler. The function call always fail with following run-time error:
The application was unable to start correctly (0xc000007b). Click OK
to close the application.
I try same project on 32bit version of Lazarus compiler it and works without any issues.
Is it not possible to load 32bit version of DLL with 64bit version of Lazarus compiler or am I need to change some setting(s) in the Lazarus compiler?
This is console application project and I declare my function import like this:
function TestFunction(Param1: Word; Param2 : Word) : Byte; stdcall; external 'test.dll';
No it is not possible. 32-bit EXE loads 32-bit DLL, 64-bit EXE loads 64-bit DLL.
Related
Is it OK for a COM DLL to be compiled as AnyCPU and work with both 32 bit and 64 bit applications?
Yesterday I started writing a C# COM DLL so that my MFC project could use the DLL. The DLL itself is for using the GMail API.
Initially I was compiling the DLL as either x86 or x64 and both of my executables were running fine.
Then I decided to change the DLL to compile as AnyCPU and now when my program runs it says Class not registered.
Does the DLL have to be compiled for each Bit edition then?
No, you can keep the .DLL compiled as "Any CPU" (in fact I certainly recommend it as long as you can), but you must register it in each version of the registry, so for example using regasm:
64-bit:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
32-bit:
c:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
I have created an Application in Linux 64bit with MonoDevelop, GTK#2 as GTK2-Project.
I am able to make an executable, the platform-target is "AnyCPU" (I have removed Posix references and GetText()-support), but I have also tried "x64".
This executable can be executed on Linux 64bit (terminal: mono App.exe)
This executable can be executed on Windows 32bit (terminal: mono App.exe)
This executable CANNOT be run on Windows 64bit (terminal: mono App.exe)
brings error:
Unhandled Exception: System.DllNotFoundException: libglib-2.0-0.dll
I have installed the GTK+ for Windows Runtime Environment on both machines, Windows 32bit and Windows 64bit.
In fact I have found this DLL libglib-2.0-0.dll on the GTK/bin-path and also have copied it to my executable-folder, even though it is set in the PATH environment variable.
Anyway, I get the same error message, but only in Windows 64bit.
Do I have a chance of making my GTK app to be running with Windows 64bit?
Is there a different libglib-2.0-0.dll for Windows x64 and how can I obtain this?
It's certainly possible to run a Gtk# 2 application on 64-bit windows, but it requires a bit of work. It appears you've already obtained the necessary .Net assemblies, and the native Win64 Gtk+ DLLs that are needed, but you also need an additional set of 64-bit native "glue" DLLs. I have not yet found a good source for these in pre-compiled form in any of my searches, but it is possible to build them from the gtk-sharp source.
I have a dll file that has been created and compiled with C++ under Windows and I unfortunately don't have the source code for it.
This dll file is working well with a .NET program compiled with visual studio.
I want to know if this is possible to import this dll file with mono, and execute it under a UNIX environment.
This dll file is sending some Smartcard APDU instructions.
Most probably no. Binaries are platform specific.
You can always try to disassemble it on Windows and try to compile the disassembled code on unix, however I think it's not worth it.
I'm getting an 'AccessViolationException' 'Attempted to read or write protected memory' when calling a method in an x86 dll when running on an x64 platform (Windows 7). Everything works great on x86 platforms.
I've read many, many posts about similar problems but haven't been able to get my code to work.
I'm in the process of trying to make our old x86 app work happily on Windows 7 (x64) and Server 2008 R2 (x64). The app is an assortment of VB6 , VB.Net, C#, MicroFocus COBOL and C++. (We couldn't think of any other languages to throw in at the time). The DotNet code was originally written in Visual Studio 2003 for DotNet 1.1. I've ported the code up to Visual Studio 2010 and DotNet 4.0. I've set the target for all the projects to x86. When I call into un-managed 32 bit dll's I get the above error.
Our InstallShield setup routine is installing the x86 dll's into C:\Windows\sysWOW64 instead of C:\Windows\System32. This behavior seems correct. The dll's are some COBOL object code and runtime components linked together into a 'C Style' dll. I don't think the problem has to do with COBOL or the linking process as I also ported up a sample app from Code Project with a VB.Net WinForms app that calls a simple C++ dll, all targeted to x86. I get the same error there. I've also tried building a C++ command line app to call the dll. The Load Library succeeds. GetProcAddress succeeds. Calling the function pointer for the particular method fails. Our VB6 apps can call the dll's just fine when running on Windows 7 x64. I've also tried turning off UAC and setting the requestedExecutionLevel in the manifest to the highestAvailable. I've tried running as administrator.
Seems like this should work, but not sure what to try next. Any ideas?
On x64 .net programs will be run as 64-bit programs and cannot call 32bit-dlls.
Try compiling the application with target x86 instead of "Any Target". You can also force the
target of the built .exe with the .Net CorFlags.exe utility to run in 32bit-mode.
Of course your program will then run in the 32bit environment, especially it will only have a maximum of 2gb of RAM.
Good news,
We investigated DEP as a possible cause of the problem as we saw that even our VB6 code will fail when DEP is turned on. We noticed that the VB.Net code was failing in the same way as VB6 when DEP was on. Apparently our COBOL dll's do something that DEP isn't happy with. Unfortunately the DotNet assemblies don't seem to respect the operating system DEP setting, so you have to turn off DEP with using editbin.exe:
editbin.exe /nxnocompat:no
I still have to test it on our full application, but it looks like we have a solution!
I am trying to add a VC6 COM DLL to our VS2010RC C# solution. The DLL was compiled with the VC6 tools to create an x86 version and was compiled with the VC7 Cross-platform tools to generate a VC7 DLL.
The x86 version of the assembly works fine as long as the consuming C# project's platform is set to x86. It doesn't matter whether the x64 or the x86 version of the DLL is actually registered. It works with both. If the platform is set to 'Any CPU' I receive a BadImageFormatException on the load of the Interop.<name>.dll.
As for the x64 version, I cannot even get the project to build. I receive the tlbimp error:
TlbImp : error TI0000: A single valid machine type compatible with the
input type library must be specified.
Has anyone seen this issue?
EDIT:
I've done a lot more digging into this issue and think this may be a Visual Studio bug. I have a clean solution. I bring in my COM assembly with language agnostic 'Any CPU' selected. The process architecture of the resulting Interop DLL is x86 rather than MSIL.
May have to make the Interop by hand for now to get this to work.
If anyone has another suggestion let me know.
This issue can be resolved by opening the CSProj file and adding the following node to any of the '(Configuration)|Any CPU' nodes that are missing it:
<PlatformTarget>AnyCPU</PlatformTarget>
If this node is not present TlbImp will default to x86 and cause issues.