Using VB6 Obj files from CAuthor: David Zimmer Date: 05.22.20 - 5:32am So yesterday i spent the whole day on a curosity just to help understand its limits and structure. What you are about to read is an experiment and me being a bit of an asshole to the compiler (and myself). In previous articles we have seen how we can swap out vb native obj files at link time and replace them with C obj files to produced mixed language binaries. (ie. include the C sqllite library in a VB6 activeX dll with no external dependancies) References include:
Sub Main() 'we must call the funcs or optimized out in native compile.. add 1, 1 msg End Sub Function add(ByVal a As Long, ByVal b As Long) As Long add = a + b End Function Function msg(Optional ByVal x As String) As String msg = "test: " & x End Function we use linktool to save the obj file so not deleted. saved as native.obj SAVE Module1.obj native.objThen we turn the obj into a lib vcvars32.bat lib /out:simple.lib native.objNow the name mangles in the lib file are for a private class function with no args ?add@Module1@@AAGXXZWe need them to be public so we have to hexedit the lib file to be QAGXXZ so that it matches the following class prototype that is usable for us. class Module1 { public: void __stdcall Module1::add(); void __stdcall Module1::msg(); }; We also had to build a lib for msvbvm60.dll vcvars32.bat dumpbin /EXPORTS msvbvm60.dll > msvbvm60.exports parse outfile and manually build def file from it lib /def:msvbvm60.def /out:msvbvm60.libNow we try to compile and see what shakes loose. Bunch of missing externals. some imports needed fixed up: __imp_@__vbaStrMove -> __imp____vbaStrMovesome imports need to be recreated with another temp lib we create ___vba@0851F380 #define DllExport __declspec(dllexport) __int64 DllExport saFlags = 0x000200920001; -> saFlags@@3_JA BSTR DllExport mTxt = SysAllocString(L"test:"); -> ?mTxt@@3PAGASome of these numeric symbols are:
To get the mangled names of your new symbols you have to grab them from the new lib, and then patch them into the vb lib. You can directly patch the vb lib to change the names of these extra imports so long as you dont exceed their original length. Their start offsets must be held elsewhere in teh file. You can shorten them and null out the rest of the buffer and the next one will still load ok so its not just a simple read till null to read the sequential list (thankfully for us) So with all of that done, and now we actually linking correctly! We still need to initilize the runtime to use it. See previous paper Reusing Pcode Functions Also our prototypes are wrong. Our add function is not void void. We need a usable function pointer to a class member function in an external lib :- //Public Function add(ByVal a As Long, ByVal b As Long) As Long typedef int (__stdcall *VBADD)(int, int); VBADD vbadd; typedef void (__stdcall Module1::*tmp)(); tmp p = &Module1::add; _asm{ mov eax, p mov vbadd, eax } So now we can call at least basic functions in a VB obj file from a C host. Totally not worth it! As with all first stabs, they are likley way overly complex. Maybe there is some elegant solution to all of this and I am a moron. I kinda hope so! I will poke some more at it if I get bored, I dont see this being useful, but it was an interesting learning curve in manual object file manipulation to make name mangles align. That crowbar could come in useful latter on in life anyway. We can also generate VB6 PCode Obj files to play with, that will have to be a different day. If your a masochist you can download the samples and play with it yourself. Comments: (0) |
About Me More Blogs Main Site |