Jump to content

Enable48BitLBA | Break the 137Gb barrier!


Recommended Posts

nice that version 4.00.1119 of esdi_506.pdr is posted but 4.00.1111 is still there which is almost infuriating :realmad:

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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

It seems that the driver file is not locked and can be replaced while Windows is running :o

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

Link to comment
Share on other sites

What, 26 drives isn't enough? :blink:

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! :lol:

Edited by LLXX
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :lol: )

Link to comment
Share on other sites

LLXX

the_guy

erpdude8:

Here are the answers of the anonymous author of several unofficial 9x/ME patches to your comments/questions/requests:

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! :D

--

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.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...