Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Largest HD under 98SE

18 views
Skip to first unread message

vampire chicken

unread,
Mar 14, 2007, 1:36:34 AM3/14/07
to
What's the largest HD that Win98SE will recognize?
No overlay programs, etc.
Thanks.

Jeff Richards

unread,
Mar 14, 2007, 5:48:02 AM3/14/07
to
W98 doesn't recognise drives - it works with partitions. It will see
partitions on any size drive that the BIOS supports, but whether or not it
works properly with very large partitions is a different question. There
can be problems with any one partition larger than 137Gb, and any partition
that extends beyond the 137Gb point on the disk, depending on the hardware
and the drivers. Also, you will have problems with utilities such as FDISK,
defrag and scandisk on very large partitions (although there are third-party
replacements).

And, of course, if the partition is on another system that is being accessed
across a network, a whole different set of rules apply.

Like most questions about absolute limits in the OS, there's no single
answer.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"vampire chicken" <drin...@the.coop> wrote in message
news:Xns98F2F097...@66.250.146.158...

Rick Chauvin

unread,
Mar 14, 2007, 9:45:49 AM3/14/07
to

"vampire chicken" <drin...@the.coop> wrote in message
news:Xns98F2F097...@66.250.146.158
> What's the largest HD that Win98SE will recognize?
> No overlay programs, etc.
> Thanks.


If you take into account and make the changes with the three issues I list
below - then there are No limitation to the size of HD you can use with
W98. If you don't want to bother with doing any of that, then there is.

There are Three issues here for FAT32 W98 that needs to be dealt with for
large hard drive support which are you need 48-bit LBA Bios support, and
then 48-bit LBA Windows Driver support, and then the Partition Size limit
that Windows utilities limitation dictates.

First on the list is that your Bios needs to have 48-bit LBA support to
start with of course, secondly after that you need to have Windows drivers
with 48-bit LBA support so that they both can utilize HD's total size over
137/128 GB ..and you can do that in a few ways: one is by using the
unofficial updated esdi_506.pdr windows driver giving 48-bit LBA support
that MSFN offers free; or buy Mr Lowe's High Capacity Disk Patch program
which is similar; or another is if you have an older supported Intel
chipset to be able to install its IAA software then that will do it too; or
the best of all ways is to use a 48-bit LBA PCI Controller Card for its
numerous advantages and benefits over the other ways - but no matter which
of these ways you choose, the third issue is that you Still have W98's
windows stock utilities limitations that dictate that the Hard Drive must
be partitioned as such - which is that W98 must not see any one partition
throughout the hard drive that's over 137/128 GB.

I wrote 137/128 that way above because you need to be aware there is
Decimal GB and Binary GB's - and many people use the figure of under 137 GB
but realize that's meant in Decimal GB - but since Windows displays in
Binary then naturally it's much better said and certainly must be done as
under 128 Binary GB because of it, and that it's stock scandisk/defrag
utilities use its figures as well. ...iow, when you open your My Computer
folder to see what your partition sizes show - it must not show any one
partition over 128GB or problems and data corruption, etc, will occur when
scandisk auto/manually runs, or when defrag is used.

I also always suggest that the Primary OS FAT32 partitions to be made under
8 GB not only for the best 4k cluster size efficiency but it's so much
easier and faster to defrag, and make backup partition images, and other
common tasks too; you don't need anymore than 8 GB anyway for the OS FAT32
primary partition, and you would store all unnecessary non-os files on the
larger Storage partitions.. iow, you take all Non-OS (Logical) partitions
and make all those larger according to your HD's size divvy up - but always
all must be under 128 GB. I like to make them an even 121GB.

The Promise (P) ATA ULTRA133 TX2 is one of the best CC on the market for
this issue imo & experience, and I've used them for years with exceptional
results. .Here's some great reading in its manual for this particular CC.
(pdf format) right click and save target on this link:
http://www.promise.com/marketing/datasheet/file/Ultra133tx2DS_v3.pdf

You can buy the card at many outlets, but here's just one random place to
get it is at NewEgg supply:
http://www.newegg.com/Product/Product.asp?Item=16-102-007&depa=0

Rick

98 Guy

unread,
Mar 14, 2007, 10:05:49 AM3/14/07
to
> > What's the largest HD that Win98SE will recognize?

Rick Chauvin wrote:

> - you need 48-bit LBA Bios support
> - then 48-bit LBA Windows Driver support
> - then the Partition Size limit that Windows utilities
> limitation dictates.

48-bit LBA support in the bios will most likely not be an issue for
any motherboard made during/since 2002. Any Pentuim-4 motherboard,
for example, should have 48-bit LGA bios support.

Regarding actual win-98 support for 48-bit LBA:

> - unofficial updated esdi_506.pdr windows driver giving 48-bit


> LBA support that MSFN offers free

> - buy Mr Lowe's High Capacity Disk Patch program which is similar
> - another is if you have an older supported Intel chipset to


> be able to install its IAA software

> use a 48-bit LBA PCI Controller Card

Also note that many/most motherboards made during/since 2003 will have
SATA ports. Most likely, anyone considering a drive larger than 120
gb will be looking at SATA drives. If your motherboard does not have
SATA ports, then getting a PCI SATA controller card will be required.
They are cheap, but be careful about win-98 support. Many/most/all
SATA-I controller cards (advertized as 1.5 gbps) should come with
win-98 drivers. I'm not sure if SATA-II (advertized as 3.0 gbps)
controllers have win-98 drivers.

To use a large SATA drive on win-98, you'll have to configure your
system to use SATA drives in RAID mode, but (unless you want to) do
not configure a RAID type for them. If you have only 1 drive, then
you won't be able to configure a raid type anyways, but the key here
is that the RAID controller will be "controlling" the drive, and not
re-map it as a secondary IDE controller. On win-98 device manager,
the RAID controller will appear as a SCSI controller. If your SATA
drive is NOT being controlled by the RAID controller, then the SATA
controller will make the drive appear as an ordinary IDE drive, and
win-98 will use ESDI_506.PDR which is bad because (as mentioned above)
that driver is not a 48-bit LBA driver (unless you obtain the modified
version of it).

One final note about SATA. If you have a motherboard with an Intel
ICH5R northbridge chip, note that the win-98 compatibility of it's
SATA (raid) controller is faulty or just plain doesn't work properly.

> the third issue is that you Still have W98's windows stock
> utilities limitations that dictate that the Hard Drive must
> be partitioned as such - which is that W98 must not see any
> one partition throughout the hard drive that's over
> 137/128 GB.

DOS Scandisk.exe can handle drives (volumes) larger than 137 gb - up
to 160 gb that I've tested.

Windows-98se native scandisk (scandskw.exe) and defrag.exe can't
handle volumes with more than 4.17 million clusters, which equates to
137 gb at the max cluster size of 32kb. However, Win-ME versions of
dskmaint.dll (used by scandskw.exe) and defrag.exe have been tested on
volumes with up to 30 million clusters and work fine.

Therefore if you want to add a large hard drive (ie large volume) to
win-98, then it's a good idea to obtain dskmaint.dll and defrag.exe
from win-me. Those files are part of the unoffical windows-98 service
pack available on (or through) MSFN.org.

> when you open your My Computer folder to see what your
> partition sizes show - it must not show any one partition
> over 128GB or problems and data corruption, etc, will
> occur when scandisk auto/manually runs, or when defrag
> is used.

DOS scandisk (if invoked manually or because of a previous bad
shut-down) has no problems with drives / volumes larger than 137 gb
(up to 160 gb that I've tested, and soon I'll be testing a 500 gb
volume).

As mentioned above, windows scandisk and defrag work fine for drives /
volumes larger than 137 gb if the win-me versions are used.

> I also always suggest that the Primary OS FAT32 partitions to
> be made under 8 GB not only for the best 4k cluster size
> efficiency but it's so much easier and faster to defrag,

You can use the undocumented format command-line switch to format a
volume with a specific cluster size, say 4 kb, and that way you can
have very large volumes with small cluster size. I've formatted a 160
gb drive as a single partition with 4 kb cluster size and win-98 ran
fine on it.

> and make backup partition images

It is true that some/many drive cloning software (like Ghost) will not
preserve the cluster size and will revert to using a larger cluster
size on destination drives.

> you don't need anymore than 8 GB anyway for the OS FAT32
> primary partition, and you would store all unnecessary
> non-os files on the larger Storage partitions..

You can put forward logical reasons to divy up a large drive into
smaller volumes and say that the OS volume should not exceed some
number, but in the end it's up to the user. The ergonomics of that
subdivision are more illusory then real. You could make the same case
for XP, but all commercial systems I've ever seen running XP have the
drive set up as a single volume and not two.

> make all those larger according to your HD's size divvy up -
> but always all must be under 128 GB.

Again, most likely anyone considering adding a drive larger than 120
gb today to a win-98 system will be adding a SATA drive, and there is
no reason to limit a volume to 120 gb in that case any more than if
you were working with win-2k or XP.

Read my thread from about a month ago titled "Cluster size and
exploring the limits of FAT-32" posted in this NG.

Ian H

unread,
Mar 14, 2007, 11:35:13 AM3/14/07
to

> I also always suggest that the Primary OS FAT32 partitions to be made
under
> 8 GB not only for the best 4k cluster size efficiency but it's so much
> easier and faster to defrag, and make backup partition images, and other
> common tasks too; you don't need anymore than 8 GB anyway for the OS FAT32
> primary partition, and you would store all unnecessary non-os files on the
> larger Storage partitions.. iow, you take all Non-OS (Logical) partitions
> and make all those larger according to your HD's size divvy up - but
always
> all must be under 128 GB. I like to make them an even 121GB.

I hear you, & hopefully you can assist an oversight I made when divvy-ing
up my current h/d.
It was set up a few months ago, and although I have no problems, I am
looking to rectify some things I could have done better.


I have A, C, D, E, F, G, H drives.
A is obvious.
C: has win98se on it; the partition is 15gig, a total waste as I dont use
the drive for much at all. (fat32)(although, its the only O/S allowed
on the internet.... so it has all modem drivers and etc.)

D: has XP on it, dual boot with 98se as above. It is 20 gig, but again, I
dont use it much at all.(Fat 32 also) (only 98 is allowed on the internet)

