On Sun, 2 May 2004, Bernd Blaauw wrote: > I have a problem with loading high the DISPLAY driver. > Aitor mentioned that it requires maybe up to 64KB initial memory, and then > shrinks itself. > My problem is that instead of loading low when "LH" fails, the entire > command fails. > that implies: "Load DISPLAY.COM high, or don't load it at all!" > (instead of: "Load DISPLAY.COM high, and if that fails load it low")
There is one problem with LH *.COM files: .COM files often believe they get plenty of memory when loading, vs. EXE files where you (the implementor) say beforehand how much memory is required to run the program. So, if the .COM image is smaller than the actual memory required, is is loaded, but then fails (using abort() or something) during startup phase. (Borland dies with exit code #3 then, BTW). You are right that FreeCOM's LH does not re-exec a program low, if it fails to load it high, but it will display an error message, if the actual exec() _syscall_ fails - in contrast when the program got loaded, but died itself. Maybe you should file a bugreport, if MS COMMAND behaves differently - regardless if the current problem is not related to it. Probably MS kernel and FD kernel provide different unused UMBs. To verify this problem, you could create a little .COM program, to just display the block size the program got loaded into; then extend the .COM file to the same file size than DISPLAY.COM, this is necessary to enforce the kernels to load the test program into the same UMB as DISPLAY.COM. (Maybe, you have to trick, when you use C, so the C startup library does not try to resize the block to 64KB and fails thereby probably. -- switching to assemlby seems to be better here at all.) Bye, -- Steffen Kaiser ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
