dencorso

SYSTEM.CB is another text mode configuration file that exists in C:\WINDOWS. Look up for it, I bet you have one. It is used, instead of SYSTEM.INI, when you boot to SAFE MODE, but otherewise it's not used. You have to fix it, or you'll be unable to go to SAFE MODE, if you ever need it. This is the Usher method of using more than 512 MiB of RAM. SYSTEM.CB may contain all the sections that may exist in SYSTEM.INI, althoug some of them will have different settings, and most don't exist. You'll probably need to create both [386Enh] and [vcache] sections in it, because usually the default SYSTEM.CB doesn't have them. Once you've done that, MaxPhysPage=40000 goes under [386Enh] and MaxFileCache=131072 goes under [vcache]. Your SYSTEM.INI, however, should already have at least [386Enh], so you may just have to create [vcache], in case there isn't such a section in it. You may put the new statements just below these headers, or below the last of the statements that may already exist in those sections. Provided they are in the correct sections, those statements should work OK. I've been thinking and rainyd has a point in what he said. So I'm revising my original suggestion MaxFileCache=393216 (that means 384 MiB) to MaxFileCache=131072 (that means 128 MiB), as RLoew suggested elsewhere, because it should be enough. For the record, rainyd's suggestion of MaxFileCache=262144 (that means 256 MiB) should work OK, too, but 128 MiB uses even less RAM for the cache, leaving it available for general use. Now, if I were you I'd set the new values in SYSTEM.INI and SYSTEM.CB, save and then reboot. The machine should reboot normally, despite these settings, with you present 512 MiB of RAM. Once you're back to windows check those files to ensure the new settings are really there, so as to rest assured all went well. Then shut the machin down, *disconnect the power source cable*, wait for about 1 min, then open the machine and add the new RAM sticks, making sure they are well seated. Then restart the machine, make sure the BIOS recognizes the memory and, if so, let it boot to windows. It should just work. You may keep the CHUNKSIZE=1024 as it is in SYSTEM.INI, but there really is no need to add such a line to SYSTEM.CB, too.

Welcom to MSFN! Simply set MaxPhysPage=40000 and MaxFileCache=393216 both in SYSTEM.INI and in SYSTEM.CB. For *much* more detail, do read my > 1 GiB RAM thread, linked from the left side of my signature.

Maybe. But this one is the latest MS says works known to work OK: <link>. Edit: I've just checked and they are one and the same. So the answer should be: yes. And about imaging programs, please allow me to quote some earlier posts of mine, which I think have all the info you need, already written in them: For the above post, substitute "troubleshooting" by "configuring" or "tweaking", or even "installing applications", and the general idea is directly applicable to your present case.

Flash cookies maybe? Read about them at www.flashtester.org and try deleting them. Also review the options selected in the flash control panel, only accessible trough the flash player itself, or via adobe's site. It's a longshot, but it never hurts to try. Maybe there's some cookie in your machine that Flash 10 interprets but 9 ignores, at the heart of your issue.

That's great! So Win ME behaves even better than I'd imagined it would! So far so good. It's slow, but probably not unbearable, and safe. Congratulations! So it permits you to let the decision about the SATA drivers for later. But do read about the options I pointed you to. Make a good backup of the present state of the system, preferably an image, to have a good fallback point, and proceed in your customization. Meanwhile I'll search for the right PSAPI.dll for you, and keep you posted. BTW, I agree with loblo: you should set MaxPhysPage=7CB00, then try MaxFileCache=393216 (and if that proves to be too much, try 131072). Do it first just to SYSTEM.INI, and only modify SYSTEM.CB, too, when you confirm it works OK.

DOS Function 4302 might be the best way to quickly ascertain the true file size, I think...

Function 6C00, bit 4 of BH! If not for you, RLoew, I'd never find out about it! You do rock! Well, the little TSR could trap the Acces Denied return and try to find out whether the file in question is bigger than 2 GiB and, if so, set the flag and retry, returning the result of the read as if it had succeeded, else let the error alone... Of course, this might result in having to take steps for safely rentering DOS to find out the file size, but it is sure possible to implement cleanly, I think.

