Hi Jerome, > I never said performance was not important. Only, there are more > important things for the installer that come first. Among those > are things like stability, portability, flexibility and others. > Improving performance is near or at the bottom of the list.
I would definitely not put it last. And using risky options for memory drivers or using unavailable features such as DOS=HIGH in spite of not loading a HMA driver, are easy to fix flaws, not peephole performance optimizations. Improves stability :-) > I’ve never used UHDD. So, tell me does UHDD do floppy > disk caching? It does. It also tracks disk changes, of course. There is no command line option to manually override whether or not you want to cache floppy. UHDD only does read- ahead in 64 kB blocks for UDMA disks, not for floppies. Floppy disk drives with disk change detection are found and cached, without read-ahead, by UHDD automatically. According to the LBACACHE docs, it can decide to pause floppy caching while 1.68 MB disks are used. Not sure whether UHDD is more audacious in such exotic cases. LBACACHE has a compile time option to force it to cache ALL floppy drives, even without disk change detection, but all default binaries of LBACACHE and UHDD simply refuse to cache floppy drives without change detection. With the exception that LBACACHE drops this requirement when it detects being run in DOSEMU, because DOSEMU 1.x failed to simulate proper floppy disk change detection. LBACACHE itself does not do any read-ahead: Instead, you load TICKLE, which reads the whole track when you first read anything from an unseen floppy track. It optionally, if you add the /CHS or /LBA options, triggers 4 kB fixed disks read-ahead. So if you have enough RAM, you can use TICKLE without command line options to make any cache, including UHDD, read-ahead floppy tracks. It takes circa 10 kB and should not be loaded into UMB by default: You first have to test whether UMB floppy I/O is supported. Whether you want to spend 10 of your precious 640 kB to speed up floppy I/O depends on whether you use floppies. >> 7. Add a commented out example COUNTRY=031 or 049 or >> similar line to the config. > > Actually, users want the installer to set this during installation Would be a nice feature, but more work than adding a commented out example COUNTRY line to the config :-) >> 22. This reminds me that your scripts should >> check whether a sufficiently smart command.com > 1) Works fine on MS-DOS, PC-DOS and probably others. Your BAT scripts use no FreeCOM-specific features? > 2) Those are only done AFTER the installer makes sure it is > running under FreeCOM. There are other things the installer > does do that would not work under MS-DOS. So, it already > has guaranteed that FreeCOM is being used by the time > it gets around to using computed jump targets. Interesting, so you already check for that? :-) How do you implement "make sure to run under FreeCOM"? >> There, more than 50 (!) packages which are available via >> LiveCD are listed as not being part of LegacyCD at all. > Like I said, I included some popular ones on the LiveCD that > it would be very painful for a user who cannot remove their > CD to try and install from the BonusCD. As they are popular, they should be on all CD anyway, not Bonus. And most of those 50 packages are quite small, so you can put them on the Legacy CD without harm :-) >> Who is the 1 person team which checks for pending package >> updates and is there a way to read about their progress? > At present, only I update the "shipping packages”. Would it help you to have volunteers for the version checks? > a large number of still active projects are released as source > only, or with their own installers, or in big globs of files > that need reorganized to prevent utter chaos when installed. That is surprising in context of DOS. > It is a very time consuming process. Definitely! Eric :-) _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
