Even a Patched Windows 9X System is not safe if the BIOS does not support 48-Bit LBA. During Startup, Windows 9X uses DOS and the BIOS to load software and update system files (WININIT). It also uses the BIOS in Safe Mode or Compatability mode. Windows XP and Vista also have to use the BIOS to load their Kernels and Disk Drivers during Startup. This leaves a window of vulnerability in which any Writes to the higher partitions could corrupt data in the lower ones.

Since the damage could be just a few bytes, as occurs when Windows XP tags an extended partition table entry, the damage may not be obvious

Neither LLXX's Patches nor my High Capacity Disk Patch solve this problem. I wrote a separate package called BOOTMAN for my customers to provide an overlay to the BIOS to provide the necessary support.

I agree - apply the patch. You might want to wipe the 98 partition and reinstall it afterwards in case.

You are ensuring that you can't access the other partitions when you install Win98, right? One thing you might consider is using a boot manager which can hide everything else when you boot into 98 and ensuring that the other partitions simply don't exist when you install 98 (use Ranish Partition Manager or something similar to "remove" the partitions from the table and put them back after you have installed 98 then change the boot manager settings to ensure they are hidden whenever you boot into 98).

Oh and you aren't using dynamic disks in XP, right?

Hope you sort it out, DaveLH, and please come back and let us know when you do and how you did it!

Way to go Lecco. Glad you found it. But what exactly is that dialog in the screenshot showing us? Sorry to be ignorant, but I can't pick out the clue.

No, youre not an ignnorant. In the lower left corner, there is the copying speed in kB/s. I thought you are familiar with Totalcopy.

That doesn't help. The mechanism used to hide a partition is to set the 'hidden' bit in the partition descriptor. So W98 still has to parse the partitiontables to see if it should ignore the particular partition, which it already does, since W98 ignores all unknown partition types.

OK, but that doesn't apply if you edit the partition table manually and actually DELETE all other partitions except the one on which you are going to install Win98. In that case, the partition table only includes that partition - the rest of the space is seen as unpartitioned EMPTY (or available) space by the Win98 installer and by Win98 when it boots. Once you have successfully installed Win98, you go back to the partition table and manually enter the partition information which was there before you "deleted" them. You don't lose data because the data in the partitions themselves still exists. It was a method by which some RPM users used to have more than 4 primary partitions - they simply deleted the partition table info for the ones they weren't using at the time. Of course, during the time that the partition table information has been deleted, you must NOT use any utilities which will try to use that space and of course you need to have recorded the partition table parameters so that you can put them back in the table.

Just an idea to find out what was going wrong.

Hi,
I just bought big SATA HDD WD 500GB. I set "IDE/combined" mode in SETUP (chipset: i945G+ICH7R) to operate 2 SATA ports like standard IDE channel (PATA have attached CDW+DVDW, SATA - HDD). I made here 1 FAT16 and 2 FAT32 (192GB) partitions. It's well accessible from DOS 7.1 but I can access only 1st FAT32 from Win98se. So I installed LBA48 patch (~100kB self-installation exe which should replace ESDI_506.PDR)

The problem is a BSOD I got on next boot (translated from CZ):
"Bad call of dynamic connection of VxD ESDI_506.PDR(03) + 000017EB to device 0026 service A. And ask if I want to continue".

When I continue it boot OK and even LBA48 works - I can access all partitions. But I got this nasty BSOD on every startup. Is there some alternative and fully working LBA48 patch?

Another question to SATA - why Win98SE cannot work with IDE/enhanced mode (1 PATA channel + 4 SATA ports?). In DOS 7.1 it works but Win98SE hangs during boot but works in safe mode. It's not too important now I can live with combined mode.

@ xrayer : I also have a 500GB SATA harddrive from WD a dont get any BSOD. Maybe its the problem wih i945 chipset, I have only i865PE. But I have also the issue with IDE/combined mode (called compatible in my BIOS). I can only use 2 channels - IDE+IDE or IDE+SATA, if I use enhanced mode, Windows hangs during bootup. I dont know where the problem is, but as I replaced my old 120 + 80 GB drives with a 500GB one, I no longer need to think about it.

