dencorso

And we're glad to have you here! Welcome to MSFN!

I'll take this oportunity to ask a rather complex question, so, please, bear with me: For Extended Partition Boot Records (EBRs), is the Partition-Type Descriptor (entry offset 4) of the Second Partition Table Entry (when it exists) always "05", or should it follow the actual Partition-Type Descriptor (be it "05" or "0F") of the Extended Partiton it exists in? In other words, if I have a "0F" Extended Partition, there will be a daisy-chain of EBRs inside it, with two entries per boot record (except for the last one): the descriptor for the first entry corresponds to the type of the Logical Partition that follows, but the second entry (which is just a pointer to the next EBR) should be of type "0F" or "05"? It seems to me they're always "05", regardless... Or is it irrelevant whether it's "0F" or "05", in this case? I know this question is not quite on-topic, but I figured this was the nearer to on-topic it'll ever be (unless I opened a thread just for it, which I think is not warranted).

What about this one?

Great! Thanks a lot!

It's great to have you back at it, nitro! I wish to remind you of this recent post of mine, about adding MsiX, which would extend the support for .msi, .msm and .msp, and should be relatively simple to add... No. Not LessMSIerables... But MsiX.exe would be a great addition. It is able to extract files from .msi, .msm and .msp installation files, and it is a command-line console program, so I guess it'll be easy to integrate. Do give it a try! Find it here: Heath Stewart's Patch Files Extractor Keep on the great work! You do rock!

The default for the Ranish Partition Manager is to create 05 extended partitions. I always correct that to 0F by hand, after partitioning a new hdd or pendrive (if and when I create muti-partitioned pendrives for some given test purpose)... I remember, from the times before I adopted Steven's patched IO.SYS having seen the enumeration problem... but its a dim memory and at the time I didn't take notes, so I cannot report apropriately on what was it I saw... Then I changed the identifier to 0F, and that was it. So, by now, we can reckon two bugs in IO.SYS: the one found by Steven and the one found by RLoew...

Alice Cooper - Poison

@jds: You say in your read.me: I've determined that the change you reverted is (quoting Steven Saunderson's original w98bug.txt): Would you please elaborate on what problems did that particular change have, and why do you consider it a misfix? Sorry again for the delayed reply. Anyway, the misfix is as follows ... When an LBA extended partition is defined, all logical partitions within in should/must use LBA addressing, even if they're not explicitly defined as LBA types. With the above-mentioned change, IO.SYS will look only at the type ID of the logical partition itself, ignoring the type ID (and hence addressing mode) of the extended partition that contains it. If the logical partition in question is not wholely within the 7.8G CHS limit, disaster (due to wrap-around)! Joe. We were talking about other matters, elsewhere, and this interesting development took place: jds found a problem with phelum's patch and reversed one of the code modifications, to catter for the case of CHS logical partitions inside LBA extended partitions. His patcher for the Win 98 FE or SE versions of IO.SYS from KB311561 is findable at his site.

Indeed! wget rocks!

With KernelEx.

Awesome!

Wow! That was fast! Way to go, RLoew! You do rock! I presume you did it by hand... Please, do consider creating a decompressor tool to automate the process. Besides the default IO.SYS for hard disks and the one that comes in the EBD floppy, three other flavours of the Win ME IO.SYS are known: the one in the bootable floppy image contained in Win ME's CD, and those embedded in discopy.dll, retrievable with DiskExtract, thanks to Nuno Brito (there are two flavors of it, one in the discopy.dll from Win XP and another in the same dll from Vista or 2k3), not to mention those in KB311561... so that an automated solution would be a wonderful tool to have handy. BTW, if I'm not mistaken, the compressed part starts with the identifier MSCM (which is reminescent of MSCF, the .cab file identifier), right?

Check carefully your BIOS configuration. If the drive B: is not activated in BIOS, Win XP may find it, and probably Anadisk too, but DOS won't. The BIOS may be finding the drive but not mounting it...

Welcome back, sherpya! It's great to have you here! Please consider showing up more often. There's lots of things to do and too few coders/modders... Auguri!

And if you want more info or more answers, sit back, relax, and read this thread *and* all those linked from it.

Yes. Unregister it with regsvr32 /u and change its extension to, say, .off... That should be enough, and is easily reversible!

RLoew, since you've studied IO.SYS possibly more deeply than anyone else here, could you perhaps write a standalone decompressor for Win ME's IO.SYS, please? I was on the verge of doing it myself several times, but never found continuous spare time enough to actually do it. It would be of great help to develop and/or port patches to Win ME's IO.SYS. And would also help settling (in case anything can settle it) an open discussion elsewhere, as well!

Some of us do. But forget it, this is an English-only forum.

RunCore rocks!

Hi o0110o! Welcome to MSFN!

I can try, during the weekend, provided there is someone willing to test it for me, so we can find out whether it works or not. On the other hand, we know that patching to v. 10 doesn't work, since that we did try already.

Not at all... at least no difference worth the effort and cost, IMHO. But, just for Windows ME, you can tweak your settings up somewhat, say, to: MaxPhysPage=7CB00 ; 1995 MiB MaxFileCache=393216 ; 384 MiB And safely find out whether more usable memory makes any difference for you, without needing either to buy anything, or to upgrade the hardware.

One has to compare the MD5 hash with that from a known untampered version of the same file, which I provided in my latest post before this one... MD5 comparison answers the question "are two given binaries identical or not?". They match! We may look elsewhere.

@JorgeA: the PE Timestamp is listed simply as "Timestamp" (the 4th line under the Header tab), when you open user32.dll with MiTeC EXE Explorer. It's given in UTC. There's a link for it and a link under "PE Timestamp" in my post #66. For the files it can open, EXE Explorer also provides the MD5 Hash, BTW. Then again, FCIV calculates hashes for any kind of file. Here's that data from bona-fide USER32.DLL from KB291362: File Size: 55,296 bytes File Version: 4.10.2231 File Version (under "Item name"): 4.10.2231 Product Version (under "Item name"): 4.10.2222 PE Timestamp: 19/04/2001 3:36:49 PM MD5: 2143F0DDE35D73A04FF12EC1FB06C439 PS: Sometimes the two instances of File Version in the right-click --> Properties --> Version do present different info, but that's not the case for this file. If the MD5 of your file matches, it's an untampered file. Then we may look elsewhere.

Your USER32.DLL (5/11/98) (12/04/09) looks highly suspect for me. Can you please provide: Size in bytes, File Version, Product Version, PE Timestamp and MD5 Hash of it? You can calculate the MD5 Hash with FDIV (KB841290), if I recall right, it runs on 9x/ME (but I cannot confirm it right now, sorry). After downloading the package, there's no need to actually run the installer, for there's nothing to install, because FCIV is a standalone console utility... you may instead simply extract it from inside the installer and just drop it into C:\WINDOWS\COMMAND.