Win32 DLLs problem

[Danesh]

Hi,

I have created some DLL files in Win32 (created in MASM) and they works fine with MASM32. When I try to import these DLLs in .NET platform they just crash and don't work. I had same problem with for example VC++ and VC++ .NET. My friend told me that on some cases they should be converted to add a header or something like that to it to be in proper form to be used in .NET. Can anybody help ?

Thanks,

Danesh

[sluggy]

When I try to import these DLLs in .NET platform

Exactly what do you mean by "importing"?

they just crash and don't work.

You can call them from a managed language just by using the p/invoke methodology, which is very similar to the method of calling dlls from classic VB.

My friend told me that on some cases they should be converted to add a header or something like that to it to be in proper form to be used in .NET.

Your friend is wrong, they can't be "just converted". If it is inline assembly in a C++ project then it can be compiled on the .Net platform, but it is still unmanaged native code (go back to using the p/invoke method, the calling code may have to be marked as unsafe).
If it is straight assembly language, you can't convert that to ".Net" because .Net uses ILASM which is not fully compiled to native asm.

[Danesh]

By "Importing" I meant call functions within DLL in my program but in a managed platform like C# .NET or VC++ .NET and that DLL is a pure assembly created in MASM32 (unmanaged). AsI said, I had these problem when I tried to use a DLL which has been created in VC++ in VC++ .NET. So you say all DLLs (Regardless of if it has been created in a managed or unmanaged platform should be called in a managed platform like VC++ .NET or VC# .NET without nay conversion or anything else, am I right? If it is right, so I have to review my code again and again...

[sluggy]

By "Importing" I meant call functions within DLL in my program but in a managed platform like C# .NET or VC++ .NET and that DLL is a pure assembly created in MASM32 (unmanaged).

This in itself is no problem, no matter what language it was created in it is just an unmanaged dll.

So you say all DLLs (Regardless of if it has been created in a managed or unmanaged platform should be called in a managed platform like VC++ .NET or VC# .NET without nay conversion or anything else, am I right?

Not quite. Any dll can be *called*. But you can't just pass parameters the way you are used to. If it is a COM dll then you need to reference it from the .Net assembly which will create an extra COM interop dll (which is a wrapper around the COM dll). If it is a standard dll then you may have to marshall some of you parameters (coerce/convert them from one type to another). For instance, you can't just pass pointers or objects* around, you need to marshall them as System.IntPtr when crossing into or back from the unmanaged code. There is a lot of information about this on the net, do some reading and make sure you have it totally clear in your head before you start changing your code, this sort of thing can be difficult to debug, and if you don't understand it first it makes it really hard to determine exactly what is causing the problems :U

*in managed C++ you still use pointers explicitly, but in the other languages like C# and VB when you have a reference to an object, it is actually a pointer, but the language hides this from you.

[Danesh]

Hi Sluggy,

Thanks for your help. It would be great if it was possible to export DLLs completely written in assembly to managed code form so it might be 100% compatible with .NET platform. However one could say that it is already possible by writing inline code in .NET environment.

Thanks,

Danesh

[psylem]

I recently came across a problem when trying to test my DLL with a VB form. I found out there are two kinds of calling conventions for functions in a DLL. Perhaps that's the 'COM' and 'standard' thing sluggy is talking about? Anyway, I found you can use both conventions in the same DLL. You can declare a kind of 'wrapper' function in the DLL so that it can be called by one or the other standards, just with a different name. However I have no idea how to tell MASM what convention to use for the function because I wrote mine in C. I do know that if you try to call a DLL function that is declared with the wrong convention it totally doesn't work. Hope that helps some how. :green

[Danesh]

Hi Psylem,

Actually, my problem was about calling unmanaged functions in a managed platform such as C# .NET. I don't know if it is answer to your question but I had defined my functions in assembly and had created DLLs. The calling method and prototypes was important. I had defiend for my sample function followin prototypes in C# .NET and calling was OK without problem:

   public class MyFuncsCall
   {// Declares managed prototypes for unmanaged functions
      [DllImport("MyDLL.dll")]
      public static extern int MyFunction (int Var1, int Var2); 
        }