Memory hold

Jeff Richards wrote:

The maximum partition size for a FAT32 partition with the tools
included with W98 is about 32Gb, but tools that allow larger
partitions to be created and managed are available.

The 137Gb limitation is imposed by the ATA interface.

W98 scandisk and defrag *do* have a 127.53GiB or 137GB partition
limitation, caused by their 16 bit nature.
http://support.microsoft.com/kb/184006/en-us

Jeff Richards wrote:

The maximum partition size for a FAT32 partition with the tools
included with W98 is about 32Gb

Wrong.

I'm not sure if, specifically, win-98 (original or first edition) had
any specific problem with drives or volumes larger than 32 gb (I highly
doubt it), but second edition (and specifically fdisk) is easily capable
of formatting drives and volumes at least up to 128 gb in size. There
may have been a problem with some versions of fdisk and their ability to
format drives or volumes larger than 64 gb. But fdisk is essentially
what we're talking about here, and different versions of fdisk did have
various problems (some were major, some were minor). Microsoft did
provide at least 1 update to fdisk after win-98se was released, perhaps
2.

The 32 gb problem you're thinking about is probably the fact that
Micro$oft handicapped win-2k and XP (and probably Vista as well) by
preventing them from having the ability to create fat32 volumes larger
than 32 gb.

As far as "management" of large fat32 volumes, specifically the use of
DOS scandisk, windows scandisk and defrag, the criteria that determines
what their limits are are different, and they center around the number
of clusters or allocation units on the volume. Any volume that does not
exceed 4 million allocation units will have no problems with windows-98
scandisk or defrag. The DOS scandisk program has no limits as far as I
can tell, and I've tested it on drives with up to 120 million clusters.
The use of Windows ME versions of scandisk and defrag on win-98 has been
found to allow the use of even larger drives (exceeding 4 million
clusters).

The 137Gb limitation is imposed by the ATA interface. Although it
is possible to arrange the partitioning so that a FAT32 partition
extends beyond this limit, restrictions in ATA and the Int13
interface means that addresses will wrap around and writes to such
a partition will corrupt other parts of the disk.

Actually Jeff, that statement is quite wrong. I'm surprised that an MVP
would post such incorrect information. It's probably indicative that
you spend little to no time using win-98 any more.

The truth is that the ATA interface is 48 bits wide, and the BIOS Int13
"enhanced" access routines allow full addressability to the full FAT32
spec. In other words, under DOS, a program (including DOS itself) has
full access to the largest FAT32 volume possible - 2.2 tb
(terra-bytes). This would be the case for any computer who's
motherboard was made, oh, say, during or after 2002. Prior to 2002,
many BIOS's did not impliment the full 48 bits, so many older computers
will experience a variety of drive-size limits that may be possible to
remedy with a BIOS update.

With regard specifically to Windows, the specs of the protected-mode IDE
driver will determine if Windows has a volume-size or drive-size
limitation (not the BIOS or NOT the specs of the ATA interface).

Win-2K and XP were both originally limited to 128 gb drive size because
of the way their IDE drivers were written. That was corrected later
with service packs. In the case of Windows 98, it's protected mode
driver (EDSI_506.PDR) is the limiting factor that prevents a "generic"
installation of win-98 from being able to use a drive larger than 128
gb. This limitation can be eliminated if a secondary drive controller
is installed (it will come with it's own driver which replaces
EDSI_506.PDR). There are also third-party direct replacements for
ESDI_506.PDR. The use of a SATA hard drive (by installing win-98 on
motherboards with SATA interfaces made during 2003 to about 2006) will
almost universally, with little effort, allow win-98 to be compatible
with pretty much any hard drive available today.

The whole system must be configured with 48-bit LBA to use any part
of a disk beyond 137Gb in W98.

While that sweeping statement is true, it can be said more specifically
that the protected mode driver that win-98 uses for hard-drive access
must adhere to the full 48-bit IDE/ATA standard. One way to do this, if
the user is really in a bind and has no other choices, is to simply
rename the file ESDI_506.PDR to something else so that win-98 doesn't
have access to it and can't load it. In that case, win-98 will resort
to "compatibility-mode" or "dos-mode" hard-drive access, in which case
it will use the bios routines to access the drive, which will be be
perfectly fine so long as the BIOS has also implimented 48-bit
addressing. This will result in slower / lower performance while using
win-98, however.

Jeff Richards wrote:

The maximum partition size for a FAT32 partition with the tools
included with W98 is about 32Gb

Wrong.

I'm not sure if, specifically, win-98 (original or first edition) had
any specific problem with drives or volumes larger than 32 gb (I highly
doubt it), but second edition (and specifically fdisk) is easily capable
of formatting drives and volumes at least up to 128 gb in size. There
may have been a problem with some versions of fdisk and their ability to
format drives or volumes larger than 64 gb. But fdisk is essentially
what we're talking about here, and different versions of fdisk did have
various problems (some were major, some were minor). Microsoft did
provide at least 1 update to fdisk after win-98se was released, perhaps
2.

The 32 gb problem you're thinking about is probably the fact that
Micro$oft handicapped win-2k and XP (and probably Vista as well) by
preventing them from having the ability to create fat32 volumes larger
than 32 gb.

As far as "management" of large fat32 volumes, specifically the use of
DOS scandisk, windows scandisk and defrag, the criteria that determines
what their limits are are different, and they center around the number
of clusters or allocation units on the volume. Any volume that does not
exceed 4 million allocation units will have no problems with windows-98
scandisk or defrag. The DOS scandisk program has no limits as far as I
can tell, and I've tested it on drives with up to 120 million clusters.
The use of Windows ME versions of scandisk and defrag on win-98 has been
found to allow the use of even larger drives (exceeding 4 million
clusters).

The 137Gb limitation is imposed by the ATA interface. Although it
is possible to arrange the partitioning so that a FAT32 partition
extends beyond this limit, restrictions in ATA and the Int13
interface means that addresses will wrap around and writes to such
a partition will corrupt other parts of the disk.

Actually Jeff, that statement is quite wrong. I'm surprised that an MVP
would post such incorrect information. It's probably indicative that
you spend little to no time using win-98 any more.

