10

I'm having a problem, I've been trying to solve it since yesterday but no luck. I have a 32-bit Delphi DLL which I want to import it in to a .NET WIN Application. This application has to be built on ANY CPU mode. Of course, the exception BadImageFormatException is thrown, which means that 64-bit applications can't load x86 DLLs. I googled around and found a solution, it said that I have to do wrapper, but it wasn't clear for me. Can anyone tell me how to solve this problem, is there any possible way that I can import a 32-bit Delphi DLL in to a program built under any CPU architecture (64-bit, 32-bit) or maybe another solution?

Lahiru Jayathilake
  • 601
  • 2
  • 10
  • 28
scatterbraiin
  • 157
  • 1
  • 2
  • 6
  • 2
    Why not compile the .NET application as x86? – OregonGhost Jun 14 '10 at 12:00
  • 3
    Why does it have to be compiled as ANY CPU? A 32-bit app will run on a 64-bit OS. – juharr Jun 14 '10 at 13:16
  • 2
    @OregonGhost Because it's the 21st century. – sproketboy Feb 22 '17 at 11:55
  • 2
    @sproketboy: The reality in the 21st century is that you can't load 32-bit DLLs within a 64-bit application, and whenever you need such a DLL (which is almost always where I work, due to hardware access or communication requirements), you just can't compile for 64 bit. And in almost all cases, you don't actually need 64 bit anyway. I don't think that "it's the 21st century" is a good reason ;) – OregonGhost Apr 20 '17 at 07:22
  • @OregonGhost Our Java apps can take full advantage of 64 bit without even having to recompile anything. – sproketboy Apr 21 '17 at 13:57
  • @sproketboy: Not if you're loading a 32-bit DLL in your process. Even the JVM can't do that, unless you're using one of the wrapper techniques explained in the answers, but that's the whole point of this question. You can also do 64 bit in .NET without having to recompile (just set target architecture to Any CPU, which is what the OP did), but then you still can't load 32-bit DLLs. It seems you're missing this important point with your 21st century obsession. The advantages of 64 bit aren't as big as you might think, unless you're exhausting your address space. – OregonGhost Apr 26 '17 at 07:34
  • @OregonGhost The point is in Java you rarely would have to load DLLs at all since it's platform neutral. – sproketboy Apr 27 '17 at 20:12
  • @sproketboy: Only if you're living in a pure little Java world and everything you use is pure Java. We have many projects using proprietary DLLs for communication with devices that are not available in 64 bit (or Java or bitness-agnostic .NET) and cannot be replaced/rewritten (for a variety of reasons). I get your point, but it is moot for many developers; and if living in an ideal world, .NET works the same as Java anyway if you compile everything for Any CPU (you sound like Java programmers by definition don't have that problem, but they do, just like there are .NET developers that don't). – OregonGhost May 08 '17 at 08:00
  • @OregonGhost Little? You mean much larger than .NET, right? The difference is that using native code is the exception not the rule like it is in .NET. But I get it if you have old legacy DLLs that you can't rewrite. – sproketboy May 08 '17 at 15:24
  • @sproketboy: I don't know why you think that using native code is the rule in .NET. It's not. It's the rule if *you need to use existing native code*, no matter which language or framework you are using. There are a lot of pure .NET applications, but a lot of interesting things cannot be done in pure Java or pure .NET, and that has nothing to do with libraries being old. You're also underestimating how much .NET code exists, but that was not the point; I could also have written pure little .NET world, with the point being that pure means you can only use a fraction of the code out there. – OregonGhost May 10 '17 at 16:03

5 Answers5

19

What you have to do is write a wrapper application that hosts the 32-bit DLL file, in a 32-bit process.

Your 64-bit application then has to talk to this 32-bit process, through network means, or by making the DLL functions available through a COM object, or similar.

You can not run a 32-bit DLL inside a 64-bit process, no matter how hard you try, so you need to run it in a 32-bit process.

