dencorso

Thanks a whole lot, Rick Chauvin, for your efforts and for the link to the files! GE v4.0.2416 really does rock! I'm free of the blur, at last! It is wonderful to be able to use a flawless GE in Win 98 SE. Nice work!

Hi, eidenk! Now that you have it, could you pack the 4.0.2091 folder you have and upload it on Rapidshare ? I have no way of opening InstallShield packages > 10.0, so I'm willing to try it but cannot. BTW, once I have it, can I just downgrade manually the files or are there much different registry entries that must be dealt with? I'm presently using build 4.0.2742, which works, but then there is the blur...

888, Win 9x/ME is known to have issues with ACPI/APM, at least for some hardware scenarios. It has been discussed before, both here and elsewhere. Just google for it and you'll find lots of info on it. See, for instance: http://www.msfn.org/board/index.php?showto...45373&st=51 But most places imply you need to do a clean reinstal with "setup /p i" to get rid of ACPI and most don't tell you that you can remove the APM device and Windows will not spontaneously reinstall (redetect) it (for setup /p i see: http://support.microsoft.com/kb/q186111/). My wish was to point out that it IS possible to remove ACPI/APM from an already installed and configured system, without a reinstall. But, in any case, it is a procedure that ought to be done only when necessary. I am a firm believer that you shouldn't try to fix what isn't broken, of course. I never talked about "spontaneous reboots" after >7hrs... What I was talking about are "black screens of death", crashes in which windows returns to a DOS mode text screen and halts, after printing the message "Windows Protection Error. You must restart your computer." These things usually happen because of missing devices at boot time (by far the most common cause, as you can find googling for it) or with faulty hardware, specially bad memory. But it usually hapens at boot time, while the condition I described happens long after the system is up and running, usually after 7 or more hours. I never found it described elsewhere and it took me a long time and much trial-and-error to trace it back to ACPI/APM. I know for sure it is a problem on some ASUS and SOYO boards for AMD processors, having VIA chipsets.

Well, BenoitRen, it is easier to do than to describe. I've just done it again today on another machine and it took me no more than 15 min to do it all. After I'd done it I decided to edit my previous post, because I'd forgotten to talk about the I/O port range conflict that uses to appear, and how to solve it. So I think that now my previous post is a really precise guide on how to remove ACPI and APM... Chozo4, I'm glad your machine is so stable. I don't think the "Windows Protection Error"s I mentioned are software related, as I've seen them happen on plain vanilla instalations having just windows and nothing more. But I do believe they're BIOS or hardware related, as I've seen them only on Asus (A7V600-X or A7V400-MX) or Soyo (SY-K7VTA PRO) boards, and updating their BIOSes to the latest existing versions did not solve the problem. But removing ACPI and APM did the trick. They may originate in bad code deep within the ACPI/APM part of their BIOSes. Or they may be related to the VIA chipsets employed in all these boards. I really don't know. But, as BenoitRen's board is an AsRock, and that is related to ASUS, I thought my post might be of help. Of course, if the problem is related to the chipset, BenoitRen will never experience it. But others may. And there may be others who want or need to remove ACPI and APM completely for other reasons, whatever those reasons may be. But, up to now I'd never found on the net a detailed recipe on how to do it, so I decided to provide one. Then again, let me ask you: in a desktop, what's the use of ACPI or APM? There is no battery which charge must be preserved at any cost to worry about...

BenoitRen, if you want a stable machine, specially with more than 512MB, do away with ACPI *and* APM. Else you'll be plagued by spontaneous crashes with "Windows Protection Error" after >7h uptime. Here's how: 1) In the BIOS, fully disable ACPI and select PIC, not APIC, as the programmable interrupt controller mode. 2) Open regedit. Go to HKLM\Software\Microsoft\Windows\CurrentVersion\Detect and add as a dword value ACPIOption=2. Close regedit and redetect your hardware: windows will remove all ACPI related devices from the system and add APM. 3) Right-click on the desktop, select Properties -> Screen Saver -> Energy Saving Features of Monitor -> Settings -> Power Schemes and select "Always On", "Never" and "Never", the select Advanced and uncheck the "Always show icon on the taskbar". Click Apply, then OK, and reboot if so requested. 4) Open MSConfig, select "Startup" and unchek both "LoadPowerProfile" boxes (there are two of them) and click Apply , then OK, and reboot. 5) Right-click on "My Computer", select Properties -> Device Manager -> System Devices -> Plug and Play BIOS -> Properties -> Settings, check the "Disable NVRAM/ESCD updates and click OK. Now select PCI Bus -> Properties -> Settings, check the "use hardware" option for Device Enumeration click OK. Reboot if so requested. (note of Nov 20, 2008: this next step can be omitted, because some machines do not accept disabling IRQ steereing, although most do accept it) Go back to Device Manager -> System Devices -> PCI Bus -> Properties, select the IRQ Steering tab and uncheck "use IRQ Steering", click OK and reboot if so requested. 6) Right-click on "My Computer", select Properties -> Device Manager -> System Devices and if it shows an "Advanced Programmable Interrupt Controller", right click on it, select Properties -> Driver -> Update Driver -> Specify the location of the driver -> Next, check "Display a list of all drivers...", click Next. It will show only the driver already installed. Then select "Show all hardware" : A listbox will appear. In the (standard system devices), choose "Programmable Interrupt Controller". You'll receive a dire warning. Ignore it and click "Yes". Reboot. 7) Return once more to Device Manager -> System Devices and select the "IO Read Data Port for ISA PnP Management", go to Properties -> Resources. If it says "The resources this device is using do not match any of its known configurations..." click on "Set Configuration Manually". There may be a conflict on the addresses of the Input/Output Range 0374-0377. Click on Change Settings and select a new range from the list that shows "No devices are conflicting" in the Conflict information box (usually 0384-0387), click OK, OK, and reboot. 8) Return once more to Device Manager -> System Devices and select the "Advanced Power Management support" and *remove* it. Don't redetect the hardware and reboot. It'll not reappear automagically, but you should check for it every time windows finds new hardware, to remove it yet again if it ever reappears. 9) And, particularly if using more than 512MB, do not use EMM386.EXE at all. (Maybe many will disagree with me about it, but in my experience Win 98SE and EMM386.EXE, Netroom, QEMM or 386-to-the-Max don't mix, with more than 512 MB of memory, and, in fact, they are unnecessary to run windows). And enjoy a stable Windows 98SE! HTH. Win 9x rocks! Of course, the standard disclaimer applies: YMMV and I may also be just a raving madman, but, then again, anything you do is of YOUR SOLE RESPONSIBILITY, anyway... You have been warned.