E: is where 'everything' goes. It has folders galore, each with subs and
etc.
All 'utilities' and sundry are here. It is 30gig, and is the best
practical
decision I made at the time. (it still has 20+ gig to play with, and it
will
get used.)

F: is in limbo at the moment. (it is 12 - 13 gig...... havent decided yet
what I want to do with this.)

G: rom
H: etc
I: etc usb etc.

Question, ::
I want to reduce the size of my C:, back to say 6 or 8 gig..... but, I
dont
want to mess with Fdisk as the primary set-up mode.
I have partition magic8, and although in 'some' chapters of help file, it
says
its okay to chop a 'bit off here an' a bit off there', in another chapter it
says that it doesnt advise chopping 'bits off' where the "C:drive" is
involved.;;;;
Then yet in another chapter it says to 'go right ahead' and do it.
(naturally I'm wary, as the Cdrive is the heart, and its beating just fine
at the moment.)
But dont get me wrong, I'm not scared of using P/M and chopping off
say... 10gig from the C: and either placing it on another partition or
even creating one or more new ones.... Its just that I dont like the
way
their help file said its okay to do it in one breath, but a few pages later
state
that they do not support 'nibbling' of the C:. (but nibble away on others.)
(specially considering we are talking about a comp that works fine now.)

Bottom line is; I would rather have done it all at Fdisk stage, and I
truely
believed I had it all panned out in the drawing board of my mind, I now
look back in regret of the time wasted Defragging a 15gig Cdrive that only
has about 3&1/2 gig on it......... and its running just fine.(but oh
such
a waste.)
My fear is that once I use a 3rd party app like partmagic, then any and all
fdisk stuff is now obselete and irrelevant...... or am I just reading
things
wrong. (in other words, if I 'steal' one tiny little 'bit' from the C:drive
and place
it elsewhere, will my whole comp/partitions now be owned by P/M in that
any thing else I want to do will have to be routed through P/M's program
before I make any move?..... if of couse I use P/M to 'steal' one 'bit'.)

Lastly, has anyone been in a similar situation? whereby you read a certain
part of P/M's help file and it says one thing, then in another breath, it
says
another...... any feedback naturally appreciated.

Ta for your post Rick, was good reading.

Ian H


Haggis

unread,
Mar 14, 2007, 11:44:39 AM3/14/07
to


"Ian H" <I...@rugger.net> wrote in message
news:ugalZ3kZ...@TK2MSFTNGP04.phx.gbl...

I don't see a problem ..they are probably concerned the the boot records are
on C: ..so there is a 'chance' of something going wrong.

I used PM and Bootitng to do just what you are looking at ..

"shrink" your C: to a size you like ...then "expand" your D: drive to take
up the unused space

eg. 80G drive started with 40/40 split then went 20/20/40 ..then 8/52/20
which is now win98/XP/Vista

note: some people may comment on putting Vista or XP on a separate drive
...and for the record I agree (except when it applies to me :>)


Ian H

unread,
Mar 14, 2007, 12:04:01 PM3/14/07
to

any feedback naturally appreciated.
> >
> > Ta for your post Rick, was good reading.
> >
> > Ian H
> >
> --------------


> I don't see a problem ..they are probably concerned the the boot records
are
> on C: ..so there is a 'chance' of something going wrong.

Nail-on-the-Head in one Haggis.
I dont like/prefer taking a 'chance' when a 'chance' can be averted
and turned into a 'sure-thng'.


>
> I used PM and Bootitng to do just what you are looking at ..
>
> "shrink" your C: to a size you like ...then "expand" your D: drive to take
> up the unused space


Have no prob at all doing the math once the theft has been complete,
but its the 'theft' i am concerned about.
(or more to the point, the 'help file' within P/M. if I mess my current
set-up, then p/m and its lawyers will say that "i shouldnt have done what
i did". like i said, in one breath they say god ahead and do it, and in
another.......... etc etc etc.)


>
> eg. 80G drive started with 40/40 split then went 20/20/40 ..then 8/52/20
> which is now win98/XP/Vista
>
> note: some people may comment on putting Vista or XP on a separate drive
> ...and for the record I agree (except when it applies to me :>)


I have no plans whatsoever of telling our 'big-brother' what color toilet
paper i use...... so vista & xp can spray their radiation
elsewhere.
(xp stays right where it is, along with its jealousy of not being allowed
access to the net.... sorry BB.)
It's merely a decoration on my pc..... or a learning curve if you like,
on
what not to pick if you want your goolies exposed.

Ian H


Ian H

unread,
Mar 14, 2007, 12:15:32 PM3/14/07
to
Ta for reply Haggis, and maybe I am being a wee over cautious;;
but I have to look back a few months when I divvy-ed up the drive
in the first place; I thought I had it under control then and had
convinced myself so.
But defragging a 15gig drive with only a 5th of the content worth it,
makes me think I am yet again on a learning process.... and I know
that the C: isnt going to grow much at all in years to come.

Thanks Haggis, I guess I'm just looking for that "100%" confidence
reply....... as opposed to "there is a chance something may go wrong".

Ron Badour

unread,
Mar 14, 2007, 3:14:18 PM3/14/07
to
137 gb

--
Regards


Ron Badour, MS MVP for W98
Tips: http://home.satx.rr.com/badour
Knowledge Base Info:
http://support.microsoft.com/default.aspx?pr=kbinfo

"vampire chicken" <drin...@the.coop> wrote in message

news:Xns98F2F097...@66.250.146.158...

vampire chicken

unread,
Mar 14, 2007, 4:33:00 PM3/14/07
to
Thank you all for the very informative answers.
I would never create a partition larger than 20 GB, so it sounds
like I should be OK.
Thanks again.

Haggis

unread,
Mar 14, 2007, 5:35:26 PM3/14/07
to
when working with computers , there is ALWAYS a 'chance' of something going
wrong.

your chances of that are quite low ..but make sure you back things up <g>

ps. try a spare HD to play with if you need to feel better about doing it


"Ian H" <I...@rugger.net> wrote in message

news:OP8%236NlZH...@TK2MSFTNGP04.phx.gbl...

Gary S. Terhune

unread,
Mar 14, 2007, 5:40:33 PM3/14/07
to
I *think* the 137 GB limit is for any partition *starting* beyond that
boundary on the physical drive.

--
Gary S. Terhune
MS-MVP Shell/User
www.grystmill.com

"vampire chicken" <drin...@the.coop> wrote in message

news:Xns98F39477...@66.250.146.158...

Noncompliant

unread,
Mar 15, 2007, 4:54:40 AM3/15/07
to
Recognize? Not sure. Have a 200GB WD. One partition/FAT32. 186GB
formatted. Partition created with 3rd party application. ME and 98SE see
it fine. Used exclusively for DI 7.0 (in XP environment) image file
storage. Keep forgetting to hide the partition with my 3rd party boot
manager for ME/98SE.

Know 98SE will wreck the file allocation table once the file storage exceeds
128GB if seen by it. Defrag and scandisk have nothing to do with this.

--
Noncompliant

Money don't wag the dog's tail.

"vampire chicken" <drin...@the.coop> wrote in message

news:Xns98F2F097...@66.250.146.158...

98 Guy

unread,
Mar 15, 2007, 10:06:34 AM3/15/07
to
Noncompliant wrote:

> Know 98SE will wreck the file allocation table once the file
> storage exceeds 128GB if seen by it.

That assumes your drive is being filled from the bottom-up (cluster or
sector speaking).

You may already have data located past the 128 gb sector location and
not know it.

BTW, if you can tolerate a win-98 hard drive performance hit, you can
re-name ESDI_506.PDR to something else (like ESDI_506.PD_) and win-98
will not find it when it starts, in which case it will switch to
"MS-DOS compatibility mode" when accessing all hard drives. That mode
will (presumably) be slower but you won't experience the 128 (137) gb
problem.

Noncompliant

unread,
Mar 16, 2007, 6:10:46 AM3/16/07
to
"98 Guy" <9...@Guy.com> wrote in message news:45F952EA...@Guy.com...

> Noncompliant wrote:
>
>> Know 98SE will wreck the file allocation table once the file
>> storage exceeds 128GB if seen by it.
>
> That assumes your drive is being filled from the bottom-up (cluster or
> sector speaking).
>
> You may already have data located past the 128 gb sector location and
> not know it.
>

Hmm, same person who says one FAT32 partition on 160GB hard drive okay in
98SE without reservations.

> BTW, if you can tolerate a win-98 hard drive performance hit, you can
> re-name ESDI_506.PDR to something else (like ESDI_506.PD_) and win-98
> will not find it when it starts, in which case it will switch to
> "MS-DOS compatibility mode" when accessing all hard drives. That mode
> will (presumably) be slower but you won't experience the 128 (137) gb
> problem.

Why would I do that considering the purpose of the partition? Oops, sorry,
you deleted that purpose in your reply.

98 Guy

unread,
Mar 16, 2007, 10:00:53 AM3/16/07
to
Noncompliant wrote:

> > You may already have data located past the 128 gb sector
> > location and not know it.
> >
>
> Hmm, same person who says one FAT32 partition on 160GB hard
> drive okay in 98SE without reservations.

I've posted a million times that Win-98's original protected-mode IDE
driver (ESDI_506.PDR) only performs 32-BIT LBA addressing, not the
required 48-bit LBA addressing.

I've always said that you can't use an IDE (PATA) hard drive larger
than 137 gb on Win-98 without using the modified version of
ESDI_506.PDR.

I HAVE said that SATA drives larger than 137 gb are OK for win-98
assuming they are controlled by a RAID controller and not mapped as an
IDE drive.

> > you can re-name ESDI_506.PDR to something else (like ESDI_506.PD_)
> > and win-98 will not find it when it starts, in which case it will
> > switch to "MS-DOS compatibility mode" when accessing all hard
> > drives.

> Why would I do that considering the purpose of the partition?