If compiling your application for 32-bit only is not an option, you have no choice but to create a host application.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
9

A general idea could be to wrap your (unmanaged) 32-bit DLL with a managed 32-bit wrapper dll and make it COM visible. This allows calls to your wrapper DLL via its COM interface.

You can than use a COM surrogate to make your COM dll appear as an out of process COM server. Take a look at this SO question for some further information on this topic: Access x86 COM from x64 .NET.

Community
  • 1
  • 1
Frank Bollack
  • 24,478
  • 5
  • 49
  • 58
2

As I understand things, you have no way of using a 32-bit DLL from a 64-bit application. That said, you may compile your application for X86 only.

The solution you found may be about how to use a DLL that exists for both 32- and 64-bit versions in an "Any CPU"-compiled project depending on whether the application is running in a 32- or 64-bit environment.

To do that, you could write two wrapper DLLs in C#, one for 64-bit and one for 32-bit and use the respective wrapper depending on whether you're running on a 64-bit or 32-bit OS.

However, this does not work when all you have is a 32-bit DLL. A 64-bit application can not use 32-bit DLLs, as well as a 32-bit application can not use 64-bit DLLs.

So you either need to compile your application for 32-bit, or you have to create a 64-bit version of your DLL.

Thorsten Dittmar
  • 55,956
  • 8
  • 91
  • 139
  • At this time, i have only on DLL (32bit one) and there's no chance to have another DLL - 64 bit version, meantime my .NET application has to be compiled as ANY CPU (which considers 64 bit too). soo, isn't there any solution for this case? – scatterbraiin Jun 14 '10 at 12:44
  • Well, as Lasse V. Karlsen suggested, you can write a separate 32-bit application (NOT LIBRARY!) which you start as a separate process and "talk to" using inter process communication. – Thorsten Dittmar Jun 14 '10 at 13:04
2

A solution although a bit of a mess could be to write a separate 32-bit application that you can talk to from your 64-bit application such as a console application you send commands to/from.

Not pretty but may work if you only need the occasional call to it.

Mikael
  • 602
  • 3
  • 9
  • I tried, not exactly like that, I wrote Class library, where I imported that Delphi DLL, compiled x86 and then i referenced it to my 64 bit Main Application, but still no luck. – scatterbraiin Jun 14 '10 at 12:54
  • Because it is the same problem, only with more complexity. Your 64-bit application can not use a 32-bit class library either! Mikael was talking about a 32-bit application you communicate with through Named Pipes or other IPC methods. – Thorsten Dittmar Jun 14 '10 at 13:03
  • I read that it is possible through IPC but to tell you the truth it was not quite clear for me.. Is there any chance you have some instructions about that?? I need more details, because it's really new for me – scatterbraiin Jun 14 '10 at 13:23
1

Just compile your .Net Application as Platform x86. It will run on x64 machines and it will use your 32bit DLL. Don't waste time on a wrapper.

user7116
  • 63,008
  • 17
  • 141
  • 172
  • Not an option if the underlying OS is 64 bit, as it will swallow the exceptions that pass through the OS layer and you will not see them! – XMight Sep 29 '14 at 15:09
  • Which magical OS configuration have you dreamed up where you can run a 32bit .Net app on the 64bit OS but exceptions are "swallowed"... – user7116 Oct 29 '14 at 00:39
  • 3
    This in not a dream, but my development conditions for several months. I have a 64 bit development machine, and if you compile for x86 platform the exceptions are swallowed (from parallel tasks and not only). Visual studio just shows in the output window "first chance of exception" which obviously you will not see in the client app running. Reason: http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/ – XMight Oct 29 '14 at 08:55
  • 1
    Paul Betts link is dead but the google cache works: http://webcache.googleusercontent.com/search?q=cache:http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/&gws_rd=cr&ei=IX2tWPCOJ6awjwSwkrCICw – sproketboy Feb 22 '17 at 12:00