I don't know exact driver version because I was installing new mobo during weekend and no network working yet and had some ?? ver. So I downloaded latest version from here and try it when back at home. I also readed from other users that enhanced mode doesn't work. BTW I use 2nd PATA HDD with Kouwell IDE/SATA adapter and is seems to be perfectly transparent to the system.

You say you have 865 chipset, then you wouldn't need this patch because of intel application accelerator should provide own LBA48 bit enabled driver for you if you installed it. Maybe it would be possible to patch intel's driver to force it work on ICH7 too.

I can send you the INFs I use, just send me a PM with your mail or ICQ. External SATA/PATA controllers do always work.


IAA doesnt work od 856PE chipset, look here.

It's not necessary, it's working now! It was caused by my confusion of driver versions. My original esdi_506.pdr was 4.10.2225 and that I used was patched 4.10.2226 and this caused the BSOD. Now I replaced it by correct patched version and everything seems to works OK. I didn't filled FAT32 partitions yet but if LBA48 was not active I cannot see the second partition and now I can.
Here's my volumes

BTW I didn't meant Kouwell adapter as a PCI card but as a small PCB which is attached to PATA drive and have SATA connector on other side (bought in CzechComputer per 250,-Kc). I used it for HDD mobile rack and to have ability to easy handle PATA drives.

>IAA doesnt work od 856PE chipset, look

Sorry I overlookd this. But I want to try some experiment with it

BTW what about DOS Scandisk from WinME? Is it safe to run it in >128G partitions? Somebody say yes others no...
I tried it and test succeed but there was not any bugs to fix so cannot say if it can corrupt something. And I don't fill partition over 128G. Should I rather rename/remove scandisk to prevent running it during boot? I have Norton utilities to do the job anyway...

Motherboard chipsets that have SATA integrated into them, rather than a separate chip, often appear to Windows 98SE as additional IDE controllers. Windows 98SE does not correctly configure these additional controllers causing lockup during boot. So far I have only resolved the problem for the MCP61S Chipset.

I post LLXX (pncw_redir_7031(AT)hotmail.com) Reply: The author has discontinued support of Enable48BitLBA and migrated to Linux.

If there is one file I think definately should be slipstreamed into your Windows 9x cd this would be it!


Forgetting to apply this patch before exceeding the 137GB of your hard disk would be a catastrophe.




So how would one go about replacing the original ESDI_506.PDR file so this new one is installed instead automatically (or preferably slipstreamed into the installation)?

>Sorry I overlookd this. But I want to try some experiment with it

Hm, so I tried to modify INF file from IAA (supports up to ICH4) to add ICH7 support, then it was installed successfully, copied intelata driver to system directory but after reboot it didn't worked. In device manager I can see 82801DG controller with primary and secondary channel with /!\ warning. It seems that limitation is in intelata.mpd driver itself so I give up. Anyway modified esdi_506.pdr seems to work fine.

>Forgetting to apply this patch before exceeding the 137GB of your hard disk would be a catastrophe.

