Hi Bernd! Nice that the new distro is delayed, maybe some things can get fixed in the next 2 weeks...
> *DOSFSCK with working FAT32 Definitely a good thing to have. Please compare 2.8-fat32 and 2.10 Imre/Lucho version compatibility for FAT16 and FAT32 for MS and FreeDOS kernels with and without FAT32 support. Maybe it helps to create a all/all compatible 2.10 version. > *DEBUG with working FAT32 support (official version this time) If Paul can find the time: For BOTH FAT16 and FAT32 it would be great to have 32 bit sector number processing! Otherwise you can only edit the first 32 MB (as with the current DEBUG version which has working FAT32 sector I/O but only for the first 32 MB). > *SYS with various suggested improvement ideas. Reminds me that "read first 512 bytes of FILE, treat it like a boot sector and write it back without truncating FILE" would be nice (to SYS disk images) to have and not that hard to add. It would even allow (limited) support for compiling a LINUX binary of SYS (in Linux, all disks are accessible through devices, so if you can SYS a file then you can also SYS a device, in other words you can SYS a disk directly with the Linux SYS :-)). > I'm without any internet connection until next week How that? So I guess all work on the distro will wait, too? > *updated kernel to 2035 Who knows, maybe we could even include a CVS/Arkady kernel in the distro? It should NOT be the default kernel, though, because there was almost no testing yet. > *improved harddisk/partition detection Reminds me that WHICHFAT - only FreeDOS kernel affected! - cannot detect "drive letter exists but drive is not formatted" case. Bernd, FREETEST results show a consistent pattern here? Please check http://www.coli.uni-sb.de/~eric/stuff/soft/specials/ whichfat.zip and free-disk-space-tester-freetest.zip (binary and sources) and tell me why the used kernel function makes WHICHFAT believe that unformatted is FAT12, how the kernel can be fixed and how WHICHFAT could work around the problem. Main function is int 21.36 afair. > *diskette installation finally possible after 2 years. > it uses temporary files on disk however :( No big problem as long as it really helps with speed! People who cannot boot from CD-ROM should still have a few 100 kbytes more harddisk space free than needed for the installed FreeDOS, so do not worry about that... Remember to rename "full" and "mini" to "base with sources" and "base without source codes", though... > *installation from another location is now possible. > This means you can copy the contents of the cd image to your harddisk, > then use the bootdisk, and point to the harddisk location of your > FreeDOS files. I would have preferred: Copy all files. Boot from any DOS floppy. Change to the directory with the copied files. Run the main batch file (which can possibly automatically check if you are REALLY in DOS and are using FreeCOM, to help people who did the copying in Windows and could not resist to click on the batch file!). Otherwise: Nice news :-). Jason was planning to revamp SHSUCDX, maybe he can get some updates fast enough for the update? How about Memtest86+, by the way? And not to forget: If somebody can push the analysis of the "Geraldo FAT32 FORMAT logs" somewhat further, maybe I could add some compatibility improvements to FreeDOS FORMAT. That somebody has to have Windows. About menu hotkeys and Arkady-fying: I think ESC should not be "all yes". In FreeCOM, ESC is an alias for NO and ENTER is an alias for YES - but only for the current question (as far as I remember). Maybe F8 should toggle F8 mode during config processing (not during autoexec processing), then Y / N (DR DOS has YESKEY=... or something, to support non-US keyboards better) and maybe ENTER / ESC aliases can be used for every single config question. F8 would mean "stop singlestepping". F5 could indeed be used for "skip rest of config / autoexec" during singlestepping mode. Arkady really writes big patches for small memory savings. Sometimes code gets harder to read, too. Code should stay READABLE and we should be very careful to avoid introduction of new BUGS, but otherwise, optimizations are always okay. I often do not comment because the patches are too many and too big. I simply hope that no new bugs are introduced... I wish Arkady could move priorities around - fix bugs first, do not start with squeezing out some optimizations. Optimizing should wait, unless it is an easy / simple / foolproof optimization. Apart from that, Arkady seems to be the only programmer who is working on the kernel at all right now!? No real news from Lucho or Tom these days. Eric ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
