Hi Alain, > Only one program is missing and that is a Scan-Disk (written as 2 words) > utility for Fat32. For what I kow, DOSFSCK is working and need only a > small fixes in the read sector.
I strongly disagree. Our SCANDISK for FAT1x is completely defunct, so we have no SCANDISK in the meaning of "nice looking user interface to the CHKDSK and DOSFSCK engines" at all. My DOSFSCK-2.8-FAT32 currently works okay, but a working 2.10 port would be much better. I hope Imre can find the time to add working lowlevel disk access drivers to 2.10 (does not work at all for me for FAT16 in FreeDOS). It would not be THAT hard. Have a look at my 2.8-FAT32 (can only read, only compiles okay in Turbo C, not in Borland C, see recent absread discussion) and Imres 2.10, maybe YOU can help us and provide a working "can read and write all FAT types" 2.10 ... What else is missing? Very important to me would be the online TODO list http://www.ibiblio.org/pub/micro/pc-stuff/freedos/todo/index.php describing the state of Beta9rc4 because people think (and they are right) that the TODO list will describe the current version. Now I already have "offline" knowledge of how far we "really" are: append is very alpha, maybe even dummy. atapicdd is pretty alpha emm386 vcpi is alpha (but great that it is there) graftabl would probably not be too hard to fix if we knew which codepages are missing. [nansi chaining will be useful as soon as display becomes a sys] [emm386: h=... should be post 1.0, ram=... and rom=... should be feasible] [no idea how far keyb is] [shsucdx /v would not be that hard, but having a cache, especially read-ahead, inside the shsucdx itself would be both useful and not easy. Even wif you use CDRcache for most of the caching...] NLSFUNC is missing, but we already have lots of NLS functionality in the kernel. I wonder how hard it would be to write NLSFUNC and who can do it. PRINT/PRINTQ has several TODOs, maybe it needs a new maintainer...? RAMDISK problems are a bit vague... Maybe even kernel related. BACKUP / RESTORE (MS file compatible) could be moved to post 1.0 if needed. DEFRAG - I would like to see an update, I think there have been bugfixes but they did not get published yet. FDISK - The newest 1.21 (?) version seems to be better than 1.20, but I think there are still important bugs on some systems. Updates planned? FORMAT - With all feedback from "Fritz" and Johnson I still could not figure out why running FreeDOS FORMAT under Windows creates broken FAT32. All boot sector fields look okay for me but still the root directory is accessed at the wrong place by Windows. MIRROR - FAT12 support would be nice. This reminds me that MIRROR (safeformat) and UNFORMAT which are builtin in FORMAT has a bug for FAT32... RECOVER - There are two modes: One zaps the FAT and root dir and tries to re-invent a fat based on directory data found by scanning the disk etc. (only a "last ch*nce" method). The other which would be more useful would be "replace broken sectors by sectors filled with '?'" and should (IMHO!) be implemented as an option to XCOPY: Copy files and instead of giving up on errors replace broken sectors... Could even delete those files which had no errors (the copy of them, that is) in some special mode. Is UNFORMAT really ready? FreeCOM should at least fix the following bugs / problems: DIR should use ext. free size (can be > 2 GB, but displaying in units of kB or even MB would be okay) on FAT32. CLS should work properly and without that extra library which it uses. Overwriting file by nonexisting file zaps file. Context memory has a memory leak. Renaming dir with trailing \ makes it disappear. Then there are some special "resolved" cases in FreeCOM: single wildcards not supported IF / FOR redirection problems I read that 0.82pl3a finally fixes "nonexisting drive reported as out of memory", so I suggest that 0.82pl3a should get some PR? Did not hear of it. UNDELETE is improving thanks to work by Rob, maybe Patric can add FAT32... the resident things could be a separate TSR (delete-log and "turn delete into move-to-trash, logging original filename") and/or post 1.0 ... MEM has some wishlist. MODE should be complete now, except that codepages are only supported for CON. Kernel COUNTRY= is there with one (not 2) arguments already, and MS syntax for MENU could be postponed. So far for that. If you have some spare time, please visit Bugzilla and check which of the bugs you can faithfully mark as fixed for current versions! I think we should get a FULL beta 9 out, but there are a few programs and not so few features missing for 1.0 ... For the FULL beta 9, I would like to have: - a binary-only CD-ROM download - a full CD-ROM download - a binary-only (i.e. no sources) 1.44M floppy distro - ... and a batch script to split that into a 720k floppy distro - an ODIN version with all executables and as many supplemental files (like the help system and NLS) as fits on one 1.44 or 1.68 MB floppy disk :-). So far my 2 cents or some more X-). Eric. PS: We recently had some interlnk/intersvr style software posted to the list (the URL that is). Did anybody with suitable hardware get that "serial port drive letter" thing to work with FreeDOS? Would be interesting. PPS: My favourite post 1.0 wishes are: DRIVPARM/DRIVER/FASTOPEN as kernel builtins, vsafe, undelete FAT32 and maybe write-behind caching for LBAcache (if you want to test read-ahead or element size effects, contact me... esp. if you have SMARTDRV or NWCACHE for comparison; CD-ROM cache will stay in the separate CDRcache for now. And remember: Do not load LBAcache into slow hard- ware UMBs if you have uncached UMBs. CDRcache is less "hurt" by this because CD-ROMs are slow anyway and CDRcache uses bigger element size!). ------------------------------------------------------- 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
