VB Decompiler Forum Index VB Decompiler
Hosted by TheAutomaters.com
 
  MemberlistMemberlist
 

VB Stdcall DLL used from C

 
   VB Decompiler Forum Index -> Visual Basic
Author Message
dzzie
New User


Joined: 21 Dec 2003
Posts: 3

Posted: Thu May 20, 2004 11:15 pm     Post subject: VB Stdcall DLL used from C

Figured this is about a good a place as there is to ask this.

Using various tricks you can get VB to output a stdcall dll, however dlls made in this manner can only be run from other VB apps because the runtime is not initalized and vbvm functions all fail.

I have been playing with just to see if I could get it to tick..anyway I want to see if I can create a VB plugin for olly or even just get the functions to work successfully when called from any C program.

after allot of playing around in debugger and disasm, I have been able to get the default vb functions to operate under these conditions, they do not error out anymore at least.

I patched dll main in my dll to call msvbvm60.CreateIExprSrvObj with args 0,4,0 and it is enuogh to initalize tls and ole pointer table, but I think something else is still off ...a quick test to one of my exported functions with msgbox still did not work.

Has anyone experimented with this and had any luck?

yes I know I need new hobby
Back to top
Anonymous
New User


Joined: 10 Feb 2008
Posts: 0

Posted: Sat May 29, 2004 6:16 am     Post subject: This should get you started...

There are some tools which allow you to use asm, or even VC objects. The good news is there's a free one, it's found here http://johnchamberlain.com/ccupdates.html and it totally rocks. It's actually written in VB itself, as a VB addon. There are also two other names that pop up in the back of my head, AdvanceVB and TweakVB or something, but they're both no pay no play.
Back to top
dzzie
New User


Joined: 21 Dec 2003
Posts: 3

Posted: Mon Jul 05, 2004 8:01 pm     Post subject:

here is an interesting solution,

do the stdcall dll thing, the base project is exe type with linker intercept to add the exports and compile as dll...

then to initilize the vb runtime, he calls his own create thread passing in original exe VB5 struc, sub main has endless loop.

after create thread, he suspends it, changes eip to point back to his code
in C project where it then resumes

