Inserting Asm code into a VB Dll.

What I have is this:

ActiveX DLL to do work, via an html.
Assembler code to format a large file FAST.

What the problem I have is:

A 512k text file that requires formatting before the ActiveX DLL can safely navigate it. The assembler code will do this, but, I don't want another DLL. I want to be able to hide the assembler inside the DLL (in another module?!) and be able to call it within the DLL as normal (and be able to access it dynamically). Pass parameters, etc. Since it needs to work with an in buffer and an out buffer (can get as large as a couple megs for each). Doing a 512k file in VB takes 2 minutes. Nobody in their right mind would wait that long. I want to cut it to 2 seconds or less.

The formatting is for streamlining, lowercase conversion, formatting of the data (validating it too), all in one shot. I've laid out the code in vb in a structured manner that will work with assembler (I prototyped) and should be able to write the assembler in short order (as I've written in other assembly languages before). It's just the "hooking" of the two together so they're one file and one "mind". :)

Anyone do this before that has found the best way to do this?

The VB compiler/linker is to the best of my knowledge not capable of linking to other object files.

You can directly edit the exe, but this is rather complicated. (and you have to repeat it everytime you recompile).

Maybe there is a way to get object code from the VB compiler, then you can use a normal linker to link it against your assembly.

But I don't think you can cut the time to 2 seconds, this is an improvement by a factor of 60! The best I managed when replacing VB with C was 10:1 of my code vs. the interpreted VB code (array heavy, but my C was a simple copy/syntax change). After all, it would take about a second to locate and load a heavily fragmented 512k file and writing it back to disk without any processing...

There seems to be no way to include it. Only thing I can think of, is save the assembler as a binary file and include it as either data or a graphic. Then use the addressof and call it from within.

As for the code, I'm not including the load time. The entire file is loaded by VB, the code will just merely re-format it in another buffer area that VB also will provide. The string concat and manipulation causes heavy overhead (in excess of 1 min 30 seconds). The actual conversion with VB (without the search) takes 30-35 seconds, adding the search for duplicate lines takes another 1:30, only other way would be to CRC the lines and match against them (another dword list, but easily done in asm). Since the code is dealing with that entire file on a byte level, yes, 2 seconds should be possible.

Just how to actually put the assembled file into VB so I can access it. (The entire file will be dynamically addressed, so it will run anywhere.)

You could include the assembled file as a binary resource, then use the VirtualAlloc API call to reserve memory that is large enough to hold the code, give it execute permission, copy the resource there and somehow call it.

Problem is, I don't know how to call there without using a C dll, but that's not what you want. Maybe you find a harmless windows function with a callback that you could abuse.

To any processor, all I really need is a safe spot in the DLL to store the code (as a data stream, heck even a string could hold it) and then go from there, or worst comes to worst, have it make a string the full length, read data (the code) in and store the code in a string! And store the data for the info there as well and then call it (each time, a waste of time if I can't just have a raw data of some sort).

Just what I said, but I don't know how to call random code in VB.

If you use API calls, your Declare function gets the offset in memory to the function, the call merely calls the code, presetting all the pre-requisite registers with the values needed for the call (which is as far as I know an assembler call to a jump table).

I wish that VB was a little more asm friendly.

That's not a random code location. This is a well-defined address in the dll, which is obtained using windows API calls and which is called to using a built-in VB syntax.

Maybe you can trick the declare syntax into accessing your code - but then you'd need an export table in your dll...

The DLL gets loaded into memory somewhere.

The Declare Function does a lookup on the dll it's referencing and gets the offset of the code in the library and when you do the actual call, it goes direct. (Thats why if you get the declare before someone else changes the API call by a hook, you don't get the hook.)

Just wish I could GET assembler code to run via VB, without adding another DLL for no reason. :/

You can link seperate .obj files via VB :)

Hook the compile process. Patch the IAT table so that you intercept CreateProcess() and you have it...

Download the artice and sourcecode :)

Thanks Elche, I've been looking for a means to DO that. I just didn't want two DLL files for something that's going to be rediculously small.

I'll do some "digesting" on that zip file and read it over a few times before I attempt doing anything with it. (I just hate crashing the machine.)

Have you used it? Also, I guess doing it inline would be okay.

Why not make a MASM DLL then use the function in that to format it, you would have to call that function before using your ActiveX dll but that shouldn't be a biggy.

Quote:

---

Why not make a MASM DLL then use the function in that to format it, you would have to call that function before using your ActiveX dll but that shouldn't be a biggy.

---

Problem is, the ActiveX will consistantly need to use it, and with it being less than 1K in size, it makes little to no sense to have it separate.

OK i just thought you only needed it before you used the ActiveX dll. I think the otherway maybe buggy/a pain in the butt to do though.

I downloaded this project from PSS.
http://www.planetsourcecode.com/vb/s...DE%5F126387411

it uses a compiled asm (as a string) in vb to be execute using the callwindowproc...


So it looks to me U CAN USE ASM FROM VB WITHOUT DLL

But lost the web address. :)

Now all I need is some aid in references to the Intel chipset instruction set for x86. Finding that is like pulling teeth on a lion with a truck. Won't seem to happen (atleast netwise).

Any ideas anyone? And anyone know of a way to force that string to stay PUT while the call happens? (So good ol' GC doesn't go "Hey, lets do some cleanup.")

:/

Shouldn't the string stay while you have a reference to it in the calling function?

Here's the Assembly reference I use.
http://webster.cs.ucr.edu/Page_TechD...386/0_toc.html

well you might find some neat stuff overhere :


http://www.programmersheaven.com/zon...article157.htm

ps. enjoy the blue screens ;)

Apparently, garbage collection can happen during the course from when you get the address of the string location and when you make the call (thus moving the string in memory).

There's a way around it, just merely have to make an UGLY looking call. But apparently others have run into it. I read somewhere that the best way to avoid it is to ensure the string doesn't move by calling directly afterwards, but there's no guarantees, since once the string is made, the call can cause a pre-usage garbage collection. :( I'm still tinkering on that part.

Thanks for the two sites, I'm super busy with another project at current, that doesn't cause BSoD's, but I love when the IDE goes flop (no wait, I don't, grumble).

BSoDs are the least of my worries. :D Next I've got to start patching into system calls. (Now won't THAT be fun.)

Yeah, you'd need a __pin keyword like the managed extensions for C++ have, which prevents the data from being moved...

Quote:

---

Originally posted by CornedBee
Yeah, you'd need a __pin keyword like the managed extensions for C++ have, which prevents the data from being moved...

---

And how to do that exactly. Only thing I can think of is the very first variable setup is a data type with a string, limited to the length + 16 (for safety sake), that's what I figured was my best bet, but last time I checked gc goes both ways. :( Just wish MS would put some control into VB to let US say "Do the GC now, it's the best time for it", so we can use it during pause times. Grumble... Just wish I can solve the C2 crashes so I can compile stuff without rebooting.

Now if I can only find a better way to pin that string still...