Jump to content

Enable48BitLBA | Break the 137Gb barrier!

LLXX

By LLXX
in Windows 9x Member Projects

 Share

Recommended Posts

Petr

Petr

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


Kelsenellenelvian

Kelsenellenelvian

Posted
Posted
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?

eidenk

eidenk

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

bristols

bristols

Posted
Posted (edited)
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
LLXX

LLXX

Posted
  • Author
Posted (edited)
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
eidenk

eidenk

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

LLXX

LLXX

Posted
  • Author
Posted

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

MDGx

Posted
Posted

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.

maximus-decim

maximus-decim

Posted
Posted (edited)

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
Acheron

Acheron

Posted
Posted (edited)

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
Petr

Petr

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

LLXX

LLXX

Posted
  • Author
Posted

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?

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
 Share
Go to topic listing

  • Recently Browsing   0 members

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