The truth is that the ATA interface is 48 bits wide, and the BIOS Int13
"enhanced" access routines allow full addressability to the full FAT32
spec. In other words, under DOS, a program (including DOS itself) has
full access to the largest FAT32 volume possible - 2.2 tb
(terra-bytes). This would be the case for any computer who's
motherboard was made, oh, say, during or after 2002. Prior to 2002,
many BIOS's did not impliment the full 48 bits, so many older computers
will experience a variety of drive-size limits that may be possible to
remedy with a BIOS update.

With regard specifically to Windows, the specs of the protected-mode IDE
driver will determine if Windows has a volume-size or drive-size
limitation (not the BIOS or NOT the specs of the ATA interface).

Win-2K and XP were both originally limited to 128 gb drive size because
of the way their IDE drivers were written. That was corrected later
with service packs. In the case of Windows 98, it's protected mode
driver (EDSI_506.PDR) is the limiting factor that prevents a "generic"
installation of win-98 from being able to use a drive larger than 128
gb. This limitation can be eliminated if a secondary drive controller
is installed (it will come with it's own driver which replaces
EDSI_506.PDR). There are also third-party direct replacements for
ESDI_506.PDR. The use of a SATA hard drive (by installing win-98 on
motherboards with SATA interfaces made during 2003 to about 2006) will
almost universally, with little effort, allow win-98 to be compatible
with pretty much any hard drive available today.

The whole system must be configured with 48-bit LBA to use any part
of a disk beyond 137Gb in W98.

While that sweeping statement is true, it can be said more specifically
that the protected mode driver that win-98 uses for hard-drive access
must adhere to the full 48-bit IDE/ATA standard. One way to do this, if
the user is really in a bind and has no other choices, is to simply
rename the file ESDI_506.PDR to something else so that win-98 doesn't
have access to it and can't load it. In that case, win-98 will resort
to "compatibility-mode" or "dos-mode" hard-drive access, in which case
it will use the bios routines to access the drive, which will be be
perfectly fine so long as the BIOS has also implimented 48-bit
addressing. This will result in slower / lower performance while using
win-98, however.

wrote:

This is correct. However I believe the maximum 137gb is per
partition. (I think this is correct?). So if you buy a 200gb
drive, make two (or more) partitions, such as 130 / 70 or 100
/ 100, or 100 / 50 / 50 (that's 3 partitions).

WRONG!

If you connect a hard drive to a win-98 system, and that drive is larger
than 128 gb (or 137 Gb, depending on how you define "giga"), then you
will screw up the data on the hard drive if windows attempts to write to
the drive beyond the 127 gb point on the drive.

So if you have a 200 gb drive, you can't simply create 2 volumes of 100
gb each and think you're ok. The first volume will be ok (you can fill
it up to 100%) but if you fill the second volume with 28 gb of files,
then the drive will become corrupted when you cross the 128 gb point on
the drive. The data you think is being written to the 129 gb point on
the drive will be wrapped-back to the 0 gb point (which is the FAT area
of the first volume) and you'll screw up that volume big time.

This only applies to hard drives that are physically connected to the
IDE port on the motherboard. I don't believe this applies to USB
drives.

Using SATA hard drives is a different story, and depending on how you
configure the SATA port in the BIOS, you can either also have this same
problem, or you won't and you can use very large SATA drives on win-98
no problem.

If I got a 200gb drive, I'd probably make at least 6 partitions on it.

Again, this is wrong.

If you connect a drive larger than 128 gb to the IDE/ATA interface of a
win-98 system, then you MUST only format and use the first 128 gb of the
drive. Even if you format it so that it has multiple volumes, that
doesn't matter. Only the first 128 gb of the drive is usable.

Anything above 128 gb is lost to you and must not be formatted because
win-98 will *try* to use it if it think's it's available, and when it
tries to use it it will screw up the file system of the drive and you'll
need very sophisticated drive repair tools to recover the data on the
drive.

wrote:

This is correct. However I believe the maximum 137gb is per
partition. (I think this is correct?). So if you buy a 200gb
drive, make two (or more) partitions, such as 130 / 70 or 100
/ 100, or 100 / 50 / 50 (that's 3 partitions).

WRONG!

If you connect a hard drive to a win-98 system, and that drive is larger
than 128 gb (or 137 Gb, depending on how you define "giga"), then you
will screw up the data on the hard drive if windows attempts to write to
the drive beyond the 127 gb point on the drive.

So if you have a 200 gb drive, you can't simply create 2 volumes of 100
gb each and think you're ok. The first volume will be ok (you can fill
it up to 100%) but if you fill the second volume with 28 gb of files,
then the drive will become corrupted when you cross the 128 gb point on
the drive. The data you think is being written to the 129 gb point on
the drive will be wrapped-back to the 0 gb point (which is the FAT area
of the first volume) and you'll screw up that volume big time.

This only applies to hard drives that are physically connected to the
IDE port on the motherboard. I don't believe this applies to USB
drives.

Using SATA hard drives is a different story, and depending on how you
configure the SATA port in the BIOS, you can either also have this same
problem, or you won't and you can use very large SATA drives on win-98
no problem.

If I got a 200gb drive, I'd probably make at least 6 partitions on it.

Again, this is wrong.

If you connect a drive larger than 128 gb to the IDE/ATA interface of a
win-98 system, then you MUST only format and use the first 128 gb of the
drive. Even if you format it so that it has multiple volumes, that
doesn't matter. Only the first 128 gb of the drive is usable.

Anything above 128 gb is lost to you and must not be formatted because
win-98 will *try* to use it if it think's it's available, and when it
tries to use it it will screw up the file system of the drive and you'll
need very sophisticated drive repair tools to recover the data on the
drive.

Ingeborg wrote:

The 137Gb limitation is imposed by the ATA interface.

W98 scandisk and defrag *do* have a 127.53GiB or 137GB partition
limitation, caused by their 16 bit nature.
http://support.microsoft.com/kb/184006/en-us

The real problem for win-98 scandisk and defrag is win-98's IDE driver -
ESDI_506.PDR. It does not allow correct access beyond the 128 gb point
on the drive. Microsoft carefully words their explaination to point the
blame at scandisk and defrag being 16 bits instead of their own failing
for updating ESDI_506.PDR to the full 48 bits (like they had to do for
2K and XP).

