I close all my files but only at the end of the proc when everything is done (right at label Read_Done).  The thing is that the reading and writing works fine if I comment out the SetFilePointer line.  Also if I set a number instead of the argument "KeyOffset" it also works fine and sets the pointer.  So there is something wrong with my variable or how I handle it.  I popped up a message box with the KeyOffset as the message and it showed the ascii character of the number I passed through so I am really stuck here as to what is wrong.
Posted on 2007-05-19 10:28:11 by Command_Prompt
FILE_BEGIN indicates that KeyOffset contains an UNSIGNED zerobased offset.
Is the number you passed smaller than the size of the input file?
It better be, or else SetFilePointer will fail.

Posted on 2007-05-19 12:51:33 by Homer
Hey Homer, thanks for the reply.  I passed 46 when I was testing it and the file is just over 3kb.  When I simply put 46 in the place of KeyOffset in the code it works fine.  Hence my confusion.
Posted on 2007-05-19 14:37:23 by Command_Prompt
Maybe the VB passes the value as 64-bit? I don't know much about VB, so I don't know any of it quirks and 'features'.

; Set file pointer in source file
  Invoke    SetFilePointer, hInFile, KeyOffset, NULL, FILE_BEGIN
  Cmp BytesRead, 0FFFFFFFFH
  Je Read_Done

What are the bottom 2 lines supposed to do? I don't see the 'BytesRead" value being set anywhere. Shouldn't it be "cmp eax, 0ffffffffh" ?
Posted on 2007-05-20 17:28:08 by ti_mo_n
Yeah that was a mistake in the coding.  I fixed it not too long after I posted it.  So great news (for me!)  I got the whole thing working, encryption and decryption routines and all.  The VB program is working great with it and no problems.  Here is a sample output from my program from encryption of a 10mb file (just a test run.  Notice the HUGE difference in time between my old VB code and assembly code! :D :D :D :D :D  54 seconds vs. ~1! 

VB Code results.  Encryption size 10,000,000 bytes:
Start time: 22:21:26, Stop Time: 22:22:20

Assembly Results.  Encryption size 10,000,000 bytes:
Start time: 22:22:20, Stop Time: 22:22:21

Thanks for the help guys!  I couldn't have done it without the help from this board.  Needless to say I am sold on asm for life! :P :P :P :P :P :P :P :P :P :P :P :P :P
Posted on 2007-05-20 22:54:40 by Command_Prompt
Some people will tell you that you are climbing onto a sinking ship.
You won't find them here.

Welcome aboard!  8)
Posted on 2007-05-21 09:12:56 by Homer
...And then another minor problem surfaces  :P.  The Procs now run fine in the development environment of VB as well as in the program after it is compiled.  The last line of code is reached (as verified by adding a quick message box line) but the compiled program gives me an error after it exits the proc saying "Object Variable or With block variable not set".  I am thinking maybe my stack has something in it that VB wasn't expecting, like a pushed value that I didn't pop back out (but I don't see where).  Any sugestions?  Are there any registers I should push prior to beginning and pop prior to the end?
Posted on 2007-05-21 13:03:34 by Command_Prompt
Nevermind...I answered my own question.  A simple PushAD at the beginning of my proc and PopAD at the end before the Ret solved everything!
Posted on 2007-05-21 14:01:19 by Command_Prompt

I've stayed out of this thread mostly because I don't know VB and I don't know anything about the internal workings of VB. But I know VC++ is notorious for using the ECX register when using classes for holding the object pointer (the 'this' keyword) in methods. Considering the developers, "Object Variable or With block variable not set" might be due to the use of ECX in your program. Try adding 'USES ECX' to your procedure instead of PushAD/PopAD (just to save some stack space). If that doesn't work you might need the PushAD/PopAD but my guess is it's probably some part of VB pissed off about not having the object pointer.

MyProcedure PROC uses ECX Arg1:DWORD, Arg2:DWORD, ArgN:DWORD

USES will handle pushing and popping of ECX for you, wherever needed. Like I said though, I'm not familiar with VB but if it follows the same conventions as VC++ then this is most likely your most recent problem, and can save you a little stack space.

Bryant Keller
Posted on 2007-05-22 13:26:31 by Synfire