Thumbs up LLXX !
Full Version: Enable48BitLBA | Break the 137Gb barrier!
MSFN Forums > Microsoft Software Products - Discussion & Support > Windows 95/98/98SE/ME > Windows 9x Member Projects
Successfully tested on WinMe with a 200GB Western Digital Caviar disk and multiple partitions :
Thumbs up LLXX !
Thumbs up LLXX !
QUOTE (erpdude8 @ Jul 26 2006, 07:43 PM) 
[...]
But you were using RAID controllers. Can you use your HDs WITHOUT RAID controllers under Win95? that's the big question!
Also can you use your big HDs without even using ANY Ultra ATA PCI adapters that have their own 48bit LBA BIOSes & drivers.
[...]
But you were using RAID controllers. Can you use your HDs WITHOUT RAID controllers under Win95? that's the big question!
Also can you use your big HDs without even using ANY Ultra ATA PCI adapters that have their own 48bit LBA BIOSes & drivers.
[...]
Yes I can, and I did use one of those two HDs until I bought the other one. It was connected to the IDE controller as primary master. RAID controller was disabled. No driver other than the default one was installed.
I only mentioned the RAID controller because the two HDs made a 240 GB (>127GB) virtual drive and I wanted to tell you about Scandisk and drives that large.
QUOTE (Marius @ Jul 28 2006, 06:10 PM)
QUOTE (erpdude8 @ Jul 26 2006, 07:43 PM)
[...]
But you were using RAID controllers. Can you use your HDs WITHOUT RAID controllers under Win95? that's the big question!
Also can you use your big HDs without even using ANY Ultra ATA PCI adapters that have their own 48bit LBA BIOSes & drivers.
[...]
Yes I can, and I did use one of those two HDs until I bought the other one. It was connected to the IDE controller as primary master. RAID controller was disabled. No driver other than the default one was installed.
I only mentioned the RAID controller because the two HDs made a 240 GB (>127GB) virtual drive and I wanted to tell you about Scandisk and drives that large.
It was full. And I have .SFV files for most of the data.
You still don't think it's possible?? At Micro$oft, "not supported" doesn't mean "not possible". It means "we don't want you to do it".
You still don't think it's possible?? At Micro$oft, "not supported" doesn't mean "not possible". It means "we don't want you to do it".
Excellent 
Now we can try to take it past 137Gb
I'll patch the latest version of ESDI_506.PDR for Windows 95 (4.00.1119 I think) after I'm done with 4.10.2226
Now we can try to take it past 137Gb
I'll patch the latest version of ESDI_506.PDR for Windows 95 (4.00.1119 I think) after I'm done with 4.10.2226
I've decided to go ahead with 4.10.2226, it is now available for download. However, it is not for all machines - use it only to replace an existing 4.10.2226 without Enable48bitLBA.
As such, work on Win95 versions 4.00.1111 and 4.00.1119 will now proceed.
As such, work on Win95 versions 4.00.1111 and 4.00.1119 will now proceed.
As of HDD corruption might be possible with high PCI bus speed I can do some experimental tests with PCI bus speeds up to 42 MHz. Sorry no tests results yet, I spent most time translating Revolutions Pack Lite to Dutch.
QUOTE (Marius @ Jul 29 2006, 04:38 AM)
It was full. And I have .SFV files for most of the data.
You still don't think it's possible?? At Micro$oft, "not supported" doesn't mean "not possible". It means "we don't want you to do it".
You still don't think it's possible?? At Micro$oft, "not supported" doesn't mean "not possible". It means "we don't want you to do it".
I have created 137 GB disk as disk D, then filled it (Win95 OSR2.1 ESDI_506.PDR 4.00.1111) to 100 GB by some files with known MD5 sum, and then calculated the MD5 sums in Windows 95 environment - and everything was good.
It would be very good to know any examples of problems above 32 GiB barrier, I still believe that Mictosoft had some reason to write that KB article.
Petr
QUOTE (erpdude8 @ Jul 26 2006, 04:09 PM)
it's just like mixing apples and oranges which does NOT make any sense!
Actually, as scientifically proven here:
http://www.improb.com/airchives/paperair/v...1-3-apples.html
apples and oranges are NOT much different.
...and generally calling another person "fool" is not very nice, I guess you can disagree with LLXX opinions and ideas without calling
jaclaz
QUOTE (Petr @ Jul 29 2006, 06:20 AM)
I have created 137 GB disk as disk D, then filled it (Win95 OSR2.1 ESDI_506.PDR 4.00.1111) to 100 GB by some files with known MD5 sum, and then calculated the MD5 sums in Windows 95 environment - and everything was good.
It would be very good to know any examples of problems above 32 GiB barrier, I still believe that Mictosoft had some reason to write that KB article.
Petr
Again, excellent. It looks like the original Win95 ESDI_506.PDR is good up to 137Gb. Win95 also internally uses a 32-bit linear sector address (while 2K/XP+ use 64-bit if I remember correctly).It would be very good to know any examples of problems above 32 GiB barrier, I still believe that Mictosoft had some reason to write that KB article.
Petr
I have stated this in my past posts, but I don't think I made it clear enough.
First, the infamous KB: http://support.microsoft.com/kb/246818/EN-US/
QUOTE
Hard disks and other media larger than 32 GB in size were not available at the time Windows 95 and subsequent Windows 95 OEM Service Releases were developed. The changes required to support media larger than 32 GB in Windows 95 would require architectural changes that cannot be supported on these platforms. Microsoft Windows 98 does support IDE hard disks larger than 32 GB in size, if the hotfix documented in the following Microsoft Knowledge Base article is applied:
243450 (http://support.microsoft.com/kb/243450/EN-US/) ScanDisk Errors on IDE Hard Disks Larger Than 32 GB
Notice the emphasized wording. It is implied that Windows 98 does *not* support IDE hard disks larger than 32 GB in size unless KB243450 fix is applied, which updates ESDI_506.PDR to 4.10.2186 (FE) or 4.10.2225 (SE). However, once again notice the wording:243450 (http://support.microsoft.com/kb/243450/EN-US/) ScanDisk Errors on IDE Hard Disks Larger Than 32 GB
QUOTE
This problem may occur on computers that use a Phoenix BIOS and use the Phoenix BitShift translation algorithm to report the geometry of large IDE hard disks. On such computers, the Windows protected-mode IDE disk driver (Esdi_506.pdr) may not correctly recognize the translation mode for the drive, resulting in an inability to access areas of the drive beyond the first 32 GB.
I have two 120GB drives, one of which has nearly 90GB of data on it. I scandisk them regularly and nothing odd is noticed (the occasional lost clusters following a bad shutdown, wrong freespace count, all quite common and non-threatening errors). I am using ESDI_506.PDR 4.10.2222 - the Original file of 98SE release. So it seems, I do NOT need 4.10.2225 to utilise HDDs of greater than 32 gigabytes and the problem is localised to "computers that use a Phoenix BIOS and use the Phoenix BitShift translation algorithm." Furthermore,QUOTE
IMPORTANT: There is no fix available for any version of Windows 95. The reason for this is explained in the following article in the Microsoft Knowledge Base:
246818 (http://support.microsoft.com/kb/246818/EN-US/) Windows 95 Does Not Support Hard Disks Larger Than 32 GB
Thus it would appear that Micro$oft is lying. "The changes required to support media larger than 32 GB in Windows 95 would require architectural changes that cannot be supported on these platforms" is a totally Null and Void statement. They just didn't want to. The ESDI_506.PDRs are very similar between 98FE and 95b. They just didn't want to add the extra code they added in 4.10.2186 to 4.00.1111/9, instead they decided to kill the whole problem by discontinuing support! In this way, KB246818 should've been better named "Windows 95 Does Not Support Hard Disks Larger Than 32 GB If Using Phoenix BIOS And BitShift Translation", although that was probably a bit too long for their liking 246818 (http://support.microsoft.com/kb/246818/EN-US/) Windows 95 Does Not Support Hard Disks Larger Than 32 GB
The truth: Windows 95 supports hard disks of up to 137 GB in size, except on systems with a Phoenix BIOS using BitShift translation.
QUOTE (erpdude8)
I just got an email response from someone from the 48bitLba.com site and this is what the person told me about Win95 & 48bit LBA:
Perhaps someone should email them again, pointing to this thread. Getting something from here listed under http://www.48bitlba.com/tools.htm should also be a good idea, as Loew's own patch seems to have gotten listed there, and also http://www.48bitlba.com/faq.htm#FAQ7 should be ameliorated appropriately QUOTE
Because Windows 95 operating system is not designed to support it. Simple as that
QUOTE (jaclaz)
...and generally calling another person "fool" is not very nice, I guess you can disagree with LLXX opinions and ideas without calling her names, just take it easy
You're a GIRL?
QUOTE (Kelsenellenelvian @ Jul 30 2006, 05:24 AM)
You're a GIRL? Anyway a Validation screenshot would be much appreciated
QUOTE (LLXX @ Jul 30 2006, 06:05 AM)
QUOTE (Kelsenellenelvian @ Jul 30 2006, 05:24 AM)
You're a GIRL? LOL!, I find that quite refreshing, people are often surprised that programing is gender neutral, amongst other things.
@LLXX
corrected original post, sorry for the misleading gender assumption.
jaclaz
corrected original post, sorry for the misleading gender assumption.
jaclaz
Just for reference - 180GB disk in rather old PC with GA-586HX motherboard with AMD K6-2/400 and Windows 95 OSR2.1, DDO installed but the disk is controlled by ESDI_506.PDR:
Click to view attachment
Of course, after 128GiB/137GB data corruption would occur but it is just because the ESDI_506.PDR does not support 48-bit LBA yet. But the systems seem to have no problem with this size. We will see when LLXX release the patched 4.00.1119 driver.
Petr
EDIT: Even without DDO and BIOS set to NONE it works the same way.
Just the correct timing of the PIIX3 controller should be checked, I suppose it is set to the slowest one because the transfer speed is approx 1800 kbytes/s only. The other slower disk shows about 8000 kbytes/s. But this is problem of any OS that does not set timing registry of the disk controller - 95/98/Me.
Petr
Click to view attachment
Of course, after 128GiB/137GB data corruption would occur but it is just because the ESDI_506.PDR does not support 48-bit LBA yet. But the systems seem to have no problem with this size. We will see when LLXX release the patched 4.00.1119 driver.
Petr
EDIT: Even without DDO and BIOS set to NONE it works the same way.
Just the correct timing of the PIIX3 controller should be checked, I suppose it is set to the slowest one because the transfer speed is approx 1800 kbytes/s only. The other slower disk shows about 8000 kbytes/s. But this is problem of any OS that does not set timing registry of the disk controller - 95/98/Me.
Petr
eidenk wrote (July 27 2006, 12:55 PM):
QUOTE
He could have elaborated just a little a bit at this point IMO by saying
where he believes a problem could occur with LLXX patch or what the other
code, he thinks needs to be also patched, does.
... And this is the answer:where he believes a problem could occur with LLXX patch or what the other
code, he thinks needs to be also patched, does.
QUOTE
The anonymous author of these 2 unofficial patches:
http://www.msfn.org/board/?showtopic=77218
http://www.msfn.org/board/?showtopic=58780
& VOLTRACK.VXD & KRNL386.EXE & other patches could not have elaborated!!!
I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a
relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
I am on business travel and do not have access to the computers that either
have the information I need to comment further or could possibly be used to
test any patch.
I firmly believe that running SCANDSKW alone is *not* sufficient to confirm
that a particular patch is working. I nearly filled a 160-Gbyte HDD with
large files using Windows Explorer and verified that *all* files, in
particular those located above 137 GByte, were correct and, most importantly,
that writing data to a location > 137 GByte did *not* overwrite data in a
location < 137 GByte and vice versa.
http://www.msfn.org/board/?showtopic=77218
http://www.msfn.org/board/?showtopic=58780
& VOLTRACK.VXD & KRNL386.EXE & other patches could not have elaborated!!!
I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a
relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
I am on business travel and do not have access to the computers that either
have the information I need to comment further or could possibly be used to
test any patch.
I firmly believe that running SCANDSKW alone is *not* sufficient to confirm
that a particular patch is working. I nearly filled a 160-Gbyte HDD with
large files using Windows Explorer and verified that *all* files, in
particular those located above 137 GByte, were correct and, most importantly,
that writing data to a location > 137 GByte did *not* overwrite data in a
location < 137 GByte and vice versa.
4.00.1111 for Windows 95 OSR2+ is now available for download. 4.00.1119 should be ready soon.
QUOTE
I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a
relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
Maybe my new code is just more efficient...
relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
Two questions:
First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?
Second, regarding data corruption above 137GB (please note I may be making fundamental wrong assumptions about how hard disk space is used, as a midlevel user, I'm assuming the space is at least sonewhat based on the physical layout of formatted partitions on a disk) -- is it a "safe" method to avoid this by partitioning a >137GB drive such that the total usable formatted portion of the drive is <137GB? Eg, I have a new 160GB drive, but since I don't need the space I have not installed any 46bit LBA patches/file versions, and it's currently configured (PartitionMagic 4.01) with three partitions, 32/32/62GB for a total of 126GB -- would this type of setup avoid >137 barrier corruption by making any "higher" space unusable?
THX JLJ
First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?
Second, regarding data corruption above 137GB (please note I may be making fundamental wrong assumptions about how hard disk space is used, as a midlevel user, I'm assuming the space is at least sonewhat based on the physical layout of formatted partitions on a disk) -- is it a "safe" method to avoid this by partitioning a >137GB drive such that the total usable formatted portion of the drive is <137GB? Eg, I have a new 160GB drive, but since I don't need the space I have not installed any 46bit LBA patches/file versions, and it's currently configured (PartitionMagic 4.01) with three partitions, 32/32/62GB for a total of 126GB -- would this type of setup avoid >137 barrier corruption by making any "higher" space unusable?
THX JLJ
QUOTE (LLXX @ Aug 2 2006, 02:10 AM)
4.00.1111 for Windows 95 OSR2+ is now available for download. 4.00.1119 should be ready soon.
QUOTE
I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a
relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
Maybe my new code is just more efficient...relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
REMOVE V4.00.1111 OF ESDI_506.PDR file, IMMEDIATELY! IT is FLAWED with power management bugs, UDMA bugs and other problems that are fixed with version 4.00.1116 of esdi_506.pdr from Q273468 & remideup.exe. Please patch ESDI_506.PDR files versions 4.00.1116 from Q273468 and 4.00.1118 from amdk6upd.exe and REMOVE 4.00.1111 of patched esdi_506.pdr OFF THIS SITE RIGHT AWAY.
<I will delete this post when ESDI_506.PDR 4.00.1111 48Bit LBA driver for Win95 OSR2 has been removed from this thread>
QUOTE (JLJ @ Aug 2 2006, 09:41 AM)
Two questions:
First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?
Second, regarding data corruption above 137GB (please note I may be making fundamental wrong assumptions about how hard disk space is used, as a midlevel user, I'm assuming the space is at least sonewhat based on the physical layout of formatted partitions on a disk) -- is it a "safe" method to avoid this by partitioning a >137GB drive such that the total usable formatted portion of the drive is <137GB? Eg, I have a new 160GB drive, but since I don't need the space I have not installed any 46bit LBA patches/file versions, and it's currently configured (PartitionMagic 4.01) with three partitions, 32/32/62GB for a total of 126GB -- would this type of setup avoid >137 barrier corruption by making any "higher" space unusable?
THX JLJ
First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?
Second, regarding data corruption above 137GB (please note I may be making fundamental wrong assumptions about how hard disk space is used, as a midlevel user, I'm assuming the space is at least sonewhat based on the physical layout of formatted partitions on a disk) -- is it a "safe" method to avoid this by partitioning a >137GB drive such that the total usable formatted portion of the drive is <137GB? Eg, I have a new 160GB drive, but since I don't need the space I have not installed any 46bit LBA patches/file versions, and it's currently configured (PartitionMagic 4.01) with three partitions, 32/32/62GB for a total of 126GB -- would this type of setup avoid >137 barrier corruption by making any "higher" space unusable?
THX JLJ
1) Theoretically up to a total of 2 TB of partitions per disk but as there is the 48bit LBA adressing bug in it, only 128 GB.
2) Yes.
QUOTE (JLJ @ Aug 2 2006, 05:41 PM)
Two questions:
First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?
ESDI_506.PDR driver has nothing to do with partitions and their sizes, this driver does low level access to the IDE/ATA disks. It receives sector number and required command (read/write/verify) and executes it. The sector number in Windows 9x is 32-bit number, one sector has 512 bytes and therefore the maximum addressable disk size is 2048 GiB = 2 TiB.First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?
I don't know what is the real maximum partition size in Windows 9x, I have successfuly tried 200 GB. Just Windows scandisk and defrag tools has to be used from Windows Me for partition sizes above 128 GiB.
QUOTE
Second, regarding data corruption above 137GB (please note I may be making fundamental wrong assumptions about how hard disk space is used, as a midlevel user, I'm assuming the space is at least sonewhat based on the physical layout of formatted partitions on a disk) -- is it a "safe" method to avoid this by partitioning a >137GB drive such that the total usable formatted portion of the drive is <137GB? Eg, I have a new 160GB drive, but since I don't need the space I have not installed any 46bit LBA patches/file versions, and it's currently configured (PartitionMagic 4.01) with three partitions, 32/32/62GB for a total of 126GB -- would this type of setup avoid >137 barrier corruption by making any "higher" space unusable?
Yes.
Petr
Version 4.00.1116 of Win95 ESDI_506.PDR file fixes these problems mentioned in SEVEN Microsoft KB articles:
http://support.microsoft.com/kb/153471/EN-US/
http://support.microsoft.com/kb/154435/EN-US/
http://support.microsoft.com/kb/154436/EN-US/
http://support.microsoft.com/kb/154976/EN-US/
http://support.microsoft.com/kb/160800/EN-US/
http://support.microsoft.com/kb/161642/EN-US/
http://support.microsoft.com/kb/171353/EN-US/
If Win95 users are using less than 4.00.1116 of esdi_506.pdr, please update to 4.00.1116 or higher to resolve these problems.
It's important to note that the 48bit LBA edition of esdi_506.pdr v4.00.1111 does NOT fix these problems. The problems were already in existence (before LLXX created the 48bit LBA driver for Win95) and MS fixed them starting with v4.00.1116 of the PDR file.
http://support.microsoft.com/kb/153471/EN-US/
http://support.microsoft.com/kb/154435/EN-US/
http://support.microsoft.com/kb/154436/EN-US/
http://support.microsoft.com/kb/154976/EN-US/
http://support.microsoft.com/kb/160800/EN-US/
http://support.microsoft.com/kb/161642/EN-US/
http://support.microsoft.com/kb/171353/EN-US/
If Win95 users are using less than 4.00.1116 of esdi_506.pdr, please update to 4.00.1116 or higher to resolve these problems.
It's important to note that the 48bit LBA edition of esdi_506.pdr v4.00.1111 does NOT fix these problems. The problems were already in existence (before LLXX created the 48bit LBA driver for Win95) and MS fixed them starting with v4.00.1116 of the PDR file.
QUOTE (erpdude8 @ Aug 2 2006, 05:46 PM)
QUOTE (LLXX @ Aug 2 2006, 02:10 AM)
4.00.1111 for Windows 95 OSR2+ is now available for download. 4.00.1119 should be ready soon.
QUOTE
I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a
relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
Maybe my new code is just more efficient...relevant command is sent to the HD controller and used the ATA-6 standards
and a manual from one of the largest HDD manufactures (Toshiba, Seagate or
WD, I forget which) to figure out how to patch. All I was looking for in
LLXX's patched file was whether *I* had *missed* code she found and patched.
However, I noticed from her patches (in a well-known location!) that she had
definitely patched *less* code than I did, that's all. If such unpatched
code is executed for a HDD that needs 48-bit LBA, data corruption is pretty
much guaranteed.
REMOVE V4.00.1111 OF ESDI_506.PDR file, IMMEDIATELY! IT is FLAWED with power management bugs, UDMA bugs and other problems that are fixed with version 4.00.1116 of esdi_506.pdr from Q273468 & remideup.exe. Please patch ESDI_506.PDR files versions 4.00.1116 from Q273468 and 4.00.1118 from amdk6upd.exe and REMOVE 4.00.1111 of patched esdi_506.pdr OFF THIS SITE RIGHT AWAY.
<I will delete this post when ESDI_506.PDR 4.00.1111 48Bit LBA driver for Win95 OSR2 has been removed from this thread>
I agree a little side note to this would help
I think LLXX just made a proof of concept. She is probably working on a 4.00.1119 version already.
erpdude8, should users avoid this "flawed" patch on Windows 95 systems with >137 GB disks, keep using their original driver and get aware of file corruption when they use their systems?
QUOTE (Petr @ Jul 29 2006, 06:20 AM)
I have created 137 GB disk as disk D, then filled it (Win95 OSR2.1 ESDI_506.PDR 4.00.1111) to 100 GB by some files with known MD5 sum, and then calculated the MD5 sums in Windows 95 environment - and everything was good.
It would be very good to know any examples of problems above 32 GiB barrier, I still believe that Mictosoft had some reason to write that KB article.
Petr
@erpdude8, see above. I also happen to be using 4.10.2222, the original Win98SE driver with no problems. 4.00.1119 is coming, there are just so many changes between these versions that I can't just copy+paste in a hex editor like I did with the 222*.
It would be very good to know any examples of problems above 32 GiB barrier, I still believe that Mictosoft had some reason to write that KB article.
Petr
I started to boot windows and got a BSOD:
QUOTE
Your mulitfunction device (Standard Dual PCI IDE controler) has some child devices useing 32bit drivers and some useing compatiblity mode drivers. this configuration is not supported...
so now my IDE controlers are stuck in 16 bit compatiblity mode. i restored the original esdi_506 file, i disabled my sata controler. is there something i need to do to make my sata drive work correctly?
ok, fixed all my 16 bit issues. now i have a question..
my sata disk doesnt even use the esdi_506.pdr driver. instead it uses a VIA driver that came on my mainboard cd. am i still effected by the 137 GB limit?
Nope! No problem for you. I ran 98SE for a while on my Sata 250GB drive with one big partition. The key is using the Sata bios and installing the Sata driver, in my case the Via SataRaid driver.
There are some motherboards that give you a choice in the Bios to run the Sata drives in IDE mode and not using the Sata Raid bios. This is great on XP/2000 as you get to use the newfangled Via IDE driver that is a bit zippier and lets you use Sata hard drives like USB, unplugging them when you want to switch. But that driver doesn't install the new stuff on 9x, only using the Microsoft ESDI driver.
So when using 9x that IDE feature (AMI doesn't have it, Award does) for Sata is bad, even though it still works. The Award bios creates a new IDE chain and Windows treats the Sata drive like an IDE drive.
I suppose one could use the new 48LBA patch and it might work though.
For you, no problem. You've got the Sata/Raid thing going so you're not using the Microsoft ESDI on the drive.
One problem for you. Windows Scan Disk and Defrag could wreck your setup if used on a drive bigger than 137GB. When I had this setup I used MSCONFIG advanced and checked to not run ScanDisk on bad shutdowns.
I also installed Norton Utilities 2002, as its Disk Doctor and Speed Disk ARE compatible with the bigger drives. I'm not sure what you could use as a substitute for ScanDisk if you don't have access to a 9x compatible version of Norton Utilities, but I think that as long as you don't use the full scan option you'd still be okay with Windows ScanDisk. It's the full scan that mucks up big drives.
Executive Software's Diskeeper is a good alternative for a substitute for Windows Defrag.
And certainly get the Windows Me versions of ScanDisk and Disk Defragmenter on there. They're faster than the 98SE one's.
If you install Norton Utilites or a 9x compatible SystemWorks, I'd advise using a custom install and unchecking the Undo Wizard stuff. That's the thing that installs the Norton Protected Recycle Bin. Although that can be emptied and disabled, it still can cause problems. And don't run anything like the System Doctor at startup. It runs in the background and keeps useless tabs on everything, slowing the system down. Disk Doctor and SpeedDisk are great though. That's all I used from the thing.
There are some motherboards that give you a choice in the Bios to run the Sata drives in IDE mode and not using the Sata Raid bios. This is great on XP/2000 as you get to use the newfangled Via IDE driver that is a bit zippier and lets you use Sata hard drives like USB, unplugging them when you want to switch. But that driver doesn't install the new stuff on 9x, only using the Microsoft ESDI driver.
So when using 9x that IDE feature (AMI doesn't have it, Award does) for Sata is bad, even though it still works. The Award bios creates a new IDE chain and Windows treats the Sata drive like an IDE drive.
I suppose one could use the new 48LBA patch and it might work though.
For you, no problem. You've got the Sata/Raid thing going so you're not using the Microsoft ESDI on the drive.
One problem for you. Windows Scan Disk and Defrag could wreck your setup if used on a drive bigger than 137GB. When I had this setup I used MSCONFIG advanced and checked to not run ScanDisk on bad shutdowns.
I also installed Norton Utilities 2002, as its Disk Doctor and Speed Disk ARE compatible with the bigger drives. I'm not sure what you could use as a substitute for ScanDisk if you don't have access to a 9x compatible version of Norton Utilities, but I think that as long as you don't use the full scan option you'd still be okay with Windows ScanDisk. It's the full scan that mucks up big drives.
Executive Software's Diskeeper is a good alternative for a substitute for Windows Defrag.
And certainly get the Windows Me versions of ScanDisk and Disk Defragmenter on there. They're faster than the 98SE one's.
If you install Norton Utilites or a 9x compatible SystemWorks, I'd advise using a custom install and unchecking the Undo Wizard stuff. That's the thing that installs the Norton Protected Recycle Bin. Although that can be emptied and disabled, it still can cause problems. And don't run anything like the System Doctor at startup. It runs in the background and keeps useless tabs on everything, slowing the system down. Disk Doctor and SpeedDisk are great though. That's all I used from the thing.
QUOTE (janus zeal @ Aug 3 2006, 03:05 PM)
ok, fixed all my 16 bit issues. now i have a question..
my sata disk doesnt even use the esdi_506.pdr driver. instead it uses a VIA driver that came on my mainboard cd. am i still effected by the 137 GB limit?
It depends on the driver. Most of the newer ones should be fine. The best way is to do the test - copy 137+ Gb of data to the drive and see if any corruption happens.
my sata disk doesnt even use the esdi_506.pdr driver. instead it uses a VIA driver that came on my mainboard cd. am i still effected by the 137 GB limit?
4.00.1119 for Windows 95OSR2+ is now available.
Comments, test results, etc. are welcome
Comments, test results, etc. are welcome
QUOTE (LLXX @ Aug 4 2006, 11:31 AM)
4.00.1119 for Windows 95OSR2+ is now available.
Comments, test results, etc. are welcome
Comments, test results, etc. are welcome
Thank you very much for this Windows 95 OSR2 version.
Now noone has to experience File corruption on any Windows 9x OS (Windows 95 < OSR2 isn't) in combination with Big HDD's anymore!!!
P.S. You definetely outperformed Loew's commercial patch. It is not available for Windows 95
QUOTE (hp38guser @ Aug 4 2006, 04:39 AM)
P.S. You definetely outperformed Loew's commercial patch. It is not available for Windows 95
What's next... Windows 3.11? I think it had its own direct-access (32-bit mode) HDD driver...BTW, DOS 7.1 *does* support 48bitLBA via Int13x.
QUOTE (LLXX @ Aug 4 2006, 05:24 AM)
QUOTE (hp38guser @ Aug 4 2006, 04:39 AM)
P.S. You definetely outperformed Loew's commercial patch. It is not available for Windows 95
What's next... Windows 3.11? I think it had its own direct-access (32-bit mode) HDD driver...BTW, DOS 7.1 *does* support 48bitLBA via Int13x.
xD if you get windows 3.11 to support 137+ GB disks i will use it
I just found out the Windows 3.11 DDK (Driver Development Kit) contains the complete source code of the WDCTRL.386 HDD driver. This should make it easy to implement some new features
(Google "Windows 3.11 ddk" to find the download.)
(Google "Windows 3.11 ddk" to find the download.)
Mini-Windows 3.2 + MS-DOS 7.1 does support 137+Gb disks, so the problem didn't exist in the first place
Enable48bitLBA project is now finalised. Someone should stick this thread.
Enable48bitLBA project is now finalised. Someone should stick this thread.
QUOTE (LLXX @ Aug 8 2006, 10:45 PM)
Enable48bitLBA project is now finalised. Someone should stick this thread.
I vist the 9x subforum mainly to be able to provide support for other people I know who use 9x. I rarely use it myself anymore..
Still.. Had to step in and say congrats and awsome work..
PM Gape to make it sticky.
as in:
Unofficial Win98 SE Service Pack
Unofficial Win98 SE Service Pack Forum
Forum Led by: Gape
as in:
Unofficial Win98 SE Service Pack
Unofficial Win98 SE Service Pack Forum
Forum Led by: Gape
nice that version 4.00.1119 of esdi_506.pdr is posted but 4.00.1111 is still there which is almost infuriating 
4.00.1111 SHOULD HAVE BEEN REMOVED and should be REPLACED with either 4.00.1116 or 4.00.1118 as 4.00.1111 is BUGGY and causes some UDMA hard drives to hang or malfunction in Win95.
Found out the REAL reason why I couldnt use the 40Gb HD on my custom made PC which used to have Win95B. It was a bad motherboard (a Jetway 600-series mobo with SiS chipsets) with leaking capacitors. My brother and I replaced it with a DFI brand mobo (with VIA chipsets) a few days ago. Now tested the 40Gb with the DFI mobo and Win95B and things went smoothly [and Win95B loaded lightning fast]. But we decided to put WinXP on there since we do use some apps that require XP.
4.00.1111 SHOULD HAVE BEEN REMOVED and should be REPLACED with either 4.00.1116 or 4.00.1118 as 4.00.1111 is BUGGY and causes some UDMA hard drives to hang or malfunction in Win95.
Found out the REAL reason why I couldnt use the 40Gb HD on my custom made PC which used to have Win95B. It was a bad motherboard (a Jetway 600-series mobo with SiS chipsets) with leaking capacitors. My brother and I replaced it with a DFI brand mobo (with VIA chipsets) a few days ago. Now tested the 40Gb with the DFI mobo and Win95B and things went smoothly [and Win95B loaded lightning fast]. But we decided to put WinXP on there since we do use some apps that require XP.
I'm leaving 4001111 there, whatever bugs it has only affects *some* systems and it works fine on others.
Likewise I'm still using 4102222 on my Win98SE system, have yet to encounter any problems.
Likewise I'm still using 4102222 on my Win98SE system, have yet to encounter any problems.
Update: I have emailed 48bitlba.com and informed them of these Drivers, and the issue regarding Windows 95 and >32Gb.
BTW: http://www.google.ca/search?hl=en&ie=I...itlba&meta=
BTW: http://www.google.ca/search?hl=en&ie=I...itlba&meta=
Any plans on making an all-in-one installer that detects the windows version and installs the correct patched file?
No. You mean you don't even know what version of Windows you're using?
If you know enough to know about this problem, you should know which driver to install.
If you know enough to know about this problem, you should know which driver to install.
QUOTE (LLXX @ Jul 15 2006, 07:02 AM)
If a device conforms to an earlier Standard (in which case LBA support is Optional), its capacity is unlikely to exceed 32Gb in any case. I doubt there were 32Gb IDE devices being produced in 1996.
I doubt that there was anything bigger than 8 GB.
They would be unlikely to exceed 8 GB.
QUOTE (krick @ Aug 16 2006, 01:15 PM)
Any plans on making an all-in-one installer that detects the windows version and installs the correct patched file?
LLXX:IMHO:
This sounds like a good idea.
If you can do it, that is.
Basically, such a patch would:
1. detect the version/build installed
2. backup the original file
3. patch the orginal file
4. reboot.
Example:
UXTHEME.DLL patcher is a universal patcher which modifies this XP/2003/MCE DLL to be able to use themes without having to purchase WindowsBlinds or other 3rd party tools. Can patch all versions of the DLL, including XP RTM, XP SP1, XP SP2, XP Post-SP2 hotfix Q319740, 2003 RTM, 2003 SP1, MCE 2004, MCE 2005, Vista beta 1 etc.
It can be found here:
http://www.softpedia.com/get/System/OS-Enh...tiPatcher.shtml
WindowsX is the author.
Another example of a multipatcher is LvlLord's TCPIP.SYS patcher for Windows XP/2003 [increases the number of concurrent TCP connections, otherwise limited by M$ in the original driver]:
http://www.lvllord.de/?url=tools
Thanks for listening.
I may consider it.
It seems that the driver file is not locked and can be replaced while Windows is running
It seems that the driver file is not locked and can be replaced while Windows is running
QUOTE (LLXX @ Aug 17 2006, 11:52 PM)
It seems that the driver file is not locked and can be replaced while Windows is running
Could it be that Windows loads a copy in memory and uses THAT to access the drives? It will need a reboot, anyway. It is just an hypothesis, I'm just wondering...
Now that the 137gb barrier is down[kudos to LLXX] & large HDDs are possible, I have a question about drive lettering. Can we go beyond the normal C-Z, will windows assign any others or is this another wall to climb?
What, 26 drives isn't enough?
The standard PC can only have 4 hard drives, up to 2Tb each.
I doubt a Win98se user would need 8 terabytes of on-line storage anyway!
The standard PC can only have 4 hard drives, up to 2Tb each.
I doubt a Win98se user would need 8 terabytes of on-line storage anyway!
How about some driver/patch/utility to help create files larger than 4GB? I know FAT32 doesn't support them but maybe some program can be created to join several pieces 4GB in size into one virtual file that can be read/written by programs even beyond 4 GB limit.
That would be rather difficult, but first there is a 2Gb barrier in copying files that has to be fixed first.
I will attempt to fix problem described in http://support.microsoft.com/?id=318293 by patching a shell32.dll.
It should not be too difficult as this is just a standard programming error of using signed instead of unsigned comparisons (the programmer must've thought files could have negatives sizes )
I will attempt to fix problem described in http://support.microsoft.com/?id=318293 by patching a shell32.dll.
It should not be too difficult as this is just a standard programming error of using signed instead of unsigned comparisons (the programmer must've thought files could have negatives sizes
)
LLXX
the_guy
erpdude8:
Here are the answers of the anonymous author of several unofficial 9x/ME patches to your comments/questions/requests:
the_guy
erpdude8:
Here are the answers of the anonymous author of several unofficial 9x/ME patches to your comments/questions/requests:
QUOTE
Here are my answers now, at last.
On August 2, 2006 (03:38 PM) 'the_guy' wrote:
> On the note of the GDI fix for 918547 posted today, would you be able to get the author to make a patch for 98FE?
> Also, could you try to make the patched 98FE and the patched 98SE > (4.10.2225) ESDI_506.PDR in 1 file, and then
> rename the file with ESDI_506.PDR 4.10.2226 to SE48BLBA.EXE?
> Slightly O/T: Would you be able to contact the author of the unofficial 918547 patch to see if they could
> patch user.exe and user32.dll to prevent the 891711 flaw.
On August 2, 2006 (04:25 PM) 'erpdude8' wrote:
> hmm, looks like the author of 918547 will need to patch the 98fe GDI files.
It is highly unlikely I will have the time to create separate patches for Win98FE. The code in GDI.EXE 4.10.2002 is arranged differently, so the patches would have to be rewritten (no simple cut & paste operation in a hex editor here). However, there appear to be no differences in functionality between 4.10.2002 and 4.10.2225, so I suggest using 4.10.2227 under Win98FE. If someone finds a difference in functionality, please let me know.
For several reasons, it is very unlikely I will create patches for USER.EXE amd USER32.DLL in the near future (or possibly ever):
(1) U891711 is not an elegant solution, but indeed provides complete protection against the vulnerabilities whereas KB919547 and U919547 protect only one way of rendering a WMF record. GDI.EXE & GDI32.DLL had to be patched to ensure all ways of rendering a WMF record were protected.
(2) It is very time consuming to create the patches as 1-2 KBytes of extra code have to be added to USER.EXE.
(3) As Petr pointed out (as a matter of fact, only for Win98SE), there are the following versions of USER.EXE:
4.10.2000 original Windows 98 FE
4.10.2001 Q291362
4.10.2222 original Windows 98 SE
4.10.2223 Q242934
4.10.2225 Q258070
4.10.2226 Q242975-v2
4.10.2227 Q260067
4.10.2228 Q262830
4.10.2229 Q265115
4.10.2230 Q277822
4.10.2231 Q291362
4.90.3000 original Windows ME
4.90.3001 Q280800
and each version would have to be patched individually. Which version should have the highest priority to be patched??? All versions of USER.EXE have bugs and it would be more important, but probably extremely challenging to fix those than adding code for KB891711 or fixing the purely "cosmetic" bug of a ghost screensaver taskbar entry. One of these bugs causes a permanent memory leak in the 16-bit USER resources when a user logs off.
I very rarely use Win98SE these days, but if I do, I run a modified version of 4.90.3001 under Win98SE (apparently w/o the issues I described in an earlier message re the original 4.90.3001 under 982ME).
On Aug 2 2006, 01:10 AM, LLXX wrote:
> Maybe my new code is just more efficient...
It all depends on the definition of efficiency!
--
I took another quick look at LLXX's patched ESDI_506.PDR. As before, I looked only at 4.90.3000 since it is closer than 4.10.2225 to what I have been using under Win98SE.
When I examined the patch, I first looked at extra code added between 00001E54 and 00001FFF. I was unable to find the instructions that are needed to set the 16-bit sector count correctly. Closer examination revealed that they are there indeed, but they "replace" the 8 NOP instructions that, in the original driver, were placed between commands sending data to two different HDC registers. I assume those 8 NOPs had been put there for a good reason. It is common code and may be executed immaterial whether the drive uses CHS translation, 28-bit LBA or 48-bit LBA. So LLXX's statement that there are no differences for < 128 GiBytes is not correct!! There are some NOP instructions between sending the higher and lower bytes of the sector count, but I am not sure they are necessary.
LLXX's added code presumes that the commands are always Read/Write Sectors Extended, but I now think this should be okay. There are two more items, probably minor or irrelevant, and I will comment on them when I have had a chance to test out a few things with my driver (unfortunately not anytime soon).
I wrote this before: LLXX's patched driver is a very nice piece of work! Keep up the good work!!!
Best wishes.
Hope this helps.
On August 2, 2006 (03:38 PM) 'the_guy' wrote:
> On the note of the GDI fix for 918547 posted today, would you be able to get the author to make a patch for 98FE?
> Also, could you try to make the patched 98FE and the patched 98SE > (4.10.2225) ESDI_506.PDR in 1 file, and then
> rename the file with ESDI_506.PDR 4.10.2226 to SE48BLBA.EXE?
> Slightly O/T: Would you be able to contact the author of the unofficial 918547 patch to see if they could
> patch user.exe and user32.dll to prevent the 891711 flaw.
On August 2, 2006 (04:25 PM) 'erpdude8' wrote:
> hmm, looks like the author of 918547 will need to patch the 98fe GDI files.
It is highly unlikely I will have the time to create separate patches for Win98FE. The code in GDI.EXE 4.10.2002 is arranged differently, so the patches would have to be rewritten (no simple cut & paste operation in a hex editor here). However, there appear to be no differences in functionality between 4.10.2002 and 4.10.2225, so I suggest using 4.10.2227 under Win98FE. If someone finds a difference in functionality, please let me know.
For several reasons, it is very unlikely I will create patches for USER.EXE amd USER32.DLL in the near future (or possibly ever):
(1) U891711 is not an elegant solution, but indeed provides complete protection against the vulnerabilities whereas KB919547 and U919547 protect only one way of rendering a WMF record. GDI.EXE & GDI32.DLL had to be patched to ensure all ways of rendering a WMF record were protected.
(2) It is very time consuming to create the patches as 1-2 KBytes of extra code have to be added to USER.EXE.
(3) As Petr pointed out (as a matter of fact, only for Win98SE), there are the following versions of USER.EXE:
4.10.2000 original Windows 98 FE
4.10.2001 Q291362
4.10.2222 original Windows 98 SE
4.10.2223 Q242934
4.10.2225 Q258070
4.10.2226 Q242975-v2
4.10.2227 Q260067
4.10.2228 Q262830
4.10.2229 Q265115
4.10.2230 Q277822
4.10.2231 Q291362
4.90.3000 original Windows ME
4.90.3001 Q280800
and each version would have to be patched individually. Which version should have the highest priority to be patched??? All versions of USER.EXE have bugs and it would be more important, but probably extremely challenging to fix those than adding code for KB891711 or fixing the purely "cosmetic" bug of a ghost screensaver taskbar entry. One of these bugs causes a permanent memory leak in the 16-bit USER resources when a user logs off.
I very rarely use Win98SE these days, but if I do, I run a modified version of 4.90.3001 under Win98SE (apparently w/o the issues I described in an earlier message re the original 4.90.3001 under 982ME).
On Aug 2 2006, 01:10 AM, LLXX wrote:
> Maybe my new code is just more efficient...
It all depends on the definition of efficiency!
--
I took another quick look at LLXX's patched ESDI_506.PDR. As before, I looked only at 4.90.3000 since it is closer than 4.10.2225 to what I have been using under Win98SE.
When I examined the patch, I first looked at extra code added between 00001E54 and 00001FFF. I was unable to find the instructions that are needed to set the 16-bit sector count correctly. Closer examination revealed that they are there indeed, but they "replace" the 8 NOP instructions that, in the original driver, were placed between commands sending data to two different HDC registers. I assume those 8 NOPs had been put there for a good reason. It is common code and may be executed immaterial whether the drive uses CHS translation, 28-bit LBA or 48-bit LBA. So LLXX's statement that there are no differences for < 128 GiBytes is not correct!! There are some NOP instructions between sending the higher and lower bytes of the sector count, but I am not sure they are necessary.
LLXX's added code presumes that the commands are always Read/Write Sectors Extended, but I now think this should be okay. There are two more items, probably minor or irrelevant, and I will comment on them when I have had a chance to test out a few things with my driver (unfortunately not anytime soon).
I wrote this before: LLXX's patched driver is a very nice piece of work! Keep up the good work!!!
Best wishes.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.