dencorso

@LoneCrusader: I'll give it a try. @Andrew T.: Which Flash 7 do you use, the one for IE, or the one for other browsers? And what's its full version number?

Spin-off thread merged into main thread.

Welcome to MSFN!

Welcome to MSFN! Hope we can be of help and that you enjoy your stay.

No. And installing 98SE without ACPI is a good idea which leads to a generally more stable configuration. I wrote about how to remove it from a finished installation in an old (but still useful) post, for which there is a link in the first post of the > 1 GiB thread. But, since you're installing from scratch, it's much cleaner to prevent Win 9x from using ACPI at install time. If all the rest works OK, I may then suggest you some extra tweaks that may be done at any time afterwards.

Since you're reinstalling, let's do it this way (let's let the installation of office XP for after all else is working OK): With just 512 MiB RAM do: 1) Install Windows and check it's working fine. 2) Install SP2.1 and check it's working fine. 3) Add a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.INI 4) Install Xeno86's modded VCache.VxD This should be enough to get you ready for more RAM. Now, let's give Usher's method a test, since you'll will be at a point it's harmless to do and it may work. 5) Add a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.CB If there isn't such a section, create it at the end of the file. *Do* *not* copy SYSTEM.INI over SYSTEM.CB! Just edit it with notepad, OK? 6) Now place in the 2x1GB memory modules and clear CMOS and reboot. Windows should start normally. Restart in Safe Mode. Restart back in normal mode. Report. If Usher's method works, that's it. If not, we now remove step (5) and proceed to add Japheth's HIMEMX.EXE and xRayeR's IO.SYS patch. If that's necessary, I'll give you as detailed instructions as you find necessary, OK? Good luck! @Usher: Yes, I know I'm proposing to use just half of your trick, since I recommended Xeno86's patched VCache. But if what I proposed above works, then you've already got your proof of concept, so bear with me, please!

The screenshots are quite good. Let's see what turns out. Meanwhile, have you run SFC.EXE already? If not, do it and report, please.

Yes. But you'll need Resource Hacker and some patience... Get the version of Explorer that has the icon you like. Save all resolutions of it to .ico files and then import them to the most updated (the one you intend to use) version of explorer. Resource editing is the best and most definitive way of doing it. @Multibooter: Now that you've got things under control, you might give your machine a once-over with the latest version of the great freeware AVG Rescue CD, just to be on the safe side.

Maybe. But it's worth to try. Do post a good, legible screenshot, and let's see what ensues.

The easiest way to do it is this: keep the old version of explorer.exe renamed to any other extension (.ori will do OK) in any convenient folder of your liking or even in c:\windows. Then right-click the desktop and find the tab that shows the especial icons. Select the icon you want to change and point it to the old icon in the old explorer file. If this generic explanation is too vague, I can give you a step-by-step one as soon as I'm using 98SE (but, at the moment I'm on XP).

There's no PSAPI.DLL in WinME. PSAPI.DLL v. 5.0.2134.1 is included in the old AVG 7.5 free packages. But it's a NT only file, AFAIK. See: KB187913

That installer just replaces Explorer.EXE, AFAIK. It should work just like when you did it manually. There's no uninstall, but that can be done manually also. The registry need not be touched.

If you use TeaTimer, try disabling it for the duration of the scan. It's a longshot, but worth trying.

Cheers sparkette! Welcome to MSFN!

Great find, RetroOS! I've just compared USB.INF and USBME.INF (BeyondCompare is perfect to do this), and I think they might be consolidated into a single .INF, but lots of testing will be needed, of course. But it sure seems possible, from this quick inspection.

Spybot S&D still works flawlessly in my system. It's Win 98SE with 98SE2ME.

For anyone annoyed by the bug described in this thread, upgrading to IE8 is the definitive solution, since this issue was resolved in IE8.

This has been posted in another thread, but I think it's quite relevant here, so I decided to quote it here:

Are you sure? Did you read my posts about system.cb in safe mode? They are here: http://www.msfn.org/board/more-than-win9x-safe-mode-t142953.html If my solution works for safe mode, it can be more useful than binary patches. @Usher: I've read it, rest assured. Not enough carefully, I'm afraid. Carefully enough. I only missed the fact you don't have a machine with enough RAM to test your idea. There is no need to your adversarial posture. My only interest is to help. And I feel that, when striving to do so, it's more sensate to propose time-proven solutions than experimental ones, as the fist option. That said, thank you for posting your interesting idea and also for calling my attention to that interesting old thread by Tihiy. Official MS patch is a must have. It should be installed with all other MS patches, f.e. using unofficial Support Pack (SESP). You may recommend SESP install. You also didn't read the OP carefully enough. The OP says he's already installed SESP 2.1! However, I recommended installing KB311561 just to be on the safe side, since, for me, it's evident he's running Win98SE in an unstable configuration, and did not do the time-proven tweaks for being able to use safe mode. This is not for safe mode. In safe mode SYSTEM.CB file is used, not system.ini. You should recommend also editing SYSTEM.CB. While it would, AFAIK, be harmless to recommend the change to SYSTEM.CB, no amount of prodding will be enough to make me use krelian as a guinea-pig for your new method, since there are time-proven alternatives I'm familiar with and know for sure that work. There is no need for this patch. It is just hardcoded setting from [vcache] section in system.ini/system.cb. Editing ini files should be recommended - this way users can test different settings and find the best settings for their machines. That's simply not true. While Xeno86's modded VCache.VxD changes the default value for VCache, which is only used when there is no settings in the [vcache] section of SYSTEM.INI/.CB, it duly abides by any settings found there, when they exist. So it's a better all-round alternative to the original MS VCache.VxD, and should be used, at least, by all users running 9x/ME with > 1 GiB RAM. In fact, while it caters for the fact that there is no [vcache] setting in the original SYSTEM.CB, so that it obviates the need for this setting both there and in SYSTEM.INI, it'll also abide by such a setting present in SYSTEM.CB. Hence, Xeno86's modded VCache.VxD won't prevent anyone from tweaking their .INI and .CB files to their liking, in no way, but sets a more secure background to fall to, if needed. Had you read carefully enough VCACHE fix attempt, you'd be cognisant with all I said above, and there would be no need for me to reply to this particular point. The changes in 4-6) are for using memory manager other than MS HIMEM.SYS. Once again, I have no machine to test it with > 1 GiB RAM, but from FreeDOS mailing lists I know Japheth's HIMEMX.EXE may still have some bugs and compatibility issues that are not solved yet. Japheth's HIMEMX.EXE v. 3.32 does indeed have some remaining bugs, the ugliest of which is creating orphan handles in some very contrived scenarios. It also simply ignores one switch, the TESTMEM switch if I remember right. And its implementation of XMS 3.0 functon 88H does not return the "highest ending address of any memory block" in the proper format (viz. in kiB). I know that from first-person experience, both from testing HIMEMX.EXE extensively and from analysis of the released source code. However, none of those bugs create any problem serious enough to prevent the day-to-day use of HIMEMX.EXE, which is a convenient tool for postponing XMS related problems caused by too much RAM for an unpatched VMM.VxD. For more on this, you should read again this most interesting post by RLoew on HIMEMX's limitations. And, BTW, HIMEM.SYS v. 3.95 also has standing bugs (three, at least, which I intend to address by releasing a patch for it in the near future), but that also doesn't prevent it from being usable and useful. In general, your recommendations are for advanced users, while my solution could be good also for testing by newbies. And you know there is no need to use as much RAM as it is possible in safe mode. It is enough to have any simple, safe and working solution. Just someone ought to test it. Now, here are various points, which have to be answered separately: RLoew's RAM Limitation Patch is not free, but is absolutely user-friendly, and can be applied with success by even the most unskilled of newbies. And RLoew gives outstanding good support for his customers, on top of that. Other solutions are free, but less user friendly. And there is only us, other users, to give what best support we can muster for other users trying to apply them. Anyone who seriously intends to run Win 9x/ME nowadays, especially with > 1 GiB RAM, must seriously intend to become an advanced user, if he isn't already. Whoever wants easy should look elsewhere, because the one thing the Win 9x/ME world cannot be anymore is "simple": you have to strugle with hardware, drivers and the like every single day, and to do that minimally efectively you must be able to work both from True DOS and from within Windows, as needed, as the bare least (or, at least not be afraid to learn how to, when needed), and also welcome help in the form of time-proven bona-fide unofficial patches, that caring users provide to obviate you from the need of using debuggers/ disassemblers/hexeditors yourself. I'm not, and never was, against the testing of your proposed solution. But, in principle, that should be done by experienced users solely, until proven to work well. What I'm certainly against is skipping over such careful testing and, instead, using new-users-in-need as guinea-pigs. That's all. Now, in the specific case of your proposed method, as it just involves editing SYSTEM.CB, I think the testing can cause no harm, so it's up to krelian to decide whether he wants to do it or not. In any case, it's counter-productive to have two users advising krelian to do completely different things at the same time.

