At 04:40 PM 9/4/2004 +0300, Luchezar Georgiev wrote:
OK, ZRDX 0.47 is buggy. But why both KAVDOS32 (ZRDX 0.49) and QV (ZRDX 0.50) hang up here before showing the prompt on exit in FreeDOS but not in MS-DOS,
No, I think ZRDX is buggy, period. And I'll tell you why. But first, note that if one takes a DOS4GW.EXE stub and runs it on the Kaspersky anti-virus, e.g. DOS4GW KAVDOS32, so that the DOS/4GW extender overrides ZRDX, then Kaspersky runs to completion and terminates to DOS just fine.
Now for the eyes glazing over description of the problem that most people will want to skip...ZRDX 0.50 is failing when the INT 21h DOS function 4ch doesn't terminate the program (Kaspersky anti-virus) and ZRDX code drops through to a STI, JMP $-2 infinite loop after MOV ax,4cffh, INT 21h in its code. TSR's might still be working in the background, but you'll never get your DOS prompt back. Okay, failing to terminate an app on function 4ch sounds like a FreeDOS failure, right? Well, apparently not in this case.
I did a trace of the whole run under QEMU to a debug log. I then backtraced and correlated the log with what I saw running in real-time under Bochs (much more stable and better debugging tools, much slower than QEMU). Turns out that the function 4cffn failure comes about during a ZRDX failure at shutdown. If you have the ZRDX source code to follow along with, in the routine TerminateHandler, there is a call to CleanMemVector. This sets up a call to FreePages. In FreePages, there is a compare on the first and last page to free in its memory control blocks. If they are not equal in value because the block is >64K, ZRDX goes into a different STI, JMP $-2 loop, which QEMU/Bochs says does happen. However, at that infinite loop point, hardware interrupts are still firing and memory is in an unstable state -- because the termination process is half-done and you're still in protected mode. So, during the JMP loop, something fires which eventually causes an exception. The exception attempts to report to the screen, fails, then ZRDX jumps to fatal error exit, switch to real mode and the MOV ax,4cffh termination.
Unfortunately, since memory isn't released, and who knows what garbage is laying around in it, FreeDOS failing to terminate on function 4cffh isn't all that surprising. Incidentally, when running under EMM386, which does work for a while, ZRDX takes a different exit path due to VCPI presence. Which may be why it works for me, at least for a bit. I did catch ZRDX releasing memory it didn't own down in the DOS area, so the EMM386 setup is probably not too stable, either.
Either ZRDX is bugged -- or in my opinion possible but far less likely -- it depends on an obscure part of FreeDOS behaving in a particular fashion and when it doesn't, the problem slowly cascades down to total collapse as described above.
Why does MS-DOS work for some people? Two possibilities besides a FreeDOS incompatibility: 1) the memory image is different and vital parts don't get sniped out or 2) MS-DOS function 4ch is more aggressive about recovering memory from a failed program and forces things back to a working state.
So I've changed my mind. I think the Kaspersky bug in Bugzilla should be marked WONTFIX and a suggestion given that users grab dos4gw.exe --readily available in many places -- to run the anti-virus. Which I will post there in a couple days unless otherwise persuaded. And I think, though I have no absolute proof, that ZRDX 0.50 still has an error causing the no-termination problem. In any case, I ain't debugging it no more no more.
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