With regard to win-98 scandisk and defrag, the answer is to simply use
the win-me versions of those apps (they allow for the use of volumes
with much higher cluster-count values).

They also say in other kb's that DOS scandisk is also a 16-bit program
and is not compatible with drives with more than 4 million clusters, but
I've found that to be an outright lie.

I suggest anyone wanting to understand these limitations in more detail
look at these:

http://tinyurl.com/ch8935
http://tinyurl.com/cm75pf

Reposted below is the majority of material contained in the above 2
links:

-----------------------------

Newsgroups: microsoft.public.win98.gen_discussion
From: 98 Guy
Date: Mon, 26 Feb 2007 10:49:46 -0500
Subject: Update 4: Cluster size and exploring the limits of FAT-32

I think this will be the last update, as I've made a rather important
discovery, which is that DOS scandisk (both the original win-98
version and the windows ME version) don't really seem to have a
cluster size limitation.

Specifically, here's what I've just tested:

drive c: 25 gb / 4kb cluster size / 6.3 million clusters
drive d: 31 gb / 4kb cluster size / 7.8 million clusters
drive e: 125 gb / 4kb cluster size / 31.2 million clusters
drive f: 156 gb / 32kb cluster size / 4.9 million clusters

drive (c) is SATA drive 1
drive (d) and (e) are SATA drive 2
drive (f) is SATA drive 3

Drive C has win-98se installed, and instead of starting 98 I instead
brought up the start menu and started in DOS. From the command
prompt, I ran scandisk (Win-98se and Win-ME).

Both of them ran fine on all of the above volumes.

Previously when I was testing dos scandisk.exe, I was booting from a
floppy, and probably wasn't loading himem.sys. Himem.sys is needed by
scandisk to run properly.

So here is the master summary of this thread:

---------------------------

1) Scandisk (DOS scandisk.exe, not Windows scandskw.exe) does not
appear to have a cluster-count limitation. Both Win-98se and Win-ME
versions of scandisk have been run on drives with up to 31 million
clusters and have executed properly with no errors. Himem.sys must be
loaded for scandisk to function properly. Microsoft states that
FAT-32 volumes are limited to 4.17 million clusters because of
scandisk.exe, and that scandisk.exe is limited to a memory or data
array size of 16 million bytes. It could very well be that this 16 mb
limit is based on Microsoft's stated minimum system requirements for
Windows 98 (which is 16 mb of system RAM) and that scandisk will
automatically make use of all available system memory if required.

----------------------------

2) Win-98se has been installed directly on 160 gb volumes formatted
with 4kb cluster size (resulting in 40 million clusters) and has not
shown any instability. This was performed on a 160 gb SATA drive
assigned to a RAID controller (but not used in RAID mode). To test
for 137gb data corruption (which theoretically takes place when a read
or write across the 137 gb boundary occurrs) a series of 1 gb VOB
files were copied repeatedly in order to fill the drive. The drive
was eventually filled with 150 of these 1 gb files, and no drive
corruption occurred.

----------------------------

3) The only drawback that I've seen when running a volume with a large
cluster count is that DOS will take a much longer time to perform the
first DIR command. This might also happen in Windows as well - I may
have seen this effect but I haven't specifically looked for it. The
issue is the computation and display of free remaining drive space,
which is part of the DIR command and also happens when browsing the
drives in windows. Related to this is the question does windows store
the amount of remaining drive space somewhere on the drive (instead of
requiring it to be re-calculated every time it's needed).

---------------------------

4) Standard DOS tools like fdisk and format can be used to partition
and format hard drives in excess of 137 gb. Fdisk was used to
partition a 160 gb drive into a 32 gb primary and 121 gb secondary.
The updated or "fixed" version of fdisk.exe was used. What has not
been tested (yet) is the undocumented /Z:n command line parameter for
format, which allows the user to specify a particular cluster size (n
x 512 bytes). Third-party drive utilities (based on On Track's Disc
Manager) can also be used to partition and format hard drives, but I
have found those utilities to be very unstable and to lock up/crash
about 75% of the time I use them.

---------------------------

5) There is evidence that 6,291,204 clusters may represent some sort
of "magic number". A third-party drive partition tool (PartitionMagic
Pro Server 8.05) resorted to this cluster count when an existing 32 gb
partition was manually resized to 4kb cluster size. Norton Disk
Doctor and Speed Disk was found to work properly using this cluster
count, but not on a volume with a slightly larger cluster count of 7.8
million clusters (see note 7 below). This 6.3 million cluster count,
combined with 32kb cluster size, results in a volume size of 206 gb.
Perhaps this set of parameters is the reason for the 200 gb hard drive
size which emerged in early to mid 2003. A dir command is also
performed instantly with no delays in computing free space given a
volume with 6.3 million clusters.

---------------------------

6) Win-98 versions of Scandisk (scandskw.exe) and Defrag did not
function on a volume with 6.3 million clusters but seems to be limited
to the MS stated value of 4.17 clusters. However, Windows ME versions
of dskmaint.dll and defrag.exe does appear to function correctly with
Windows 98se and compatibility with volume size of up to 31.2 million
clusters has been observed. It is not know what their ultimate limit
is.

----------------------------

7) Norton Utilities is a very common third-party set of applications
and their compatibility with large hard drives with a large cluster
count may be of importance to some people. I have found that Norton
Disk Doctor and Norton Speed disk were compatible with volumes with up
to 6.3 million clusters, but not more without using the command-line
parameter /NOLBA. When using this parameter, NDD and SD worked on
volumes with 7.8 million clusters but not 31 million. The exact
cluster-count limit is therefore unknown at this point and I may
explore that in the future.

The switch /NOLBA forces NDD and SD to skip the drive configuration
check. This can also be done using a registry entry by adding a DWORD
registry value named NOLBACHECK at this location:
HKEY_LOCAL_MACHINE\Software\Symantec\Norton Utilities

When this option is set to 1, Norton Disk Doctor and Speed Disk skip
the drive configuration check.

----------------------------