I have removed those 6.0.2900.xxxx files because they are meant for MS IE 6.0 SP2 , which is installed by XP SP2. I recall having some minor issues while using them a while back, so I reverted back to older XP SP1 [MS IE 6.0 SP1] files, which provide better compatibility with 9x OSes. But if you'd like to use them, please feel free to do so. [...] Thanks for the feedback, MDGx. Well, I've actually been testing some MS IE 6.0 SP2 files for a while, so here are my findings: I've used BROWSELC.DLL 6.0.2900.2180 for some time but gave up on it, because I found it to be too resource-hungry: I'd get a Low Resource error message just by browsing around the MSFN forum in Hi-Fi Version, and if I don't change to the Lo-Fi Version quickly enough, my system would go down to 0% GDI resources with all the usual associated bad things happening... I've reverted to BROWSELC.DLL 6.0.2800.1106 and this issue went away. It seems that PROBLEMCHYLD had found a similar problem with BROWSELC.DLL 6.0.2900.2180, in a rather different scenario. See: http://www.msfn.org/board/index.php?showto...p;p=567490& On the other hand, I've been using the 6.0.2900.2180 builds of BROWSEWM.DLL SHDOCLC.DLL and SFOLDER.DLL for about a fortnight now, with no apparent problems happening so far. However, if I ever find any issues with any of them I'll sure post about them. But, in view of your message I've decided to downgrade to build 6.0.2800.1106 ADVPACK.DLL and ASCTRLS.OCX, just to be on the safe side. I do realize that I'm perhaps somewhat off-topic with this message, but since half the files here mentioned were once part of 98SE2XP, I felt this would be the place to post. Should I have posted to the main updates + patches + (hot)fixes topic? Please advise. Thanks once more. Best wishes.

msvcrt.dll v6.1.9847.0 works on BOTH Win98 SE AND WinME, dencorso. I know this because that file works fine under WinME and even under Win95. I've used that file on other 9x versions of Windows and found no problems with that file. Thanks for the feedback, erpdude8!

Hi, MDGx: Way back then, you used to distribute: ADVPACK.DLL 6.0.2900.2180 ASCTRLS.OCX 6.0.2900.2180 BROWSELC.DLL 6.0.2900.2180 as part of 98SE2XP. Then you reverted to older files, and they aren't part of the present 98MP10. Could you please tell me what issues did they cause? I've looked arround both the forum and your site, but didn't find any hint on what happened. And I found no version history for 98MP10 that reached to 98SE2XP times. Can you please help me? Thanks. I'd be grateful also if other members of this forum who had/have experience with these files were willing to report their findings on their use. Is there anyone that still does use any of them? Thank you all!

Hi, PROBLEMCHYLD! This is a characteristic behaviour that is inherited from good old MS_DOS: The command interpreter can have any name. This is "by design". Moreover, it doesn't matter whether the extention is .com or . exe, since both are known to the SO as "executable". But probably it will stop working if you change the extention to .pdf or .txt ... On the other hand, from the point-of-view of the program loader, if the extension is executale it goes ahead and tries to execute the file, then checking the file format signature, to be able to do so: if none is found it wil assume it's a .com (executable image) format and try to execute it from the first byte, whereas if a format signature (MZ, PE, NE, LE) is found it will take the known necessary steps to load correctly the diverse segments of the file, and then transfer control to the address found in the program file header. By the way, MS-DOS 7.1 COMMAND.COM is, in fact, an .exe file, as can be seen by loading it in any hexeditor and observing that the first two bytes are MZ. The name is just a nod to older times. All this said, there remains the question of cmd.exe's depen- dencies, which are another reason for it not to run under Win 9x. But that's another matter entirely. In the past, there was a "fever" for replacements of the DOS command interpreter, the best know of which was Norton Utilities's NDOS.COM (who else still remembers of it?)... HTH

