dencorso

Your question 3 cannot be answered by anyone at MSFN. In fact, it shouldn't even be posed. For your reference:

Gavotte does.

Yes, assuming that Windows 7 x64 still honors them as older versions did. That's why I call it a longshot. But since its easy to do and reversible, I think it's worth trying. Even if you don't see any effect immediately afterwards, do wait a couple of days before reversing, just to be sure.

Your disk is being detected as removable. You need to add karyonix's DiskMod v. 0.0.2.2.

Don't be. It's been a funny ride! But now, enough is enough. @5247846: Please do take your wild goose chase elsewhere. MSFN is not the place for it.

A longshot worth trying with AMDs is the following: Go to HKLM\System\Current\ControlSet\Control\Session Manager and set EnableMCA=0 and EnableMCE=0 and see whether the BSODs stop. If they don't, return those two settings to their previous state.

Hands down Win 98SE.

If you add Maximus-Decim NUSB, USB works flawlessly on Win 98SE.

Why?

You've just done that. It's good to see you around, Usher, even if the circunstances are not the happiest. And, in fact, besides what you've already pointed out, he also used RLoew's text (and original results) over on the usenet, without proper attribution. But, on top of it all, by visiting that group on the usenet, and searching around a little, it also becomes clear that wsxedcrfv is, in fact, already thrice banned member 98 Guy.

Yes. KB78346 states it applies to the file size, nothing is said about sections. And yes, if it applies to 98, it sure applies to ME. This type of feature didn't change between them. It may, however, not apply to Win 2k, XP and later versions... The way to test it is to create a, say, 70 kiB cdplayer.ini and test it in the conditions Bill in Co. gave.

That settles it! Thanks whole a lot for the swift reply, RLoew! And I stand corrected. MS could have used 32-bit pointers, but they preferred to keep the 16-bit. Go figure! One possible explanation to that is they did it to force people away from .INI files, as mentioned above by Tripredacus. Another one, more probable IMO, is they just couldn't care less about a deprecated feature, even if undocumented.

EMM386 and any XMS TSR's, if any, come first. The Registry appears to be next. The VMM32 Modules follow. The /M Option disrupts this allocation, so that the Registry and VMM Modules are placed above the 16MB range. Thanks a lot! I've got a much better mental picture, now, of how it works. BTW, XMS TSRs are rare birds, indeed. I wouldn't even have thought about them here, had you not mentioned them.

Now, that's great news!

It can be downloaded using GenuineCheck from Windows 98. Here's how.

I see nothing in the "Applies to" section, other than a link to "Back to the Top". It's there: just click on the + sign in a box beside the bold "Applies to:", and it'll expand. Moreover, if you had visited the second link I gave, the one to the 1999 version at the WayBack Machine, you'd have seen it without needing to expand it. I said it, and I repeat: I really doubt 9x/ME kept those pointers as 16-bit. @RLoew: if and when you have the time, would you kindly check the internals of one of the APIs mentioned in KB78346, just to settle this question once and for all? Thanks a lot in advance.

KB78346 only makes sense if the SIGNED INT and UNSIGNED INT used for pointers are 16-bit numbers, because 64 kiB is 2^16. So, there, MS is talking about 16-bit code. And this is consistent with a 5-digit KB number. It can be true that those 16-bit pointers were carried over to 9x/ME. And it'd probably be feasible to patch them to 20-bit or more, if that's the case, but the question to tackle first is: is it the case, or, to put in other words, are those pointers really still 16-bit in 9x/ME? After all, in a much older version of KB78346, as preserved by the WayBack Machine, it's stated it applies to Win 3.xx and WfW 3.xx, and that was 1999, so Win 95 (all versions), 98 and 98SE were around at the time. And the newer version pointed by Tripredacus states the same in its "Applies To" section. In any case, to me seems clear that the above KB refers to the files themselves, and not their inner sections, as limited to 64 kiB. But, I insist, the reason for it is the use of 16-bit pointers. I think that restriction simply doesn't apply to Win 9x/ME or the NT-family OSes.

Before going any further, do create another version of the compressed sfx from the uncompressed source. The file you first created may be really corrupt in very subtle ways. In other words, check that the issue is reproductible.

@RLoew: You talked about a 18MiB registry and the lowest 16 MiB... may I ask, just out of curiosity, at which physical address, even if variable, does Win 9x/ME start loading the registry? Just above the HMA? @jds: IIRR, the demo version of the RAM Limitation Patch works for 10 min before rebooting... it might be enough, with the /M option, for RegCon to compact your registry (but do create a backup first, and store it safely, of course). BTW, how much RAM does your machine have?

Neither 7 Ultimate x86 will. For that you need a x64 OS. Both 7 Ultimate and XP have x64 versions, which do support >> 3 GiB

If you can afford 7 Ultimate and XP Pro, I'd say you should create a double boot machine, especially in case you go with the hardware CoffeeFiend suggested you. Why not have the best of both worlds?

Welcome to MSFN, Cyril!

Hi, Joe! I guess you've not been following the forum as you should... Rick just reposted some of those apps, including RegCon, a few days ago... Much of what Windows collects is usage tracks. One of the best tools for those on 9X is MRU blaster. As for destroying your system, you can avoid this by using TestRun by BB to make a test registry to work on. You can also boot to DOS and back up system.dat and user.dat to another location first. If you trash your registry, just restore them from DOS. I'm not sure of the availability of either so I've uploaded copies of both. In the thread I linked to earlier, the RegCon utility is good for compacting the registry. I've uploaded it here. The translated registry docs mentioned are uploaded here. Both are 7zip archives. When you get the registry cleaned out, compacted, and optimized, the link in my signature describes using batch files that will keep it that way.

I stand corrected. Sure: 4,294,967,296 * 4,096 = 16 TiB. I need to get more sleep... Thanks, RLoew! I've corrected my previous post and the quotation of it, in red, to highlight the correction. BTW, I've been using an External USB 2.0 Seagate Expansion 1500 GB with a Seagate Barracuda LP ST31500541AS (5900 rpm) 1500 GB HDD inside, for one year already, if not more, without any issues. It's partitioned into 3 roughly equal sized partitions. Although I've never had the chance to use a 2 TB HDD yet, I agree with RLoew and allen2: it has to be safe, because it's real size is 1.82 TiB. But it should not be used as a single partiton, unless RLoew's patch is used. In fact, there was an issue, but not related to size: all green Barracudas have an auto spin-down on idle feature. Neither Win XP SP3, nor Win 98SE, do understand it, so that every time it spins down, the OSes think it has been disconnected and reconnected, and redetect it, causing it to spin up again. The solution to this issue is to use the Seagate Manager Software, which accompanies the drive, to set the spin down time to "Never", effectively disabling that feature. I don't know whether the Seagate Manager works on 9x/ME, because I did it on XP. In any case it must be done just once, so it's not really fundamental to have the Seagate Manager working on 9x/ME.

The MBR uses addresses of 32 bits to point to the partitions. This means 2^32 (=4,294,967,296) possible sector addresses. If the HDD has 512 bytes sectors, this means 4,294,967,296 * 512 = 2 TiB. Moreover, the DOS/NTFS boot record also has a 32-bit sector count field, resulting in the same limitation. Of course, if using 4 kiB sectors, this limit becomes to 16 TiB. Now, this is just theoretical, because it's not clear, at this time, how well Win 9x/ME supports 4 kiB sectors. However, RLoew has found out that there is a bug in VFAT.VxD, so that, due to that bug, a patch is required to use safely partitions > 1 TiB. But if no partitions > 1 TiB are used, its safe to use a 2 TiB HDD with Win 9x/ME.