Hi, some comments on your comments... HIMEM /INT15H=... should not be extremely hard to do, so I vote for it. HIMEM /HMAMIN=m is indeed not very useful. Being able to allocate PARTS of the HMA would be nice but was not introduced before MS DOS 7 or so, and before that time, HMAMIN protected the system from giving the HMA away as a whole to some program which only wanted a bit of it. HIMEM /TESTMEM:... is indeed not that useful. An exist-check might be useful, but a check like "write own address to all 0x?????000 form addresses" (to check if there is really RAM there and it is not multiple copies of the first 16 MB or something) will probably be useful to detect broken BIOS-hooking memory allocation schemes without wasting much CPU time. HIMEM /TEST is quite nice, so it should probably be ad*ertized more.
CHKDSK is written with compatibility in mind even though it has several auto-activating cache builtin cache schemes. It looks like CHKDSK for the user, adds surface scan, and is 8086 compatible. CHKDSK of MS DOS does not support FAT32 - this is generally a task for SCANDISK at least in the earlier versions of FAT32-enabled Windows. SCANDISK can use the DOSFSCK engine if it is okay to require a 386 CPU and quite a bit of RAM. Otherwise I would recommend that SCANDISK should call the CHKDSK program as a child process for the actual checks and only have the surface scan with the drive usage diagram display actually inside the SCANDISK binary (this diagram is already displayed by DEFRAG, so DEFRAG is a good starting point for SCANDISK). Another possible SCANDISK would be a combination of the DEFRAG user interface and the CHKDSK or DOSFSCK engine all wrapped up in a single binary. That would be harder to break because you cannot forget installing CHKDSK or DOSFSCK... DOSFSCK has the advantage of supporting FAT32 while it has the problem of having no even remotely MS-looking user interface (not a problem if you only use the engine for SCANDISK). The fastest way to write SCANDISK would be implementing the user interface only as sort of a "progress bar" to CHKDSK, possibly using source code taken from the existing broken scandisk. This would be missing the eye-candy of the usage diagram during the surface scan (which should definitely have some progress indicator - which should be off if isatty() is false for stdout - like a "cluster X of Y" display even in the plain CHKDSK program!). It would also be missing any possible interactive fix stuff: could somebody find out which interactive fixes are offered by SCANDISK at all?? Other than CHKDSK, the DOSFSCK engine already contains many interactive prompts (which you can switch to "automatic" for non-interactive mode) and even a "simulate all collected writes and scan again" mode. Collecting written data is also good for creating a "save UNDO data" feature for a DOSFSCK-based SCANDISK. So I think if it is okay to require a 386 and enough free RAM, then an all-in-one SCANDISK binary based on the DOSFSCK engine would probably be the best choice. CHKDSK would stay around for FAT12/FAT16 analysis on any FreeDOS compatible computer. This is similar to MS style where CHKDSK just works and SCANDISK has all the eye candy and a few extra checks and the interactive mode and the FAT32 support. Last but not least it is useful to have TWO different ways to scan FAT12/FAT16 (because you can assume that both have different bugs, this will help finding the bugs in both tools). FreeDOS kernel should be MS DOS 3.3 but system should be MS DOS 6.22? Not really an easy choice. I would prefer "MS DOS 5.0 in all aspects" plus LBA plus "kernel and some of the tools with FAT32 support". MS DOS 6.22 differs to MS DOS 5.0 in that MS added several third party products after 5.00, some of which are both complex and not really core DOS things (e.g. the Windows 3 user interfaces for UNDELETE / BACKUP / SMARTDRV, the tools UNDELETE, MIRROR, UNFORMAT, BACKUP, RESTORE, MSAV (with MWAV Windows GUI), VSAFE, DEFRAG, SCANDISK, ...). And of course there is QBASIC/HELP/EDIT (sharing the QBASIC binary which does the bulk of the work) and DOSSHELL. Let me see... German website with a well sorted listing... (Steve has a more detailed list, including information about older DOS versions): http://www.chemie.fu-berlin.de/chemnet/general/topics/dos_neu.html DOS 4.0 -> 3.5inch drives, partitions >32 MB (with SHARE), DOSSHELL DOS 5.0 -> UMBs, HMA, smaller kernel, UNFORMAT/UNDELETE, QBASIC/HELP/EDIT, DIR with sorting, DOSKEY, mixed improvements (e.g. SMARTDRV improved) --- DOS 6.0 -> improved EMM386, MEMMAKER (config tuning helper), MSAV/VSAFE, DBLSPACE (compressed drives), PC-Tools "MS"BACKUP, Norton/Symantec DEFRAG, improved help/FASTHELP, config MENU functionality, CHOICE, INTERLNK/INTERSVR, MOVE, DELTREE, improved MEM, DIR, UMB-loading of things improved DOS 6.20 -> SCANDISK, DISKCOPY improved (using harddisk as buffer), single- stepping in autoexec, improved DBLSPACE / HIMEM / SMARTDRV (added CD-ROM caching, I think; SMARTDRV 4.x of DOS 6.0 already added delayed writes, 4.2 makes "write before returning to prompt" default, 5.0 of DOS 6.20 and Windows 3.11 even makes "no delayed writes" default: http://www.knowwareglobal.com/optimal/optimal_smartdrv.htm The smartdrv of DOS 4.01 and 5.0 is a SYS file and caches BIOS based, while the smartdrv of DOS 6.xx is an EXE file and caches "int" 25/26 based and can even cache networked drives as far as I remember. The sys version uses EMS. Or XMS. Default is XMS/extended, /a makes it use EMS/expanded. ... note that DOS 4/5 SMARTDRV had a syntax of only [size] [/a], not more). DOS 6.21 -> removed DBLSPACE (license troubles) DOS 6.22 -> some bugfixes, add DRVSPACE (clone of DBLSPACE), something like that... Forgotten on the above site but still...: DOS 5 adds EXPAND, LOADFIX (to load EXEPACKed files > 64k boundary, workaround for "the only" thing which keeps people putting A20 gates into x86 processors since the 1980s...), SETVER, MIRROR (counterpart to UNFORMAT). DOS 6.xx also added the MSD system diagnostics tool. The NCCorps FreeDOS distro seems to be planning to help with DBLSPACE, DOSSHELL, INTERLNK/INTERSRV and DRIVER,SYS: http://nccorpstemp.o-f.com/fd10list.htm So apart from Windows 3.11 compatibility, how far are we? DOS 4.0 yes - we have some disk cache and a graphical user interface etc.! DOS 5.0 mostly - we do not have a good QBASIC (BWBasic improvement project is currently on hold due to lack of interest, let me know if you want to help). All other DOS 5.0 goodies are present in FreeDOS by now, although with some limitations (unformat, undelete, edit, dosshell, setver). EXPAND is missing? --- DOS 6.0 not really - our EMM386 is limited, MEMMAKER not existing at all, ClamAV clamscan can replace MSAV, a VSAFE would be nice (I would like to start such a project, who wants to help? Rob?), DBLSPACE would have to be removed 0.21 versions later due to license issues ;-), BACKUP would be bought from PC-Tools, DEFRAG would be bought from Norton/Symantec, HELP/FASTHELP is present but in some aspects describes MS DOS instead of FreeDOS (!), config MENU is present but nor syntax compatible to MS, CHOICE is there, some "serial port drive letter" tool has been found by Tyler but nobody tested it successfully yet (!), MOVE works, DELTREE works, DIR works, LH and DEVICEHIGH work, MEM could be better but works. DOS 6.20 uhmm... we are thinking about a SCANDISK of WinDOS 7.xx power, our DISKCOPY is already great, autoexec stepping works, we might - no joke - add support for readonly compressed filesystems in 2004 or 2005 at least, our XMS drivers are improving and I might eventually get bored enough too add delayed writes and other gimmicks to LBAcache (and maybe add a network drive cache and a mechanism to share XMS between the different caches). So my personal opinion is: QBASIC is more than abandonware (has been online for download on MS servers for quite a while!), EXPAND is for MS style install archives which are usually bundled with EXPAND. So we should focus on bug- fixing and improving the existing tools to reach "MS DOS 5.0 and some more" feature set. Whenever we have extra spare time, we can work our way towards more MS DOS 6.0 features - but without trying to be a close clone. Having a virus scanner is okay, but cloning MSAV would mean cloning a bad product which is 11 years old, for example (probably more, MS DOS 6.22 was of 1993, and I do not remember any updates for MSAV shipped after that). Many of the extra features of MS DOS 6.xx were bought from 3rd party sources. You can use FreeDOS with lots of 3rd party software, too X-). APPEND would be nice for dual-floppy-no-harddisk systems. So having it is good. If it refuses to work on FAT32 or anything like that, fine for me. DRIVER/DRIVPARM in the kernel would be nice for embedded systems and probably not even very complicated to add! Normal users with harddisks will need neither APPEND nor DRIVER/DRIVPARM. I think we can call FreeDOS a clone of MS DOS 5.0 features with many goodies from later Win/DOS versions inside but with still a few DOS 5.0 features missing - some "legacy" ones do not hurt, some others like Win 3.11 compat should probably be fixed before we call it FreeDOS 1.0 ... This is not exactly a short reaction to the suggested TODO list updates but it is a longer elaboration about SCANDISK and the-MS-DOS-which-we-should-try- to-reach choices. Congrats if you have reached the end of this mail 8-). Eric. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
