Well I see no bug in this fmemcpy.
Bug - no, but it does use EAX which probably conflicts with something else later. If I remove EAX use, it works!
One other thing I can imagine being a problem is that some device drivers or programs you use rely on the high word of eax being zero.
No, it doesn't deend on which and what programs are INSTALLed.
since you said: "after the install commands are processed (if any)". This means that if no "install" was present no problems occurred?
Yes. I wanted to say that if ANY installhigh= command is processed (no matter which!), it crashes after executing all the install commands. But later I noted that with different length of printed text, sometimes HIRAM asks me in German something after the kernel admits that some Int 2F call is not supported, printing funny characters for the call number... So, as there are too many instances where fmemcpy is called, I think that the best strategy is fixing its code itself.
so what you could try is to add a xor eax, eax at a strategic place, ie. _exec_user:
xor eax, eax
in procsupt.asm. Also execrh.asm for device drivers.
...and everywhere where fmemcpy is called? But isn't it better to fix fmemcpy itself?! Besides, as I told, it doesn't depend on exactly which program is installed - it depends on whether ANY installhigh= command is executed ot not, so I really think that it's an internal kernel problem, not a problem of external programs. The more so as most of them are written for 8086 anyway ;-)
Lucho
------------------------------------------------------- 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_id=1356&alloc_id=3438&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