8) Anyone considering adding a large hard drive (a drive larger than
137 gb) to an existing win-98 computer needs to consider certain
issues that include the drive type (IDE/PATA vs SATA) as well as how
the drive is controlled by the motherboard BIOS (mapped to IDE channel
or controlled by RAID controller). The main issue here is that you DO
NOT WANT the win-98se 32-bit driver (ESDI_506.PDR) to be used to
access a hard drive larger than 137 gb. Many or most motherboards
made for the past 3 years will have built-in SATA ports. Windows-98
users are advised to obtain SATA drives instead of the older
conventional IDE drives when adding a new drive (larger than 137 gb)
to a system or if building a new system.

------------------------------

Newsgroups: microsoft.public.win98.gen_discussion,
microsoft.public.win98.disks.general,
alt.windows98
From: 98 Guy
Date: Mon, 23 Jul 2007 19:15:57 -0400
Local: Mon, Jul 23 2007 7:15 pm
Subject: Windows 98 large file-count tests on large volume (500 gb hard
drive)

File copy test - Windows 98

-------------------------
Hardware Details:

Motherboard: ASRock Dual VSTA:
http://www.asrock.com/mb/overview.as...l=775Dual-vsta
CPU: Intel Celeron 3.46 ghz
Chipset: VIA PT880 Pro/Ultra Chipset
Driver download (VIA Hyperion Pro Driver Package):
http://www.viaarena.com/Driver/VIA_H...nPro_V512A.zip
Onboard lan: Via Rhine II / Lan driver: fetnd5av.sys
http://www.viaarena.com/Driver/VT610...235_VT8237_VT8...
Installed memory: 512 mb, DDR
USB 2.0 Root Hub (driver: usbhub20.sys)
VIA PCI to USB Enhanced Host Controller (driver: usbehci.sys)
http://www.viaarena.com/Driver/VIA_USB2_V270p1-L-M.zip

Hard drive: Western Digital WD5000KS (500 gb) SATA
Hard drive is controlled by on-board VIA VT8237A Raid controller
(viamraid.mpd, ios.vxd, viamvsd.vxd)
-------------------------

Windows-98se CD was copied to it's own directory on the hard drive,
and all cab files were unpacked into their own separate subdirectory.
In addition to the unpacked cabs, I copied all files in my win-98
system and system32 directories. So this sub-directory has 2000 files
(129 mb). The over-all size of the win-CD directory is therefore 767
mb (5565 files, 366 folders).

I replicated that directory 541 times in a tree as follows:

c:\file test (root test directory)

\Super-1
\Super-2
\Super-3

In each of the above three directories, 10 subdirectories (0001
through 0010). In each of those 10 directories, 18 subdirectories
(000A through 000R). In each of those, a copy of the above-described
win98-CD source files.

The file-properties dialog box for c:\file test takes 10 to 15 minutes
to arrive at a final tally, which is:

Size: 405 gb (435,633,783 bytes) 441,899,741,184
Contains: 3,010,665 Files, 199,119 Folder

Screen capture of file-properties dialog box:

http://www.fileden.com/files/2007/5/.../file-test.jpg

(that is no longer a functional link)

Based on the size (135 gb) and time-stamps of the Super-x directories,
I calculated that the file-copy rate was effectively 11.5 mb per
second (it took 3.5 hours to copy the contents of Super-1 to Super-2).

chkdsk c:

487,431,968 kilobytes total disk space
52,323,392 kilobytes free

4096 bytes in each allocation unit
121,857,992 total allocation units on disk
13,080,848 available allocation units on disk

I re-started the computer in DOS and ran DOS-scandisk. I left it
running, will check back in a few hours to see how it finished.

Conclusion / Comments:

Well, basically, I almost filled a 500 gb hard drive with a replicated
set of files that range in size from a few bytes to a few mb in size.
A grand total of over 3 million files spread across almost 200,000
directories. Windows was functional during and after this file-copy
process, and the system continues to boot and function normally.

If anyone out there is not satisfied that my test methodology was not
sufficient to correctly test win-98 for a file-count limitation or a
directory-size limitation that may arise given current modern large
hard drives available today, please speak up and describe an alternate
test method.

As a comment, I don't believe that creating a set of zero-byte files
will necessarily accomplish or test windows-98 with the same level of
"stress" as the test I describe here.

---------------------------

The drive in question was formatted with Western Digital "Data
Lifeguard Tools" version 11.2 for DOS:

http://support.wdc.com/download/downloadxml.asp#53
http://websupport.wdc.com/rd.asp?p=s...http://support...

It creates a bootable floppy with drive-formatting software (I believe
it's some version of OnTrack's Disk Manager software). It allows for
the quick partioning and formatting of WD drives. For FAT-32, it
allows the user to choose the cluster size, from 512 bytes up to 32
kb.

I don't think there is a specific directory size (number of
entries) limitation, except in the root directory.

Actually, I think that FAT and FAT-16 had a limit of something like
512 entries in the root directory (I remember some win-95 systems that
didn't work properly when the number of files in the root directory
reached 512). I believe I read somewhere that FAT-32 does not
allocate a fixed size for the directory hence there is no practical
limitation as to how many entries the directory (root or otherwise)
can contain.

-----------

Just a bit of an update regarding DOS scandisk and my 500 gb drive.

After approx. 24 hours, scandisk is still operating on the drive.

Within the first few minutes (perhaps the first 15 - 30 minutes) it
checked the Media Descriptor and the File Allocation Tables. What has
taken the majority of time so far is the check of the Directory
Structure. It is currently at the 24% point of that check.

I'll let it go over night and see where it's at in the morning.

--------------

Ok, there seems to be a problem with enabling virtual memory.

From the System Properties, Performance tab, I am told that virtual
memory is not enabled. When I bring up the virtual memory dialog box,
the radio-button "let windows manage my virtual memory settings" is
selected, and the following information is shown in grey:

Hard Disk: c:\ -14440 MB Free
Minumum: 0
Maximum: no maximum

When I select the radio button "Let me specify my own virtual memory
settings" those settings change to this:

Hard Disk: c:\-14440 MB Free
Minimum: 0
Maximum: 51096

