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...
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
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.
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
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).
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).
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...
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
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. :/
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.
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.
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.")
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. Next I've got to start patching into system calls. (Now won't THAT be fun.)
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...
Inserting Asm code into a VB Dll.
Reply With Quote
CornedBee
I'm still tinkering on that part.
Next I've got to start patching into system calls. (Now won't THAT be fun.)
