Hi! > > With this I'm leaving FreeDOS for the next couple of months at least. I > > may put up an update for MEM but that's it.
Would be nice. I hope you can include some of my suggested more verbose error messages (see my patch) with that. > > There was a bit of noise on > > the mailing list but the main reason is that I'm generally happy about > > the kernel, all I wanted in the beginning is to get it to cooperate > > nicely with DOSEMU. That's done and more. A whole lot more, actually. Thanks big time! > > Squeezing even more bytes out > > of the kernel and fixing even more bugs is certainly possible, but it's > > time to leave that to someone else as my (volunteer) job is finished. I hope that no new bugs will be introduced by squeezing out some more bytes. Already tested 2035 with XMSDSK: The LCD / DPMI16BI problem seems to be gone, even with 2034, so that was probably a "both FD*XMS* and HIMEM" problem and not a kernel one, and the HIMEM update solved it. Strange but nice. I found 2035 to save again some 0.5k of low memory over 2034, while taking 0.?k more in UMB. Interesting. As far as I can tell, in 2035, there is something like 2k of low RAM used for kernel devices and code, 2k for IDT / BIOS data / ..., and most of the rest (cf:0 ...) of the stuff in low RAM seems to be from global data structures like the List of Lists (which cannot really be optimized - MS compatibility). Is that correct? How big is the LoL right now? I assume you cannot move it to UMBs after loading the UMB driver, because chances are too big that somebody already has stored a pointer to the LoL in low RAM? I get 627k of low RAM free in DOSEMU now and 622k in plain FreeDOS. Wow! I hope you will have a good time in NZ. Thanks for all the fish ;-). And of course DOSEMU will probably make you stay tuned to FreeDOS, although now only as FreeDOS USER for a good while. Happy FreeDOSing! Best wishes & cheers. Eric. PS: Checking bugzilla... 22 known bugs - some of which are exotic wishes or very hardware / software specific. Those which should be fixed next, if you ask me, or at least re-checked whether they still occur, are: 698 int 13h DMA boundary helper missing (our boundary helper is hooked to "int" 25/26 and int 21.7xxx instead) 423 failure to notice write error in Quicken in Dosemu - still existing? 943 initdisk crash in SCSI 735 / 1651 problems related to floppy disk change and access errors 1743 interlnk/intersvr incompatibility - if we can get that other "serial port drive letter" to work, or write our own, this bug will no longer be a problem... 1766 Windows 386 mode compatibility: We should first improve 286 mode stability (only 3.0/3.1 has it, 3.0 even has an 8086 mode), then fix bug 698, and then finally add the extra multitasking related hooks for int 13 hooking etc., which are actually not THAT many. But even DR DOS had big problems with it, because DOS has to correct / workaround some Windows bugs to become Windows 3.11 386 mode compatible. Not sure why MS DOS 3.x works then, though. Maybe the bugs only happen with UMBs? Apart from that, improving FreeCOM is one of the biggest FreeDOS 1.0 TODOs left. ------------------------------------------------------- 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=3149&alloc_id=8166&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