I changed the maximum to 512 (I assume that's mega-bytes) and
restarted. Virtual memory was still showing as being disabled. I set
both the min and max to be 512 and restarted again. It still said
that virtual memory was disabled, but this time the Hard Disk value
had changed to -13928 MB Free (a difference of 512). I changed both
to 128 and still virtual memory was still disabled.

Prior to each change, I looked for win386.swp in the root directory,
but it was never there (even when I tried to unhide it using attrib).

So something wierd is going on with the swap file and virtual memory.
Might have to resort to messing with registry or .ini settings to see
if I can get it going. Any known issues with Win-98 showing a
negative number for hard drive space or otherwise for refusing to
enable the swap file?

------------------

PS I have always been told the problem of large number of
clusters in 98 was due to the fact that on boot the FAT
Table was read into memory and would use up all available
memory just to hold the FAT Table.

That argument was offered back last February when I first tried
running win-98 on fat-32 volumes with large cluster counts.

I countered by pointing out that by Microsoft's own reasoning, a
volume was never allowed to have more than 4.177 million clusters
because that was the largest number of clusters that DOS scandisk
could process given a supposed 16 mb array size limitation. They
mentioned nothing about windows needing to load the entire FAT table
during normal use. And besides, given Win98's specified minimum
requirements (16 mb ram), you'd have a situation where a good chunk of
that would have been consumed by the FAT.

I've since discovered that DOS scandisk has no such 16 mb memory
limitation. Or perhaps it does, but it doesn't effect it's ability to
process a FAT with more than 4 million clusters. I think that the
only time the entire FAT table is read into system memory is during
disk maintainence like Windows scandisk and defrag.

If it's true that you need 4 bytes per cluster to read in the FAT
table, then maybe if I put more memory into the system the windows-ME
versions of scandisk and defrag would work. I think I'll try that.

If this were true it seems that with your 500G test all
available memory would be used and there would be nothing
left for programs.

Yes, that would have to be the case given 121 million clusters in my
situation (with 512 mb installed memory).

It also seems that your boot times would be in minutes not
seconds just to read the FAT Table.

The system boots fast, certainly within 1 minute. I haven't timed it
yet.

--------------------

Franc Zabkar wrote:
Is this it?

Negative Hard Disk Free Size Reported on Virtual Memory Tab in
System Properties: http://support.microsoft.com/kb/272620

As reported he

http://support.microsoft.com/kb/272620

I obtained the updated file from the win-98 service-pack thing
(unpacked it manually) and replaced my existing sysdm.cpl. While it
did correct the display of a negative free size on the hard drive, it
did not solve the virtual memory issue.

I then connected another SATA drive to the system (160 gb, with a
single 25 gb FAT-32 partition, formatted with 4 kb clusters, a little
over 6 million clusters) and Win-98 DID enable virtual memory when
instructed to put the swap file on the new drive.

So for some reason win-98 did not want to locate the swap file on the
500 gb drive. Either it did not like the fact that the drive was
formatted with 4kb cluster size (resulting in 121 million clusters) or
it didn't like where on the drive it would have to put it (at the back
10% of the drive).

Also -

I increased the amount of installed memory to 1 gb, and still got
"insufficient memory" when running Windows Scandisk and Defrag on the
500 gb drive.

DOS scandisk does not give an error, but it would have taken 4 days to
run (given it was at the 30% point after 30 hours).

--------------
July 28, 2007

Ron Martell wrote:

The FAT32 implementation provides for 28 bits to be used for
cluster numbers, which means that it is possible to have up
to 268,435,445 total clusters on a drive.

Smaller limitations are the result of the tools (FDISK & Format
for example) normally used to create FAT32 drives.

There is little to no information regarding Win-98's compatibility or
operational stability with volumes with large cluster-counts, and just
what gets broken at what cluster-count.

The year-2000 update to fdisk does work for 250 gb drives (I haven't
tried it on a 500 gb drive). Format also works on 250 gb drives, but
because of it's use of 32kb cluster size there will be 7.6 million
clusters on a 250 gb drive.

I am not sure if the native win-98 versions of scandskw.exe,
dskmaint.dll and defrag.exe will operate on a volume that exceeds 4.17
million clusters but the win-me versions will, at least up to 31
million clusters. The windows ME versions did not function on a
volume with 121 million clusters, displaying an "insufficient memory"
message (even on a system with 1 gb memory).

The MS-DOS version of scandisk.exe does not seem to have a
cluster-count limitation and has been seen to run without issue even
on a 500 gb drive with 121 million clusters (although it was only
allowed to run for 30 hours before being terminated - it was projected
that it would have taken 3 more days to complete it's scan).

It has been speculated that the number of clusters is limited because
win-98 loads the entire FAT table into memory during normal
operational use, but given the recent test with a 121-million cluster
drive that theory appears to be wrong.

The only issue so far with win-98 installed on a 500 gb volume with
121 million clusters is that it will not create or place the swap file
on it, hence virtual memory will not be enabled. It will create /
place the swap file on a secondary drive, even if that drive is
another 500 gb drive (but formatted with 32kb cluster size resulting
in 15 million clusters).

Ingeborg wrote:

The 137Gb limitation is imposed by the ATA interface.

W98 scandisk and defrag *do* have a 127.53GiB or 137GB partition
limitation, caused by their 16 bit nature.
http://support.microsoft.com/kb/184006/en-us

The real problem for win-98 scandisk and defrag is win-98's IDE driver -
ESDI_506.PDR. It does not allow correct access beyond the 128 gb point
on the drive. Microsoft carefully words their explaination to point the
blame at scandisk and defrag being 16 bits instead of their own failing
for updating ESDI_506.PDR to the full 48 bits (like they had to do for
2K and XP).

With regard to win-98 scandisk and defrag, the answer is to simply use
the win-me versions of those apps (they allow for the use of volumes
with much higher cluster-count values).

They also say in other kb's that DOS scandisk is also a 16-bit program
and is not compatible with drives with more than 4 million clusters, but
I've found that to be an outright lie.

I suggest anyone wanting to understand these limitations in more detail
look at these:

http://tinyurl.com/ch8935
http://tinyurl.com/cm75pf

Reposted below is the majority of material contained in the above 2
links:

-----------------------------

Newsgroups: microsoft.public.win98.gen_discussion
From: 98 Guy
Date: Mon, 26 Feb 2007 10:49:46 -0500
Subject: Update 4: Cluster size and exploring the limits of FAT-32

I think this will be the last update, as I've made a rather important
discovery, which is that DOS scandisk (both the original win-98
version and the windows ME version) don't really seem to have a
cluster size limitation.

Specifically, here's what I've just tested:

drive c: 25 gb / 4kb cluster size / 6.3 million clusters
drive d: 31 gb / 4kb cluster size / 7.8 million clusters
drive e: 125 gb / 4kb cluster size / 31.2 million clusters
drive f: 156 gb / 32kb cluster size / 4.9 million clusters

drive (c) is SATA drive 1
drive (d) and (e) are SATA drive 2
drive (f) is SATA drive 3

Drive C has win-98se installed, and instead of starting 98 I instead
brought up the start menu and started in DOS. From the command
prompt, I ran scandisk (Win-98se and Win-ME).

Both of them ran fine on all of the above volumes.

Previously when I was testing dos scandisk.exe, I was booting from a
floppy, and probably wasn't loading himem.sys. Himem.sys is needed by
scandisk to run properly.

So here is the master summary of this thread:

---------------------------

1) Scandisk (DOS scandisk.exe, not Windows scandskw.exe) does not
appear to have a cluster-count limitation. Both Win-98se and Win-ME
versions of scandisk have been run on drives with up to 31 million
clusters and have executed properly with no errors. Himem.sys must be
loaded for scandisk to function properly. Microsoft states that
FAT-32 volumes are limited to 4.17 million clusters because of
scandisk.exe, and that scandisk.exe is limited to a memory or data
array size of 16 million bytes. It could very well be that this 16 mb
limit is based on Microsoft's stated minimum system requirements for
Windows 98 (which is 16 mb of system RAM) and that scandisk will
automatically make use of all available system memory if required.

