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
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.
Thanks Hutch that's what I needed to hear. I'm off to give it a try then.
--
Best Regards,
Magus
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]
Quote from: John on December 20, 2004, 02:02:11 PM
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
Quote from: John on December 20, 2004, 02:02:11 PM
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.
Private Sub Form_Load()
hModule = LoadLibrary(App.Path & "\ASM.dll")
End Sub
Private Sub Form_Unload(Cancel As Integer)
FreeLibrary hModule
End Sub
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:
.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.
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.
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:
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
Quote from: John on December 20, 2004, 08:23:10 PM
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:
.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.
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.
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?
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.
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]
Quote from: zooba on February 20, 2008, 01:00:24 AM
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).
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.