Question about esdi_506.pdr version 4.10.2226 from Microsoft

[rloew]

@Fredledingue:

That's puzzling. I've only encountered MS-DOS compatibility mode on HDs connected to additional ATA/RAID controllers on which I haven't loaded drivers for yet. Once I load the proper drivers, that problem goes away. Is your I: drive on one of those type controllers? I've never experienced it on HDs connected to my main IDE controllers. There is the possibility that the modified ESDI_506.PDR isn't compatible with your IDE controllers for some reason. I'm assuming your HD is IDE/PATA.

ESDI_506.PDR is not compatable with additional IDE Controllers even if the Default INF installs it, as occurs on some motherboards.

I have written a Patch and an INF File to correct this issue.

[Fredledingue]

Prozactive:

"Some reason" must be the only known reason why my computer doesn't want to use other than 4.10.2222.

Because thoericaly it should. Albeit rare, I'm not the only one. I have seen at least one case like me here.

[MDGx]

The updated version of ESDI_506.PDR that I installed back then had an indicated file version of 4.10.2225. I'm convinced that it's identical to the latest "updated" 4.10.2230 version installed by MDGx's Atadrv98.exe update. I've finally run a binary file comparison between the two versions and these were the only differences detected (as I already noted earlier via visual inspection):

00005D86: B1 B6

00005E4D: 32 33

00005E4E: 35 30

The last 2 differences are just the version number changing from 4.10.2225 to 4.10.2230.

The 1st byte change [b1 B6] might be the 1 responsible for the compatibility update with disks > 137 GiB. [?]

I believe more testing is needed.

About what was changed/updated in this build, the author's text [included in the package] offers some details:

http://www.mdgx.com/files/atadrv98.php

HTH

[dencorso]

The 1st byte change [b1 B6] might be the 1 responsible for the compatibility update with disks > 137 GiB. [?]

I believe more testing is needed.

No the fist byte is also a version number change. MS specification for the file version structure indicates there must be both a hexadecimal and an ascii version number present. In the hexadecimal version number 0x02B1 = 2225 and 0x02B6 =02230. A common reversioning mistake is to change just the ascii version number, while forgetting about the hexadecimal one.

But I think you are misreading me, MDGx: the LLXX patch is much longer than one byte, but here I'm talking about her patched version 4.10.0.2225 (as downloadable from her thread or from your site) vs. version 4.10.0.2230 (present in BHDD31.ZIP), which is the same file, but reversioned by Maximus-Decim.

Now, if you compare the original MS 4.10.0.2225 vs. LLXX's patched 4.10.0.2225, you'll find lots of differences, although they have almost the same size, because she made her patch fit in areas that, in the original file, contain only zeroes. The simplest way to recognize the LLXX's patched file is by the presence of her signature, starting at hexadecimal offset 0x26E3, since the original file has only zeroes in that same region; moreover, the file patched by LLXX is exacltly 24.431 bytes long, ending with 0x32, the ascii char for number 2, whereas the original MS file is just 24.430 bytes long. HTH.

[MDGx]

The 1st byte change [b1 B6] might be the 1 responsible for the compatibility update with disks > 137 GiB. [?]

I believe more testing is needed.

No the fist byte is also a version number change. MS specification for the file version structure indicates there must be both a hexadecimal and an ascii version number present. In the hexadecimal version number 0x02B1 = 2225 and 0x02B6 =02230. A common reversioning mistake is to change just the ascii version number, while forgetting about the hexadecimal one.

But I think you are misreading me, MDGx: the LLXX patch is much longer than one byte, but here I'm talking about her patched version 4.10.0.2225 (as downloadable from her thread or from your site) vs. version 4.10.0.2230 (present in BHDD31.ZIP), which is the same file, but reversioned by Maximus-Decim.

Now, if you compare the original MS 4.10.0.2225 vs. LLXX's patched 4.10.0.2225, you'll find lots of differences, although they have almost the same size, because she made her patch fit in areas that, in the original file, contain only zeroes. The simplest way to recognize the LLXX's patched file is by the presence of her signature, starting at hexadecimal offset 0x26E3, since the original file has only zeroes in that same region; moreover, the file patched by LLXX is exacltly 24.431 bytes long, ending with 0x32, the ascii char for number 2, whereas the original MS file is just 24.430 bytes long. HTH.

Thanks for the clarification.