I'm only posting an option. It's up to you to consider if it's
appropriate, or necessary, for your (or anyone else's) situation.

John John

unread,
Mar 16, 2007, 10:25:29 AM3/16/07
to
The bottom line is that without third party drivers Windows 98 cannot do
48-bit Logical Block Addressing. It doesn't matter that the drives are
SATA or PATA, as shipped Windows 98 cannot do it. Data loss will occur
if the 137GB boundary is crossed.

John

98 Guy

unread,
Mar 16, 2007, 11:18:44 AM3/16/07
to
John John wrote:

> The bottom line is that without third party drivers Windows 98
> cannot do 48-bit Logical Block Addressing.

It can if you disable (rename) ESDI_506.PDR.

> It doesn't matter that the drives are SATA or PATA,

Yes, it _can_ matter, as SATA gives you more opportunity, more
compatibility.

> as shipped Windows 98 cannot do it.

As shipped, Windows XP could not handle drives larger than 137 gb
until SP1, and Win-2K could not handle large drives until SP3.

> Data loss will occur if the 137GB boundary is crossed.

That is the theory, and it sounds logical, but I have not tested it
nor have I read a report of anyone who has encountered it.

John John

unread,
Mar 16, 2007, 12:15:04 PM3/16/07
to
Many have tested this and all have come to the same conclusion: data
loss occurs if the 137GB boundary is crossed. What Windows 2000 or XP
does or doesn't do is completely irrelevant to the discussion at hand so
I'm not sure why you have brought it into the discussion. Use drives
larger than 137 GB without third party solutions with Windows 98 and you
are asking for trouble. If the problem were to simply be resolved by
renaming the ESDI_506.PDR file then this would long ago have been made
known and made public by all the hard drive manufacturers, by all those
who have thoroughly studied the problem and by Microsoft itself. If
that was the solution to the problem then there would be hundreds of
thousands of web sites and newsgroup postings advising users of the fix,
the same as the hundreds of thousands of fixes that are now posted when
people ask about the problem with the later Windows versions that you
mentioned.

People can do as they please and they can take any advice they wish on
the matter, personally I wouldn't do it. That is nothing personal
against you, I respect your opinion and find your postings interesting
and informative. But on this issue I disagree with you. In depth
information on the 48-bit lba issues with Windows 98 is widely available
on most of the hard drive manufacturer's web sites as well as on the
http://www.48bitlba.com/ site.

John

98 Guy

unread,
Mar 16, 2007, 8:17:07 PM3/16/07
to
John John wrote:

> What Windows 2000 or XP does or doesn't do is completely
> irrelevant to the discussion at hand so I'm not sure why
> you have brought it into the discussion.

You kept mentioning what win-98 can and can't do "out of the box" with
respect to 48-bit LBA. I'm just pointing out that there is no need to
restrict win-98's large-drive support capability by not considering
third-party work-arounds and non-IDE drive alternatives, and that
Win-XP and Win-2K were once also similarly restricted.

> Use drives larger than 137 GB without third party solutions with
> Windows 98 and you are asking for trouble.

In many, most, or all cases, there is really no "third-party" solution
required when win-98 is installed on a large SATA hard drive.

In fact, it's easier to install win-98 on a SATA drive than it is for
2K or XP. You usually have to have SATA drivers ready on floppy or
other media during 2K/XP installation.

> If the problem were to simply be resolved by renaming the
> ESDI_506.PDR file then this would long ago have been made
> known and made public by all the hard drive manufacturers

Not necessarily. Win-98 was in decline when hard drives were
transitioning beyond the 120 gb size, and many installations of win-98
at the time were done on machines that were limited in their bios to
32-bit LBA. Presumably many would not see disabling the
protected-mode ESDI driver as an ergonomic solution anyways. For all
those reasons, it's not surprising that disabling ESDI_506.PDR was
never "put out there" as a solution.

But it is nonetheless true.

Win-98 will resort to "MS DOS compatibility mode" which I believe used
direct calls to INT13 similar to how DOS performs hard drive access.

Dos (version 4.10.2222, sometimes called DOS 7.x) is fully capable of
accessing, reading and writing to drives larger than 137 gb if the
motherboard bios is 48-bit LBA capable.

> who have thoroughly studied the problem and by Microsoft itself.

You expect Microsoft to come out and address the issue of win-98 and
48-bit LBA drive access?

It was well within MS's capability to perform the trivial modificaiton
of ESDI_506.PDR and give it 48-bit LBA compatibility back in 2002 when
the issue also needed to be addressed for XP. It was a time when 98
was (supposedly) still supported by MS. In theory even ME needed that
fix as well to ESDI_506.PDR.

> If that was the solution to the problem then there would be
> hundreds of thousands of web sites and newsgroup postings
> advising users of the fix,

Well I'm telling you it's that simple. Rename or remove ESDI_506.PDR
and Win-98 will resort to real-mode compatability hard-drive access
and it will be able to span the 137 gb barrier with no problems. The
tradeoff is a hit to drive performance.

> the same as the hundreds of thousands of fixes that are now posted
> when people ask about the problem with the later Windows versions
> that you mentioned.

Since MS did not provide an updated protected mode driver for win-98,
why would you expect they would make an official announcement to
simply remove and not use the existing driver for those wishing to
give win-98 large drive compatibility? MS would not see that as a
solution. Their solution is to stop using 98 and migrate to XP.



> But on this issue I disagree with you. In depth information
> on the 48-bit lba issues with Windows 98 is widely available

Beyond saying that the problem for win-98 is it's protected mode
driver, they say nothing else, such as what happens when 98 is using
compatibility mode (real mode) drive access.

Ingeborg

unread,
Mar 17, 2007, 8:33:10 AM3/17/07
to
98 Guy wrote:

> 32-bit LBA

Here you are wrong. You mean 28 bit LBA.

Noncompliant

unread,
Mar 17, 2007, 9:32:00 AM3/17/07
to
"98 Guy" <9...@Guy.com> wrote in message news:45FAA315...@Guy.com...

> Noncompliant wrote:
>
>> > You may already have data located past the 128 gb sector
>> > location and not know it.
>> >
>>
>> Hmm, same person who says one FAT32 partition on 160GB hard
>> drive okay in 98SE without reservations.
>
> I've posted a million times that Win-98's original protected-mode IDE
> driver (ESDI_506.PDR) only performs 32-BIT LBA addressing, not the
> required 48-bit LBA addressing.
>
> I've always said that you can't use an IDE (PATA) hard drive larger
> than 137 gb on Win-98 without using the modified version of
> ESDI_506.PDR.
>
> I HAVE said that SATA drives larger than 137 gb are OK for win-98
> assuming they are controlled by a RAID controller and not mapped as an
> IDE drive.
>

98/98SE don't care if its SATA or IDE when reading or writing in regards to
the 132GB boundary limitation. It will botch the files and data at some
point.

>> > you can re-name ESDI_506.PDR to something else (like ESDI_506.PD_)
>> > and win-98 will not find it when it starts, in which case it will
>> > switch to "MS-DOS compatibility mode" when accessing all hard
>> > drives.
>
>> Why would I do that considering the purpose of the partition?
>
> I'm only posting an option. It's up to you to consider if it's
> appropriate, or necessary, for your (or anyone else's) situation.

There is never an appropriate situation for what you're stating. You can
take a 200GB hard drive, divide it up to many partitions. When the total
data saved cumulatively exceeds 128GB on the physical hard drive, the file
system will be trashed on the last partition accessed. I've done my own
tests and confident in my conclusions. I'm not going to be quiet about it,
like some other notable and regular contributors are here.

Rick Chauvin

unread,
Mar 17, 2007, 11:49:56 AM3/17/07
to
"98 Guy" wrote in message news:45F8013D...@Guy.com

[....]

Everything I said in my post is accurate...

~~~~~~~~~~~~~

Get over yourself guy...

It's interesting how it appears you critiqued every single sentence I wrote,
but I'm not going to even read what you wrote on your butt-in to a post of mine
and don't ever expect an answer . . . been there done that with you in months
past and it's like talking to a someone who knows a little but professes to
know all - but really only wants to draw people in so they can listen to
themselves pontificate about things whether right or wrong doesn't matter, they
just want/need attention to debate/argue about something for their own ego or
whatever. I've seen many techs here and there give you some gems of advice that
were well founded and totally true, and you just verbally trash back in their
face telling them to listen instead to whatever your non-authoritative story
is... ...give us a break and get over yourself already.

Rick


98 Guy

unread,
Mar 17, 2007, 11:54:57 AM3/17/07
to
Noncompliant wrote:

> > I HAVE said that SATA drives larger than 137 gb are OK for
> > win-98 assuming they are controlled by a RAID controller
> > and not mapped as an IDE drive.
> >
>
> 98/98SE don't care if its SATA or IDE when reading or writing
> in regards to the 132GB boundary limitation. It will botch
> the files and data at some point.

You are wrong wrong wrong.

Read my posts in this news group from around a month ago:

Cluster size and exploring the limits of FAT-32

Update 1: Cluster size and exploring the limits of FAT-32
Update 2: Cluster size and exploring the limits of FAT-32
Update 3: Cluster size and exploring the limits of FAT-32
Update 4: Cluster size and exploring the limits of FAT-32

"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."

> > I'm only posting an option. It's up to you to consider if
> > it's appropriate, or necessary, for your (or anyone else's)
> > situation.
>
> There is never an appropriate situation for what you're stating.
> You can take a 200GB hard drive, divide it up to many partitions.
> When the total data saved cumulatively exceeds 128GB on the
> physical hard drive, the file system will be trashed on the
> last partition accessed.

> I've done my own tests and confident in my conclusions.

Did you perform those tests on a SATA, or a PATA hard drive? (don't
say it doesn't matter - just answer the question).

If it was a PATA (IDE) drive, did you run win-98 without the
ESDI_506.PDR driver? If that driver was running, then of course
you're going to see corruption.

> I'm not going to be quiet about it,

Well then at least perform the right tests.

If you are saying that you have tested win-98 on a large IDE/PATA hard
drive *without* ESDI_506.PDR running, and if during that test the file
system was corrupted because of a read/write across the 137 gb
boundary, then I'll admit that you are right and I am wrong. (we're
also assuming that the motherboard or system you're using has 48-bit
LBA capability in the bios - you must have that or all bets are off).

In the mean time, I AM telling you that I was able to fill a 160 gb
SATA hard drive and NO such corruption occurred.

98 Guy

unread,
Mar 17, 2007, 12:11:30 PM3/17/07
to
Rick Chauvin wrote:

> Get over yourself guy...

You really need help Rick.

> It's interesting how it appears you critiqued every single
> sentence I wrote,

I *added* more information to your post. If the goal here is to
provide the OP (and others) with complete information, then tell me
specifically what I posted that you have a problem with, or that was
not correct.

If you don't like it when others add more information to one of your
answers, then don't post to usenet, because that is what usenet is all
about.

> it's like talking to a someone who knows a little but professes
> to know all

A very bitter statement there Rick, and totally unsupported in the
current context. If you have a problem with the content I added in
that post, then be a man and let's talk about it here. Don't be a
child and make a hit-and-run statement and then fade into the
background. Otherwise others reading this will see that you're just
taking cheap shots without backing them up.

> but really only wants to draw people in so they can listen to
> themselves pontificate about things

Sorry to steal your thunder Rick. Sorry you feel that I'm taking your
glory away by posting follow-ups.

Seems that you're the one with the ego here, and you have to raise
this junk here to protect it.

> I've seen many techs here and there give you some gems of advice
> that were well founded and totally true, and you just verbally
> trash back in their face

Post an example.

real@hotmail.com MEB

unread,
Mar 18, 2007, 3:22:57 AM3/18/07
to


"98 Guy" <9...@Guy.com> wrote in message news:45FC0F51...@Guy.com...

I think you've missed what you actually needed to test [and what everyone
has been attempting to direct you too]. It ISN'T the large size [though
manipulating those massive files in 98 would be an issue] or the 150 files.
The fat only had 150 files and the related addressing.