I did not try his tool to generate the dlls, i used another and get intermittant crashs, his tool may make other tweaks (at least one i know of embedding **strucVB5 at MZ+7

anyway interesting technique

http://www.Planet-Source-Code.com/vb/sc ... 2&lngWId=1
Back to top
Libor
New User


Joined: 11 Aug 2004
Posts: 13

Posted: Wed Aug 11, 2004 8:56 pm     Post subject:

Hi,
i managed to make stdcall DLL.
I tested forms, msgbox, classes...and all worked well.

No I work with my friend on vb add-in that will allow to compile stdcall DLLs, do inline ASM...

You have to call ThunRTMain to do initializing...but there is a problem...maybe you know about it....

What does this API - msvbvm60.CreateIExprSrvObj - do?

The code using SetThreadContext is quite interesting.

Libor
Back to top
Libor
New User


Joined: 11 Aug 2004
Posts: 13

Posted: Wed Aug 11, 2004 9:06 pm     Post subject:

VBINLINEASM - maybe you know it

http://www.persistentrealities.com/vbfi ... em=5&t=asm
Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Tue Aug 24, 2004 11:59 am     Post subject:

I've never needed to call ThunRTmain from my dll's. The real problem is that by linking your own DllMain you bypass the UserDllMain call that the normal __vbaS start would make.

That's crucial as it initialises the DLL's thread context correctly - otherwise, as soon as you touch anything related to the global object collection (accessed via a TlsIndex), you're cactus!

Suggest adding UserDllMain to your DEF file, so you can call it in your DllMain before returning ... should make a difference

Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Tue Aug 24, 2004 12:12 pm     Post subject:

RE: "INLINE ASM"

I'd hesitate before recommending complicated systems like that. Do you really need "inline asm" in the strict sense of the term?

I got bricks hurled at me for referring to my "just-in-time" ASM system as "in-line" in another forum, actually! But they had a point, I concede...

Just-in-time code injection is cleaner, easier, requires no add-ins, either ZERO or ONE external api (0 = dummy VTable, 1 = CallWindowProc), and so leaves vrtually no footprint, and all with standard VB6 code, and all without yet another add-in.
Back to top
Libor
New User


Joined: 11 Aug 2004
Posts: 13

Posted: Tue Aug 24, 2004 8:50 pm     Post subject:

your new post-
add-in - source code and documentation will be avaible
no externals will be used in StdCall DLL

DLLMain-
I know about __vbaS problem

Inline ASM-
If you like editing .lst files...I rather use writing ASM code in VB IDE
CallWindowProc and VTable - quite nice methods, but editing .lst is better
Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Tue Aug 24, 2004 10:26 pm     Post subject:

Libor, that's cool, I wasn't criticising your work, in fact I didn't realise you were actually building a product, just discussing your private research...

It sounds like you are going along pretty well .... although I have serious reservations about using the EXE project template`- what made you choose that path, if you don't mind me asking?


Can you tell us why you chose that path in the first place?
Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Wed Aug 25, 2004 7:31 am     Post subject: Dr Memory says "DOH!"

Libor: you can cheerfully ignore my last comment!

I think I understand now - you're building a smart add-in for sale, that will let the customer produce VB dll's that are API callable, have their own GUI's, and, most importantly (!) can be called by ANYBODY, yes?

You confused me from the start with the term "stdcall dll's", since all VB dll's are exclusively stdcall already! You meant that the thing was API-driven rather than COM-driven, "stdcall-able"!

Am I right? It would certainly explain your preference for an EXE project template - that's what I'd do (well ok, that's what I did)

It all sounds quite impressive, actually ... are you near to beta-test stage with it yet?

Keep up the good work!

BTW: Did you come across a bit of a link problem at some stage?

emphasis on "bit"!
Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Wed Aug 25, 2004 7:52 am     Post subject:

"This is not an executable file" I think was the message in question
Back to top
Libor
New User


Joined: 11 Aug 2004
Posts: 13

Posted: Wed Aug 25, 2004 9:17 am     Post subject: OK

OK
add-in will be freeware+source codes+documentation

Now, I do not have time to write info how Add-in will do/make StdCall DLLs. But surely I will write it.

StdCall DLL = template is Standart EXE project, not ActiveX DLL
DLL could be used in other languages - I have tested ASM and C.

I have written small msvbvm60.dll pre-loader that will initialize TLS. (pre-loader" is set of ASM functions (about 700 lines of code))

now working on Add-in Gui

And problems with Link?
I have not had any problems, but my friend (he writes code to allow inlineASM and even inlineC) has some.
In CompileController package there is a DOC file where problem is described - C2 produces wrong LST files - it uses same name of variables...sure you know it
Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Wed Aug 25, 2004 12:49 pm     Post subject:

G'day...


  • Freeware

    Great! let me know if I can help perhaps ... I've learned a few useful tricks[/*:m:1dmocirv]


  • "StdCall DLL"
    They are still all DLL's, and if they export functions you can call them from any language using StdCall! DllGetClassObject, for example!

    Calling of course, is one thing, functioning is another ....[/*:m:1dmocirv]


  • TLS initloader

    Curious and unclear as to why you need this ... are you binding your own copy of the lib or using the shared one?[/*:m:1dmocirv]


  • Yes, the bug with the listings was a classic! The LINK problem I had was simply that the DLL I get doesn't have the DLL bit turned on. It is perfect in very other respect, my CC just waits for the LINK to finish and hits that one bit! I've never followed it up as it's not really a problem[/*:m:1dmocirv]


  • Primary function?
    Is it your Inline ASM system in fact the main focus of the proposed product? Ok, so that's why you want the preloader I guess...[/*:m:1dmocirv]


Sounds like you're having fun ...

Cheers!
Back to top
drk||Raziel
New User


Joined: 25 Aug 2004
Posts: 8
Location: Athens

Posted: Wed Aug 25, 2004 2:34 pm     Post subject:

Hi ,
I'm the guy working with Libor..

The loader is needed to get the VB runtime to work...
The main idea was to create standar dlls but assembly was
needed so .. The target is to make VB better , in anyway possible
(inlineAsm , InlineC , much more ideas )

And yeah ... we 're having fun
Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Wed Aug 25, 2004 6:45 pm     Post subject:

Ok, great, look forward to hearing further progress
Back to top
dzzie
New User


Joined: 21 Dec 2003
Posts: 3

Posted: Sun Sep 12, 2004 12:12 pm     Post subject:

I am not really sure what the CreateIExprSrvObj export does, I had just traced out some branches of execution and noticed that it made its way to an internal pointer initilization table which the root of the first crash I was encountering with VB runtime not being properly initilized. Was just a shot in the dark to see if I could find a quick hack to get the runtime initilized with out to much more work.

I will definatly have to check out the vbinline asm, i saw a listing for it on psc but it was removed before I could check it out. Looking forward to it.

I ended up finding a solution to what I was originally after by just creating an instance of the VB ActiveX object from VC project and then calling a method on one of its interfaces.

I didnt want to get into full on COM programming in my VC project, but doing just that much is enough to make it handle all loading and initilization of VB runtime automatically.

After that you can just use stdcall exports from VC project along with VBs native declare function mechanism to interact with each other.

http://sandsprite.com/CodeStuff/VB_Plugin_for_Olly.html

It would still be interesting to look at what steps COM takes to initilized vb runtime for loading active x dll....not sure if that is some custom dll main code in active x server or mabey some framework standard exports of it.

Dr Memory I will definatly have to check out the info and code in your other posts too looks pretty slick
Back to top
Dr Memory
Expert


Joined: 16 Aug 2004
Posts: 147
Location: Surrey, UK

Posted: Sun Sep 12, 2004 3:36 pm     Post subject:

Cheers!

I actually began all this a few weeks ago with a bit of sample code that did just that - manufactured a genuine DllGetClassObject call from the client...

My mission has been to move it all into the dll itself, fully automate it, so the user just makes a call to any server function, and hey presto .... the dll is self-initialising ....

The original sample was by Olaf Schmidt, a little thing called GetInstance, or CreateInstance, something like that ...

The very name CreateIExprSvrObj seems to suggest "Create Internet Explorer Server Object", I imagine that supports the plugin browser control .... this is just a guess, though

(later) and probably a poor one, DOH (that would be ComCtl32) ...

It's more likely to be related to VBA services for the browsers, as I imagine cookies are often VBA (still guessing, but perhaps a little better now? )

I can see that it does call "IsVBAInitialised" before doing anything else, so I imagine it's the primary entry point for that interface, (interface with a capital I, too, I imagine)
_________________
[size=75:2sg2dqh1]At first, I was irridescent. Then, I became transparent. Finally, I was absent ...
Back to top
Welf Wiest
New User


Joined: 15 Dec 2007
Posts: 4

Posted: Mon Dec 17, 2007 10:50 am     Post subject:

I solved the problem of mixing a visual basic ole dll with C++ Obj Files and linking them correctly to a working dll.
My approach was to specify a new entry point to then linker. From the new entry point I call both _vbaS and CrtMainStartup.
Critical was the point: all Dll Imports of the C++ Code requires DelayLoad to avoid conflict with the VB Compiled Code (Kernel32 replaced by Kernel3x).
From this I get a mixed VB / C++ Dll with arbitrary exports.
Optionally I make a hook to msvbvm60.VBDllGetClassObject Import, so the C++ can also expose Class Factories
Back to top
   VB Decompiler Forum Index -> Visual Basic All times are GMT
Page 1 of 1

 
You can post new topics in this forum
You can reply to topics in this forum
You can edit your posts in this forum
You can delete your posts in this forum
You can vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group