Not so catastrophe. I booted my win98 before applying this patch (1st I needed to download it from somewhere and it didn't caused any damage to
data on other two big FAT32 partitions. One partition was even accessible and fully readable because I didn't filled it up to 128G limit. Other partition was reported as unknown. Of course I didn't try to write anything there before patching.

Just because you don't INTENTIONALLY write to a Partition does not mean writes don't occur. Win 9X creates RECYCLE bins, WinME creates restore points, and Win XP writes Disk Management info, without user interaction.

This type of damage can be very localized and not show up unless you test every byte of every file in every Partition. The unpatched ESDI_506.PDR does not simply wraparound when crossing the 137GB boundary but jumps around to different areas in a complex pattern.

Yeah not a catastrophe straight away, but if you still forget to apply the patch then fill the primary partition beyond 137GB or split a large hard disk into multiple partitions then try to use a part of the drive beyond 137GB you could be in for a nasty shock.


I never use my original Win98 disk to install Win98SE. I always use a backup disk I've created as I can add all my drivers and utilities to it that I always install. Slipstreaming ESDI_506.PDR would be rather reassuring. Can it be done?

I managed to replace the file inside the cab on the win98 disk and the install went fine but i never did go above the 137 gig limit.

Oh sure, I don't support this kind of hazards and agree that integrating patch into installation is a good idea. Just wanted to say that it should't be catastrophic if you know what you are doing. About recycled - I have disabled it and when use my favorite file manager to delete fiels even recycle.bin directories are not created. And I didn't try to delete anything from those partitions anyway.

BTW does anybody know why Win98 don't like (hang at boot) SATA enhanced mode (enabled in BIOS to use more than 4 IDE drives [2 on PATA, 2 on SATA]). It works fine in DOS and safemode because then BIOS int 13h extension is used and take care about it.

The point about not applying it before using the disk is that if the system attempts to write even one byte to above the limit, it will be written at the start of the disk and possibly mess up something you can't fix. (If you are installing Win98 in a partition which starts above 137GB you won't have any trouble - the installation process won't reboot into Win98 so you HAVE to replace the file at/before the appropriate moment!)

Two easy ways to get the file in place:

1. One is to put it in the cab file in the Win98SE installation CD. It would be a good idea to make sure the original file exists there too in case it is needed later (rename it to ESDI_506.ORIG.PDR or something) and also to make sure there is a note in the readme file or on the CD itself. That's effectively a slipstream although you get no choice to avoid replacing it that way. (On my Win98SE CD it is in WIN98_51.CAB - I don't know if this varies for different versions.)
   
2. The other is to replace it from DOS (not a DOS windows obviously). You can do this from a boot to DOS (from diskette, CD, USB stick etc), but it is also safe to do this by attending the Win98SE installation and stopping it rebooting into Win98SE the first time. At that stage, the Win98 OS has not accessed the disk. To do it from DOS, obviously you need to put the file somewhere where DOS can access it so that you can copy/move it into the ..\WINDOWS\SYSTEM\IOSUBSYS directory.

Hope that helps!

Can you just unpack a .cab file then recreate the .cab file with the new file in it?

What program do you use?




Also, I notice Gapes Unofficial SP2 & SP3 says it supports semi slipstreaming, and all you have to do is copy your Win98 file from your Windows98 cd to your hard disk, then extract the files in the SP2.cab file into your Win98 folder that you copied earlier. These updated files will replace the existing files on the cd. Does that mean Windows 98 has a type of slipstreaming support built into Win98's installation process?

I think there are extract.exe and makecab.exe (not sure of 2nd name) freely available allows you to extract and rebuild CAB files. But I did only extraction not rebuilding new cab.

Are you sure about that? Why is that?

The unpatched ESDI_506.PDR driver checks if the sector number is within the 28-Bit range. Whoever designed the driver never wrote the code to handle higher sector numbers, or reject them. The code falls through to the older CHS algorithm. The CHS code does the math using unintialized geometry and 16-Bit cylinders to come up with settings that are sent to a drive which has never been initialized for CHS. The end result is a complex pattern of accesses over a portion of the 137GB range, intermixed with disk errors.

Sorry - I should have mentioned it. There are a number of utilities around. Search Engines are your friends!

If you search, you may find the one I use - good old Microsoft:

MakeCab.Exe

You can get that from Microsoft (free as in free beer as opposed to free thinking lol) - see Knowldegebase Article http://support.microsoft.com/kb/310618 which tells you how to use it and the link for downloading it. You need to do a little reading to work it, but don't worry - it isn't rocket surgery


