Jump to content

Enable48BitLBA | Break the 137Gb barrier!


Recommended Posts

I didn't know about the extra digit that could also get placed before the buildnumber. I definetely vote for this numbering method :thumbup

There are two occurences of the vesrion number in the version resource.

The first is string type and there may be written anything, including any text details about the build, for example hhctrl.ocx has "5.2.3790.1830 (srv03_sp1_rtm.050324-1447)" in this field, and standard Windows 98 SE files have 4.10.2222 here. Maybe we can have here something like "4.10.2227 (LLXX 060722-0001)" to identify clearly the origin and detail version of the file - I think there may be many different builds of the same file.

The second is binary version number and it consists from 4 16-bit number, it means this version number may be in the range 0.0.0.0 - 65535.65535.65335.65335. Standard Windows 98 SE files have 4.10.0.2222 here.

Strange thing is with Windows Me files, most files have binary version number 4.90.0.3000 but some of them don't follow this rule:

4.90.3001.0	1394BUS.SYS
4.90.3001.0 ARP1394.SYS
4.90.3001.0 ATMUNI.SYS
4.90.3001.0 IPHLPAPI.DLL
4.90.3001.0 PORTCLS.SYS
4.90.3001.0 SYSAUDIO.SYS
4.90.3001.0 USBAUDIO.SYS
4.90.3002.0 HIDSERV.EXE
4.90.3002.0 SBP2PORT.SYS
4.90.3002.0 USBHUB.SYS
4.90.3002.0 WIASERVC.DLL
4.90.3003.0 61883.SYS
4.90.3003.0 SSDPAPI.DLL
4.90.3003.0 SSDPSRV.EXE
4.90.3003.0 UPNP.DLL
4.90.3004.0 OHCI1394.SYS

but most of the files in mesp follow the a.m. rule:

4.90.0.3000	VNETBIOS.VXD
4.90.0.3001 CCPORT.SYS
4.90.0.3001 CDFS.VXD
4.90.0.3001 DISKVSD.VXD
4.90.0.3001 DOSMGR.VXD
4.90.0.3001 GDI.EXE
4.90.0.3001 GDI32.DLL
4.90.0.3001 HSFLOP.PDR
4.90.0.3001 IRENUM.VXD
4.90.0.3001 MARSCORE.DLL
4.90.0.3001 MMSYS.CPL
4.90.0.3001 MSConfig.exe
4.90.0.3001 NETDI.DLL
4.90.0.3001 NETPPTP.SYS
4.90.0.3001 PPPATM.SYS
4.90.0.3001 RT.SYS
4.90.0.3001 SCSIPORT.PDR
4.90.0.3001 SYSDM.CPL
4.90.0.3001 SYSTEM.DRV
4.90.0.3001 UDF.VXD
4.90.0.3001 USBMON.DLL
4.90.0.3001 USER.EXE
4.90.0.3001 USER32.DLL
4.90.0.3001 VFAT.VXD
4.90.0.3001 VKD.VXD
4.90.0.3002 CONFIGMG.VXD
4.90.0.3002 KMIXER.SYS
4.90.0.3002 PCCARD.VXD
4.90.0.3002 SERENUM.VXD
4.90.0.3002 SYSTRAY.EXE
4.90.0.3002 VSERVER.VXD
4.90.0.3003 ACPI.SYS
4.90.0.3003 CBSS.VXD
4.90.0.3003 CDVSD.VXD
4.90.0.3003 IFSMGR.VXD
4.90.0.3003 NWLINK.VXD
4.90.0.3003 PCI.VXD
4.90.0.3003 SMgr.dll
4.90.0.3003 VMOUSE.VXD
4.90.0.3003 WDMAUD.SYS
4.90.0.3004 HCUPDATE.EXE
4.90.0.3004 HelpCtr.exe
4.90.0.3004 IOS.VXD
4.90.0.3004 PCHSETUP.EXE
4.90.0.3005 NTKERN.VXD
4.90.0.3007 VPOWERD.VXD
4.90.0.3007 VREDIR.VXD

There in no similar confusion for Windows 98 and 98SE - with one exception only:

4.10.2223.0	RNR20.DLL

Petr

Link to comment
Share on other sites


Couple of stupid question but here goes:

#1 What driver version is for 98se?

#2 Is this meant to be integrated into the source?

#3 How can I address the issue in fdisk where there is a limit of @8gigs?

Never mind I figured out all 3

#1 had to download 3 packs but I got the right one.

#2 Yup it sure is integrate-able.

#3 SuperFdisk!!! w00t!

I now have a win98 installed on a 200 gig drive from the beginning!

What would be the QUICKEST way to fill 130 gigs of space?

Link to comment
Share on other sites

What would be the QUICKEST way to fill 130 gigs of space?

Copy stuff over until you reach this point. I usually do tar nearly 2GB of files and then copy it over until I reach the limit I want.

Unfortunately I can't test myself ATM.

Link to comment
Share on other sites

My suggestion is to modify version 4.10.2225 only (forget about 4.10.2222, nobody needs it), and name it 4.10.1.2225. 4.10.2226 could be 4.10.1.2226 if anybody needs it. 4.10.2186 could be 4.10.1.2186 and 4.90.3000 could be 4.90.1.3000.

This would clearly indicate different versions branch for drivers with LLXX's patch.

FWIW, I too vote for this method of numbering LLXX's patch. Of all the schemes suggested so far, it is the least presumptuous, the least complicated and the least confusing, given the number of versions ESDI_506.PDR being patched and renumbered (when I say the "least presumptuous", I mean that if an official 4.10.2227 did show up [not likely, I know], then this method easily deals with it and avoids replicated numbering).

