Hi,
If I understood Eric's point, it might be UPX fault, as it would fail
whenever it tries to enlarge the UMB as required by the uncompressed
program and silently fails. So I may have to provide uncompressed 64KB
DISPLAY.COM in the next release (last before DISPLAY.SYS).
On the other hand, in the same situation MS-DOS seems to deal with this
situation correctly (that is, if it can load high then loads low), and
FD-DISPLAY will not have problems there, so there's something about
FreeDOS kernel too. Bernd seems to have found other problems regarding
UMB management and kernel.
Aitor
[EMAIL PROTECTED] escribió:
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,
---
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=3149alloc_id=8166op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