Try your test with a known file, say 70 kb, then multiple that by enough to
fill the drive by creating multiple differently named directories with
varying [or same] amounts of differently named files [File names can be
reused inside differing directories]. Use a bat or script file for the job.
If the size seems incorrect, pick one that will create a disk that exceeds
the supposed limits.
Rick C, Franc, or someone, can create one for you if you can't figure one
out.

Let's re-post this prior info, with a bit more:

File system limits are imposed by the file system driver.
Maximum allocation units per volume in Windows 95 and Windows 98 with fat32
= 4,177,918

The value of an entry in the file allocation table for each allocation unit
in FAT32 can range from 0x00000002 to 0x0FFFFFEF. {TAKE DUE NOTICE OF THIS,
just how many is that}

Allocation unit size for Windows 95 and Windows 98 = Any power of 2
between 512 bytes and 32768 bytes inclusive (File allocation table
size)/(Bytes per FAT entry) - (First two reserved allocation unit numbers in
the file allocation table) = (16 × 1024 - 64) × 1024/4 - 2 = 4,177,918
allocation units.

The maximum FAT volume size for Windows 95/98:
Maximum allocation units per volume × Maximum allocation unit
size=4,177,918×32 KB, which is 127.5 GB.

The maximum possible number of clusters on a volume using the FAT32 file
system is 268,435,445.
With a maximum of 32 KB per cluster with space for the file allocation
table (FAT), this equates to a maximum disk size of approximately 8
terabytes (TB).

HOWEVER,
It doesn't matter that you can CREATE more clusters, or the POTENTIAL disk
size; what matters is if the files saved and manipulated beyond the limits
and barriers are intact and uncorrupted [particularly with your non-standard
4 kb size].

You cannot decrease the cluster size on a volume using the FAT32 file system
so that the FAT ends up larger than 16 MB less 64 KB in size. {TAKE DUE
NOTICE OF THIS. This is a key element that must be kept in mind]

A FAT entry on a volume using the FAT32 file system uses 4 bytes [ANOTHER
KEY ELEMENT], so ScanDisk cannot process the FAT on a volume using the FAT32
file system that defines more than 4,177,920 clusters (including the two
reserved clusters). Including the Fats themselves, this works out, at the
maximum of 32 KB per cluster, to a volume size of 127.53 gigabytes (GB).

Remember, you have to shut down scandisk checking on a bad startup or you
WILL corrupt the disk.
So even IF you can get it to work, what do you plan to use to work on the
disk with? Best find one that doesn't follow the "standards" and the limits.
Remember all of this, particularly if your crossing the 1024 cylinder
boundary [which is not natively supported].

So if your intending to PROOF something: Make sure you have 98 installed
and running the test bat or script. Then do this:

After you get this done [if it somehow works] then run the system for a
week or more: opening; deleting several thousand; moving files; copying
files to new directories; and creating new directories, meanwhile, using
some type of tool to look into and ensure the file is the same [unaltered]
everywhere on the disk.

THEN AND ONLY THEN, report back to the group with your results, and MAYBE
this becomes a verified results.
Right now, to put it bluntly, your just blowing through your bung hole,
making noise and creating a bad smell. It takes verified results running the
system as any old JOE BLOW would to prove what your attempting here.
[Believe it or not, I'm trying to be helpful here.]
Because there really isn't a whole lot of VERIFIED results relating to SATA
> Win9X/ME > successful large hard drives usage.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG - http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
http://groups.google.com/group/the-peoples-law?hl=en - discussion group for
general aspects of Law verses the Peoples' of the world

"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________


John John

unread,
Mar 18, 2007, 8:37:32 AM3/18/07
to
MEB wrote:

He doesn't care that the disk tools can't work with a FAT of more than
16MB, but he hasn't suggested a replacement for the tools. He also
doesn't care about bad shutdowns and scandisk on reboot, he doesn't
think that it is necessary to verify that the File Allocation Table is
intact after bad shutdowns. He doesn't care about his files.

He also doesn't quite understand performance issues caused by disk
bottlenecks. He doesn't know that disk bottlenecks are pretty well the
single most detrimental factors affecting performance. He doesn't
understand that performance improvements obtained by adding more RAM is
mostly due to reductions in disk paging. He fails to understand that
_everything_ about computers is to do with files and disks and that the
FAT is *constantly* being accessed. He creates a disk with 40 million
clusters which results in a FAT size of over 152MB which will lead to an
increased, if not insane amount of disk paging, the worst performance
hit that a computer can take! As if that isn't bad enough he then puts
his drive in Compatibility Mode! Craziness!

John

98 Guy

unread,
Mar 18, 2007, 10:16:38 AM3/18/07
to
John John wrote:

> He doesn't care that the disk tools can't work with a FAT of
> more than 16MB, but he hasn't suggested a replacement for the
> tools.

I have posted that dos scandisk (scandisk.exe - the native scandisk
that comes with 98se) is indeed capable of handling a much larger FAT
table than would normally fit inside a 16mb memory space. I have not
found a limit for scandisk.exe so far, but it does work at least up to
a cluster count of 40 million - far beyond the often stated value of
4.177 million.

> He also doesn't care about bad shutdowns and scandisk on reboot,

In my tests, indeed the system HAS restarted after a bad shutdown and
scandisk WAS invoked at startup and it DID run smoothly and without
issue.

> he doesn't think that it is necessary to verify that the File
> Allocation Table is intact after bad shutdowns.

See my last statement. Also note that Windows ME version of
Win-Scandisk (scandskw.exe) and defrag.exe runs fine on drives with
large FAT tables.

> He doesn't care about his files.

Completely innacurate statement. That's why I'm doing these tests.

> He also doesn't quite understand performance issues caused
> by disk bottlenecks.

I have yet to perform disk or file performance measurements on large
volumes using "non-standard" cluster size of 4 kb (which is really a
STANDARD cluster size for a small volume) but I am satisfied that 1 gb
per minute for a file copy from/to the same drive that I've seen so
far is pretty good.

> He doesn't know that disk bottlenecks are pretty well the
> single most detrimental factors affecting performance.

I am not so much focused on performance as I am on seeing if I can run
a large volume using a more efficient cluster size - a size that by
default format.com does not use.

We all know that the default cluster size for NTFS is 4kb, and that a
constant (and small) cluster size is one of NTFS's claimed advantages
over FAT-32. Which is true, if you do not specifically test to see if
win-98 can run on a large volume formatted with a small (4kb) cluster
size, which I have found that it can.

> He doesn't understand that performance improvements obtained by
> adding more RAM is mostly due to reductions in disk paging.

Where have I ever touched on that issue?

> He fails to understand that _everything_ about computers is
> to do with files and disks and that the FAT is *constantly*
> being accessed. He creates a disk with 40 million clusters
> which results in a FAT size of over 152MB which will lead to an
> increased, if not insane amount of disk paging,

Please quote a source that indicates that the entire FAT is loaded by
the OS at any point of it's startup or operation, other than
specifically for disk maintainence or defragmentation?

That issue has been discussed here, and I've posited that the entire
FAT is not loaded as part of the OS's normal operation, nor would
there be a reason to load the entire FAT.

> Craziness!

Your conclusion is based on the presumption that the entire FAT is
loaded by win-98 during normal operation. I disagree with that
assumption, and my supporting argument is this: The minimum hardware
specification for win-98 was a system with 16 mb of memory. The
maximum possible size of the FAT, as claimed by Microsoft, was 16 mb
(which is where the 4.177 million cluster-count is derived from). If
what you're saying is true (that the entire FAT is loaded into memory
during routine operation) then a good chunk of available system memory
on early win-98 systems, and potentially ALL system memory, would be
used just to store the FAT. That would indeed be crazy - too crazy to
be true.

Microsoft's own explanation for the 4.177 million cluster-count limit
is not that it would be too inefficient for the OS. Their explanation
is that the DOS scandisk.exe utility is limited to a 16-million memory
allocation, and given 16mb of memory, that reduces to 4.177 million
clusters that it can work with. However, as stated near the top of my
post, I've not seen such a limitation for scandisk.exe. I also have
not seen any such large amount of available memory being allocated for
the system or specifically for the FAT, which I should be seeing if
indeed a fat with 40-million clusters was being loaded into system
memory.

98 Guy

unread,
Mar 18, 2007, 11:42:22 AM3/18/07
to
MEB wrote:

> I think you've missed what you actually needed to test [and what
> everyone has been attempting to direct you too]. It ISN'T the
> large size [though manipulating those massive files in 98 would
> be an issue] or the 150 files.
>
> The fat only had 150 files and the related addressing.

?