Sorry, I don't use Gapes. I now rely almost entirely on this Board's own "Auto-Patcher For Windows 98se". If you haven't tried it, you might like to! (It includes the option of switching the ESDI_506.PDR file and has the option to use the correct one but obviously only after Win98SE is installed and you are patching it.)

Hope that helps!

HELP!

If I install the patch on my computer, Hard disks drives are forced into DOS-compatibility mode.

I'm worried because I just bought a 400Gb drive...

Did you consider upgrading to XP and making sure your motherboard supports 48-Bit LBA?

How do I check wheter my MoBo supports 48-bit LBA?

(I don't plan to insntall XP on this machine)

Thanks.

Try HDINFO... I've never used it myself, but it claims to be able to test your BIOS for 48-bit LBA support.

You say 'if'. Does that mean that when you reverse the installation, the harddrive works OK? I'd expect the patched ESDI_506.pdr to be corrupted somehow, or the wrong version.
The compatibility modus is forced when windows decides that it has no appropriate drivers for the drive, which happens when the device is not recognized, or when the proper driver is unavailable (by corruption for instance).

Yes, when I restore the original ESDI_506.pdr, the drive(s) work(s) OK.
I'v tried to one in LLMX's zip file (Mistakingingly the 22226 version, then 22225.), MDGx's installer and Gape's uSP2 and 3. All put my drives on DOS-compatibility mode. I have this problem since uSP2 was realeased. That's the only file that doesn't fit on my computer.

I have a WD 120 GB (real: 111Gb). Before, I had a second 40 Gb drive that is removed now.

I'm doing a test with HDINFO, right now to see if my BIOS and MoBo are compatible...

Currently the BIOS shows for the drive LBA: ON and 32-bits: ON. It doesn't mention anything about 48-bits.
The MoBo is 5 years old.

I mounted the new WD 400Gb drive into the case and set it as primary slave. The primary master is a WD 120 Gb.

The BIOS detects the new drive but displays for it a capacity of 136.9 Gb only.

Then, I restarted windows.
Windows Explorer doesn't see the drive (maybe because it's not formatted - but how do I format a drive that windows doesn't see? I hope to find the solution here, on WD website - ).
In the Device Manager, however, it seems to be there because there are two "generic IDE drive TYPE 47". If there is only one hard disc installed there should be only one, I think.

Then I ran HDINFO. ===> Surprise!
The primary master (the 120 Gb drive) doesn't support 48-bits LBA (and supports everything else)
The primary slave (the new 400 Gb drive) supports 48-bits LBA and displays a capacity of 400 Gb (contrary to BIOS)!

Then I ran 48LbaChk under plain DOS
===> Second surprise!
It says "Your BIOS appears to be 48-bits LBA capable and you have a drive larger than 137 Gb installed".
Which is good news.

Yet, the problems remain that the BIOS doesn't see more than 136.9 Gb, Windows doesn't see it at all and the ESDI_506.pdr patch still set drive C in compatibility mode.

I'm a little bit confused with all these conflicting informations...

You'll have to partition it. Explorer will only see a *partition* it recognizes. Windows has recognized it, as it sees 2 harddisks.

I applied r.Loew patch and... it works!

I was able to partition the new drive up to 143 Gb (Windows sees it with that much free space) with WD's Datas Lifeguard (utility from WD's website).
Something impossible before applying r.Loew's patch.
Now, I didn't try to fill the drive with 143 Gb of datas, but the fact that windows sees it as a 143 Gb drive is very promising.
(It's just a little bit silly to limit the demo version to 145 Gb because it's unclear whether you effectively broke the 137 Gb barrier if you or the partition utility counts 1 gigabites as 1,024 Mb or as 1,000 Mb, as 1,073,741,824 bytes or 1000,000,000 bytes an so on. One way you are under 137Gb "real", the other way you are not. )

The problem with the ESDI_506.pdr patch from LLMX, is that the Device Manager doesn't see any of the hard drive.
Datas Lifeguard, which allows you to format and partition the drive, doesn't detect the drive as a WD one when the patch is installed. Both Device Manager and Datas Lifeguard detect the drive normaly when the original pdr file is restored. But in this case, Datas Lifeguard won't let me use more than 137 Gb.