----------------------------

2) Win-98se has been installed directly on 160 gb volumes formatted
with 4kb cluster size (resulting in 40 million clusters) and has not
shown any instability. This was performed on a 160 gb SATA drive
assigned to a RAID controller (but not used in RAID mode). To test
for 137gb data corruption (which theoretically takes place when a read
or write across the 137 gb boundary occurrs) a series of 1 gb VOB
files were copied repeatedly in order to fill the drive. The drive
was eventually filled with 150 of these 1 gb files, and no drive
corruption occurred.

----------------------------

3) The only drawback that I've seen when running a volume with a large
cluster count is that DOS will take a much longer time to perform the
first DIR command. This might also happen in Windows as well - I may
have seen this effect but I haven't specifically looked for it. The
issue is the computation and display of free remaining drive space,
which is part of the DIR command and also happens when browsing the
drives in windows. Related to this is the question does windows store
the amount of remaining drive space somewhere on the drive (instead of
requiring it to be re-calculated every time it's needed).

---------------------------

4) Standard DOS tools like fdisk and format can be used to partition
and format hard drives in excess of 137 gb. Fdisk was used to
partition a 160 gb drive into a 32 gb primary and 121 gb secondary.
The updated or "fixed" version of fdisk.exe was used. What has not
been tested (yet) is the undocumented /Z:n command line parameter for
format, which allows the user to specify a particular cluster size (n
x 512 bytes). Third-party drive utilities (based on On Track's Disc
Manager) can also be used to partition and format hard drives, but I
have found those utilities to be very unstable and to lock up/crash
about 75% of the time I use them.

---------------------------

5) There is evidence that 6,291,204 clusters may represent some sort
of "magic number". A third-party drive partition tool (PartitionMagic
Pro Server 8.05) resorted to this cluster count when an existing 32 gb
partition was manually resized to 4kb cluster size. Norton Disk
Doctor and Speed Disk was found to work properly using this cluster
count, but not on a volume with a slightly larger cluster count of 7.8
million clusters (see note 7 below). This 6.3 million cluster count,
combined with 32kb cluster size, results in a volume size of 206 gb.
Perhaps this set of parameters is the reason for the 200 gb hard drive
size which emerged in early to mid 2003. A dir command is also
performed instantly with no delays in computing free space given a
volume with 6.3 million clusters.

---------------------------

6) Win-98 versions of Scandisk (scandskw.exe) and Defrag did not
function on a volume with 6.3 million clusters but seems to be limited
to the MS stated value of 4.17 clusters. However, Windows ME versions
of dskmaint.dll and defrag.exe does appear to function correctly with
Windows 98se and compatibility with volume size of up to 31.2 million
clusters has been observed. It is not know what their ultimate limit
is.

----------------------------

7) Norton Utilities is a very common third-party set of applications
and their compatibility with large hard drives with a large cluster
count may be of importance to some people. I have found that Norton
Disk Doctor and Norton Speed disk were compatible with volumes with up
to 6.3 million clusters, but not more without using the command-line
parameter /NOLBA. When using this parameter, NDD and SD worked on
volumes with 7.8 million clusters but not 31 million. The exact
cluster-count limit is therefore unknown at this point and I may
explore that in the future.

The switch /NOLBA forces NDD and SD to skip the drive configuration
check. This can also be done using a registry entry by adding a DWORD
registry value named NOLBACHECK at this location:
HKEY_LOCAL_MACHINE\Software\Symantec\Norton Utilities

When this option is set to 1, Norton Disk Doctor and Speed Disk skip
the drive configuration check.

----------------------------

8) Anyone considering adding a large hard drive (a drive larger than
137 gb) to an existing win-98 computer needs to consider certain
issues that include the drive type (IDE/PATA vs SATA) as well as how
the drive is controlled by the motherboard BIOS (mapped to IDE channel
or controlled by RAID controller). The main issue here is that you DO
NOT WANT the win-98se 32-bit driver (ESDI_506.PDR) to be used to
access a hard drive larger than 137 gb. Many or most motherboards
made for the past 3 years will have built-in SATA ports. Windows-98
users are advised to obtain SATA drives instead of the older
conventional IDE drives when adding a new drive (larger than 137 gb)
to a system or if building a new system.

------------------------------

Newsgroups: microsoft.public.win98.gen_discussion,
microsoft.public.win98.disks.general,
alt.windows98
From: 98 Guy
Date: Mon, 23 Jul 2007 19:15:57 -0400
Local: Mon, Jul 23 2007 7:15 pm
Subject: Windows 98 large file-count tests on large volume (500 gb hard
drive)