The drive in question had thousands of files on it (win-98 plus many
other directories containing the installation files of other apps,
drivers, etc, about 1 or 2 gig's worth). That, in addition to the VOB
files (10 vob files per directory, 4 such directories stored within
their own subdirectory, then that tree of 40 files copied several
times).

I don't know why you think the file size or the file structure is
important. If there is a sector-wrapping issue at the 137 gb point on
the drive, it should be encountered no matter what type of file data
is being written to it. As long as the drive is filled with data up
to and past that point, if there is a sector-wrapping issue then it
will happen and it should wrap back to sector 0 and trash it's own
FAT, maybe the MBR at that point.

> Let's re-post this prior info, with a bit more:
>
> File system limits are imposed by the file system driver.

Which I presume you are referring to ESDI_506.PDR, which given a drive
formatted with 32kb cluster size and 4.177 million clusters results in
a volume size of 137 gb which is identical to the 28-bit sector
addressing limitation of ESDI_506.PDR (2^28 x 512 bytes/sector = 137
gb).

> Maximum allocation units per volume in Windows 95 and Windows
> 98 with fat32 = 4,177,918

Technically, it's the 28-bit limitation of ESDI_506.PDR that leads to
the 137 gb volume limit for win-98, not the (supposed) 4,177,918
cluster count limitation. I've already shown that win-98 can natively
handle volumes formatted with up to 40 million clusters with no issues
(I don't consider scandskw or defrag to be part of windows native
file-handling and drive-handling mechanisms, but even in that case, as
I've mentioned before, substitution of Win-ME's versions of those
programs will remedy even that situation).

I've already pointed out Microsoft's rational or explanation (or
source) of the 4,177,918 cluster-count limit - which comes from
scandisk.exe, which in fact scandisk.exe does not actually have this
limitation anyways.

> The value of an entry in the file allocation table for each
> allocation unit in FAT32 can range from 0x00000002 to
> 0x0FFFFFEF. {TAKE DUE NOTICE OF THIS, just how many is that}

http://www.msfn.org/board/index.php?showtopic=46752

"The maximum FAT32 partition size is 2 TB, it is (2^32-1) * 512 =
2,199,023,255,552 bytes. Windows seems to use 32-bit addressing
of sectors. If the upper 4 bits are zero, 28-bit LBA will be used
and no problem arise. But for size above 137GB, 48-bit LBA
addressing has to be used and it means the above described two
writes to each address register, in this case it means to write
the upper 8 bits to the LBA Low register and zeroes to LBA Mid
and LBA High in first step, and in the second step to write
remaining 24 bits to LBA Low-Mid-High. Also Sector Count register
has to be written in 2-byte sequence if programmed.

And this is the modification that has to be done with ESDI_506.PDR
driver. "

It's not clear to me if a FAT entry stores a sector value, or a
cluster value.

This link says that it stores a cluster value:

http://en.wikipedia.org/wiki/File_Allocation_Table

But the MSFN text (above) seems to say that it stores a sector value.

A volume formatted with 4kb cluster size, given 2^28 clusters, would
equate to 1100 gb (1.1 terra bytes) and would not exceed the 28-bit
storage limit (if the FAT entries store cluster values).

If the FAT stores sector values, then 2^28 x 512 = 137 gb, in which
case it should not be possible to create a FAT-32 volume larger than
137 gb without exceeding the 28-bit storage limit of an individual FAT
entry.

So it would appear to me that a FAT entry stores a cluster number, not
a sector number (although the two would be the same if a cluster size
was 512 bytes).

> Allocation unit size for Windows 95 and Windows 98 = Any power of
> 2 between 512 bytes and 32768 bytes inclusive (File allocation table
> size)/(Bytes per FAT entry) - (First two reserved allocation unit
> numbers in the file allocation table) = (16 × 1024 - 64) × 1024/4
> - 2 = 4,177,918 allocation units.

That equation of yours needs more explanation of each parameter. I
can come up with many different ways to mathematically arrive at
4,177,918. You need to explain where those numbers comes from.

Microsoft itself has stated that 4,177,918 is derived *backwards*
starting from 16mb of memory space available to dos scandisk. I've
quoted the URL in previous posts.

> The maximum FAT volume size for Windows 95/98: Maximum
> allocation units per volume × Maximum allocation unit
> size=4,177,918×32 KB, which is 127.5 GB.

If you restrict a volume to 4.177 million clusters, and use 32 kb per
cluster, then yes you will arrive at 127.5 gb.

However, the 4.177 million cluster-count size is what we're talking
about here, and win-98 can handle a much higher cluster-count than
that.

Ultimately, it's ESDI_506.PDR, and how it translates cluster-number to
sector-number, that is the problem here, and it is limited to 137 gb
(or 127.5 gb) because it does not perform 48-bit LBA addressing.

I can format a 137 gb volume with 4 kb cluster size and end up with 33
million clusters. In theory, that should be no problem for
ESDI_506.PDR because that volume can be addressed with 28-bit
(technically 32-bit) addressing.

> The maximum possible number of clusters on a volume using the
> FAT32 file system is 268,435,445.

Which is 2^28 - 11

> With a maximum of 32 KB per cluster with space for the file
> allocation table (FAT), this equates to a maximum disk size
> of approximately 8 terabytes (TB).
>
> HOWEVER,
> It doesn't matter that you can CREATE more clusters

No, the problem with Win-98 is ESDI_506.PDR, and that it doesn't
perform 48-bit sector addressing, which it must do when accessing a
volume (or drive?) past the 137 gb point, regardless of the
cluster-size used.

> You cannot decrease the cluster size on a volume using the
> FAT32 file system so that the FAT ends up larger than 16 MB
> less 64 KB in size. {TAKE DUE NOTICE OF THIS. This is a key
> element that must be kept in mind]

Again, I am repeating myself.

Microsoft has stated that the reason of this 16 mb limit for the size
of the FAT is to be able to load it inside the largest memory array
that dos scandisk can create. I've also stated that the minumum
hardware specification for win-98 is a system with 16 mb of memory.
There is no other reason that I've ever seen that says that the FAT
must not exceed 16 mb. Claims that the FAT is loaded by windows
during normal operation is also not logical the way I see it, it's not
necessary either, and it would be a huge drain on early installations
of win-98 to have most of their available memory consumed by storing
the FAT.

> ScanDisk cannot process the FAT on a volume using the FAT32 file
> system that defines more than 4,177,920 clusters (including the
> two reserved clusters).

As I have posted now several times, I *have* run (dos) scandisk.exe on
volumes of various sizes (6 million clusters through 40 million
clusters) and it worked fine.

The key is that himem.sys must be loaded.

> Remember, you have to shut down scandisk checking on a bad
> startup or you WILL corrupt the disk.

I have run scandisk on a drive (volume) with 40 million clusters, 160
gb in total size, and it worked fine.

Rick Chauvin

unread,
Mar 18, 2007, 2:16:48 PM3/18/07
to

"98 Guy" <9...@Guy.com> wrote in message news:45FC1332...@Guy.com
[...]

> I *added* more information to your post. If the goal here is to
> provide the OP (and others) with complete information, then tell me
> specifically what I posted that you have a problem with, or that was
> not correct.

I only skimmed a little and that was enough. I don't agree with lots of the
concepts you expressed off of my post and I feel rather than what you say as
*added* that instead mingled misguided inexperienced information to it - but if
you think I'm going to discuss any details with you - I'm not, and not going
to get drawn into the same ol same ol from you that everyone else does
everywhere you go - I just don't have the patience this year to deal with your
type of attitude. Experience shows us you won't listen anyway and you just
follow your own heady..

> A very bitter statement there Rick, and totally unsupported in the
> current context. If you have a problem with the content I added in

I'm not a bitter person by any means, quite the opposite actually. I did not
mean for it to come off that way either - I was just telling it like it is.

I just get tired of your tactics here. In your eyes everyone seems to be wrong
and you're the only one right, and you seem to enjoy drawing people in to ask
information for the sole purpose to challenge everyone everywhere in your own
way, when the ultimate truth of many of your explanations are not entirely
accurate but you arrogantly defend they are.

>> I've seen many techs here and there give you some gems of advice
>> that were well founded and totally true, and you just verbally
>> trash back in their face

> Post an example.

Every forum and post you make guy it's evident, the sad part is
you just don't see or get it, but hey... I have my own faults to work on and
it's not right for me to judge others. I will not read any past, current,
or future of your posts, and certainly will not reply anymore. I just don't
want to hear it guy.

I said I wouldn't reply and meant it, but, I only needed to make this last
reply in my way to apologize to the heavens that if I may have not acted in an
all giving loving manner no matter who it is or what they say - but I just
figured sometimes you need to call it as you see it.

This week my mom is on her death bed though and perhaps if I spilled a little
sorrow in the guise of aggravation words in response to your stifling attitude
that offers little or no expressed appreciation or consideration to anyone, but
hey if I handled my choice of words wrong in the moment then I'm sorry to the
universe for not being perfect all the time.

peace though,

Rick


real@hotmail.com MEB

unread,
Mar 18, 2007, 2:17:04 PM3/18/07
to
Okay, I'm about to blow you off as well.

I'm not going to debate the issues with you here, do the test as described,
creating the potential million+ files and directories if you intend to
proof your point, otherwise nothing you post will have value. Several
thousand files and directories does NOT proof the issue, nor exceed the
limitations and design. If all your concerned about is pirating DVDs then
fine, use your setup, just don't post any future failures because we could
care less.
And yes, I monitor MSFN and otherwise partake, so you don't need to direct
me to their material.

--
MEB
http://peoplescounsel.orgfree.com/
BLOG - http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
http://groups.google.com/group/the-peoples-law?hl=en - discussion group for
general aspects of Law verses the Peoples' of the world

"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________

"98 Guy" <9...@Guy.com> wrote in message news:45FD5DDE...@Guy.com...

98 Guy

unread,
Mar 18, 2007, 3:56:26 PM3/18/07
to
Rick Chauvin wrote:

> > I *added* more information to your post.
>

> I only skimmed a little and that was enough.

Apparently you set the bar very low for what constitutes opinion vs
fact.

> mingled misguided inexperienced information to it

I've detailed exactly what I've been looking into, what I've been
trying, and what I've found to work and not work.

You seem to do nothing but belly-ache that all I post is opinion.

You wave off every offer to rebut what I've said, or even to answer
exactly *what* I've said that's incorrect.

> and not going to get drawn into the same ol same ol from you

If all you can do is belly-ache and say that "your wrong, but I won't
bother to say why" then what the hell kind of argument is that?

Statements like that make you look like a fool.

> In your eyes everyone seems to be wrong and you're the only one
> right

People say win-98 can't work with drives or volumes larger than 137
gb. People say that win-98 can't handle FAT-32 volumes with more than
4 million clusters.

I've done it, I've said how I've done it, I've put forward
explanations as to why it probably works, and I've put forward
explanations as to why the limitations were even originated in the
first place. And I will defend my observations and explanations,
especially against those who choose not to personally explore them for
themselves.

> and you seem to enjoy drawing people in to ask information
> for the sole purpose to challenge everyone everywhere in your
> own way,

If you were to even bother to read the post that got you all upset,
you would see that there was hardly anything that I posted that was a
challenge to what you wrote.

But you won't read it, will you?

You'd just rather prefer to hide your head in the sand, and think that
all I do is attack you.

> This week my mom is on her death bed though and perhaps if I
> spilled a little sorrow in the guise of aggravation words in
> response to your stifling attitude

You should know better than to post to usenet when you are being
challenged by real events in real life that affect your attitude and
temperment - if not your judgement.

I am not going to apologize for anything I've posted in this thread.
What I posted, and what you admit to only "skimming over", contained
no malice or personal opinion against you. YOU chose to read some
kind of attack into it, YOU chose to respond to it in these last few
posts and turned it into a personal attack against me.

> hey if I handled my choice of words wrong

It's not the words.

You chose to create an issue where none existed.

MalcolmO

unread,
Mar 19, 2007, 1:03:02 AM3/19/07
to
> I *think* the 137 GB limit is for any partition *starting* beyond that
> boundary on the physical drive.

Correct! In Win98, to use anything beyond the 137GB point on a disk, one
MUST have BIOS support and a 48-bit-capable driver, regardless of the
number or size of partitions on said disk.

Bill in Co.

unread,
Mar 19, 2007, 1:49:58 AM3/19/07
to
I've missed some of this thread, but can I ask this related question here?
IF one gets a drive larger than 137 GB, can one still be able to use it, as
long as one partitions it so no partition is greater than that size? OR
is it that you can't even put it into your system (to even set it up),
without some special drivers????

John John

unread,
Mar 19, 2007, 10:44:35 AM3/19/07
to
Microsoft says:

• The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory block
maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95
or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file
system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry
on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot

process the FAT on a volume using the FAT32 file system that defines
more than 4,177,920 clusters (including the two reserved clusters).

Including the FATs themselves, this works out, at the maximum of 32 KB

per cluster, to a volume size of 127.53 gigabytes (GB).

http://support.microsoft.com/kb/184006/en-us


The folks at 48bitlba.com say:

CAUTION! (...Using a PCI ATA Controller card or using updated drivers to
support 48-bit LBA...) are the only two options we know of to use 48-bit
LBA hard drive partitioned to full capacity with Windows 98 or Me. The
hard drives will work properly because updated Windows drivers are
installed which provide 48-bit LBA support with Windows 98 or Me. You
may be able to install a 48-bit LBA drive without either of the above
options where it seems that the drive is working at full capacity.
However, from our tests we found that data will become corrupted once
the amount of data on the hard drive begins to extend beyond 137 GB.
http://www.48bitlba.com/win98.htm


Intel says:

Windows* XP, Windows 2000, Windows Me, Windows 98 SE, Windows 98, and
Windows NT* 4.0 do not provide native support for hard drives that are
larger than 137GB. 48-bit LBA support can be added with Windows* XP
Service Pack 1 †and Windows* 2000 Service Pack 4 †. Please contact
Microsoft* for additional information. In order to enable hard drives
larger than 137GB, you will need to install the Intel Application
Accelerator or install a 3rd party 48-bit LBA controller card.
http://www.intel.com/support/chipsets/iaa/sb/cs-009299.htm


Seagate Technology says:

...Windows 98SE has a default limitation of 137GB supporting ATA
interface disc drives. Therefore, your boot drive partition will have a
maximum size of 137GB.

...Also, the native Windows 98SE ScanDisk and Defrag utilities are
limited to smaller partition sizes and may not function on partitions
greater than 127GB. There are no fixes available from Microsoft for this
limitation. Third-party software may be available to defrag and monitor
larger FAT32 file systems. Seagate recommends creating partitions of a
size that can be managed by the native Windows 98SE ScanDisk and Defrag
utilities.
http://www.seagate.com/www/en-us/support/knowledge_base/


98 Guy says:

> I have posted that dos scandisk (scandisk.exe - the native scandisk
> that comes with 98se) is indeed capable of handling a much larger FAT
> table than would normally fit inside a 16mb memory space. I have not
> found a limit for scandisk.exe so far, but it does work at least up to
> a cluster count of 40 million - far beyond the often stated value of
> 4.177 million.

> In my tests, indeed the system HAS restarted after a bad shutdown and


> scandisk WAS invoked at startup and it DID run smoothly and without
> issue.

Translation: Microsoft, Intel, Seagate, 48bitlba.com et al are a bunch
of fools who don't know what they are talking about and my tests
supersede any tests that the above idiots may have done.


To further obscure the issue 98 Guy tells us:

> We all know that the default cluster size for NTFS is 4kb, and that a
> constant (and small) cluster size is one of NTFS's claimed advantages
> over FAT-32. Which is true, if you do not specifically test to see if
> win-98 can run on a large volume formatted with a small (4kb) cluster
> size, which I have found that it can.


NTFS is designed to work on NT operating systems, not on DOS based
Windows 9x. NTFS uses B-tree architecture, it doesn't have to leaf
trough the whole MFT to find folders and files. Comparing or making
parallels between these operating systems and their file systems is like
comparing radishes to potatoes!

John


Gary S. Terhune

unread,
Mar 19, 2007, 12:23:38 PM3/19/07
to
But say I have a partition that starts at 120GB on the drive, and extends to
250 GB. Does any of the data on that partition become vulnerable?

--
Gary S. Terhune
MS-MVP Shell/User
www.grystmill.com

"MalcolmO" <us...@domain.invalid> wrote in message
news:etl5bu$9b7$1...@aioe.org...

Bill in Co.

unread,
Mar 19, 2007, 11:57:02 PM3/19/07
to
Can someone pse answer this?? TNX!

Bill in Co. wrote:
> I've missed part of this thread, but can I ask this related question here?

real@hotmail.com MEB

unread,
Mar 20, 2007, 2:49:02 AM3/20/07
to
"Bill in Co." <not_rea...@earthlink.net> wrote in message
news:ew7bTPqa...@TK2MSFTNGP04.phx.gbl...

Sorry, thought you might have picked up John's present [03-19-07], I'll not
get technical:

Look here http://www.48bitlba.com/win98.htm which provides some relevant
information which should answer some of your questions.

Here's another non-Microsoft reference:
http://www.dewassoc.com/kbase/hard_drives/drive_size_barrier_limitations.htm
http://www.dewassoc.com/kbase/hard_drives/hard_drive_size_barriers.htm
which is non-technical discussion, so perhaps providing easier reading and
understanding.
You can also back check this group as SEVERAL discussions have been done in
the last year or so here.

There are several other/after market drivers available for SATA and/or
large hard drives, if your hard drive does not come with 98 support. Some
are free while others are not.
Check MSFN for an additional Win98 discussion related to the issue if you
need more information, and a free driver posted on MGDX [ 48BITLBA.EXE which
contains a modified version of esdi_506.pdr ].

A primary consideration is always the BIOS and what it supports via its
translation [such as LBA], and other hardware related issues: such as a
controller card with a supplied driver which provides large drive support or
its onboard controller [is it Brian that posts a recommended card?]; or a
program such as the Intel Application Accelerator which provided larger
drive support. Then the issue becomes the partition size [though there HAS
been disagreement whether there may still be potential issues].

As for large non-SATA [IDE now called PATA] the limit can also be somewhat
overcome with a drive overlay program [ sometimes the only way, though NOT
recommended ] and proper partitioning. Though even then limitations come
into play, revolving around BIOS/hardware support, and OS and tool
limitations. The maximum safe partition limit is generally stated as being
127 gig.

One can't really hit that 2.1(2) to 8 terebyte [depending upon who you
read/believe and the OS] under Fat32. The 98 OS contains its own file
handling limitations [just as XP and Vista do] which, when compromised,
causes failures. Too many other things running, too much overhead. To come
anywhere near that, one would need [for practical purposes] a file SERVER
{specifically designed for that purpose} running Fat32.