So you have an IBM laptop? Doesn't seem likely! You probably need 22, not 25. Check the original file version number.

You might want to have a look at the thread for the Win98SE Autopatcher (under Unofficial Service Pack on this site).

Have you tried manually setting BIOS hard drive info based on WD literature?

Hi Briton.

I'v read everywhere that the 22226 is for IBM laptops and that the 22225 is for all other PC.
Moreover I'v applied the patch through installing MDGx's installer and also Gape's uSP.
It would be surprising that two w98 Gods ( ) made the same mistake by placing a wrong file in their installer and that by an incredible luck these wrong files work on most computers except mine.

But since there is version 222222 around, I'm going to test it, just in case I'm lucky. Maybe you are the right guy after all... Otherwise I'll lay $10 for Loew's path. That's not the end of the world.

Happy New Year!

Huh! (repeating myself...)

Reckon if R.Loew has a viable patch that's a vast improvement in lieu of LLXX' patch, it would be soooo nice if he would just "give it up" instead of charging for a patch to an "obsolete" OS. Granted, there a quite a number of persons still using the "obsolete" OS, but, c'mon, wouldn't it be better (from a marketing point of view; he got "yelled at" for doing that in MSFN) to just "release" it openly and try to gain a name for being good at what he does, then go on to more profitable (read $$$ instead of $) ventures?

Not knocking your rationale; you do need a "proper" fix if your gonna use a 137gb+ HDD... just seems kinda way too capitalistic.

Let us know how popping that $10 works...

Sorry - I checked my own versions to see what I did. My oh my that sticky needs relabelling lol

My mistake. Here is how I have them labelled for the boxes I use them on:

4102222F Older Desktop PC Win98SE.ZIP
4102225F Desktop PC Win98SE.ZIP
4102226F IBM laptop v4.10.2226 of PDR file only.ZIP
4903000F WinMe.ZIP

If I remember correctly, the advice I was given on the board was that I should match the installed version number. Did you actually check what file version your installation disk installs?

So you are correct - 26 is for IBM laptop.