File copy test - Windows 98

-------------------------
Hardware Details:

Motherboard: ASRock Dual VSTA:
http://www.asrock.com/mb/overview.as...l=775Dual-vsta
CPU: Intel Celeron 3.46 ghz
Chipset: VIA PT880 Pro/Ultra Chipset
Driver download (VIA Hyperion Pro Driver Package):
http://www.viaarena.com/Driver/VIA_H...nPro_V512A.zip
Onboard lan: Via Rhine II / Lan driver: fetnd5av.sys
http://www.viaarena.com/Driver/VT610...235_VT8237_VT8...
Installed memory: 512 mb, DDR
USB 2.0 Root Hub (driver: usbhub20.sys)
VIA PCI to USB Enhanced Host Controller (driver: usbehci.sys)
http://www.viaarena.com/Driver/VIA_USB2_V270p1-L-M.zip

Hard drive: Western Digital WD5000KS (500 gb) SATA
Hard drive is controlled by on-board VIA VT8237A Raid controller
(viamraid.mpd, ios.vxd, viamvsd.vxd)
-------------------------

Windows-98se CD was copied to it's own directory on the hard drive,
and all cab files were unpacked into their own separate subdirectory.
In addition to the unpacked cabs, I copied all files in my win-98
system and system32 directories. So this sub-directory has 2000 files
(129 mb). The over-all size of the win-CD directory is therefore 767
mb (5565 files, 366 folders).

I replicated that directory 541 times in a tree as follows:

c:\file test (root test directory)

\Super-1
\Super-2
\Super-3

In each of the above three directories, 10 subdirectories (0001
through 0010). In each of those 10 directories, 18 subdirectories
(000A through 000R). In each of those, a copy of the above-described
win98-CD source files.

The file-properties dialog box for c:\file test takes 10 to 15 minutes
to arrive at a final tally, which is:

Size: 405 gb (435,633,783 bytes) 441,899,741,184
Contains: 3,010,665 Files, 199,119 Folder

Screen capture of file-properties dialog box:

http://www.fileden.com/files/2007/5/.../file-test.jpg

(that is no longer a functional link)

Based on the size (135 gb) and time-stamps of the Super-x directories,
I calculated that the file-copy rate was effectively 11.5 mb per
second (it took 3.5 hours to copy the contents of Super-1 to Super-2).

chkdsk c:

487,431,968 kilobytes total disk space
52,323,392 kilobytes free

4096 bytes in each allocation unit
121,857,992 total allocation units on disk
13,080,848 available allocation units on disk

I re-started the computer in DOS and ran DOS-scandisk. I left it
running, will check back in a few hours to see how it finished.

Conclusion / Comments:

Well, basically, I almost filled a 500 gb hard drive with a replicated
set of files that range in size from a few bytes to a few mb in size.
A grand total of over 3 million files spread across almost 200,000
directories. Windows was functional during and after this file-copy
process, and the system continues to boot and function normally.

If anyone out there is not satisfied that my test methodology was not
sufficient to correctly test win-98 for a file-count limitation or a
directory-size limitation that may arise given current modern large
hard drives available today, please speak up and describe an alternate
test method.

As a comment, I don't believe that creating a set of zero-byte files
will necessarily accomplish or test windows-98 with the same level of
"stress" as the test I describe here.

---------------------------

The drive in question was formatted with Western Digital "Data
Lifeguard Tools" version 11.2 for DOS:

http://support.wdc.com/download/downloadxml.asp#53
http://websupport.wdc.com/rd.asp?p=s...http://support...

It creates a bootable floppy with drive-formatting software (I believe
it's some version of OnTrack's Disk Manager software). It allows for
the quick partioning and formatting of WD drives. For FAT-32, it
allows the user to choose the cluster size, from 512 bytes up to 32
kb.

I don't think there is a specific directory size (number of
entries) limitation, except in the root directory.

Actually, I think that FAT and FAT-16 had a limit of something like
512 entries in the root directory (I remember some win-95 systems that
didn't work properly when the number of files in the root directory
reached 512). I believe I read somewhere that FAT-32 does not
allocate a fixed size for the directory hence there is no practical
limitation as to how many entries the directory (root or otherwise)
can contain.

-----------

Just a bit of an update regarding DOS scandisk and my 500 gb drive.

After approx. 24 hours, scandisk is still operating on the drive.

Within the first few minutes (perhaps the first 15 - 30 minutes) it
checked the Media Descriptor and the File Allocation Tables. What has
taken the majority of time so far is the check of the Directory
Structure. It is currently at the 24% point of that check.

I'll let it go over night and see where it's at in the morning.

--------------

Ok, there seems to be a problem with enabling virtual memory.

From the System Properties, Performance tab, I am told that virtual
memory is not enabled. When I bring up the virtual memory dialog box,
the radio-button "let windows manage my virtual memory settings" is
selected, and the following information is shown in grey:

Hard Disk: c:\ -14440 MB Free
Minumum: 0
Maximum: no maximum

When I select the radio button "Let me specify my own virtual memory
settings" those settings change to this:

Hard Disk: c:\-14440 MB Free
Minimum: 0
Maximum: 51096