If you're being thrown off by the 98Guy segment of this discussion; that
revolves around NOT using a driver in Win98, but using DOS Mode
compatibility and BIOS support "ONLY" [when using SATA drives], so don't
mistake that separate and distinct issue pursuant THAT discussion.

Bill in Co.

unread,
Mar 20, 2007, 5:06:35 AM3/20/07
to
OK, and thanks for the info here, MEB. So to make a long story short, it
looks like if you're using Win98SE and FAT32, you will NOT be able to use a
DRIVE (and not just a partition) larger than 127 GB without some special
"tricks". And, I ain't going that route! (As in, thanks, but no
thanks. :-)

120 GB drives are still available, and are MUCH more than I need anyways, so
it's no big deal over here! But thanks for the references!

cquirke (MVP Windows shell/user)

unread,
Mar 20, 2007, 10:17:13 AM3/20/07
to
On Sun, 18 Mar 2007 10:16:38 -0400, 98 Guy <9...@Guy.com> wrote:
>John John wrote:

>We all know that the default cluster size for NTFS is 4kb, and that a
>constant (and small) cluster size is one of NTFS's claimed advantages
>over FAT-32. Which is true, if you do not specifically test to see if
>win-98 can run on a large volume formatted with a small (4kb) cluster
>size, which I have found that it can.

I don't consider cluster size to be that important for volumes that
don't do a lot of paging. Outside of the context of 4k CPU page size,
I think the advantages of "small clusters" are overrated, especially
when pursuing these will trade-off in other ways, e.g. huge FATs.

>Your conclusion is based on the presumption that the entire FAT is
>loaded by win-98 during normal operation. I disagree with that
>assumption, and my supporting argument is this: The minimum hardware
>specification for win-98 was a system with 16 mb of memory. The
>maximum possible size of the FAT, as claimed by Microsoft, was 16 mb
>(which is where the 4.177 million cluster-count is derived from). If
>what you're saying is true (that the entire FAT is loaded into memory
>during routine operation) then a good chunk of available system memory
>on early win-98 systems, and potentially ALL system memory, would be
>used just to store the FAT.

