bristols

It looks like it contains atl80.dll, msvcp80.dll, msvcm80.dll, msvcr80.dll, mfc80.dll, mfc80u.dll, mfcm80.dll, mfcm80u.dll and other files version 8.00.50727.42. Petr Thanks Miko, great. Petr (or anyone), would older Visual C++ files (such ATL.DLL build 3.00.9782, MSVCP60.DLL build 6.00.8972.0, and the other files that MDGx specifies from VS6 SP6 Full) have to be removed before installing these later ones? Edit: Just noticed that MDGx has removed his instructions for extracting files from VS6 SP6 Full, and has posted an EXE which contains them: Unofficial VS6 SP6 Runtime + ActiveX Controls Libraries (DLLs) Thanks MDGx! But the question still remains - install the 2005 Redistributable that miko linked to (VCREDIT_x86.EXE), or VS6SP6.EXE, or both?

After I had replaced the buggy URLMON.DLL from KB912812 (build 6.00.2800.1538) with the older version from 905915 (build 6.00.2800.1526), I tried to install MDDACU 1.1. When the installer was "Setting up Control Panel", I got this error message: RUNDLL32 caused an invalid page fault in module KERNEL32.DLL at 016f:bff7a138. Registers: EAX=01472064 CS=016f EIP=bff7a138 EFLGS=00210212 EBX=0041c710 SS=0177 ESP=03befcfc EBP=03befd30 ECX=20616d6d DS=0177 ESI=0041c6a4 FS=424f EDX=64616f4c ES=0177 EDI=014720d0 GS=0000 Bytes at CS:EIP: 89 51 08 8b 53 08 8b 43 04 89 42 04 8d 93 0b 10 Stack dump: 03befd30 0041c6a4 00410000 00000000 bff7b31d 00410000 0041c6a4 0000006c 00000200 0041abb8 0041ac38 00000000 0041c6a4 03befd6c 65f014db 00410000 I had applied the Kernel Update to KERNEL32.DLL some time ago. Could the updated KERNEL32.DLL be the reason for the error message? Then I uninstalled the Kernel Update, and tried installing MDDACU 1.1 again. Same error message. After clicking off the error message, the rest of the installation seems to complete OK. What gives?

This post seriously needs to be made a sticky. Very shortly (after MS supports ends in July), new updates for 9x will become fewer and fewer, even assuming that there will be a few more unofficial updates to come. There's a danger that this thread will drop off the front page of the forum, and into obscurity. In this scenario, there's a real danger that 9x users coming new to these forums will never see this thread. This thread (and these updates) does serve a purpose apart from either the FE/SE/ME SPs. It baffles me why this hasn't been acknowledged by the moderators. Why not make this a sticky?

Ah, I see. OK, I guess you're both quite right and it shouldn't be used. Hope you didn't mind me asking - it seemed like something that hadn't been adequately answered before. Thanks for putting me right.

bad idea, bristols. using riched32.dll v5.00.2134.1 under W9x/ME systems may BREAK certain apps. plus file size of v5.00.2134.1 of riched32.dll file is 3,856 bytes. File size of riched32.dll v5.00.1461.82 is 203,024 bytes. Also LOOK at v5.00.2134.1 and v5.00.1461.82 of RICHED32.DLL's File "Properties" and look in the Version tab... ...so v5.0.2134.1 of Riched32.dll may be incompatible with 9XME systems and meant only for NT-based systems. I noticed all those things, erpdude (especially noticeable is the big file-size difference). But still: - I've been using RICHED32.DLL build 5.0.2134.1 for a few days. I've tested it with old apps that use it (some pre-2k). So far, no problems at all. - Other DLLs, such as several included in SE SP2, have the product name of a later OS (COMCTL32.DLL, to name just one) - Note eidenk's observations from a few months back: http://www.msfn.org/board/index.php?showtopic=61407&st=15 RICHED32.DLL build 5.0.2134.1 has no unresolved dependencies. So, given the fact that it is in RICHEDNT.EXE, I'm assuming that the only reason not to use it in 9x is that it breaks some apps. But I haven't found any reports that it breaks stuff in 9x. I'm just wondering if this build has been overlooked/forgotten about, when we could use it.

