Hi Justin, thanks for your help offer! Win 3.11 can only run in 386 multitasked mode, which requires extra kernel support e.g. in the int 13 handler and in some int 2f functions for "managing" the int 13 handler and related. So it is no surprise that Win 3.11 does not run. HOWEVER, it would be interesting to get fresh test results (kernel 2035, new himem or maybe ms himem, better no emm386, maybe use DOS=LOW and a non-XMS-Swap FreeCOM for the test as well) for the 286 mode of Windows 3.0 / 3.1 (use WIN /S to start in this mode - you may want to use other "enable compatibility stuff" options of WIN as well, not sure). In 286 mode, Windows can run on a 286 (you guessed that, right?). Aitor suggested that it only runs one DPMI task at a time then, swapping the other stuff to XMS. That should be much easier to handle for FreeDOS compared to the "fully" multitasking 386 mode (/3 mode of Windows 3.0 / 3.1 - and the same as the only possible mode of 3.11 ...).
Extra explanation about 1049: Abort, Ignore, Retry, Fail should do something like abort, ignore, retry and fail respectively. Questions are whether this does actually happen and which exact semantics one would expect for the 4 options. I think it was something like: Abort = abort program, ignore = just continue as if the access had worked (?), retry = try again (not visible for the program which tried the access usually), fail = tell the calling program at once that the access has failed, do not keep trying. In 1176, we are actually talking about two CONTROLLERS or in other words three or four floppy drives! Only PC-PC and PC-XT could handle that, it seems. But maybe some vintage computer expert here knows better. For each controller you have one ribbon cable and up to two drives - but I hear that controllers in new PCs now no longer support 2 drives anymore??? Thanks for testing 1743 (interlnk/intersvr). Maybe FreeDOS supports only interlnk or only intersvr - in that case you can use another DOS for the other end of the connection. Probably makes no difference, but you can test with MS command.com if you want. The real problem seems to be a kernel one. Usual "try to use boring memory settings" might help, and maybe STACKS=9,384 (which is by the way also recommended for Windows 3.1). But maybe INTER* simply relies too much on undocumented MS kernel structures. And happy testing of Solitaire Suite and the other QB 4.5 / VBDOS issue... > LBACache Slow Computer Test - I own an IBM PS/2 Model 56 SX which is an > Intel 386 SX 20MHz with 12 MB RAM. [and SCSI harddisk] Sounds good. As told, try with a small cache in 0.25 - 4 MB size range... Maybe you can find some FreeDOS programs which do not run at all on that PC. In that case, they probably use floating point calc or other things which require > 386 CPU. I think FDAPM will work (but will it matter? The 386 CPUs did not need any cooling at all...). UDMA will not work, obviously. Neither will LBA, but LBAcache should be able to use CHS in that case. You could iuse OnTrack or EzDrive to install LBA support if you insisted on having LBA, though ... CD-ROM stuff should work on 386+ but I guess you have no CD-ROM in that PC. I assume that the oldest PC where CD-ROM can work at all would be 286, but FreeDOS drivers all require 386+ for CD-ROM. I hope that CHKDSK will not be too slow (hey, maybe try DOSFSCK...). DEFRAG might be quite slow on your 386!? Even loading big files in EDIT might be slow...? MODE / DISPLAY should work if you have EGA or better graphics. Actually all MODE functions should work...!? Some aspects of FORMAT might be slowish. I assume that GRAPHICS will be slow unless you use Post Script printers. I wonder if MemTestE would work (this and other Linux loader style things like MEMDISK / ISOLINUX / ... require a 386, but maybe MemTestE even needs PCI bus?). MIRROR might be slow but actually I do not really trust it anyway. MORESYS should work nicely. NANSI should work and should not cause speed problems. You cannot test SHARE.COM (.COM!) unless you have a program which uses it, I guess. SORT speed should be acceptable. TE and TED3 editor speeds should be fine. TICKLE should work as usual. Meybe even the TICKLEHD (use HD (in upper case) option for CHS...) has effect on your system, on faster systems the TICKLEHD effect is very small... remember to use FLOP option of LBAcache when you use TICKLE/TICKLEHD, to speed up floppy access. UNDELETE should work - try a dirsave of some directory to a file on another disk and watch the screen output, for example. ZIP / UNZIP should work and should be fast enough (remember that pre-386 need to use ZIP16 / UNZIP16 and that you need the CWSDPMI file for *ZIP*). XCOPY should work. (and so on...) Most other tools (how about cutemouse / mkeyb / ..., will they work on a 286? Not that you have a 286, just wondering...) should work exactly as usual. You have a 386, so all HIMEM, EMM386, dos extended programs, caches, XMS swapping FreeCOM... should all be happy. Please mail me directly (i.e. not through the list) if you have further questions. I think you can simply use your inspiration and creativity and try a bit of this and that, on the 386 and - where old-PC-compatibility is not the interesting question - another more modern computer ;-). Thanks! Eric. PS: Maybe DISKCOPY / DISKCOMP / DOSFSCK will be slow on 386sx, too? Depending on your amount of BUFFERS, avoid having too many elements in PATH / using APPEND / having too long directories ... well, or use them intentionally to experience how much they hurt performance. I believe that even with enough buffers / cache the CPU overhead of directory processing might be remarkable. Then a FASTOPEN would be an idea (but the kernel API for that, int 2f.122a, is not well documented and I am not sure if a FASTOPEN which merely hooks int 21 but does not use a special kernel API could work... but hey, we can always go and create a special FreeDOS kernel API for a FreeDOS FASTOPEN ;-)). ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
