Hallo Eric,
we already do have 622k low DOS RAM free in a quite straightforward configuration (in DOSEMU, where HIMEM / EMM386 take almost no memory, even 627k), and I never met any program which really needed more than 590k, so this is only about bragging.
Exactly. I have 629 KB free in FreeDOS and that's enough for me.
More interesting and useful would definitely be something like my suggested "checksum some/all SFT entry fields and force an update of the corresponding f_node if a SFT entry is found to be changed from outside. I believe this would be necessary to allow DOS boxes to work inside Win 3.x standard mode (DSWAP/WSWAP)."
Then go ahead, what are you waiting for? You do have write CVS access, don't you? ;-) But remember what Tom said about the 3m long stick (that he won't touch the unstable kernel). Got the hint? ;-)
programs which call int 13 directly have to check for DMA boundaries themselves) nor do we have the "original int vectors 10/13/15/19/1b" data at 70:100 or the DDPT at 0:522 (we have it at 70:0). Hard to tell which compatibility problems those details could cause.
If I remember correctly, Bart had some solid arguments against moving from 60:0 to 70:0...
Bonus question: Does MS DOS actually call int 25/26 itself or does it - like FreeDOS - only offer int 25/26 for disk tools, but calls the device drivers directly for everything else?
It's like FreeDOS - doesn't call Int 25h/26h itself but calls the device drivers directly.
Regards, Lucho
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
