1

I am attempting to work with an FTDI device (https://ftdichip.com/products/c232hm-ddhsl-0-2/) for which the DLL requires x64 targeting to run without a badimageformat exception.

In the same program we also need to communicate with a Feasa device (https://www.feasa.ie/ledanalyser.html) that only works when we target x86 if we want to avoid the same exception.

I had to write DLLImports/marshaling for both of these, and (for now) they seem to be working OK when selecting the correct x64/x86 setting until the other one's functions are attempting to run. In both cases the other DLL will throw badimageformat exceptions.

I am not aware of either of these companies having updated DLL's yet. Both only have c++ (FTDI has one c# wrapper that is missing critical functions for my user case) libraries that had to be marshaled. I have worked with c++ quite a bit in the past but our company primarily uses c# and I would just be kicking the can down the road, so to speak, by using c++ for the application. I'm not actually sure using c++ would solve this issue anyway.

Anyone familiar with this kind of issue? Is there any possible way to get both of these DLL's to work on the same application at once? I feel like I'm most likely going to lose many hours of work having found out these third party DLLs only work on specific settings.

EDIT: we found out later that Feasa does have both x86 and x64 dlls, the other dll file fixed the issue.

Plaje
  • 65
  • 9
  • 3
    No, you need inter-process communication between a 32 and 64-bit process, because you can't have both DLLs in the same process. I think [Combine 32- and 64bit drivers in one program](https://stackoverflow.com/q/55124756) is a good canonical answer for ways of handling it. – Peter Cordes Aug 27 '21 at 17:00
  • 1
    And BTW, this is why binary-only software suck. Vendors, please stop doing this crap. The near future might have AArch64 and/or RISC-V desktops / laptops, not just x86-64, so x86 / x86-64 machine code won't even run natively on the same CPU in another mode for cheapish IPC. I get that as consumers, we can't always give *too* much weight to the availability of open-source drivers when selecting which hardware device we choose to support with our dollars, but when you can, it's something to consider. – Peter Cordes Aug 27 '21 at 17:08

0 Answers0