Closed nurbles closed 1 year ago
I am a little bit confused what product B is... 32bit or 64 bit?
And the general answer is that LegacyWrapper supports 32bit and 64bit Windows DLLs (not .NET class libraries).
Sorry, "Product B" is "the old 32-bit DLL" that I need to use from a now 64 bit program. So my plan was to write a 64 bit DLL with the same interface as the old 32-bit DLL had, and have my 64-bit DLL find a way to call the 32-bit, hopefully using LegacyWrapper, but it looked like I needed to code my DLL in C# in order to make the necessary declarations.
However, the more I look the trickier it may be because the calling convention for some of the functions includes an integer followed by a point to an array of [the previous parameter's value] number of elements. Sometimes more than one of those. And sometimes they are arrays of (64-bit) pointers. Would LegacyWrapper be able to deal with all of the pointer adjustments?
Please note that your application must be a managed (say: .NET, written in C# or VB.NET) application to use LegacyWrapper. It sounds like your application is built by some other technology?
However, LegacyWrapper supports different calling conventions like stdcall, cdecl and so on. Just have a look at the LegacyDllMethod
class.
I'm trying to build a wedge (my term) to put between the now 64 bit Visual Studio 2022 and our source control package, QVCSPro 3.10 (a 32 bit DLL from 2014). I have no source for either, but I do have the interface spec from Microsoft for source control provider DLLs, which is plain C. My 'wedge' could be anything that can present the appropriate C-style interface to Visual Studio and convert the parameters received into the appropriate C-style calls into the 32 bit DLL.
I think I've figured out all of the things I need to do (using Microsoft's COM method to call 32 bit from 64 bit), but I'm a Native C Windows programmer (yup, a dying breed, quite literally in my case) and I was hoping to find an easier way. (smile)
However, I may "cheat" the COM stuff and steal your named pipe idea (or perhaps TCP through localhost) to communicate between my 64bit DLL-client and my 32bit DLL-server.
Feel free to close (or even remove) this issue. Thanks for chatting with me!
So, if I understood you correctly, both sides of the communication are built as a "native" application (without .NET virtualization). If so, I'm afraid you cannot use LegacyWrapper.
Of course, you can build something with named pipes or other network communication yourself.
Kind regards Franz
I'm hoping to create something to stick between an updated-to-64-bit product (A) that will allow it to still use an old 32-bit product (B) that we still use. Product A expects product B to be a 64-bit DLL, so I'm hoping that I can use LegacyWrapper to produce a DLL (that Product A can call) to act as a 64 bit wrapper for the old 32 bit DLL. LegacyWrapper sounds perfect ... except I'm a C programmer (not C++ or C#) and Visual Studio doesn't seem to have a template for a C# DLL and event if it did, I'm not sure all the exported functions and types would match for both the exported functions and the 32-bit functions to be called.
Is what I'm hoping to do possible or must I take (at least) a few months to learn to create all the COM things necessary to create this from scratch?