dencorso

No, not hostile... defensive, maybe. Fact is I think Roy's keeping too many builds alive and up-to-date, already. And no, if you had read the thread, you'd find out there actually is a reason why he's not making non-SSE PM 28. Not only it is not "trivial", but actually it does not work, IIRR. When one makes a disparaging remark, one should be prepared to receive a pointed retort, isn't it? No offense meant, though.

If so, why don't you go ahead and do it?

@All: don't post here yet, let Dave-H work on it, this is a work-in-progress, obviously!

No! He has too many nuts to crack on his plate, already! No offense meant, really, but it's not courteous to pester people! Your latest question can be best answered by your testing them yourself. @roytam1's browsers are his (quite big already) gift to the community... you're welcome to use them for free, but it's not polite to bother him to death with vague questions. You don't wanna test? OK. You may read this thread and the previous one in full and you'll know all there is to know about every one of roytam's browsers.

Hmm... a hyacinth macaw and fireworks galore, perhaps?

Greetings @Andromeda43! Good to have you around!

Alternative for what? Patching vmm32.vxd is part of what the Ram Limitation Patch does, not all of it. The patch is now free and easily available, so why use any less comprehensive alternative?

You'll find the latest HIMEMEX inside the non-XMS ramdisk package. It must be loaded before HIMEM.SYS.

Did you try an anti-clockwise cartwell on four fingers at precisely a quarter past nine in the evening?

Your experience is a small subset of all possible experiences, and actually applies just to your own use of an OS, whereas the knowledge acquired by code analysis (if correctly done) covers all possible experiences. Moreover what can happen may never happen at all. The only true way of avoiding a delayed crash, in case one wants to hide memory from Win 9x/ME, is if it never finds it out. That's what RLoew's HimemEX.sys (a non-XMS large memory manager) does. HIMEMX.EXE is good just until it's actually used to provide XMS, when Win tries to take control and comes down crashing. A XMS ramdisk is one of the ways one may use to cause it to happen, but any XMS client which actually uses a big enough chunk of it will do, too.

MSE 4.4.304.0 is pretty good at detecting things when they're actually accessed (not necessarily to execute, but to copy, move or read, too), in my experience. It may miss passive files until then, though.

Scandskw.exe is an NE exe (16-bit) and, therefore, it's limited in memory access, no matter whether you use RLoew's RAM Limitation Patch or not; the problem lies with scandskw.exe itself. But, I'm sure, if you instead use scandisk.exe in plain DOS, it'll work all right abd be able to finish. Howeber, you shouldn't need xRayeR's patch at all for safe mode. RLoew's RAM Limitation Patch should be enough, if correctly applied. If not, Usher's method (edited SYSTEM.CB) makes unnecessary to ever use Himemx and xRayeR's patch. All that info is collected here in the 9x/ME forum, and much more, but since nobody ever seems to be able to search and use it in any meaningful way, it's already more lost in fact than the proverbial tears in rain! There's a section on the 1st post of my > 2 GiB thread entitled: "Noteworthy specific posts inside MSFN threads"... read all those posts, and all your questions shall be answered better than I can. If you've already read 'em all, do it again because with what you know now, many formerly obscure comments will become understandable. Those are complex subjects, so undestanding them can only happen in steps.

Well, y'all who know me know full well I've never used Vista. But I do use 7 SP1 and I am a XP SP3 die-hard. On XP, MSE still works with no nags, but cannot use any AV definition file later than 1.293.2807.0, because all later AV definition files require an Engine version > 1.1.15800.1 and those engines require functions not supported by XP. OTOH, because of using it on XP, I've kept one of my 7 SP1 (x86) machines running MSE 4.4.304.0, and it remains updating normally and working OK up to now. Of course, to do so, it uses the latest available Engine version and AV definition files seamlessly. Today, however, it dawned on me the same may still happen on Vista, too... and maybe it can even auto-update. But even if not, it sure can be updated by hand, provided the latest available Engine version's requirementes are met by Vista. Is it actually possible to keep using MSE 4.4.304.0 on Vista? I don't really know, but perhaps somebody among you may be interested in testing it. Below is an image of it running on 7 SP1 x86 (no I don't use x64, so I didn't test on it) as of today. HTH.

RLoew's products are compatible with smartdrive.exe and never were tested with xhdd.sys, but the recommendation is to use neither, because they're bypassed, anyway, by the protected mode 32-disk access. You can use... ... and forget about them. Himemx is a time-bomb when used with 9x/ME, because it prevents Windows from taking control of the XMS administration. There's more info by RLoew himself about that in one of the posts linked from the 1st post of my thread on > 2 GiB RAM. tl;dr: use himem.sys and forget about it.

Yes. And since RLoew's isn't Manufacturer-specific, it should always work, whatever the chipset. Notice, however that, in any case 9x/ME requires the 137GB patch (either RLoew's or LLXX's), in addition to the SATA patch or VIA driver.

As I said, the 8237 chips are SATA I patched to understand SATA II, but they do limit performance to not more than 150 MB/s. See, I found the data from my tests with the GB-i-RAM (which uses DDR-RAM) for you to see... A really great SATA III SSD will probably yield similar (or even slightly better, but I do doubt it) results.

Your board features a VIA 8237S southbridge. The 8237 family is a family of SATA150/UltraATA133 capable chips, in reality. Reportedly, they can support 150 MB/s full-duplex (if nothing else were using the southbridge at the same time), but I've never seen that happen, so, although they understand SATA300 protocols correctly, not even a Gigabyte i-RAM board (which is SATA150) can reach 150 MB/s full-duplex on any 8237, in my experience, although the GB i-RAM does get near 133 MB/s. That said, 87 GB/s on a SATA300 mechanical HDD (i e: not an SSD nor a hardware RAM-drive) appears to me quite realistic. See also the attached .pdf Via_chipsets_vt8237.pdf

Lots of people do... however, most, like myself, lost interest in or otherwise gave up on 9x/ME forever, way back when. Still, most of the info you'll ever need is collected in the thread I've just pointed you to, which I no longer update, but which preserves most info you may require. ==== Additional info added later ==== MinFileCache is *never* needed. MaxFileCache and MaxPhysPage should be removed for using the RAM Limitation Patch. The most usual setting for the patch is to run it with the /M command-line parameter. SPLIT8MB shouldn't usually be needed. For more about that:

Don't hold your breath...

Because using an Exocet to swat a fly is a bit of an overreaction, isn't it?

And, after checking with FC /B and making sure it actually is right, just to keep on the safe side, do fix the PE checksum by running n7Epsilon's excellent PEChecksum like this: PEChecksum -c ETDCtrl.exe

It does not. But there are boards having just ACPI, and on those boards one can get without both ACPI (because of /p i) and APM (because there was none to start with).

Way to do, @Mov AX, 0xDEAD!

You're welcome! And, BTW, <Alt><PrintScrn> (to get a snapshot of the currently active window only) also works.