MDGx, why not use RICHED32.DLL build 5.00.2134.1 from your RICHEDNT.EXE file in your RICHED9X.exe file, too?

Maybe the reason is that none of these files is available in any Service Pack or update. This file only can be bought with Windows NT 4.0 or Windows 2000 or Windows XP or Windows Server 2003. Petr Incidentally, about RICHED32.DLL: the version included in the unofficial RICHED9X.EXE for 9x is 5.0.1461.82. The version that eidenk and Petr were talking about above is 5.0.2134.1, which was (at least) included with Windows 2000. However, there's another RICHED32.DLL included in MDGx's RICHEDNT.EXE (the same build number as the Win2k file, but with a later date: in Win2k it's 1999, while in RICHEDNT.EXE it's 2001). So, the fact that RICHED32.DLL build 5.0.2134.1 is included in RICHEDNT.EXE means that it is distributable, and can be used instead of the older 5.0.2134.1 in RICHED9x... right? I've tested it (98 SE) with no problems so far.

the_guy (and MDGx), thanks for taking the time to compile and post these. But like noguru, I also had a problem installing IE905495 and OE911567 (98 SE English, IE 6.0 SP1). Unlike noguru, the files did install for me, but not before I was prompted for 'missing files': with 905495, I was prompted for the MSIEFTP.DLL, and with 911567, I was prompted for the DIRECTDB.DLL file. On both occasions, the directory already suggested by the prompt window was the correct temporary directory containing the files. So, the files were found, and the installation continued. There was no 'reboot' prompt after installation (I guess that's intentional), but I confirmed that the files had been installed with SFC.

Thanks erpdude for checking again for KB908531. I really hope that it doesn't turn into a 891711-type situation. There's a good chance that 908531 will be the last patch issued by MS for 9x systems. What a way to go out that would be. I guess MS has run into problems with it. It has been reported that the patch released for 2k/XP/2003 systems is causing problems: Report about 908531 at Yahoo! News Perhaps the fact that it hasn't arrived yet for 9x is a blessing in disguise.

Using RICHED20.DLL build 5.40.11.22.12, I have the same Metapad result as you did Petr when you tried viewing your table in Windows 98 English (98 SE English here). So, "ě" and "č" don't appear for me in TABLE2.TXT.

Petr, MDGx's RICHED9X.EXE contains a later version of RICHED20.DLL than the SE SP - 5.31.23.1224: http://www.msfn.org/board/?showtopic=61407 Apologies for using this quote if more recent information/files make it obsolete now. I don't know if MDGx tested the later versions of RICHED20.DLL that are in your package, and he seems pretty busy at the moment, so I'm not sure if he's available to give any further input regarding his testing. I'll try out the two later versions (in 98 SE) and post back any findings.

Right beaker. What I meant was the inf/reg files and simply a list of required MS files - not the files themselves, of course. Look forward to your next post.

Excellent work, beaker. Could you post inf/reg files and the list of required files here? Otherwise, I think you'll get a lot of requests for them. If for whatever reason you can't/won't, could you please send them to me via Private Message?

Thanks MDGx, as usual, for posting the latest monthly security updates. Just to be clear, there's apparently still an outstanding update for 9x, addressing two Explorer vunerabilities, that, at the time of writing, MS has not yet released:

Yes, I did notice that the_guy is the author. Sorry for not making this clear. The version of ADVPACK.DLL included in the patch is 7.00.5335.5 (winmain(wmbla).060317-1722), which is timestamped, strangely, 01 January 1980. The version I have in %windir%/system is 6.00.2900.2180 (xpsp_sp2_rtm.040803-2158). Any thoughts, the_guy?

HI MDGx, Thanks for posting these. Sorry to report that I am still unable to install both of these patches. Here's the error message: Error loading advpack.dll. Any ideas?

Thanks guy. This didn't work for me. The error I received said: A device attached to the system is not functioning. I have no idea to what this refers. I'll wait for MDGx to (hopefully) post the corrected patch.

Same circumstances and problem for me when trying to install this update for WMP 9.0.

Yeah, that's unfortunate. Well, in this case, I'm none the wiser as to whether ROOTSUPD.EXE installed or not (because I didn't do a 'before & after' comparison of the size of my registry, for example). Thanks anyway erples.

Whoa, really impressive. As serta said, some of the text could be better anti-aliased (and I noticed that the font for the number "98" is not the same as the "Windows" font - Frutiger 45, right?), but I'm sure that this is something you will change for the final release. Which is exciting in itself - RPLite5. VIA KT600 board (VT8237 southbridge) AMD Athlon 2800 Inno3D 256MB graphics card (NVIDIA GeForce FX 5500 chipset, Forceware v.77.72) Viewsonic VP171s monitor (1280 x 1024 res.)

The first program I've found that uses GDIPLUS.DLL on 9x is the (fabulous) Quintessential Media Player (the latest development build 108, anyway). GDIPLUS.DLL is not native to 9x systems. Does anyone know of other programs that use it?

Nice one MDGx, thank you for putting this right. Thanks for this erpdude8 - good spot. Although it certainly contains updates to my current root certificates, I tried to run this file and it wouldn't install them (on 98 SE with SP2.1, and 98 SE with SP2.1a and 98SE2ME). Could you explain how you installed them, if it involved anything more than just running the .exe file, please?

Will do in the future.This would be great. Thanks MDGx.

Sure. This I understand. This is clear also. I wasn't questioning your knowledge at all. Right! This is kind of nearer to what I personally was asking about - installing individual files from ME updates, rather than trying to install ME hotfixes on 98SE by executing the .exe. I guess my question is/was quite simple (and the answer obvious, probably), but I just wanted to run it by you, to be 100% clear. Take for example the file WINSOCK.DLL - one of the 98SE files updated by 98SE2ME to a ME file. If in the future a ME hotfix turns up with the latest known build of this file - a later build than the one supplied by 98SE2ME - is there any reason why a person should not unpack the hotfix and replace their 98SE2ME-replaced WINSOCK.DLL file with a newer build? So, is it ok to manually update files that 98SE2ME has previously updated? Or, is the answer less than clear cut, so that one has to decide on a file-to-file basis? I hope these are slightly different questions to the one you have already answered. Edit: Thanks for asking that one again, PsycoUnc. I deliberately left that question out in this post, because it's my guess that this is possible, but that which of the newer 98SE files replacing older ME files will cause problems will be mainly only known as the result of trial and error, and in many cases these particular problems remain to be encountered (because I guess not many people have been installing 98SE2ME and then allowing 98SE updates to install files with lower build numbers than those of the ME files installed by 98SE2ME). Just for the record (for anyone who didn't follow the thread, and as an example of the situation we're talking about here), the recent unofficial CRYPT9x update contained a higher build-numbered but older and 'less functional' ME file than the latest, newer but lower build-numbered 98SE file (in fact I think it was the file CRYPT32.DLL, which had been updated for 98SE but not for ME). Petr pointed this out, and after that the older ME file in CRYPT9x was replaced by the newer 98SE file. Gah, I hope this makes sense.

Hi MDGx/PsycoUnc, I've had similar questions myself about 98SE2ME. So this means that: 1. The ME updates that you periodically post MDGx in the New 98 FE + 98 SE + ME patches thread are of no use to those who have installed 98SE2ME, even when an updated ME file introduced into 98SE by 98SE2ME is included in a ME update posted to the above thread? 2. Sometimes newer 98SE updates, which include files that surpass the functionality of a ME file introduced to a 98SE system by 98SE2ME, should be installed on such systems to replace an older (but of course, with a later build number) ME file? 3. If 'yes' to 2., a person would have to have some detailed knowledge about the functionality of the files in question, in order to decide whether or not the newer 98SE file should replace the older (but with a later build number) ME file? I had assumed that this was the case. I think it is. So for example, the latest 98SE2ME release contains the unofficial GDI32 WMF fix for ME. That's generally right, isn't it? Hah, sorry to be finicky/blind to any explanations provided so far.