Delay between Masm assembling a program and the program starting

[jimg]

The attached file contains two versions of a program.  The only difference is that  TimeTest2.asm has the very last two instructions, nop's commented out.

Both seem to assemble and link in the same amount of time, almost instantly.  The problem is that there is an extra two second delay before the first program shows up on the screen.  If you run makeit.bat, you will see it take over three seconds for the program to show on the screen.  If you run makeit2.bat, it takes about one second to show.

Please bear in mind that this is not a functional program,  I stripped out stuff until I got down to the magic size that causes the problem.  Also, the batch files contain "set BIN=\MASM32\BIN\,   set INCLUDE=\MASM32\INCLUDE\,   and set LIB=\MASM32\LIB\  so may need to be changed to your paths.

I did this test using Masm Version 6.14.8444 that is packaged with Masm32.  The problem occurs similarly with Masm 6.15 and JWasm, it just takes a little more embedded code before the problem shows up.

If you run the exe files, you will see that both come up instantly and run identically, so it is something to do with the assembler/linker.   The delay would not be a problem for a normal program, but this one is meant to be a "make a change, assemble, run,  repeat" type situation, so I would like to eliminate the extra two seconds in the process if possible.   A clue might be that the size of the exe's are  8192 bytes for the faster one and 8704 bytes for the slower one, even though the only difference is two nop's.

Does anyone know an assembler flag or switch that will eliminate this problem?

[Wannabe]

Missing file to build:
TimeTest2.asm(50) : fatal error A1000: cannot open file : \WinAsm\Progs\AllMyStuff\Printx.inc

[jimg]

Sorry about that.  Always something.   Replaced file in above post.

[dedndave]

both programs come up very quickly (via batch) on my machine (XP SP3)
perhaps you have an A/V scanner running that hiccups on one, but not the other ?

[jimg]

Amazing Dave, you got it in one.  I turned off MSE and sure enough, instant response.   I would never have thought there would have been that big a difference.
Why would it take MSE three times as long to scan a file with two extra instructions?   I would be curious to know which AV scanners have the problem and which don't.  MSE has been very benign up to this point.  And strange it only has the problem right after assembly and not when the exe is run.  I guess it only scans an exe once and marks it okay.

[MichaelW]

Why would it take MSE three times as long to scan a file with two extra instructions?

I run MSE and I frequently time code, and over time it has become apparent that on the first execution it's not just scanning the executable but actually executing it in a "sandbox", or some such. If the test takes 10 seconds to run then MSE will delay for at least 10 seconds. It's not a problem for a one-time test, but when going through repeated modify-test cycles the only solution is to turn off real-time protection.

[jj2007]

I run MSE and I frequently time code, and over time it has become apparent that on the first execution it's not just scanning the executable but actually executing it in a "sandbox"

Interesting. Looks like a neat trick, running the exe and waiting if it does nasty things - but malware developers would let their apps just idle for some minutes (until MSE closes the exe), and then start phoning home etc...

[MichaelW]

Interesting. Looks like a neat trick, running the exe and waiting if it does nasty things - but malware developers would let their apps just idle for some minutes (until MSE closes the exe), and then start phoning home etc...

MSE probably waits for the exe to terminate itself. And there is the question of how the exe could know that it's not running in a sandbox. Given Microsoft's involvement, I would think that the sandbox execution environment from the POV of the exe would be identical to a "normal" execution environment. And with real-time protection enabled, I doubt that the exe could "phone home", replicate itself, delete or alter system files, or anything similar.