Hi Tom, suggestions to shrink FreeCOM code size and improve things: - replace cmd_cls by something which does not use that stupid library function which only works for 80x25... - replace delay() by something which uses 40[6c]. This will affect: The "panic" delay and the beep_l and beep_n delay. The latter two are broken anyway (crash on some Acer PCs, and far too long beep on DOSEMU). Finally there is a delay() call in cgettime.c, but that one can be removed completely, or replaced by a call to "idle". It is used for the "press f5/f8" message, but the actual delay for the message is done with dos_gettime there. The delay() call in cgetime.c is just an ugly way of being idle.
SCNR :-P. Eric PS: Bart is right, XMS swapping FreeCOM can be compiled for 286+, but on the other hand if you compile for 8086, it will at least WORK (but not swap, so it will use a lot of RAM, probably more than a FreeCOM which has been compiled without XMS swap feature) on 8086. PPS: Both Steve and Tyler did have some problems with config / autoexec processing on both 2034-FAT32 and SF.net 2035, so there MUST be something true about this (hardware specific) story, and it is really annoying that none of the kernel people believes Steve. The fdos.org "2035" works better, but the naming scheme is confusing. Call it 2035b or 2036. ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
