I made a very simple distribution, close to the original MS-DOS disks. Main carachteristics:
- Single floppy - Single language - No fancy program or interface at all, but complete functionality - Simple batch menu, with most functions are for partitioning, formating and installing. - Config optional with a supplied Congif+Autoexec containing a simple but advanced setup. I was making a new version, allong with required files for GPL distribution, including a very good windows floppy generation executable (I create it with a licenced program). I just put it on wait for the new kernel. So far I found 2 BIG advantages in the new kernel: - Better SATA operation, at least in one machine only the new kernel worked - better security: I use a database program and the new kernel rarely has lost clusters after system crashes I am glad to know that there is work on the new kernel's bug :) Alain Pat Villani escreveu: > Hello Alain, > > I probably missed it. What is different about your distribution? f it > is a major imrpvement to what we have, why not distribute it as a > FreeDOS distribution? > > Pat > > > On Thu, Jan 7, 2010 at 7:54 AM, Alain Mouette <ala...@pobox.com > <mailto:ala...@pobox.com>> wrote: > > Hi all, > > first of all, Happy ne year :) > > Is there anyone working on, o willing to work on this cross-linked files > bug? It seams to me that this can be very important for FreeDOS use, I > allways assume that if a bug exists somewhere hidden, it could also > atack under other circumstances, ie. not only on a 4Gb 99.9% full > disk :( > > I have prepeared a new FreeDOS distribution for REAL USE in the field > and this is holding me back. I never had problems with disks (older > kernel), maybe even lass then with MS-DOS 7.10, and the latest kernel > that I tested is even better (near to no lost cluster on reset). So this > new version is very exciting :) > > Thanks for all, > Alain > > Eric Auer escreveu: > > Hi dos386 :-) > > > >> 1. No new details to the "Crosslink-BUG" ... cluster size is 4 > KiB :-| > > > > However, it is very interesting that it involves broken high 16 bits > > on FAT32 on almost full disks. I hope this helped Bart to zoom in on > > potential causes for the bug :-). > > > > http://sourceforge.net/support/tracker.php?aid=2901916 > > > www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html > > <http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html> > > > > To summarize your 19 Dec 2009 mail: Use kernel 2039 on a FAT32 > (FAT28) > > disk, for example 6 GB with 4 kB/cluster and quite full, for example > > 95 p/c, with fragmented free space. Copy some files, delete some, > copy > > some more files. Then, you say, many cross-links show up, mostly > in the > > freshly copied two sets of files, also lost cluster chains. You > are very > > right that the INTERESTING thing is that the broken files all > have bad > > starting cluster numbers, all below 0x10000, even though there > were no > > free clusters in the first 65536 clusters before the experiment! > > > > > > > >> 2. Discovered a NEW BUG: > > > > Half of it is not a bug, the other half is... > > > >> 1. Get WDE or similar > >> 2. Overwrite both entries in FS-info sector with $FFFF'FFFF > >> 3. Reboot to FreeDOS > >> 4. DIR - there is a massive delay at the end > > > > This is because DIR tells you how much space is used / free. > > For that, DOS has to count all used / free FAT clusters by > > reading the whole FAT, which is big in FAT32. The FS-Info > > sector caches the information, but by setting the values to > > the FFFF which you mention, you force a recalculation... > > > >> 5. DIR - no delay anymore > > > > See above :-) > > > >> 6. Try to brew a file or SUBDIR ("MD") > >> - expected result: should work > >> - effective result: DOESN'T WORK > > > > Do you also get problems with file creation or growth, as > > far as those involve allocation of more clusters? If yes, > > which problems, just failure? Or creation of cross links? > > > >> 7. Retry and it will work now > > > > Interesting! > > > >> EDR-DOS doesn't have this bug. > > > > It probably also has the delay? I assume by bug you only mean > > the problem of creating a directory after invalidating FS-Info? > > > > Eric > > > > PS: I think 2039 got less publicity than 2038 and 2038 > > has more conservative updates. Combined, this means in > > 2039 you have more changes but (yet) fewer testers... > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > <mailto:Freedos-kernel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/freedos-kernel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
