can i use VB6 created dll in assembly? i have several dll created with visual basic 6 and i want to know if i can use it in assembly program or do i have to recreate them with assembly.
Posted on 2003-12-23 03:38:28 by <null>
Yes, you can use a dll created in any language, but its even easier if you have the LIB file for that dll. In this case, you can includelib and call the functions by name. Otherwise, you need to load the dll manually, and then find named function addresses individually and store them in variables.
We can call functions from ANY language in asm. Even if the dll is actually not a basic dll but a COM Object we can still call VB methods from asm. Everything is possible, and chances are, you can search this board for the answer you seek.
Posted on 2003-12-23 03:54:22 by Homer
thank EvilHomer2k

i think i still have the tutorial about dll here somewhere. i posted this because i want to be sure it can be done before wasting time translating these dll in assembly. i guess reinventing the wheel is an awful waste of time.
Posted on 2003-12-23 04:29:33 by <null>
I am trying to call a function in a VB6.0 dll without success. I searched the board and found this thread. It would be very interesting if someone could show me how to call a VB dll. I have attached a simple example of an asm dialog app and a VB dll. I have compiled the dll and have the lib file but I can't create a inc.file because the function name doesn't exist in the lib file.

Best regards
Posted on 2004-05-23 14:19:07 by minor28
You need to learn how to use COM. Look at the COM section on this board or ask Japheth. He does a lot of COM stuff.
Posted on 2004-05-23 14:42:06 by evil__donkey
Well, I know a little about com and assembler. Is a VB dll always a com object? I took EvilHomer2k's statement
Yes, you can use a dll created in any language, but its even easier if you have the LIB file for that dll. In this case, you can includelib and call the functions by name.
that you can use a VB dll as any other dll. Isn't this correct?

Best regards
Posted on 2004-05-23 15:24:33 by minor28
Not exactly, the quote is taken out of context.

VB generally uses OCX files which are actually a renamed DLL file.
These are not ordinary DLL files, they are COM based.
COM DLLs are easy to recognize because these DLL's only export the same handful of named functions, and always use the same names for them.
It is through these functions that the rest of the functions are accessed.
COM can appear quite confusing at first, don't despair..
Posted on 2004-05-24 00:46:50 by Homer
I must say that it is considerable more complicated to use a VB dll in your application than you think. As far as I know you don't use the lib file. When VB compiles the dll it is registred in registry. All information about the dll is retrieved from registry. I used my COM.exe to retrieve the information.

The dll has only one function, Message. The Message function generates a string. The string i shown in the dialog edit box.

I attach the VBdll project.
Posted on 2004-05-24 10:15:39 by minor28
That's correct - there's no need for the .LIB file in general, but what of COM DLL's which were NOT created by VB (maybe in MASM?), or simply have never been Registered to the OS? There's no problem: one of the standard exported functions for a COM DLL is called dllRegister, ands its job is to Register the COM DLL with the OS.. in fact, if you use the command REGSVR32 to register an ocx (com dll), that command loads your DLL and calls your dllRegister function - please read that twice - ITS YOUR FUNCTION that is being called, and part of writing a COM DLL is writing that function.
Assuming that the DLL has not been registered to the OS, we could do it ourselves by loading our DLL and calling the function ourselves.
Now this is where the .LIB file comes in - lets say for arguments sake that the COM DLL (the server) is yours, that you wrote it, then you have the option to not use a DLL at all, but embed the DLL within your executable (the client), and have your executable register "itself" as a COM server, such that both halves of the COM contract are located in the same file.. all you need to do is ensure that the executable exports the standard set of COM DLL exported functions.
Can a VB programmer get away with that ?

Another point of interest is the "Invoke Method" exposed by IDispatch interfaces - this is a function we write which simply calls other Methods that may or may not be public - from an ASM point of view, and assuming that the Virtual Table is not being messed with, we simply don't need to call Methods via the Invoke Method, we can call them manually via the vtbl.

My comments may provoke some rethinking of the COM architecture in relation to the call overhead introduced by the utilization of abstracted calling conventions, or they may sail over your collective..

Have a nice day :)
Posted on 2004-05-25 00:42:13 by Homer
I am not sure I can follow your reasoning. But I have found 4 exports items in my dll (DllCanUnloadNow, DllGetClassObject, DllRegisterServer and DllUnregisterServer). With this complement to the asm code I can register and unregister the VBdll.
.if eax==WM_INITDIALOG

invoke LoadLibrary,addr szVBdll
mov hVBdll,eax
invoke GetProcAddress,hVBdll,addr szDLLRegisterServer
call eax

.elseif eax==WM_CLOSE
invoke EndDialog,hWin,0
invoke GetProcAddress,hVBdll,addr szDLLUnregisterServer
call eax
invoke FreeLibrary,hVBdll


Now this is where the .LIB file comes in - lets say for arguments sake that the COM DLL (the server) is yours, that you wrote it, then you have the option to not use a DLL at all, but embed the DLL within your executable (the client), and have your executable register "itself" as a COM server, such that both halves of the COM contract are located in the same file.

I suppose this embedding thing ?s not conserning VB written dlls. But if so how to do that?

Best regards
Posted on 2004-05-25 11:28:51 by minor28