Memory != RAM.
Memory = RAM + swap space.

My supporting argument is this test:
- run Win95 in 8M RAM
- within the GUI, load Duke Nukem 3D
- then load Terminal Velocity
- then load Excel, Calculator, etc.

Note that while both of htese DOS games require reduction of default
SmartDrv allocations to run in DOS with 8M RAM, they can both run (OK,
walk) at the same time within Win95 GUI.

If you did the same test with swap file disabled, I'd expect it to
fail. So yes, the entire FAT maybe loaded into memory, even though it
is not locked into physical RAM. If that blows out the page file by
(say) 150M to hold the FAT there, then you've offset quite a bit of
the notional gains of small clusters. Given you aren't interested in
performance, what other reasons to use small clusters are left?

>Microsoft's own explanation for the 4.177 million cluster-count limit
>is not that it would be too inefficient for the OS. Their explanation
>is that the DOS scandisk.exe utility is limited to a 16-million memory
>allocation, and given 16mb of memory, that reduces to 4.177 million
>clusters that it can work with. However, as stated near the top of my
>post, I've not seen such a limitation for scandisk.exe. I also have
>not seen any such large amount of available memory being allocated for
>the system or specifically for the FAT, which I should be seeing if
>indeed a fat with 40-million clusters was being loaded into system
>memory.

The metric to watch there, would be "swap file in use".

Testing this by filling volumes crossing or beyond the 137G barrier is
a good test, but not a complete one, because there may be particular
contexts that do break on the 137G barrier.

We've seen this already, in the case of XP SP1, which (unlike Win98xx)
was claimed to be OK for > 137G. The code that dumps to hard drive
after a system crash is not 137G-OK in XP SP1, and can corrupt the
volume. That's something that would not have showed up on testing the
system as you have done.

The file system has my nads in its jaws.
I prefer not to pick a fight with it :-)

>--------------- ----- ---- --- -- - - -
Tech Support: The guys who follow the
'Parade of New Products' with a shovel.
>--------------- ----- ---- --- -- - - -

cquirke (MVP Windows shell/user)

unread,
Mar 20, 2007, 10:29:26 AM3/20/07
to
On Sun, 18 Mar 2007 11:42:22 -0400, 98 Guy <9...@Guy.com> wrote:
>MEB wrote:

>> File system limits are imposed by the file system driver.

>Which I presume you are referring to ESDI_506.PDR, which given a drive
>formatted with 32kb cluster size and 4.177 million clusters results in
>a volume size of 137 gb which is identical to the 28-bit sector
>addressing limitation of ESDI_506.PDR (2^28 x 512 bytes/sector = 137
>gb).

Do you physically remove this driver, or hope that it won't be
invoked? Have you tested in Safe Mode?

>It's not clear to me if a FAT entry stores a sector value, or a
>cluster value.

Cluster value. There are three levels of addressing:
- physical sectors, at system (partition table) level
- logical sectors, at file system structure level
- clusters, at data space level

IOW, the partition is found via physical sector addressing, then the
OS's logical sector addressing is imposed, with the zeroth sector
being the start of that volume's boot record. This is how the OS
finds FATs and root directory.

Thereafter, directory entries and FAT table entries use the same
cluster addresses. If all the directory entry "start of chain" values
plus all those non-special values in one of the two duplicate FATs
were combined, no address should appear twice - if so, then a
crosslink is present from that address onwards.

Some other file system structures, e.g. reserved sectors, will be
addressed in logical sectors, not clusters.

Some tools and environments may lock down a file and then navigate
that file as a reserved space using different logic. This may apply
to swap file management?

To actually access disk, the drivers have to bump down from file
system adstraction to the physical disk. The drivers in use during a
Windows GUI runtime may not be the ones in use in Safe Mode, or during
the DOS mode phase of GUI boot (e.g. spontaneous Scandisk in Win98xx),
or where DOS mode has been booted instead.

Even within something like Scandisk, what happens may depend on what
Scandisk is trying to do or fix. It's a high-risk YMMV game.

>--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
>--------------- ---- --- -- - - - -

real@hotmail.com MEB

unread,
Mar 20, 2007, 10:47:31 AM3/20/07
to


"Bill in Co." <not_rea...@earthlink.net> wrote in message

news:%2341LS8s...@TK2MSFTNGP05.phx.gbl...


| OK, and thanks for the info here, MEB. So to make a long story short,
it
| looks like if you're using Win98SE and FAT32, you will NOT be able to use
a
| DRIVE (and not just a partition) larger than 127 GB without some special
| "tricks". And, I ain't going that route! (As in, thanks, but no
| thanks. :-)
|
| 120 GB drives are still available, and are MUCH more than I need anyways,
so
| it's no big deal over here! But thanks for the references!

Yeah, that's pretty much the "safe zone" short answer, with one more
consideration though.

Another consideration revolves around the type of application and tools one
uses ON those disks/partitions as they may have their own in-built
limitations. Personally, I think this is likely why there may be some
debatable issues related to the disks/partitioning, and why there is no
actual finite answer.
As was shown in this group [and elsewhere], Win98 itself has various
indications of in-built limitations which we can use as representative of
the issue. Such as: the My Documents folder and files limitations issue; the
Outlook default folder issue; and the shell32/kernel replacement issues and
related dll discussions.
These should cause us to think carefully about and attempt to understand
that other programs/applications MAY have in-built limitations which we need
to take under consideration when discussing failures and limitations, and
any corruption issues shown. Likely, these MAY be the actual issue causing
and/or contributing to/compounding that corruption. But don't let this
mislead you either, only you and your specific configuration can determine
the actual limitations relative to your specific configuration.

cquirke (MVP Windows shell/user)

unread,
Mar 20, 2007, 11:36:53 AM3/20/07
to
On Mon, 19 Mar 2007 09:23:38 -0700, "Gary S. Terhune"

>But say I have a partition that starts at 120GB on the drive, and extends to
>250 GB. Does any of the data on that partition become vulnerable?

<bart> Maybe </bart>

Best practice with am > 137G HD in an unsafe OS is to jumper the HD to
limit it to 137G, if the physical HD has that feature.

Next-best is to keep all partitions and volumes within the first 137G
of the physical capacity.

I am not sure if the second will always be 100% safe.

>-------------------- ----- ---- --- -- - - - -
Trsut me, I won't make a mistake!
>-------------------- ----- ---- --- -- - - - -

Bill in Co.

unread,
Mar 20, 2007, 2:28:03 PM3/20/07
to
MEB wrote:
> "Bill in Co." <not_rea...@earthlink.net> wrote in message
> news:%2341LS8s...@TK2MSFTNGP05.phx.gbl...
>> OK, and thanks for the info here, MEB. So to make a long story short,
it
>> looks like if you're using Win98SE and FAT32, you will NOT be able to use
a
>> DRIVE (and not just a partition) larger than 127 GB without some special
>> "tricks". And, I ain't going that route! (As in, thanks, but no
>> thanks. :-)
>>
>> 120 GB drives are still available, and are MUCH more than I need anyways,
so
>> it's no big deal over here! But thanks for the references!
>
> Yeah, that's pretty much the "safe zone" short answer, with one more
> consideration though.
>
> Another consideration revolves around the type of application and tools
one
> uses ON those disks/partitions as they may have their own in-built
> limitations. Personally, I think this is likely why there may be some
> debatable issues related to the disks/partitioning, and why there is no
> actual finite answer.

So it seems.

> As was shown in this group [and elsewhere], Win98 itself has various
> indications of in-built limitations which we can use as representative of
> the issue. Such as: the My Documents folder and files limitations issue;
the
> Outlook default folder issue; and the shell32/kernel replacement issues
and
> related dll discussions.
> These should cause us to think carefully about and attempt to understand
> that other programs/applications MAY have in-built limitations which we
need
> to take under consideration when discussing failures and limitations, and
> any corruption issues shown. Likely, these MAY be the actual issue
causing
> and/or contributing to/compounding that corruption. But don't let this
> mislead you either, only you and your specific configuration can determine
> the actual limitations relative to your specific configuration.

OK. And I do use a lot of those tools, too. (I even remember the "loss"
of being able to use some of my old tools when I went from FAT 16 to FAT 32!
:-).

For me, I don't mind living on the edge a bit with SOME things (to wit, I do
play a bit with the registry, and most recently with that damn index.dat TIF
file corruption problem with the Wikipedia site).

But I have never used, and won't use, things like disk overlay managers
(that need to load at bootup), and disk compression - thanks, but no thank!
In that respect, I want my system "clean" and "non-problematic" (under any
circumstances) - well, at least at that level. I've got enough to mess
with without having to deal with that potential fallout. :-)

Gary S. Terhune

unread,
Mar 20, 2007, 11:11:11 PM3/20/07
to
Thanks for the clarification, Chris.

--
Gary S. Terhune
MS-MVP Shell/User
www.grystmill.com

"cquirke (MVP Windows shell/user)" <cquir...@nospam.mvps.org> wrote in
message news:dpvvv2pbbu43bd0t8...@4ax.com...

Jeff Richards

unread,
Mar 22, 2007, 6:22:44 AM3/22/07
to
My understanding is that if the system supports 48-bit LBA properly and
everything is correctly installed, the location of the partition won't
matter. The only remaining limitation in that case is the partition size.

Of course, that conclusion is somewhat self fulfilling, as, by definition,
if there is a problem with that configuration then 48-bit LBA wasn't
properly supported after all.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Gary S. Terhune" <gr...@grystnews.com> wrote in message
news:ei8DqLka...@TK2MSFTNGP02.phx.gbl...

Gary S. Terhune

unread,
Mar 22, 2007, 10:11:59 AM3/22/07
to
Ahh, so a rule of thumb we don't really have. Just more "if/thens". Oh well.

Myself, I'm trying to figure out how to make this old AT board recognize
more than 8GB, <g>. (Well, it doesn't recognize a 60GB drive properly,
anyway.)

--
Gary S. Terhune
MS-MVP Shell/User
www.grystmill.com

"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:uWlELwGb...@TK2MSFTNGP06.phx.gbl...

real@hotmail.com MEB

unread,
Mar 22, 2007, 1:49:13 PM3/22/07
to


"Gary S. Terhune" <gr...@grystnews.com> wrote in message