(As for the $10 - small price to pay for someone else to do the brainwork! Some go open, some ask for donations. It's up to the owner of the intellectual property rights!)

So 22 is for older desktop PC. Maybe I should install the one for older PC?
Now I'm a little bit at loss how to proceed after I installed Lowe's patch to test another patch. I'v started to use the HD and don't ant to erase everything now.
Can I change the vxd back and forth file and continue with the current HD drive partition (144 Gb) and content?

About the $10, I would be glad to give them to him if that's the solution I need in my case. The problem is more the hassle of moving my derriere to make the payment. It's never clear whether my pay-pal payments are accepted.

im just wanting some confirmation, i just installed 98se and usp3, drivers and stuff, and i installed 48BITLBA and intel application accelerator and on a 40gb disk then ghosted it to a 160gb disk and ran the 160gb disk and i filled it up using MAKE2GB from COPY2GB i filled the disk to 149GB its not really 160GB oh well so i have 139mb left and windows still boots so i can assume i didnt have any problems with 48bitlba?

Hard Drive manufacturers are all cheating about the number of Gb. They say 160 Gb while it's infact 160 billions of bytes.
160 000 000 000b is 149 GB indeed. ((160 000 000 000/1024)/1024)/1024 = 149
So it's normal.

Download Dingue Calculator on my website (signature). I included a data unit convertor...

No they're not. A 160 GB disk should be able to store 160 * 10⁹ bytes. This equals to 149 GiB which is 149 * 2³⁰. This is convented by the IEC in 1999.

@awergh:
Theoretically your test is not rock solid. There could be corruption which do not stop Windows from booting. Since you've passed the 128 GiB limit with 32 GiB, about 25% of the disk should be currupted when the patch doesn't work.
I *think* you're safe, since I can't imagine that windows would not give a single complain with such a corruption, but it *is* possible. LLXX advices that you should test the disk integrety with scandisk, after having filled it with data. You should *not* use W98 scandisk, which can corrupt partitions bigger than 127 GiB, but WinME scandisk, or some 3th party scanner. In any case it's recommended to exchange scandisk and defrag with the WinME versions, when using partitions >127 GiB, as you can read earlier in this thread.

my though about 149gb instead of 160gb was that Seagate got sued recently, but maybe they havent put the right amounts yet.

well i did have a bsod about vmm or something recently so im not sure i re cloned the drive from the 40gb, and i decided to do what i intend which is 120gb partion and 29gb for other os or something, but im only at 9gb full of 20gb because i decided not to use MAKE2GB for some reason

IMO, it's safest to divide the drive into 127GB partitions in case you reinstal windows and forget to update defrag and scandisk to ME.

160Gb vs 149Gb: Maybe it's legal, yet it's not honest. The bigger the drives are the bigger the difference and the disapointment of the poeple.

That's true. In this case Windows is wrong. It should not mention the disk as 149GB, but 149GiB. On the other hand, W98 is older than the '99 IEC convention, so how could it conform? On the third hand, AFAIK Vista still does it wrong.

i gave up and decided only to partition 120gb and leave the 29gb to do nothing, what do ytou mean vista does it wrong afaik all OSs treat a GB as 1024MB

Well, this is going slightly off-topic. You will know that 1 kB is not 1000 bytes but 1024. Yet the 'k' prefix means 1000. In 'binary environments' it was practise to use the 'k' prefix for 1024, because it's easy, it was relatively accurate (only 2.4% wrong), and there was no other prefix available. But memory and disks became bigger. the difference between a 'real' MB and a 'practical' MB is almost 5%, for GB this is 7.3%, and for TB this will be 10%. Your brandnew 1TB disk will be 100GB too small! As Fredledingue stated: 'The bigger the drives are the bigger the difference'. And the 'binary environment' became less well defined. The decimal and binary prefixes became mixed. In earlier days I had an 14k4 modem, which could handle a full duplex 14400 bits/second. In this case a 'k' is obviously 1000. Why? Isn't is a 'binary device'? What about my 4Mb broadband? It turns out to be 4000000b. But the upload is 1Mb, which is 1048576b. Did you know that the 1.44MB floppy size is 1.44 * 1024 * 1000 bytes?
So this practise became inconvenient. For this reason the IEC introduced the binary prefixes Ki, Mi, Gi, ...
The harddisk manufacturers are right when they sell you a 160GB harddisk which can contain 160000000000 bytes. They are using an international standard. It would be nice if they sold you a 149GiB disk, but as long as their competitors don't, they cannot do that.
Vista (and all OSs) should use the right prefix. Using standards in a wrong way is confusing and error prone.

First time I read about GiB, KiB etc... eventhought the convention was created in 1999.
Why no one ever used it? Why M$ never made a patch to diplay GiB instaed of GB, starting from w98se?
Maybe to maintain the confusion about data tranfer speed and storage. I maintain this confusion is intentional.

I also wonder why hard drive manufacturers never do 160 GiB HD, and do only 160 GB...
After a Vista OS installatiom, a 160 GB has only 134 GiB of storage left.
I wonder how many consumer complained that they didn't have the right HD in their new computer...

I think foppy size is derived from its physical geometry, so you should write 80*18*2*512 = 1474560 instead
meaningless 1.44*1024*1000 even if the result is same.
Anyway I don't bother about MB and MiB, it's not serious difference compared e.g. to nowdays HDD sizes.
From your experience you will know where is used MiBs and MBs. But sometimes I wonder too, e.g. I would expect that
CF card will use MiBs because it contains flash chips which are surely 2^N sized but they probably save this capacity
for badblock relocation and other hidden storage for CF controller.