The method you propose is interesting and ought to be thoroughly tested. It has the attractive of being much simpler than the solutions in use nowadays. Here is a reference I think might be of interest for those intending to use it Understanding Safe Mode. I have now added this thread to the list of relevant threads in the 1st post of the Win 9x/ME with > 1 GiB thread.

Hi, Dave! Welcome to MSFN!

w98iopat.exe must be run from c:\, not from c:\windows. Are you sure you were on c:\ when you ran it, and that it also was on c:\?

Are you sure that both himem.sys and himem.exe are in c:\windows?

There is no need to reinstall. Copying the config.sys from ebd to c:\ will not work... Supposing you did follow these instructions to the letter (now, did you?): The this is how to fix the blotched step (6): Boot to DOS from a floppy disk or a cd or a pendrive Change partition Windows boots from (let's say it's C:\) Delete config.sys. Then, at the prompt type: Copy con config.sys <Enter> DEVICE=C:\WINDOWS\HIMEM.EXE /NUMHANDLES=64 <Ctrl>Z <Enter> A new config.sys, containing just the correct line will be created. Observe that to type <Ctrl>Z you should press and hold the <Ctrl> key and then press Z, and then release both keys. After this, remove the floppy and reboot. Tell me what happens. BTW, do you speak Portuguese?

Are you sure? Did you read my posts about system.cb in safe mode? They are here: http://www.msfn.org/board/more-than-win9x-safe-mode-t142953.html If my solution works for safe mode, it can be more useful than binary patches. @Usher: I've read it, rest assured. Your solution may well work. I have not tested it, nor can do it easily, because nowadays I use the RAM Limitation Patch, which I deem the best solution. It gives the system much more stability than any of the free solutions and access to all the RAM. Since I've got no experience with your method, I cannot recommend it, although this does not mean I'm implying it doesn't work. I simply never tried it, and, as far as I know, nobody else did, since you posted it. But I'm willing to add your thread and your machine to the > 1 GiB list, provided you PM me the description of your system, in the lines of the descriptions of the machines already listed there. But using xRayeR's patch is very reliable, and has been thoroughly tested by many users. Xeno86's modded VCache.VxD and xRayeR's modded IO.SYS are perfectly safe, there's no need to be paranoid about them, and they obviate a lot of work. I recommend doing the following (read this as a Mini How-To), which works for both Normal and Safe Modes: 1) Adding a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.INI 2) Installing Xeno86's modded VCache.VxD (after this, usually, no MaxFileCache line is needed in SYSTEM.INI) 3) Adding HIMEMX.EXE to C:\WINDOWS, and then renaming it to HIMEM.EXE 4) Applying MS KB311561, then rebooting. 5) Running xRayeR's w98iopat.exe, in True DOS, from C:\ 6) Creating a CONFIG.SYS in C:\, containing the single line "DEVICE=C:\WINDOWS\HIMEM.EXE /NUMHANDLES=64", without the inverted commas. For even better results, one should instead use RLoew's RAM Limitation Patch, of course, but that's not for free, and the above procedure is the most reliable way to do it completely for free, in my experience.