Does the Performance tab in System Properties show the HDDs as working in DOS Compatibility Mode? There're no official drivers for the ICH8-M sata controller. Intel dropped 9x/ME at ICH7. KernelEx doesn't work with WDM drivers (and this is by design, so rest assured it won't work). It's possible to find a version of PSAPI.dll designed for Win 9x/ME somewhere, I'm sure it exists (I just cannot right now point you to it, because I don't remember where, but I'm sure I've seen it for download many times), but I really doubt it'll do you any good... other issues will certainly appear, once you solve that. Walter Oney's WDMSTUB.SYS, on the other hand, can make some WDM drivers work with 9x/ME, but nobody has ever succeeded doing it with disk drivers. You've got 3 options: RLoew's SATA patch with ESDI_506.PDR (since your HDD is 120 GB you don't necessarily need a version also patched for the 48-bit LBA issue), but that's not free; you've got Xeno86's version (link) of Alter's UNIATA, which is highly experimental, at this point, but free; or you've got to keep the HDDs in compatibility mode (by just renaming ESDI_506.PDR for good)... BTW, are you running with ESDI_506.PDR without having renamed it?

Sure the MS layer for Unicode you get from Microsoft. But there's no need to search for it as there is a direct link to download it from the 1st post in the KernelEx thread. I should know it, since I put it there. The PSAPI.DLL missing is a common error, for it just exists by default in NT-OSes, not in 9x/ME. However, only very rarely one can use any Win 2k drivers in 9x/ME with success, and even then, Walter Oney's WDMSTUB.SYS is usually required for those rare drivers that do work. So it's not trivial to have success at it. But, with that said, I think you shlould slow down and make sure your SATA drive has proper drivers or your system may cllapse at any moment. What do you see in the device manager? No exclamation marks and no drives in compatibility mode? How comes? Please do attach screenshots of your device manager window with disk drivers, with ide controllers and with SCSI/RAID controllers expanded, for us all to see. Once that's settled, then you may proceed as fast as you want.

If the non-RAID is AHCI, it won't work with Win 9x/ME, while if it is " IDE-mode" it'll do OK, but probably be slower than RAID, provided their .mpd for it works OK. This <link> also may be of interest.

This is just a longshot , but you might: (i) Try disabling the following statements contained in ahcix86.inf (from v.3.2.1540.53) , by prepending a semicolon to them (here indicated in bold red)... Or you might delete those two values from the registry, after the driver is installed (but do save the key by exporting it, before deleting anything)... they should be at HKLM\SYSTEM\CurrentControlSet\services\ahcix86\Settings\CAM. This page elsewhere may be relevant, too, even if indirectly. (ii) Or, even easier, although less subtle, install v. 3.1.1540.25 (the one that works), then, manually, while booted from DOS or Linux, rename ahcix86.sys (v. 3.1.1540.25) to ahcix86.025 and add ahcix86.sys (v. 3.2.1540.53) to the same folder, which should be %windir%/SYSTEM32/DRIVERS, and then boot windows again and see what happens. Either of these suggestions may just work, but may also mess things up. So do it at your own risk, or don't even try it.

No... I, for one, had never ever heard of such bug. But it may be a fact, at least in some contexts, so thanks for the heads up. I'd like to be able to help more, but in this case, the only thing I can say is: you've got a working INF for the 3112 drivers... I'd start by comparing it with the various INFs from the 3114 drivers you've found, to use it as a guide for the modification of one of the 3114's INFs, preferably the least different, when compared with the 3112 INF. I know that's a lot of work, but what is not, nowadays, in what regards 9x/ME?

No. There's no ready-to-use updated installation CD for Win 98SE. And no Win ME is slightly better, in what regards memory management, but the SATA problem remains the same. Use Ubuntu to hunt around for the reappearance of ESDI_506.PDR. You might have copies of it in: (i) C:\WINDOWS\SYSTEM\IOSUBSYS; (ii) C:\WINDOWS\SYSTEM or (iii) C:\WINDOWS\SYSBCKUP and rename them all. Then go to C:\WINDOWS\SYSTEM\PRECOPY and rename SP2.CAB to SP2.OLD. Then find SYSTEM.CB in C:\WINDOWS, and edit it to contain the same MaxPhysPage=40000 and MaxFileCache=131072 statements (you'll probably have to create the [vcache] and [386Enh] sections there, as well, to do it) that exist in SYSTEM.INI. Then try to boot again, and report. We are getting there by slow steps. As for Win 2k, it's a different beast altogether. Installing Win 2k SP4 in your machine would be much simpler, in fact.

Accept my deepest condolences, Kel!

Did it go all the way and actually let you have a workable desktop once, and then the error occurred, or was the error further on, after the 1st reboot, so that you never reached a workable desktop before the appearance of the new error? Does ESDI_506.PDR remain renamed or did another version of it pop up from somewhere?

OK! I think now it's a good time for a test... @osiff: would you please try the settings below and report what happened? 1) set MaxPhysPage=40000 and MaxFileCache=131072 in SYSTEM.INI and rename C:\WINDOWS\SYSTEM\IOSUBSYS\ESDI_506.PDR to ESDI_506.OFF 2) Now reboot to the HDD and let the installation finish. If, and only if it crashes, then try changing MaxFileCache=65536, but keep MaxPhysPage=40000.

@datasg: the only thing a banned member can get at MSFN is the ban. Hence, you're banned for being cuudulieu!

Here you go! <link>