I changed the maximum to 512 (I assume that's mega-bytes) and
restarted. Virtual memory was still showing as being disabled. I set
both the min and max to be 512 and restarted again. It still said
that virtual memory was disabled, but this time the Hard Disk value
had changed to -13928 MB Free (a difference of 512). I changed both
to 128 and still virtual memory was still disabled.

Prior to each change, I looked for win386.swp in the root directory,
but it was never there (even when I tried to unhide it using attrib).

So something wierd is going on with the swap file and virtual memory.
Might have to resort to messing with registry or .ini settings to see
if I can get it going. Any known issues with Win-98 showing a
negative number for hard drive space or otherwise for refusing to
enable the swap file?

------------------

PS I have always been told the problem of large number of
clusters in 98 was due to the fact that on boot the FAT
Table was read into memory and would use up all available
memory just to hold the FAT Table.

That argument was offered back last February when I first tried
running win-98 on fat-32 volumes with large cluster counts.

I countered by pointing out that by Microsoft's own reasoning, a
volume was never allowed to have more than 4.177 million clusters
because that was the largest number of clusters that DOS scandisk
could process given a supposed 16 mb array size limitation. They
mentioned nothing about windows needing to load the entire FAT table
during normal use. And besides, given Win98's specified minimum
requirements (16 mb ram), you'd have a situation where a good chunk of
that would have been consumed by the FAT.

I've since discovered that DOS scandisk has no such 16 mb memory
limitation. Or perhaps it does, but it doesn't effect it's ability to
process a FAT with more than 4 million clusters. I think that the
only time the entire FAT table is read into system memory is during
disk maintainence like Windows scandisk and defrag.

If it's true that you need 4 bytes per cluster to read in the FAT
table, then maybe if I put more memory into the system the windows-ME
versions of scandisk and defrag would work. I think I'll try that.

If this were true it seems that with your 500G test all
available memory would be used and there would be nothing
left for programs.

Yes, that would have to be the case given 121 million clusters in my
situation (with 512 mb installed memory).

It also seems that your boot times would be in minutes not
seconds just to read the FAT Table.

The system boots fast, certainly within 1 minute. I haven't timed it
yet.

--------------------

Franc Zabkar wrote:
Is this it?

Negative Hard Disk Free Size Reported on Virtual Memory Tab in
System Properties: http://support.microsoft.com/kb/272620

As reported he

http://support.microsoft.com/kb/272620

I obtained the updated file from the win-98 service-pack thing
(unpacked it manually) and replaced my existing sysdm.cpl. While it
did correct the display of a negative free size on the hard drive, it
did not solve the virtual memory issue.

I then connected another SATA drive to the system (160 gb, with a
single 25 gb FAT-32 partition, formatted with 4 kb clusters, a little
over 6 million clusters) and Win-98 DID enable virtual memory when
instructed to put the swap file on the new drive.

So for some reason win-98 did not want to locate the swap file on the
500 gb drive. Either it did not like the fact that the drive was
formatted with 4kb cluster size (resulting in 121 million clusters) or
it didn't like where on the drive it would have to put it (at the back
10% of the drive).

Also -

I increased the amount of installed memory to 1 gb, and still got
"insufficient memory" when running Windows Scandisk and Defrag on the
500 gb drive.

DOS scandisk does not give an error, but it would have taken 4 days to
run (given it was at the 30% point after 30 hours).

--------------
July 28, 2007

Ron Martell wrote:

The FAT32 implementation provides for 28 bits to be used for
cluster numbers, which means that it is possible to have up
to 268,435,445 total clusters on a drive.

Smaller limitations are the result of the tools (FDISK & Format
for example) normally used to create FAT32 drives.

There is little to no information regarding Win-98's compatibility or
operational stability with volumes with large cluster-counts, and just
what gets broken at what cluster-count.

The year-2000 update to fdisk does work for 250 gb drives (I haven't
tried it on a 500 gb drive). Format also works on 250 gb drives, but
because of it's use of 32kb cluster size there will be 7.6 million
clusters on a 250 gb drive.

I am not sure if the native win-98 versions of scandskw.exe,
dskmaint.dll and defrag.exe will operate on a volume that exceeds 4.17
million clusters but the win-me versions will, at least up to 31
million clusters. The windows ME versions did not function on a
volume with 121 million clusters, displaying an "insufficient memory"
message (even on a system with 1 gb memory).

The MS-DOS version of scandisk.exe does not seem to have a
cluster-count limitation and has been seen to run without issue even
on a 500 gb drive with 121 million clusters (although it was only
allowed to run for 30 hours before being terminated - it was projected
that it would have taken 3 more days to complete it's scan).

It has been speculated that the number of clusters is limited because
win-98 loads the entire FAT table into memory during normal
operational use, but given the recent test with a 121-million cluster
drive that theory appears to be wrong.

The only issue so far with win-98 installed on a 500 gb volume with
121 million clusters is that it will not create or place the swap file
on it, hence virtual memory will not be enabled. It will create /
place the swap file on a secondary drive, even if that drive is
another 500 gb drive (but formatted with 32kb cluster size resulting
in 15 million clusters).

98 Guy wrote:

The real problem for win-98 scandisk and defrag is win-98's IDE driver -
ESDI_506.PDR. It does not allow correct access beyond the 128 gb point
on the drive. Microsoft carefully words their explaination to point the
blame at scandisk and defrag being 16 bits instead of their own failing
for updating ESDI_506.PDR to the full 48 bits (like they had to do for
2K and XP).

With regard to win-98 scandisk and defrag, the answer is to simply use
the win-me versions of those apps

That's nice! So by the use of WinME disktools the 28 bit IDE driver problem
is solved?

Maybe you should read what you're writing before posting.

98 Guy wrote:

The real problem for win-98 scandisk and defrag is win-98's IDE driver -
ESDI_506.PDR. It does not allow correct access beyond the 128 gb point
on the drive. Microsoft carefully words their explaination to point the
blame at scandisk and defrag being 16 bits instead of their own failing
for updating ESDI_506.PDR to the full 48 bits (like they had to do for
2K and XP).

With regard to win-98 scandisk and defrag, the answer is to simply use
the win-me versions of those apps

That's nice! So by the use of WinME disktools the 28 bit IDE driver problem
is solved?

Maybe you should read what you're writing before posting.

"98 Guy" wrote in message ...
wrote:

If you connect a hard drive to a win-98 system, and that drive is larger
than 128 gb (or 137 Gb, depending on how you define "giga"), then you
will screw up the data on the hard drive if windows attempts to write to
the drive beyond the 127 gb point on the drive. . . .
This only applies to hard drives that are physically connected to the
IDE port on the motherboard. I don't believe this applies to USB
drives.

Using SATA hard drives is a different story . . .

USB behavior here confirms the USB comment above.
250 Gb USB drive (preformatted FAT32, used as a single
logical drive) now has 184 Gb in use, 66 Gb vacant.
Instead of MS I use tools of Fix-It Utilities (and run DiskScan
every week or so, DEFRAG seldom -- only if the DiskScan
visual display looks strange.)

--
Don Phillipson
Carlsbad Springs
(Ottawa, Canada)