long analysis follows, some suggestions at the bottom of this mail :-)
> Thank you for your reply. I tried few kernel and here are the results:
I gather you mean "you tried the SYS of a few kernels together with
the corresponding KERNEL versions"? My focus is on the SYS activity,
as the kernel should at least show a version message before hanging
as long as the boot sector put by SYS has done the correct stuff.
> 2041_86f16 : floppy boots but no hard drives detected
If you only have FAT32 partitions, then using a kernel without
FAT32 support would lead to that expected result, yes ;-)
Other versions, sorted (2020 is anycient anyway) from old to new:
> 2030: BOOTS!
> 2031_32: BOOTS!
> 2032: hangs
> 2032a: hangs
> 2035a: boots, detects HDD, sys [...] hard drive fails to boot
> 2039_86f32: as above
> 2041_86f32: as above
In short, we introduced a bug in the SYS of version 2032?
That would be 2003-09-21 while version 2031 is 2003-07-19.
But your pictures on Google seem to say that version 2032
still is okay, while newer versions are not okay?
> And that one results in a hang:
As Google is a pain for DOS users, a summary of what it says...
SYS 2.8 detects FAT32, FAT at sector 3f+20, 0 root dir entries,
FAT at sector 63+32, root dir at PREVIOUS + 0*2, kernel.sys has
45884 bytes, command.com has 92109 bytes... (date 2003-09-21)
> This is a successfully sys c: output
SYS 2.6 (unknown date) kernel.sys 44900 bytes, FAT at sector 5f
which is 3f+20, data at sector 603f, 0 root dir entries, 255 root
dir sectors (really???), FAT at sector 487060009 = 63+32 (???),
root dir at sector 1313429276 = PREVIOUS + 0*2, data starts at
sector 1163081785 = PREVIOUS + 255, command.com is 92109 bytes.
Note that the displayed numbers look very wrong, so SYS might be
calculating bogus FAT32 parameters... Or maybe it only displays
wrong values, while internally using correct values. This can be
a side effect of compiling SYS with the "wrong" compiler in case
of incomplete portability. The weird thing is that SYS works for
you in version 2.6 :-)
Checking the source code...
2009: Jeremy introduced a command line option to force CHS / LBA.
2004, 2009, 2010, 2011: Fixes to make things work for all compilers?
2007: Faster file copy, update FAT32 backup boot sector if needed.
2007: Fixes for FAT32
2003-09-21: Metakern compatibility r702
2003-08-08: Support for other sector sizes on FAT16, SYS 2.7
(note that the kernel itself only works for 512 byte sectors)
2003-06-16: This is version SYS 2.6 here.
etc. Note that SYS 2.6 only supports CHS style boot for FAT32!
I suggest the following: Apparently the FAT32 boot sectors have
not changed since 2004, but SYS itself has evolved further. In
particular, try the newest SYS 3.6e which has two options for
/FORCE:LBA and /FORCE:CHS with obvious effects. Please try with
/VERBOSE and with > output.txt so you can paste results into a
I see two possible problems: Either your BIOS supports LBA but
our FAT32 LBA boot sector is incompatible with it. In that case,
the /FORCE:CHS option for SYS will help you. Or SYS itself has
errors in calculating FAT32 parameters. Then both LBA and CHS
might be broken in certain versions of SYS, but should at least
be fixed again in newest versions.
This tells me that the FAT32 boot sectors changed at those dates:
2004-01-24 different load seg and stack handling, no int 13.0
(SYS 3.1, kernel 2.0.33, claims to improve FAT parameter calculation)
2003-09-21 different padding, a:\metakern.sys detect & use (SYS 2.8)
(not sure if SYS really copies metakern.sys to the target drive??)
2003-08-08 new CHS and LBA FAT32 boot sectors (patches: Jon & me)
and new CHS-LBA-auto-detect FAT12 FAT16 boot sector (by Tom) (SYS 2.7)
Note that SYS 2.6 and older did not support LBA for FAT32 at all
and the CHS FAT32 and CHS or LBA FAT12 FAT16 boot were different.
The different versions of the kernel download (which include SYS)
can be found in our Sourceforge file area:
Thanks! Cheers, Eric
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
Freedos-user mailing list