At the same time, this method clearly sets apart LLXX's patches from the official versions, but also produces no uncertainty about which patch corresponds to which official version. As Petr again pointed out, maybe the string type field can be used by LLXX to add some kind of identification for his patches, too.

LLXX - thanks, I can't wait to try it. You've done 9x a great turn. :)

Edited by bristols
Link to comment
Share on other sites

#3 How can I address the issue in fdisk where there is a limit of @8gigs?

Here you can find corrected version of FDISK http://support.microsoft.com/Default.aspx?kbid=263044. I have tried it with 250 GB disk, it works but has a display bug for disks and partitions bigger than 99 GB.

Or you can use any 3rd part too, I use Ranish Partition Manager.

Petr

Edited by Petr
Link to comment
Share on other sites

As Petr again pointed out, maybe the string type field can be used by LLXX to add some kind of identification for his patches, too.
You mean her patches :)

Actually I don't really care about the versioning system, IMHO I don't think it's that important. What's more important is verifying that it actually works correctly.

Use this FDISK replacement : http://www.23cc.com/free-fdisk/ (ignore the "works on hard disks up to 128Gb" statement... it supports 48-bit LBA via Int13ext)

Windows 9x's disk tools such as Scandisk and Defrag are limited to 128Gb partition sizes. As such, here is a recommended test procedure, to be done on a clean drive.

1. Make several partitions, each less than or equal to 128Gb.

2. Format and install Windows on the primary partition. Replace the ESDI_506.PDR with the fixed version.

3. Copy a large file as many times as necessary to fill the entire drive.

4. Run scandisk on each partition to verify that the data is intact.

Also, 4.10.2186 has been fixed.

Edited by LLXX
Link to comment
Share on other sites

I have tried it with 250 GB disk, it works but has a display bug for disks and partitions bigger than 99 GB.

How is that possible ? With a normal esdi, 110 GB should display properly, isnt'it ?

And from what I grasped anything below 128 GB should behave just as normal with the LLXX patches.

Link to comment
Share on other sites

#3 How can I address the issue in fdisk where there is a limit of @8gigs?

Here you can find corrected version of FDISK http://support.microsoft.com/Default.aspx?kbid=263044. I have tried it with 250 GB disk, it works but has a display bug for disks and partitions bigger than 99 GB.

Or you can use any 3rd part too, I use Ranish Partition Manager.

Petr

NOTE: This hotfix is not designed for 48-bit logical block addressing (LBA) hard disks, and it is not supported on hard disks larger than 137 GB.
That's what M$'s description of the hotfix says. "not supported" must mean untested, not doesn't work...
Link to comment
Share on other sites

Created iexpress installers for 98 FE 2186, 98 SE 2225 + ME:

Fix below also here:

http://www.mdgx.com/web.htm#MEU

* Unofficial Windows ME 48-bit LBA (Logical Block Addressing) > 137 GB (E)IDE/ATAPI Hard Disk Driver ESDI_506.PDR 4.90.3000 Fix:

http://www.msfn.org/board/?showtopic=78592

Direct download [148 KB, English]:

http://www.mdgx.com/files/ME48BLBA.EXE

Fix below also here:

http://www.mdgx.com/web.htm#9SU

* Unofficial Windows 98 SE 48-bit LBA (Logical Block Addressing) > 137 GB (E)IDE/ATAPI Hard Disk Driver ESDI_506.PDR 4.10.2225 Fix:

http://www.msfn.org/board/?showtopic=78592

Direct download [80 KB, English]:

http://www.mdgx.com/files/48BITLBA.EXE

Fix below also here:

http://www.mdgx.com/web.htm#W98

* Unofficial Windows 98 48-bit LBA (Logical Block Addressing) > 137 GB (E)IDE/ATAPI Hard Disk Driver ESDI_506.PDR 4.10.2186 Fix:

http://www.msfn.org/board/?showtopic=78592

Direct download [80 KB, English]:

http://www.mdgx.com/files/9848BLBA.EXE

These updates will be added to this list soon:

http://www.msfn.org/board/?showtopic=46581

Keep up the good work.

Link to comment
Share on other sites

LLXX - thanks :thumbup

**********************************************

In advance I apologize, if has broken the rights someone :blushing:

BigHDD 2.0

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

Include:

esdi_506.pdr - LLXX version 4.10.2225 (up to version 4.10.2230)

defrag.exe - Windows Me

dskmaint.dll - Windows Me

scandskw.exe - Windows Me

format.exe - Free Format 0.91v

fdisk.exe - Free Fdisk 1.21

Documentations and Installation

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

English: http://rapidshare.de/files/26697545/bhdd20e.zip.html

Edited by maximus-decim
Link to comment
Share on other sites

What about esdi_506.pdr included with Windows 95?

If patching is not very difficult it would be great to create also a Windows 95 patch. There might be some hobbyists still using Windows 95. Does Windows 95 support FAT32 anyway?

Edited by hp38guser
Link to comment
Share on other sites

Does Windows 95 support FAT32 anyway?

Windows 95 retail version and original OEM version (4.00.950, with DOS 7.0) does not support FAT32.

FAT32 is supported in OEM Service Release 2 version and later (4.00.1111, with DOS 7.1).

The original OSR2 ESDI_506.PDR file has version number 4.00.1111, some newer files have versions:

Q171353 4.00.1116

Q192841 4.00.1118

Q175629 4.00.1119 (support of > 8 GB)

More details here:

Windows Support for Large IDE Hard Disks

Petr

Link to comment
Share on other sites

If you could give me a link to 4.10.1119 then I'll try to fix it...

the one I have from my Win95b distro is 4.10.1111

The driver structure changed greatly between 95 and 98 (and again with ME), so this is going to take moar time to implement... but I will do it :)

Any test results yet?

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