[LLXX]

krick, on Jul 21 2006, 10:14 AM, said:

I know I'm probably too late here but I think it would be better to change the version numbers like this...

4.10.2222 -> 4.10.2232
4.10.2223 -> 4.10.2233
4.10.2224 -> 4.10.2234
4.10.2225 -> 4.10.2235
4.10.2226 -> 4.10.2236

Two reasons:

1) there might actually be a 2227 or higher build in the wild that we don't know about so jumping by 10 leaves a gap for safety.
2) the last digit stays the same so you can easily tell what the original version was

Just for reference, there's a wiki page on microsoft version numbering...
http://en.wikipedia...._Version_Number

I've searched the internets, there is no official ESDI_506.PDR version 4.10.2227. That version number is currently used for the fixed 4.10.2222. Fixed version of 4.10.2225 will be 4.10.2230. Adding 5 to the version number isn't that confusing...

BTW I've also fixed 4.10.2001 (Windows 98FE). I haven't found 4.10.2186 yet.

(Someone may want to provide more information on First Edition versioning so an appropriate scheme for the new files can be implemented.)

This post has been edited by LLXX: 21 July 2006 - 02:34 PM

[the_guy]

version 4.10.2186 is included with kb243450. Direct Download Link here.

Also, I know 4.10.2222 patched is 4.10.2227. Why not make 4.10.2225 patched 4.10.2228? Also, the 98FE version should be made 4.10.2187. Just my opinion.

the_guy

[Petr]

LLXX, on Jul 21 2006, 10:30 PM, said:

I've searched the internets, there is no official ESDI_506.PDR version 4.10.2227. That version number is currently used for the fixed 4.10.2222. Fixed version of 4.10.2225 will be 4.10.2230. Adding 5 to the version number isn't that confusing...

It is extremely confusing because all Microsoft hotfixes are cumulative, it means higher minor version number contains all fixes from the lower version number. The proposed numbering breaks this rule. See
General information about Windows 98 and Windows 98 Second Edition hotfixes

Quote

Multiple fixes can be applied to the same component. With a few rare exceptions, these fixes are always cumulative. A change implemented in a given version of a particular component is also included in later versions of that component, along with any additional change implemented in the later versions. (For example, version 4.10.2224 is going to contain the change implemented in version 4.10.2223, as well as the new change.)

The cumulative nature of these changes, combined with the incremented version numbers, means that, with very few exceptions, there is always one current version of a given component that contains all fixes made to that component to date.

General information about Windows Millennium Edition hotfixes
contains the same statement.

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.

But - it is nice to discuss about the version numbers but nobody verified 100% functionality on different disks and with different chipsets yet. This is much more important.

Petr

This post has been edited by Petr: 22 July 2006 - 02:53 AM

[Acheron]

Petr, on Jul 22 2006, 10:46 AM, said:

LLXX, on Jul 21 2006, 10:30 PM, said:

I've searched the internets, there is no official ESDI_506.PDR version 4.10.2227. That version number is currently used for the fixed 4.10.2222. Fixed version of 4.10.2225 will be 4.10.2230. Adding 5 to the version number isn't that confusing...

It is extremely confusing because all Microsoft hotfixes are cumulative, it means higher minor version number contains all fixes from the lower version number. The proposed numbering breaks this rule. See
General information about Windows 98 and Windows 98 Second Edition hotfixes

Quote

Multiple fixes can be applied to the same component. With a few rare exceptions, these fixes are always cumulative. A change implemented in a given version of a particular component is also included in later versions of that component, along with any additional change implemented in the later versions. (For example, version 4.10.2224 is going to contain the change implemented in version 4.10.2223, as well as the new change.)

The cumulative nature of these changes, combined with the incremented version numbers, means that, with very few exceptions, there is always one current version of a given component that contains all fixes made to that component to date.

General information about Windows Millennium Edition hotfixes
contains the same statement.

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.

But - it is nice to discuss about the version numbers but nobody verified 100% functionality on different disks and with different chipsets yet. This is much more important.

Petr

I don't agree about Version numbering not being first priority. We must assist that we don't get any confusing numbering in testing phase.

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

About testing. I'm already backing up my stuff right now, before I can run some tests on my system with 250 GB UDMA-6 HDD.

[Kelsenellenelvian]

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?

[Petr]

hp38guser, on Jul 22 2006, 11:57 AM, said:

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

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, on Jul 22 2006, 04:14 AM, said:

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]

Quote

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]

Petr, on Jul 22 2006, 08:46 AM, said:

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.

This post has been edited by bristols: 22 July 2006 - 07:17 AM

[Petr]

Kelsenellenelvian, on Jul 22 2006, 12:14 PM, said:

#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.micro...spx?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

This post has been edited by Petr: 22 July 2006 - 09:15 AM

[LLXX]

Quote

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.

This post has been edited by LLXX: 22 July 2006 - 03:53 PM

[eidenk]

Petr, on Jul 22 2006, 09:13 AM, said:

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.

[n7Epsilon]

I think Petr was referring to Fdisk, that works independently in DOS without using ESDI_506.PDR.

[LLXX]

Petr, on Jul 22 2006, 10:13 AM, said:

Kelsenellenelvian, on Jul 22 2006, 12:14 PM, said:

#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.micro...spx?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

Quote

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]

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/...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/...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/...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/...showtopic=46581

Keep up the good work.

[maximus-decim]

LLXX - thanks
**********************************************
In advance I apologize, if has broken the rights someone
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...hdd20e.zip.html

This post has been edited by maximus-decim: 23 July 2006 - 05:03 AM

[Acheron]

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?

This post has been edited by hp38guser: 23 July 2006 - 02:15 AM

[awergh]

95 supports FAT32, i have installed 95B on FAT32 many times

[Petr]

hp38guser, on Jul 23 2006, 10:14 AM, said:

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]

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?