MASM32 and Visual Basic 6 interfacing?

[Magus 1011]

How do I go about interfacing MASM32 routines to Visual Basic 6?
Is it as big of a pain as MASM to DOS and BASIC were?

--
Best Regards,
Magus

[hutch--]

Its more different than difficult. What you need to get the swing of is setting up the VB code to directly call procedures written in a MASM DLL. You can go the other way and write dedicated interfaces for VB but its a lot more work. MASM routinely handles both STDCALL and C calling conventions so just work out the calling capacity you have in VB6 and it should be no problem.

[Magus 1011]

Thanks Hutch that's what I needed to hear. I'm off to give it a try then.

--
Best Regards,
Magus

[John]

Here is an example of doing just what you are looking to do. I did this a while back just see if I could get it working.

I hope you find it useful.

[attachment deleted by admin]

[Magus 1011]

Here is an example of doing just what you are looking to do. I did this a while back just see if I could get it working.

I hope you find it useful.

Very! :U Thank You!

--
Best Regards,
Magus

[Robert Collins]

Here is an example of doing just what you are looking to do. I did this a while back just see if I could get it working.

I hope you find it useful.

What is the purpose of the below two? I downloaded the file, commented out the two statements below and the program works exactly the same as though they were not commented out.

Code Select Expand


Private Sub Form_Load()
   hModule = LoadLibrary(App.Path & "\ASM.dll")
End Sub

Private Sub Form_Unload(Cancel As Integer)
   FreeLibrary hModule
End Sub


[John]

LoadLibrary will load the DLL and FreeLibrary will unload it.

The time when you would notice a difference is if you were to uncomment the code in the following section of the ASM DLL then rebuild it and place it in the same directory as the VB APP:

Code Select Expand

.if dwReason == DLL_PROCESS_ATTACH || dwReason == DLL_THREAD_ATTACH
    ;invoke MessageBox, NULL, addr DLLName, addr DLLName, MB_OK
    pushf
    pop flags
;.elseif dwReason == DLL_PROCESS_DETACH
    ;invoke MessageBox, NULL, addr DLLName, addr DLLName, MB_OK
.endif

You will see that the library will load right away when the application is loaded. If you remove the LoadLibrary call from the VB app the DLL won't be loaded until the first time you use it.

[Maven]

If you need to work with arrrays in visual basic, you may find the following structures useful as visual basic passes all arrays as OLE_SAFEARRAY.

Code Select Expand


      SAFEARRAYBOUND struct
            cElements       DWORD ?         ; Number of Elements
            lLbound DWORD ?         ; Lower Boundary
      SAFEARRAYBOUND ends

      OLE_SAFEARRAY struct
      cDims WORD ?         ; Number of dimensions
      fFeatures       WORD ?         ; Bitfield indicating attributes
      cbElements       DWORD ?         ; size of an element of the array
          cLocks DWORD ?         ; lock counter 0=Locked
      pvData DWORD ?         ; Pointer to data
      rgsabound             SAFEARRAYBOUND <>         ; Contains info for dimensions
      OLE_SAFEARRAY ends



Example usage:

Code Select Expand


testfun proc bArray:DWORD
mov eax, bArray
mov edx, [eax] ; Edx is now a safearray ptr.

; Store total number of elelments in array into ecx
mov ecx, (OLE_SAFEARRAY ptr [edx]).rgsabound.cElements

ret
testfun endp


[Robert Collins]

LoadLibrary will load the DLL and FreeLibrary will unload it.

The time when you would notice a difference is if you were to uncomment the code in the following section of the ASM DLL then rebuild it and place it in the same directory as the VB APP:

Code Select Expand

.if dwReason == DLL_PROCESS_ATTACH || dwReason == DLL_THREAD_ATTACH
    ;invoke MessageBox, NULL, addr DLLName, addr DLLName, MB_OK
    pushf
    pop flags
;.elseif dwReason == DLL_PROCESS_DETACH
    ;invoke MessageBox, NULL, addr DLLName, addr DLLName, MB_OK
.endif

Thanks John, I understand the difference.

You will see that the library will load right away when the application is loaded. If you remove the LoadLibrary call from the VB app the DLL won't be loaded until the first time you use it.

[Mark Jones]

Hi, at university the C++ class was changed to a VB 8 class just this semester, so I (reluctantly) am learning VB 8. So far, it's been pretty good actually, although the executables are larger and of course you have nowhere near as much control in the code. But it's effective enough.

Question: calling ASM functions from VB is possible through an ASM DLL. But can this be done in reverse? i.e. Can an assembly program call functions in a VB DLL? And what is required for this? COM? ActiveX? I ask preemptively because VB seems harder to "hack" than assembler, and if I wanted to implement some security in my program, it seems reasonable that writing a routine in VB and calling it from assembler would increase the overall security. Anyone try this? Or is it pointless? Comments welcome please.

[Robert Collins]

Haven't done it but it would appear that it wouldn't matter which language a DLL was written in so I will say that yes you can call functions from a VB DLL in an Assembly program as long as it is a valid DLL. Why not I ask?

[Rockoon]

VB6 DLL's will obviously have a depenency on the VB6 runtime library (a quite large DLL.) Not so obvious is that these DLL's are full blown OLE COM servers.

VB8 isn't VB6. VB8 DLL's are fully managed by .NET so again you are dealing with a large runtime library, but these DLL's are not automatically OLE COM servers (although I think you can swing that with a flag or two in the IDE)

VB6 uses the STDCALL calling convention with one small tweak. Functions which return structures of 64 bits or less do so in EDX:EAX.

[zooba]

Rockoon is correct, .NET assemblies can be made COM-visible and that is probably the only way to call into them. The DLLImport attribute is the easiest way to call out from a .NET assembly.

For those interested in linking VB6 (and possibly later versions? I haven't tried) properly (as opposed to Declare Function ... Lib ...), I have attached the source of my SQLiteVB project which wraps SQLite into a COM DLL. The .odl file contains the definitions and there are examples throughout of using BSTR, VARIANT and SAFE_ARRAY. (Note that there isn't enough provided to actually build the project, but there should be enough to get an idea of how to do it.) The .odl file should be compiled with the MIDL tool (comes with the Windows SDK) and linked with the rest of the DLL.

Cheers,

Zooba :U

[attachment deleted by admin]

[sluggy]

Rockoon is correct, .NET assemblies can be made COM-visible and that is probably the only way to call into them. The DLLImport attribute is the easiest way to call out from a .NET assembly.

Calling from asm in to a .Net assembly can certainly be done without the use of COM interop, although it isn't as simple as going the other way. What you need is a mixed mode (CLI/C++) assembly, this is a single assembly that is a mixture of native C++ and fully managed C++. You call the native C++ exported functions, which then call in to the managed functions. This has complications because your assembly cannot be trusted due to the native C++ being marked as unsafe, and you have to do a lot of manual marshalling of parameters (you will spend a lot of time trying to get this bit right). You can only use C++, because that is the only .Net language that can be used for mixed mode unsafe code.

It's not easy, but it is satisfying once you get it to work. No promises, but i have a project that does this sitting somewhere on an old machine, i will see if i can dig it out (time permitting - it means i also have to install VS2003 to check that it is in working condition, it has been about 3 or 4 years since i last touched that project).

[ecube]

You can interface vb's dll's via com, it's usually pretty annoying,theres a few com example in the masm package, one for vbscript which is useful, but theres also a way to make a "regular" dlls in vb that you can easily call in your asm programs, you'll have to look around abit for an example, planetsourcecode probably has one.