Hi everybody,
I also agree that there should be a next release candidate first, not immediately a FreeDOS 1.3 release. Even when RC5 is perfect, nobody would stop us from simply bumping the version number for release. And when it is not perfect, things can be improved before the actual release. I do NOT think that ALL open issues should be fixed for a simple FreeDOS 1.3 release, that would be more something for a FreeDOS 2.0 release ;-) Things I want to be addressed for the next release candidate are in particular the disk drivers: Is my theory correct that the disk caches (lbacache or uhdd) could have a problem with the ELTORITO driver? Can we make more protected games work by tuning the UDVD2 driver or maybe add a cheat to the CDRCACHE? It is important for me that both the installer and the installed FreeDOS use UHDD when possible, to improve performance, given the lack of I/O speed of our kernel itself, in particular for FAT32. For ELTORITO boot mode, CDRCACHE would also have to be used, because UHDD cannot cache other CD/DVD drivers than UDVD2. It also is important for me that old bugs in the autoexec and config files get fixed. Given that some of those are created dynamically, this is a task for the installer experts. See my old mailing list thread about the topic earlier this year. In vaguely related news: Please make the LiteUSB image 32 MB, so there is enough free space to work on the USB stick with it. There seems to be a bug in the overview HTML file, which says the floppy edition images are 12 MB or use 120m or 144m media: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html I would wish the LegacyCD to include all packages of the LiveCD. Can we tame FDISK to no longer nuke existing MBR without asking triggered by the mere absence of the 55 aa magic? Can FDISK have the MBR sub-menu enabled for interactive mode and can all three MBR code options announced in the docs actually be made accessible for scripted command line style installation? Can it have a mode to check for existing MBR code, using Jerome's new detection tool as reference implementation? Or should we just switch to XFDISK? There also are some ideas for FDAPM (parse larger ACPI blocks), CTMOUSE (become 8086 compatible), NGE NIBBLES (improve docs for my update, requested by Jim), CDROM2 (add STOP and UPC commands), CDRCACHE (remove messages about raw access), LBACACHE (see above) and probably others. Some of the above would require help from people who can do very specific tests (e.g. with eltorito boot versus caches, protected games versus CD/DVD, or CPU compatibility analysis of ctmouse to make sure no non-8086 code gets overlooked). Other items would be mostly documentation-specific (cleaning up my NGE NIBBLES update). I agree that AMB is a nice addition but not necessarily a full replacement for HTMLHELP, so both should stay available for now, given that HTML is a more widespread documentation format. Note sure which commands lack FAT32 support yet? DEFRAG comes to mind, maybe CHKDSK for those who do not want to use DOSFSCK? Could you make a list, Willi? LFN are an interesting problem, FreeCOM itself only uses them on request (DIR /LFN) as far as I remember. Most apps probably do not really care, so FreeCOM could be "empowered" to automatically translate long names to short names for all apps which are on a list of LFN-unaware apps? Not something for FreeDOS 1.3 though. For FreeCOM and kernel, I would want the CHANGELOG (!) to reflect the current state of affairs in the version which gets included into a real FreeDOS 1.3 release. For a release candidate, it is okay to have some "undocumented improvements", but actual releases should really have their changelog documentation in up to date :-) Weird that documentation exists about BACKUP and RESTORE, but no actual tool? Could be either a planned pair of tools or one which got lost in the last decades? People can use ZIP as workaround, but having documentation about non-existing apps is confusing. I expect that by far not all DOS apps support translated Y/N etc., but I bet that somebody already has a list which ones do or do not? Some packages are likely to be OUTDATED. Checking this would be a task which could be distributed over a few people who want to help without having to code: They can go over the LSM and compare the packaged version number to the one of upstream app websites, or trivially skip packages which are unmaintained upstream anyways. If I remember correctly, LHA and UNRAR have unresolved license issues? Same for AHCICD and MPXPLAY, alas. I have tried to ask the maintainer of the latter, but got no reaction so far. Maybe somebody here has better connections to him? I suggest to have some more compilers etc. on the normal install images, NOT moved away to the BonusCD: FASM, FBC with help, FPC, INSIGHT, JWASM, NASM, UPX. Possibly also OW and the I16 compilers. It is unfortunate that TPPATCH (runtime error 200) is out, maybe some alternatives with better license exist, also for TC apps? Of course, UHDD and ELTORITO need to be available in most media. In turn, GCDROM can be moved away to "BonusCD only" status. Even UIDE can be moved to "BonusCD" only, UHDD/UDVD2 are better. Given the different use cases, RDISK should be available next to SRDISK. XMGR and FDXMS... should be available at least in BonusCD, to give people alternatives in case of problems with HIMEM or JEMMEX. At the moment, FDXMS and FDXMS286 are available everywhere, which is overdoing availability, while XMGR and RDISK are not on any image. As mentioned above, LegacyCD should have all LiveCD packages: Right now, none of the networking drivers or apps are available on Legacy. Not sure why FDINST and FDISRC are separate packages? Of course I propose to make FDSHIELD available on all media, as it is my answer to VSAFE antivirus, which was part of "base" in MS DOS 6.x ;-) No need to add CLAMSCAN (clamav) as answer to MSAV, though: That would be far too large far a "base" package. See above for my position on XFDISK. We have also discussed some file managers and info tools for DOS a while ago. I hope this will lead to including some nice apps in the upcoming release candidate, see the discussion on the mailing list for details :-) Thanks! A good info tool would be INFOPLUS 1.58, which is better than old COMPINFO. Agood file manager would be DOS Navigator or (faster, less features) DOSZIP commander. The documentation of MODE is outdated: It should not mention disk head parking. Instead it should mention the new text mode resolution related features and CODEPAGE features. Volunteers? See the MODE /? text about what MODE actually does today :-) It would be good if Japheth's HX RT and HX GUI could become part of the distro. They let you run simple Win apps in DOS. Also, thanks to the improved license, 386SWAT and DPMIONE should probably be included in their github.com versions. Regards, Eric PS: See freedos-user 5 June and 3 May, Robert's 15 May mail on freedos-user, as well as other replies in those threads, the thread on freedos-devel on 8 June, and so on. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
