Hello all,
Meanwhile, for some reason I am also getting this error when starting
commandg.com under DOSBox (0.74-4.2 on Ubuntu):
[Out of memory loading STRINGS.]
Failed to load the strings resources into memory, the location
pointed to in %COMSPEC% seems to be invalid. Please specify another
location of FreeCOM to try to load the strings from, e.g.:
C:\COMMAND.COM
or just hit enter to cancel to load the strings.
I have found out what is causing this problem, though I am not sure of
the best way to fix it.
When DOSalloc ( ) (in suppl/src/dosalloc.c) tries to get DOS's current
memory allocation strategy (int 0x21, ax = 0x5800), it tries to clear
the carry flag before calling int 0x21, by saying
#if defined(_TC_EARLY_)
__emit__((unsigned char)0xf8); /* clc */
#elif defined(__WATCOMC__) || defined(__GNUC__)
reg.x.flags &= ~1;
#else
asm {
clc
}
#endif
geninterrupt(0x21);
However, both the intr ( ) implementation in Open Watcom, and the intr (
) implementation in suppl/src/intr.asm used when compiling with
gcc-ia16, will _not_ try to load any flags --- including CF --- from
reg.x.flags, so int 0x21 basically gets called with CF in an undefined
state (and it happens to be set in commandg's case). And DOSBox's
implementation of the "get allocation strategy" call does not change CF.
One way to fix this immediate problem is to let the code simply assume
that the "get allocation strategy" call worked. However, I see that
there is also a "get UMB link state" call (int 0x21, ax = 0x5802)
further up, where we would like to _set_ CF before the call, i.e. assume
the call has failed unless we can be sure it succeeded. I am wondering
if it would be better to just reimplement this particular routine in
assembly...
Thank you!
--
https://github.com/tkchia
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel