-1

I have an unmanaged handler used in C# code, the delegate is defined like

[UnmanagedFunctionPointer(CallingConvention.StdCall)]
public delegate int Callback (arguments)

It works well in 32bit version and I'm asking me what changes have to be done in 64bit version. The C header of the dll containing the handler defines all functions as __stdcall if WIN32 and as __fastcall if WIN64 (i.e. the dll comes in both 32 and 64bit versions). But in NET documentation it is said that fastcall is not supported. I don't understand what all this means, how should I change (or not) the code for 64 bits ?

Ðаn
  • 10,934
  • 11
  • 59
  • 95
user5493558
  • 92
  • 1
  • 7
  • Use 32 bit version since 64 bit version is a fastcall and Net doc says fastcall is not supported. – jdweng Apr 25 '17 at 12:41
  • the dlls and the C headers come with a hardware I bought, I haven't written it. So I understand your -1 is for the hardware vendor. – user5493558 Apr 25 '17 at 12:46
  • 2
    Write unmanaged wrappers that employ `__stdcall` and forward to the `__fastcall` versions (or use C++/CLI to immediately expose these functions as managed ones), and the other way around for callbacks (pass a `__fastcall` delegate to the unmanaged code that calls the `__stdcall` managed callback). You probably don't want to do that by hand if there's a lot of functions, so some code to generate them might be needed. – Jeroen Mostert Apr 25 '17 at 13:21
  • 2
    All this is necessary only if the 32-bit version *can't run* on 64-bit Windows (which might be the case if it interfaces directly with a driver). If it can, simply compile your managed code as "Prefer 32-bit" and use the 32-bit versions exclusively, that's much simpler. – Jeroen Mostert Apr 25 '17 at 13:24
  • Thanks Jeroen for the suggestion. Actually my code can run in 32bit on 64bit Windows (if the 32bit version of the external dll is used). But I also distribute a C# source so I don't know on which architecture and with which driver version it will be used (I might also just prevent users to compile only in x86 mode). That said I find it strange - why the manufacturer would want to make it so complicated? – user5493558 Apr 25 '17 at 14:01
  • 1
    It's probable the manufacturer isn't concerned at all with .NET code interfacing with the DLL. In unmanaged code, this is simply not a concern since you #include the headers and away you go. No source needs to be modified since the calling convention is part of the (presupplied) header. If the supplier *was* concerned about managed code, they would have supplied the API themselves. Building hardware and writing drivers is hard enough -- managed code is Someone Else's Problem. – Jeroen Mostert Apr 25 '17 at 14:05

1 Answers1

1

You don't need to do anything. Calling convention directives are ignored when targeting 64 bit code because there is a single calling convention for that architecture. Leave the code as it is. It will work correctly for both 32 and 64 bit compilation.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490