news:eiNQIwIb...@TK2MSFTNGP03.phx.gbl...


| Ahh, so a rule of thumb we don't really have. Just more "if/thens". Oh
well.
|
| Myself, I'm trying to figure out how to make this old AT board recognize
| more than 8GB, <g>. (Well, it doesn't recognize a 60GB drive properly,
| anyway.)
|
| --
| Gary S. Terhune
| MS-MVP Shell/User
| www.grystmill.com

Well, how about some info on that mother board, BIOS version, and the hard
drive your attempting to use.

PERhaps, someone can help with that situational configuration.

--
MEB
http://peoplescounsel.orgfree.com/
BLOG - http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
http://groups.google.com/group/the-peoples-law?hl=en - discussion group for
general aspects of Law verses the Peoples' of the world

"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________

|

real@hotmail.com MEB

unread,
Mar 22, 2007, 2:22:47 PM3/22/07
to


"Bill in Co." <not_rea...@earthlink.net> wrote in message

news:Oq8EC2xa...@TK2MSFTNGP03.phx.gbl...


| MEB wrote:
| > "Bill in Co." <not_rea...@earthlink.net> wrote in message
| > news:%2341LS8s...@TK2MSFTNGP05.phx.gbl...
| >> OK, and thanks for the info here, MEB. So to make a long story
short,
| it
| >> looks like if you're using Win98SE and FAT32, you will NOT be able to
use
| a
| >> DRIVE (and not just a partition) larger than 127 GB without some
special
| >> "tricks". And, I ain't going that route! (As in, thanks, but no
| >> thanks. :-)

Well, they're not exactly tricks, per se, but attempts to deal with the
limitations of BIOS and/or system.
For instance, the esdi_506 was created because Microsoft SHOULD have
created this during the 98/ME support period, but did not.
There really wasn't any reason for not doing so, OTHER THAN Microsoft's
attempt to move users to OSs which did supply that support. Even then,
Microsoft may have had to make a hotfix to provide that support properly.

Well, we all have those defunct tools. Gees I have hundreds of floppies
filed with these old tools I tested or used which I should get rid of, or
burn to CDROM. Occasionally I pull one of these old "favorite" programs out
just to test it on something,,, sometimes regretting that I did.

ANYWAY,,, if there is the least question concerning something you might
use, use something else. This 98 OS has hundreds of thousands of
programs/applications that do safely work within it, so there is no real
reason to even attempt to use something that may cause problems.

AND, regardless of the resistance to Linux, should it be necessary to use
it for older systems [and these present XP systems in the future] with no
driver support for 98, yet able to run it in the virtual environment within
Linux without the massive bloat of XP or 2000, 98 may survive for another
dozen years.

|
|
| > --
| > MEB

Gary S. Terhune

unread,
Mar 22, 2007, 2:46:59 PM3/22/07
to
When I'm less busy, perhaps. No big deal. I've got a couple of drives that
work in the machine, and it's for testing, anyway.

--
Gary S. Terhune
MS-MVP Shell/User
www.grystmill.com

"MEB" <meb@not re...@hotmail.com> wrote in message
news:O4edhpKb...@TK2MSFTNGP03.phx.gbl...

AlmostBob

unread,
Mar 22, 2007, 5:38:34 PM3/22/07
to
I have the 48bit lba patch and full use of 3 160Gig drives, exactly how I do
not know, that is what teenagers are FOR.

--
-
Adaware http://www.lavasoft.de
spybot http://www.safer-networking.org
AVG free antivirus http://free.grisoft.com/
Etrust/Vet/CA.online Antivirus scan
http://www3.ca.com/securityadvisor/virusinfo/scan.aspx
Super Antispyware http://www.superantispyware.com/
Panda online AntiVirus scan http://www.activescan.com
Panda online AntiSpyware Scan
http://www.pandasoftware.com/virus_info/spyware/test/
Catalog of removal tools (1)
http://www.pandasoftware.com/download/utilities/
Catalog of removal tools (2)
http://www3.ca.com/securityadvisor/newsinfo/collateral.aspx?CID=40387
Trouble Shooting guide to Windows http://mvps.org/winhelp2002/
Blocking Unwanted Parasites with a Hosts file
http://mvps.org/winhelp2002/hosts.htm
links provided as a courtesy, read all instructions on the pages before
use
Grateful thanks to the authors/webmasters
_
"Gary S. Terhune" <none> wrote in message
news:OrqcxJLb...@TK2MSFTNGP04.phx.gbl...

cquirke (MVP Windows shell/user)

unread,
Mar 23, 2007, 9:05:31 AM3/23/07
to
On Thu, 22 Mar 2007 07:11:59 -0700, "Gary S. Terhune"
<gr...@grystnews.com> wrote:

>Ahh, so a rule of thumb we don't really have. Just more "if/thens". Oh well.
>
>Myself, I'm trying to figure out how to make this old AT board recognize
>more than 8GB, <g>. (Well, it doesn't recognize a 60GB drive properly,
>anyway.)

BIOS limits are supposed to occur only at the traditional 500M, 8G,
32G and 137G boundaries, with some brand-name wonks failing at 2G.

The way BIOS fails, varies... and I'm fuzzy on the details, but from
memory, the 500M, 8G and 137G failures will show the HD as limited to
that size, while the 32G limit will hard-lock the system whenever BIOS
attempts to detect the HD.

In practice, I see many motherboards that exhibit the
hard-lock-on-detection behavior at arbitrary capacities between 32G
and 137G, typically making anything larger than 60G or 80G impossible
to use while 40G is seen OK as 40G.

Because the hard-lock pattern happens long before MBR is processed,
it's not amenable to DDO or other software workarounds, as have been
used with varying success for the 500M and 8G limits.

If there's a BIOS update that fixes this, then you could try that, or
you could try adding a controller that has its own BIOS.

But the more inventive (i.e. non-standard) you have to get, the more
likely some OS upgrade, 3rd-party tool or other adversity will ambush
you and barf everything.

>--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!

>--------------- ---- --- -- - - - -

cquirke (MVP Windows shell/user)

unread,
Mar 23, 2007, 9:09:37 AM3/23/07
to
On Thu, 22 Mar 2007 11:46:59 -0700, "Gary S. Terhune" <none> wrote:

>When I'm less busy, perhaps. No big deal. I've got a couple of drives that
>work in the machine, and it's for testing, anyway.

Oh - I reminder I forgot; FDisk and Format limitations!

FDisk from Win95/98 fails somewhere around 50G or so, i.e. shows bogus
capacities. There's a fixed FDisk for these OSs that works as well as
the one from WinME, i.e. will work up to 137G, but like all FDisks (no
matter how "fixed") won't allow input over 99G for user-sized volumes.

Format often gets capacity wrong, but it's a cosmetic error only; it's
good up to 137G, whereafter things can be expected to fall apart.

You don't have to reboot between successive uses of FDisk, but you do
have to reboot between last FDisk changes and any use of Format.

>------------ ----- ---- --- -- - - - -
The most accurate diagnostic instrument
in medicine is the Retrospectoscope
>------------ ----- ---- --- -- - - - -

John John

unread,
Mar 23, 2007, 9:27:07 AM3/23/07
to
cquirke (MVP Windows shell/user) wrote:

> On Thu, 22 Mar 2007 11:46:59 -0700, "Gary S. Terhune" <none> wrote:
>
>
>>When I'm less busy, perhaps. No big deal. I've got a couple of drives that
>>work in the machine, and it's for testing, anyway.
>
>
> Oh - I reminder I forgot; FDisk and Format limitations!
>
> FDisk from Win95/98 fails somewhere around 50G or so, i.e. shows bogus
> capacities.

It (fdisk) needs a whack on the head at 64GB. Microsoft issued a
revised version for it http://support.microsoft.com/kb/263044

John

Gary S. Terhune

unread,
Mar 23, 2007, 1:31:30 PM3/23/07
to
That's what I have... A 60GB disk limited to 8GB.

--
Gary S. Terhune
MS-MVP Shell/User
www.grystmill.com

"cquirke (MVP Windows shell/user)" <cquir...@nospam.mvps.org> wrote in
message news:1pj703tfovilpir05...@4ax.com...

cquirke (MVP Windows shell/user)

unread,
Mar 24, 2007, 5:00:07 AM3/24/07
to
On Fri, 23 Mar 2007 10:31:30 -0700, "Gary S. Terhune" <none> wrote:

>That's what I have... A 60GB disk limited to 8GB.

Yep; you have a few choices:
- use as a really fast 8G HD
- update BIOS to support as larger capacity
- use a DDO to use as larger capacity
- use OS's native support to use as larger capacity

Which you choose, may depend on:
- whether you use multiple OSs
- whether you use the HD in other systems
- whether your OS is compatible with the DDO
- how well an incumbent OS takes to BIOS changes
- how comfy you are with maintaining a non-standard MBR
- whether you need DOS mode support (if "native OS" etc.)

The odd thing is, different limits can apply at different levels,
sometimes in ways that appear paradoxical. I've seen 8G-limited
system that are happy over 32G when some way of crossing the 8G limit
is found, and I had at least one system where BIOS and DOS mode
couldn't see the fuill capacity, but the Win9x GUI could.

More often than not, I've just used as a "fast 8G", as often that's
been the most appropriate approach for the context. Usually it's an
old but critical system that has to be kept alive with maximum
reliability, because it's running an expensive or abandoned
application that won't work on newer hardware or OS.

Ah, dem legacy lock-in blues, tra-la-la :-/

>-------------------- ----- ---- --- -- - - - -
Tip Of The Day:
To disable the 'Tip of the Day' feature...
>-------------------- ----- ---- --- -- - - - -

Gary S. Terhune

unread,
Mar 24, 2007, 2:44:24 PM3/24/07
to
No BIOS update available (old PC Chips board), and I'm not really interested
in other solutions, I don't think. I'll just stick with my old, small
drives. Like I said, it's just a test machine for Win98/98SE/ME. Two 8GB
drives are sufficient to multi-boot the OSes and have some storage.

--
Gary S. Terhune
MS-MVP Shell/User
www.grystmill.com

"cquirke (MVP Windows shell/user)" <cquir...@nospam.mvps.org> wrote in

message news:akp903l0mltrekkii...@4ax.com...

0 new messages