Hi!
11-Фев-2004 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG> not supported, printing funny characters for the call number... So, as there
LG> are too many instances where fmemcpy is called, I think that the best
LG> strategy is fixing its code itself.
This is not fixing, this is workaround. Unreliable workaround. To be
more reliable (to prevent EAX usage at all) you should use something like:
#ifdef __BORLANDC__
# pragma option -1-
#endif
... fmemcpy (...) { ... }
Unfortunately, I don't know, how to turn return target processor option
back - target may be 386, but it may be also 8086. Probably, next (after
fmemcpy() definition) should work:
#ifdef __BORLANDC__
# pragma option -3.
#endif
>> in procsupt.asm. Also execrh.asm for device drivers.
LG> ...and everywhere where fmemcpy is called? But isn't it better to fix
LG> fmemcpy itself?!
This is not fmemcpy bug. When calling external C function, calling code
_should_ expect that _any_ register (except explicitly denoted - si/di/bp in
BC) may be destroyed.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