IMHO, that is an example of a wrong/misleading error message: it means the library already is registered and loaded. Somebody please do correct me if I am wrong, but I think what happens is regsvr32 does not succeed in loading the dll (because there already is another instance of it running) and terminates, sending that error message. At the end of the day, it amounts to what eidenk just said: there is no need to regsvr32 it.

MSVCRT.DLL 6.1.9847.0 from KB838751 works flawlessly with Win 98SE, I have been using it since May 06, 2007 without any noticeable problem. It is described in <http://support.microsoft.com/kb/838751> and is available from MDGx's site at <http://www.mdgx.com/files/Q838751.EXE>. It has to be installed manually, since this hotfix is intended for Win 2k. But I think repackaging it as an for Win 98SE (and probably also for Win ME) is worthwhile as, IMHO, this is the *last* build that works properly with those OSes (even if I didn't test it with Win ME, I see no reason for it to be compatible with 98SE and not with ME).

A viable alternative to Oxygen Manager, that I guarantee works flawlessly in Win 98SE is MobTime Cell Phone Manager 2006 (at least up to v. 6.0.9, which is the one I now use). It is shareware, like Oxygen Manager. And it is very resource-hungry, meaning you must run it almost alone or else your system resources will drop to 0%! But, then again, you don't need to access your mobile phone longer than to be able to back-up your data or to upload things to the phone or to download from it, hence its resouce-hunger is not a very big nuisance, IMHO, but YMMV, of course. My phone, BTW, is a Nokia 6111. The link to find it is: http://www.mobtime.com HTH

Dear MDGx: I do appreciate your 98SE2ME a lot. But the modded SYSDM.CPL 4.90.3001 included in it, besides saying "Microsoft Windows 98 Second Edition", instead of "Microsoft Windows ME", suppresses the display of the version info to avoid the old "4.90.3000 A" version mistake from appearing. But there it remains... So I decided to try my hand at it and modded once again the SYSDM.CPL 4.90.3001, which I got from ME280800.EXE, for it to say "Microsoft Windows 98 Second Edition", but did not suppress the version info display. All I accomplished up to this point was to get the "4.90.3000 A" version apearing once more... But, it turns out that SYSDM.CPL gets its version info from inside USER.EXE (of which I use 4.90.3001, of course!). In fact, the ASCII string "4.90.3000" can be found inside it exactly three times. The last one is part of the version info resource, so I let that one alone and hexedited the other two to be "4.10.2222", and, bingo!, now SYSDM.CPL shows the windows version correctly as "4.10.2222 A". I have been using these two modded files on my system for over a fortnight now, and have detected no adverse effects from the above described mods. So I feel confident they are safe. Hence I decided to post here about my modded files, in case you, or any other member of the forum, find them interesting. They can be downloaded here: Nu_Mod.zip Keep on the great work!

Greetings to you all! This is my first post to this forum, although I've been reading it for some time now... I've been experimenting with the files posted by whatever420 and here are my findings: I have the latest OLEUP installed in my fully updated Win 98SE system, so I started with these files: ASYCFILT.DLL 2.40.4528 OLEAUT32.DLL 2.40.4522 OLEDLG.DLL 5.0.1601.0 OLEPRO32.DLL 5.0.4528 STDOLE2.TLB 2.40.4528 Since whatever420's post, I've been running OLEPRO32.DLL 5.0.5014 instead of 5.0.4528 and COMCAT.DLL 5.0.2600.1 in my system, having found no apparent problems. It's been about a month already, so I thought I should write you about it. Previously I had been using COMCAT.DLL 5.0.2195.1 (I can't remember whence exactly did I get it...) It also worked fine. But these COMCAT.DLL are all 5.0, as is also COMCAT.DLL 5.0.1601.1, installed by 98SE2ME so the all should work well with OLE32.DLL 4.71 (I use currently OLE32.DLL 4.71.3328.0) See http://support.microsoft.com/default.aspx?...B;EN-US;Q201364 Then again, OLEPRO32.DLL 5.0.5014 is a different matter, because it's OLE 3.50 and all the files installed by OLEUP are 2.40, including OLEPRO32.DLL 5.0.4528, but it is an experimental fact that it works well, at least in my machine. So, despite the fact it's OLE 3.50, OLEPRO32.DLL 5.0.5014 seems to be the most updated version of OLEPRO32 to run correctly on Win 98SE... As for the other OLE 3.50 files posted by whatever420, I agree with MDGx: they do not work correctly on 98SE.