Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.Login to AccountCreate an Account

Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

MDGx

Posted 20 July 2006 - 12:01 PM

MDGx

98SE2ME + 98MP10

Patrons

2,365 posts

Joined 22-November 04

Thanks for the info, guys.

I did notice the 4.0b change, but that's only for internal use, the actual iexpress INF update won't take in account the product version, only the file version.Edit:The product version should not be changed, 4.0 means the Win95/98/ME/NT4 line of OSes.There is no such thing as 4.0b WinOS.2000 is product line 5.0, XP/2003 is 5.1 and Vista will probably be 5.2 or 6.0 [?].

And the file version must always be newer [larger number] than the previous release [M$ came up with that rule], so the INF installer can overwrite the older file with the newer one.

IMHO, I strongly recommend to use 4.10.2225 [the most compatible so far, and already has all up-to-date patches] to create the 48-bit LBA driver.The original 4.10.2222 has bugs, which were already fixed by M$ in 4.10.2223, 4.10.2225 + 4.10.2226 [you can leave the last one aside, because that fix applies strictly to IBM portables].If you patched the buggy 4.10.2222, the fixes implemented by M$ in 2223 + 2225 would be lost, and that's not a good thing. And, besides, proper patching should be cumulative.

So, LLXX, if possible, at your convenience, let me know if you can patch 4.10.2225.And you can name it whatever you wish, as long as it's above 2226.Thanks.

Posted 20 July 2006 - 02:07 PM

jimmsta

Posted 20 July 2006 - 05:51 PM

jimmsta

computer janitor

Member

378 posts

Joined 04-May 05

LLXX, You've amazed me - not only did you have one version done, but managed to get three different releases working in a short time. Good work. Now if only I had a way to test it, but alas, all my systems run XP or have small hdd's (I have a 98SE box with a bunch of 4-18GB SCSI drives, but not anything over that size).

Guest_ABC32_*

Posted 21 July 2006 - 01:46 AM

Guest_ABC32_*

Guests

Joined --

Amazing work. I tested the WIN ME Edition of ESDI_506.pdr on a 6.4GB drive (HP Vectra VL 6/400 with PHOENIX BIOS 4.0), it doesn't cause corruption on drives <128GB as it seems. Everything works fine until now. But i have to try with something bigger than 128GB...

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

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

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

Petr

Posted 22 July 2006 - 02:46 AM

Petr

Friend of MSFN

Member

939 posts

Joined 15-April 05

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

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.

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.

Acheron

Posted 22 July 2006 - 03:57 AM

Acheron

Friend of MSFN

Member

970 posts

Joined 28-June 04

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

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.

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.

Petr

Posted 22 July 2006 - 04:51 AM

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:

bristols

Posted 22 July 2006 - 07:11 AM

bristols

Advanced Member

Member

441 posts

Joined 24-September 05

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.