I think Win9x/ME honors it. A very similar setting was the only one that worked for Andy Aronoff (Post #5 in this thread over in WindowsKB), who I suppose was the first to succeed with 2 GiB, way back when, about two years before v. 1.0 of the RAM Limitation Patch.

No. Begin installation up to the 1st reboot. Don't let it reboot from the HDD (easiest way is to put a DOS bootable floppy in the FDD, if you have it, or any bootable CD -- your Ubuntu will do all right -- in de optical drive, and set FDD or CD/DVD drive as 1st boot device in the BIOS, so that the reboot will boot from the floppy or CD, instead of the HDD). Then, either: 1) set MaxPhysPage=40000 and MaxFileCache=16384 in SYSTEM.INI and rename C:\WINDOWS\SYSTEM\IOSUBSYS\ESDI_506.PDR to ESDI_506.OFF 2) Now reboot to the HDD and let the installation finish. or Install the RAM Limitation Patch, from DOS, as per RLoew's intructions enclosed in the patch distribuition archive (part of which I quoted in a previous post), and rename C:\WINDOWS\SYSTEM\IOSUBSYS\ESDI_506.PDR to ESDI_506.OFF.

The uSP adds many tweaks to SYSTEM.INI, and among them custom MaxPhysPage and MaxFileCache statements that are unnecessary for one using the RAM Limitation Patch. The former would account for the incorrect amount of RAM displayed by Windows. As for the instability you found, that would have to be looked into further. I consider it wise to save SYSTEM.INI, WIN.INI, CONTROL.INI, CONFIG.SYS, AUTOEXEC.BAT and MSDOS.SYS before applying the uSP, then comparing these files with the former versions to decide which, if any, of the configuration tweaks added by uSP should be kept. So, adding the uSP to anything that is not a plain vanilla system must be done with due care. Which is clearly the case here, for the machine osiff is seeting up. But over and above that, I wouldn't reccomend installing uSP blindly on such a system, at least not before one is quite sure it is working, reliable and stable, and then, only doing it after having a known-good backup.

The main problem with the RAM Limitation Patch (RLP), followed by uSP is that uSP *replaces* VMM.VxD, which is fine by itself, but it is one of the files (the main one) patched extensively by RMP. So applying the uSP cripples RLP. The only solution is to reapply the RLP to patch the newly added VMM.VxD 4.10.2226, but that's a situation for which RLoew's patcher was not intended, so that some manual tweaking is required, but it's possible and not too difficult to do (but one needs to know what one's doing, in detail). However, osiff's problem is even more complex because having a SATA boot drive with an Intel controller and very limitated options for tweaking at BIOS configuration leves, as is usual for laptops/notebooks/netbooks. Probably the best course (the least painful one) would be to patch the SATA driver outside the machine, instal with a custom installation disk, along the lines you did for Win 95, then aply the RLP in DOS, between reboots. That will get the system up and running. Then install uSP, let the system crash, and repatch everything from DOS. But *both* Rloew's patches seem to me to be really *fundamental* for this setup (and, of course, they come with RLoew's superb support, which will be of great help here). The considerations I posted here are also of interest to help make a good picture of how Win 9x/ME behave with lots of physical RAM. Once the machine is up and running 98SE, then the other driver issues can be dealt with, one at a time.

No, there isn't, sorry! Quouting myself from other posts: So, to go beyond that, you *need* RLoew's one-and-only RAM Limitation Patch. Now, an intersting fact is that, without the RAM Limitation Patch, you actually don't need HIMEMX with up to 1.5 GiB of RAM, and that leads to perfectly stable setups, while 2 GiB or more won't even boot, in most cases, whithout using HIMEMX or a RAMDISK to hide part of the RAM, and even so, most setups are not very stable, although there are some exceptions, reported in the list, in post #2. On the other hand, you can add both the MaxPhysPage and MaxFileCache to SYSTEM.CB (Usher's Method) *and* add xRayeR's patch to regain the ability to access Safe Mode, with > 1.5 GiB of physical RAM installed (see post #1, for more details). Now, if you intend to keep using the machine with 2 GiB, not just do it as a temporary experiment, do PM me its specs in the format used in the list (as soon as you deem your configuration definitive) and, of course, I'll add it to the list, in post #2.

von Karajan & the Berlin Philharmonic - Albinoni's Adagio (from a real vinyl LP of 1975). ... which is actually a creation of Remo Giazotto, but great, nonetheless!

To give up, at this point, is really a pity! While I, for one, was keenly aware of the great difficulty presented by your project, the most difficult things also are the most stimulating (that's why people climb mountains, and the like...). So, please, take a break, go to the movies, enjoy the week and the week-end, and then consider why not give it a last, very forceful, try. And, in case you do decide for it, bear in mind most of the worst hurdles that await you, on starting again from scratch, are already known: hence we may plan together on how to overcome them beforehand. It would have to be a slow attack, probably backed up by partition imaging, to give you easy fallback points, along the way. But since you've already got the system to boot once, it sure can be done. Of course, you have to weigh well the cost and the benefits, like in any other situation in life. We'll be here, as always, and if you decide to give it that last try, we sure remain available to help you get there, no matter how long it takes.