CLASYS

That's correct. And it works fine in 98lite. However, I don't seem to have a sort menu command!Perhaps there is a registry patch to restore that function? cjl

Expected value. When chips aren't asked to do the ultimate impossible, they continue for centuries to do the possible.Today memory isn't even unit-tested. All is done by statistics. Pull out a few random samples, subject them to accellerated testing [probably to the point of destruction!] and in essence find out the ultimate slowed-down access speed that can be reliably depended on when the chips are old. Then test the entire lot merely for current access speed and basic functionality. Assume the entire lot will behave as compared to the samples subjected to the intense testing, perhaps with a tiny derating safety factor to hedge against the possibility that the samples weren't actually representative, but were perhaps a little "hotter" than the rest, etc. Given the amount of powered-on hours on average we put computers to, an honestly rated system that has worked fine for three years should never have a RAM problem due to aging. That said, the occasional cheater still comes up where the memory ages below the point of reliability. [Please note: I have already changed the RAM on several box-makers machines due to proven failure; none of them were as much as three years old. I guess the memory is rated to get past the warranty period and then crap out!] In the world of laptops, there is a pervasive conventional wisdom about a quality point of "new memory" which of course begs the question as to how the original memory came to be known as "old memory". I had to help someone with a ThinkPad that was failing. The memory turned out to be from mr alphabet-soup instead of the original IBM [and it could have been and should have been an upgrade, but instead the original was removed and replaced with the third-party twice as large; this smells because if the original memory was present, the cost to upgrade to double memory should be less than replacing with the "new" one, etc.]. I suspect the eBay seller of this machine was creating a dichotomy of machines with IBM RAM culled off of such as this one, doubling up on IBM RAM on reliable models, and selling off the "new" memory machines for more memory because they were "better" etc. cjl

You can keep your beliefs. I'll stick with the information from the chip manufacturers. Actually, you do have it somewhat right.This is not a matter of "wearing out" as much as migration. The net effect is that undesirable capacitance builds up and the absolute maximum speed the chip could theoretically be accessed at becomes lower. Most of the effect occurs in the early years and mostly while the chip is powered on [as opposed to just lying around or being ambiently heated; however higher temperatures while powered on can exacerbate the situation, this is the basis of accellerated testing.] Of course, if the SPD chip is limiting required access speeds to far slower than that, you never have a problem! Back when my IBM PC II was new in the early '80's with original RAM, each motherboard was "burned in" with the entire board subjected to testing. As machines got newer, less testing was done. I suspect your XT 286 board was still using burned-in RAM that was thoroughly tested for ultimate [and lowered] speed, and then timed to match. Back then, there was always some joker who thought that it was cool to set less wait states than the chips were marked for because "it worked". Of course it only ACTUALLY worked for some months! [The fix, of course, was to honor the RATED speed, not the casual observation speed!] The sleezeballs from back then sold reject memory and people were duped into using it as if the markings could be trusted. These machines failed because the real speed of the memory was such that when new it barely passed, and as it aged, it went into unreliable territory at the claimed speed. In some machines, you could have wide lattitude on setting wait states to compensate, thus you got a slower machine but at least it worked. If the memory was that bad, then you were SOL for buying crap quality, etc. Ever since we all switched to SDRAM with the little SPD chips on the memory board, all of this should be moot. But this doesn't stop Mr. three-letters and his brethren from making crap memory boards that claim the eventual speed to be the same as the when-new speed, and without a mobo that can compensate [and slow down] you are SOL with them when they age, etc. cjl

maybe. or maybe not. we shall see. I havent seen or experience any of the memory modules I've used on my computers get any slower. perhaps is US (computer users) are getting faster and have a perception that memory modules are moving a little slower. we do live in a fast changing world today. Glad your memory modules aren't too unreliable as they age ..... AND GET SLOWER.erp: You apparently don't get the point: Your memory chips are getting slower; they all do. If you bought reputable modules, they were rated for the slower speed they become, not the fleeting-fast you get when they are new. Your machine does NOT change the access speed to the memory at all! Your USAGE of the memory never changes [unless ...] but the chips are getting slower. Your machine is likely one of the overwhelmingly large number of machines that have no manual memory timing capability. What happens instead is there is an SPD chip on the DRAM board that the CPU and BIOS POST program reads to dynamically determine what the speed of the memory [apparently] is. If you have a reputable chip, then the SPD timing is consistent with where your chips are when they are old, and still some additional "headroom" to perhaps age further, all this harmlessly. So, in this case [consider yourself fortunate] then no matter how old or slow your memory gets, it still meets or exceeds the requirement of the overall system as reported to same by the SPD chip. But clearly, it is getting closer to merely passing the requirement; when it was new it passed it with flying colors, but no more. The problem is that there are sleezeballs in this world that sell memory that is NOT capable of long-term use [i could mention brand names, but let's just say that companies with three random letters in their name as a group have been the most problematic over the years]. The SPD chips on these modules are too ambitious; the chips fade and the module becomes the source of erratic behavior; the system cannot slow down to match the newer less-capable SDRAM because it is obligated to honor the timing offered up by the SPD. In an honest world, these parts should never have been sold together. Sometimes you find chips honestly rated lousy, such as CL3 instead of CL2.5. Clearly these slow your machine down from day one as compared to the 2.5 ones, but perhaps it's an honest rating that will always be met in the long run. Clearly the same chips should not be soldered onto a board where the SPD says this is a CL2.5 overall device! I had an encounter with a machine based on an AOPEN board which actually supported manual timing to override the SPD chip. It was getting really flakey, and I hadn't been to it since it became about 2.5 years old and quite unreliable. [Previously I was there when it was 6-8 months old and not a problem.] As a bandaid, I was able to retard the memory timing, over-riding the SPD timing. The machine was noticeably different - quite slow and quite reliable. A good trade-off temporarily. I came back later with good memory; it worked fine and just as slow; then I enabled the timing-by-SPD and it got faster again, but continued to work reliably, as expected. [All this happened about 8 months ago; apparently still working fine; the old memory was made by a three-letter-company, etc.] With regard to laptops specifically PC-100 SDRAM: There are some problematic models of laptops that, while rated expressly for PC-100, do NOT like just any old PC-100! This is not an SPD issue [which is probably also present!] but an aberration of certain Intel chipsets. Basically, PC-100 SODIMM laptop memory comes in two flavors: One is noted by the fact the board is filled with a bunch of chips that are clearly quite rectangular, generally standing vertically next to each other, and probably at most 8 on a side [assuming there is anything on the back side]. If these are 128 MB or larger, they may not reliably work! [Again, it depends on the precise implementation of the chipset on the mobo.] The one that will ALWAYS work [assuming the SPD problem above is honestly dealt with] is the one where there are 16 little chips on a side, where each one is essentially a little square chip [which is pretty much the only way to get 16 on a side in that tiny SO-DIMM package!]. Generally, this version costs more; many places sell the former for less than half of the price of the latter! But if your system is one of those that requires the latter, you are wasting your money; they will fail quite quickly, perhaps even on day one, but more likely within 6 months to a year, NOT because they are fraudulently rated, but because the chipset requires "low-density" SDRAM and the 8-chip variety is "high-density". [slightly more technical detail: Chips are organized in a Zx1 and a zx4 configuration internally. You get to the same place, but in one arrangement, the physical chip is supplying 4 bits at once, containing 1/4 the address space, while in the other arrangement, each chip supplies 1 data bit, but there are 4 times as many addresses.] The downfall of the x4 [high-density] chips is that they are inherently slower to access, and this is NOT accounted for in the SPD. If the memory socket and support chips want the low-density only, then the high-density will be either flakey, short-lived until flakiness, or downright just won't work even when new depending on circumstances. In the [now somewhat obsolescent] world of PC-100 SDRAM DIMM modules, the same problems happen, but generally there isn't a price gouge assocatiated with specifying low-density. Another watchword could also be that the module is PC66 or PC100 compatible, which is NEVER the case with the high-density [assuming the info is accurate!] I have a system based on a PII-333 that loves PC-66 and low-density PC-100 but totally hates high-density PC-100. cjl

Perhaps because of 98lite CHUBBY shell, but no such option when I right-click on the Start Menucjl

'scuse if this is an old topic: I have a large/long Start Menu in 98SE and the default behavior is to show only the elements that fit from top down. At the bottom is an arrow I can place the cursor on that will send the menu up, eventually so only the bottom most are on the screen and the arrow is now on the top. Stopping short of this, arrows will appear on the top and bottom. Isn't there a setting somewhere to make it instead open multiple column so that all of the items are on the screen at the same time [unless I run out of screen space for all the columns!]. I believe this is the default behavior for Win95 that I seek. On a related note: How do you get sorting of the Start Menu items? I run CCleaner to remove something called the menu-order cache, this seems to help. tia, cjl

Actually, no, you can do it before, which is often preferable.As I have documented before, using 98lite or IEradicator to remove IE 5.0 in 98SE requires a counter-intuitive installation of IE 6.0 or 6.0 SP1 if you intend to update Outlook Express with any of the rollup-class OE updates to IE/OE. Even if you install 98lite after, you still would have to not yet upgrade past IE 5.0, then let 98lite add/remove it and you should remove it, if the goal is IE 6.0/6.0 SP1. Also, any shell-swap is now useless. Pick any you want, but be prepared to stay with the choice; the mere attempt to shell-swap [even to the currently used shell!] destroys the whole IE/IE 6/6 sp1 installation; you have to remove and start again [as I documented elsewhere] but it will work [after all that effort]. Can anyone help me with a small detail: There is a bug when installing 98lite before: You lose the personal web server, no option, no nothing. Is there a specific program to run that puts personal web server back? If this cannot be accomplished and you need PWS, this is a deal-breaker for using 98lite before/during and you must use after. 98lite initially doesn't address web folders, but after it's installed, that option appears [unchecked at first; you can enable it]. In 98lite, there is a checkbox for removing IE 5.0. This is technically correct, or at least initially. Problem is that IE 5.0 being seemingly present is a prerequisite for adding on Windows Update, which has also become an add/remove object. The fix, documented somewhere on litepc.net is to perform a registry patch that makes it appear that IE 5.0 is installed. [This is a registry setting meaningful only to 98lite.] You need to perform this if after IE 5.0 is removed/was opted out on a before-type install, you actually did put back IE, presumably a newer version. Checking the box will actually attempt to install IE 5.0 back, likely corrupting things if you have already installed a newer version! Thus, use the registry patch to set the checkbox, not the actual operation of checking it, etc. cjl

All 9x versions have a fake Write.exe that instead uses wordpad. The original can be taken from Win 3.10/3.11/WFW. Ditto for Card.cjl

Hmm...Using the 905915 update for IE 5.5 SP2 as the source for the Browseui.dll makes perfect sense, since apparently Browseui.dll is part of the cumulative updates and actually hasn't changed since 867282. Also, apparently Browselc.dll was never updated beyond original release in both IE55SP2 and IE60 SP1. Only question: Since 912812 for IE 6.0 SP1 is itself known to be broken [urlmon.dll], current practice would appear to be to first install 912812, THEN run urlmonfx.exe [that is the two-step approach, isn't it? Nothing else to do, no reg changes, etc.? mgdx site shows much complication, but is urlmonfx the equivalent of all of those steps, or not?], does doing this partial back-out change anything? Meaning the browseui.dll file moved to the \program files\Internet Explorer should be taken from 912812 even though the rest of 912812 isn't [all] there? cjl

What's dial-up? cjl (Optimum Boost 2.1 MBps uplink, 28.4 MBps downlink)

You need to install the SP 2.1a. This is really important because there are a whole lot of laptop-specific 98 updates already in there, and all will get applied at once. Then upgrade IE to at least IE 55 SP2 and all of its upgrades. At this point, there are some considerations: The totally CLEAN way to run is IE 55 SP2 and all of its upgrades. You need to goto ERPMAN (erpdude8) site to get the collection, since some of them do not run "naturally" on 98SE, so he has posted some that have been "synthesized" to be 98/98SE-compatible. Alternatively, you can upgrade (as MS advises) to IE 60 SP1 and all of its upgrades. [small note: As reported by Petr, you need to download the root certificates update in order for Windows Update to download this for you, should you choose the WU method of obtaining this, etc. I don't use WU ever, other than as a post-install check so it properly claims I need no updates, etc.] If you go with IE 6 however, you then have to get two replacement files BROWSEUI.DLL and BROWSELC.DLL and move/replace them as defined in other threads. [They come from IE55SP2 and any update to same from Q867282 or a newer rollup that includes it. The LC file is in the original release; the UI version is in the update. Run the update executable on a command line with the /c option to enable self-unpack of the update instead of install, etc. Shut down to real MS-DOS mode to replace the files after first copying them to the \program files\Internet Explorer folder. The copy can be done from Windows, but the replacement only from real DOS.] Replacing these files prevents 98SE from locking up badly. The problem is aggravated by lotsa file move/copy/delete/empty recycle bin etc., or large file same operations, or speed of CPU. So, unless all you use it for is to launch programs that don't save files, consider this mandatory. So, take your pick; either way I don't advise staying with IE 5.0, which is the only version the SP 2.1a will update. IE 55SP2 is the best version prior to 6 and avoids the lock-up problems; IE 6.0 SP1 is the best post-55 version and the two-file fix remedies 99% of the problem. [Note: An alarming trend: Many programs such as free on-line anti-malware scanners are starting to require IE 6.0 or higher, not just IE!! A notable breath of fresh air is Trend Micro Housecall version 6.5, which allows you to dump IE entirely by specifying a Sun Java-based version by default, so all you need is Netscape/Mozilla/FireFox/Opera, etc.] Depending on your other needs, there's a bunch of MSXML and MDAC updates available [see MGDX site for details]; WU will demand you install a little bit of that typically. Generally important to get the latest [for 98SE!] drivers for your machine. Recommend you install them before doing anything else. If this is a ThinkPad, you can get a laundry list of what is available by placing the model number in at the website, etc. Many are generic to most ThinkPads, but some are always model-specific. Other vendors have similar, but generally less-well organized, etc. The rest is up to you, but no different from any other machine in terms of AV/spyware protection, utilities, etc. You should get the ME scanfrag package for those two gems that run on 95, 98, 98SE as well as ME. cjl

What a newbie you are: My LINC-8 is up and running and was my first computer in 1975 when it was already 9 years old. I have at least 20 computers older than your new-fangled toys! LINC-8's run software based on pointing devices that interact with the screen stemming all the way back to the forerunner 1962 LINC. Anything called DOS [much less Windows] is clearly ripped off from a variety of Digital Equipment [DEC] O/S's all written prior to 1970. Oh, and btw, Windows was NOT written by MS for PCs; rather it was written for the Rainbow in the '80's and only later grafted onto PCs. I have the 1970 12" Sony first color set working fine [soon to need a convertor for digital TV I suppose, as do you!]. cjl [and don't get me started about the 029 keypunch and card-reader in the basement!]

I am aware of this; and I also believe some in-between updates install other IEPEERS.DLL versions newer than 329919 but less than the still-broken 912812.This whole 912812 mess is very boggling. Why should it matter which version you get on that file? Why does it need to have a registry setting to manage which one "deserves" to be present? As it stands now, can I install 912812, then run URLMONFX.EXE to get URLMON.DLL backed to the last good version [or do I have to also do anything else; there are so many versions of fixups for this; does this newest one just have to be run as I describe above, or is there still more rigamaroll to perform to get it to work? And is there any interaction with the IEPEERS.DLL stuff as a result?] A side issue: I just noticed that I posted three independent replies to this thread [with no one else intervening], but the forum has decided they are one giant post! What gives on this? cjl (trying to break posts down to manageable size, but the forum software is punishing me )

See the top of the thread. It just says it's on the MGDX site; Anyone know where it actually stems from [user-written?]cjl Why have you got a problem with those two ? Because they are user-written and need to know what option switches are used for them. Also, they are known to interact strangely with the O/S under some circumstances such as opening for browsing to get some update files, etc.cjl Since there is no mention of 98 or 98 SE, I assumed that for some reason this update wasn't suitable them. Could anyone put me right on this?] The KB article says it's for 98 and 98 SE as well. cjl

Dunno about SIMS 2 other than obnoxious check for O/S superfluously is a spreading disease. Here's a potential fix for the entire problem: Install the game on XP as it desires to. Preferably use MicroHelp Uninstaller monitor [since bought out by CyberMedia and then Mcafee; same product, different corporate logo] since that is better than Uninstaller guessing after-the-fact. Use the uninstaller to uninstall the app; this makes a .ZIP file [with an alternate extension, but it is actually .zip compatible] containing the essence of what was installed. Use the "transport" option when doing this. Then take the whole mess to the 98SE system and run the "install" of the transported application. [The "install" is just a script that puts into the system each and every item, file, .dll, registry setting, etc. that was noticed by the uninstalation, especially accurately if installation monitor was running at the time, but even after-the-fact, it's a good guesser.] This should make it run if possible on the descendent system. A couple of tips: 1) It may be necessary to install it on a system with the same system drive volume letter as it was installed on originally. Remember that when dual-booting or substituting 98SE for XP. This is NOT a matter of being on Drive C:, as these days virtually nothing is drive-C: bound [perhaps some bad defaults in install software, but can be modified at install time, etc.], but is a matter of installing on the same system drive as was the first time around, etc. If the app is clean, this shouldn't matter; the "transport" option knows what to do for well-behaved apps. 2) To prove you even have a ghost-of-a-chance to get it to work, since you don't know if it works on 98SE in the first place, try this first: Install transport package on another XP system on that same hardware on the same drive [essentially an earlier backup of what you have now, except before the app was installed]. If the app works where it was never officially installed normally, this at least proves the transport package was completed correctly. Failing this test, attempt to sleuth out what went wrong with uninstaller that it didn't get all of the right pieces, etc. [sometimes a .DLL issue you can iron out first!] For the most part, this test passes easily if you used the installation monitor in the following manner: 1) Install XP virgin on the machine; no other apps. 2) Install Uninstaller; turn on installation monitor and reboot. 3) Install APP. This makes the subsequent transport the smartest and avoids the most .DLL missing problems since no other app can interfere with the file placement process that the app was performing, etc. In any case, the transported package doesn't check for O/S version and runs on Win95 and up. If the O/S features aren't relevant, it should run. Generally, O/S sabotege is in the original installation program, not the app inherently, etc. Good luck! cjl

Petr: What's the EARLIEST Root Certificates Update that allows WU to work now? [Apparently not the Jan 2006 version necessary.] cjl

Just make sure your AUTOEXEC.BAT file ends with: CLS <make sure no CR and LF here!> This solves the entire problem. Use notepad or whatever to ensure there is no trailing CR or LF past the CLS cjl

"Outlook Express could not be started because MSOE.DLL could not be initialized. Outlook Express may be intalled incorrectly." This is a familiar error message to me. Not likely the same scenario, but when you use 98lite, beware of the following: Due to some interactions not fully understood, something in OE can easily get corrupted yielding this complaint. Somehow 98lite ticks off something in the O/S such that the Outlook Express hotfixes, going all the way back to Q330994 through just about every OE rolled-up update since, will yield that complaint. Here is how to fix it in this situation, and perhaps it will work for the present complaint as well: You have to completely remove IE. In 98lite, that's a standard feature. The freeware version from litepc.net is IEradicator and will do the same job. If you are a 98lite user, there exists the so-called SLEEK and MICRO shell choices. If this is the case, you have to create a patched copy of the file LOADWC.EXE that links to SHELL32.W98 instead of SHELL32.DLL. If you are not a 98lite user, or a user of 98lite CHUBBY or OVERWEIGHT shell choices, then the solution is the same as for a non-98lite situation. Install IE 6.0 SP1 with OE 6 the normal way. Remember, this is over no prior version of IE/OE, that's what IEradicator [or telling 98lite to not install IE] does! Normally, this is an upgrade process, but in this case it is NOT! [And it DOES matter!] When you are at the end of the install, it asks you to click to restart the computer. If using MICRO or SLEEK, you have to now copy LOADWC.EXE [the one patched] to \WINDOWS\SYSTEM over the one that was put there by the install. Ignore this step otherwise. Reboot, and IE/OE gets installed [again, this is NOT a re-install, since it has been totally removed; this is a VIRGIN install of IE that can only be compared to installing IE55 over Win95, the last system IE 4.01 or newer was never bundled into, etc.]. Now, the key step: Reinstall IE yet again. Always choose a custom install at this point. Just click on all the components you want, but you must choose at least all the ones in bold [because they were there before the problem!]. This will lead to a message telling you you don't need to reinstall IE. However, it gives you an option to reinstall all of the components. Do this despite the recommendation to the contrary. [Note: In rare cases, only so far seen in WinME, the message doesn't come up on this second IE install attempt; it will come up eventually, and you have to keep reinstalling until it does; the largest case known was it took a total of four installs to get the message, but it eventually does happen; the overwhelming expected value is the second install.] At this point, IE and OE should completely work, but need a large dosage of Windows Update or equivalent since you now have the 2002 version of IE and OE and no patches. However, all of the updates will install and not corrupt OE which was the original complaint, etc. Failing to do the reinstall with the message will seem to work, but is guaranteed to fail when you attempt to add any OE update [from Q330994 to the present] again yielding the same exact error message. Thus, this longer remedy is the only complete way to solve the problem. We don't know how/what gets corrupted in OE, but this method always sets it straight. All of the intuitive but lesser attempts don't work. [Historical note: Q330994 was about the 7th update from Windows Update for IE/OE many months after initial release and all seemed fine until the baffling problem that adding in Q330994 just broke OE. After a lot of false starts, this method was hatched as a permanent solution used to this day to fix broken OE and avoid a system-wide reinstall if all else is fine.] cjl

As LLXX knows, the discussion here is a bit ignorant; please read the 98SE Service Pack subforum for a comprehensive answer to this discussion. Here's a few things: 1) You need a maintenance system for XP, Vista, or whatever incomplete M$ system you choose to run. Laugh all you want while reading this, unless you are one of the more knowledgeable who likely have learned first hand when XP crashed and burned and you needed a maintenance system to bail you out [an ever-enlargening group). 2) The best defragger for your machine is from WinME. It runs on Win95, Win98 (First Edition, the one from Nov 1997), Win98 (Second edition, the one from Apr 1999), and WinME. It runs anywhere from 10-100 times as fast as anything you can run on XP, regardless of price. Compare to the built-in XP defragger which cannot a ) do more than one drive at a time, b ) Is ludicrously slow, c) cannot be scheduled so you have to be there to start it, end it, and if multiple drives start each driver's defrag. We recommend 98SE to run this from. 3) Show me a system as stable as 98SE as modified by the Unofficial Service Pack project we have on the sub-forum. M$ allows everyone to run systems with literally hundreds of known bugs unfixed. 98SE was no exception, except that now that is no longer the case. 4) 98SE cannot be virused to the point that it itself is incapable of noticing the malware contamination. XP and eventually Vista cannot make that claim. I have had too many personal experiences with XP virused such that with every tool at my disposal, XP claimed to be malware free, yet booting to a 98SE maintenance system on the same hardware, a trivial on-line free scan showed kernel contamination [such as in SVCHOST.EXE] that uses all of the system's protection mechanisms to protect the virus from detection and eradication. Another Vista/XP/2000 system could have been equally contaminated, thus these are not good candidates for maintenance systems; 98SE cannot get in so deep without either noticing something is wrong or being revealed to have invaders that show up with available anti-malware tools. 5) 98SE supports large disks, but may need to be properly configured. As a practical matter, maximum partition size is limited to 137 GB per partition, NOT overall hard disk size. There is support for SATA, but it depends on your hardware as to whether it's compatible or not. In the case of BIOS-compatible SATA, this is supposed to be a non-issue, else admittedly it becomes an issue of driver availability. Pretty much if you can boot to an original XP CD on your laptop, 98SE can handle it. Some hardware needs a diskette containing a system driver expressly for that hardware. If so, you may be SOL with regard to 98SE, but it depends on the third-party who provides the drivers, not a 98SE issue per se. 6) For some applications, the second core of a dual-core system is ignored even within XP, other than you might hope that an application is aware of the second core and claims it as its own. Admittedly the world of apps is split on this point, and 98SE always loses if XP should win. That said, a lot of applications run faster on 98SE. YMMV of course. So, yes, run XP if you need to, but don't delude this into a panacea, since clearly it isn't one. None of us want to run maintenance systems, but all of us need them. Not a matter of if, but of merely when. cjl (noted and acknowledged contributor to the Unofficial Service Pack for 98SE; by no means the largest)

How about a webpage with hyperlinks to do it all? [self-contained, it shouldn't take more than a single DL DVD-ROM cjl

All DCOM patches + updates:http://www.mdgx.com/add.htm#COM HTH Sorry to have opened this can of worms:So, KB article 240664 is for NT, but update Q240664.EXE implements what KB243220 describes? [And thus SHOULD have been called Q243220.EXE but they never did that! ?] I assume that the line "Must (re)install this Fix AFTER ... refers to DCOM98 itself? If not, what? And among other things what could have been installed BEFORE that the AFTER refers to can be 269874? [Raising the rev of rpcrt4.dll using 269874 lowers some other aspect of DCOM98?] And I assume the DCOM98UP.EXE unofficial package is a way to get all of them at once to avoid a reinstall of whatever? And finally, if the 98SE SP 2.1a is installed AFTER all of the above as a final step, is that good enough to solve whatever the AFTER is referring to? cjl (trying to wrestle confusion to the ground)

Good ideas about 315575 and 269874 aside:Isn't Q240664 an NT update? [should we care about this for 98SE? And if so, can I get a copy?] I don't have Q243220, but it seems to provide RPCLTCCM.DLL to the same level as the SP 2.1a. Again, can I get a copy of this? And what relevance to the rpcrt4.dll problem? Apparently a relatively new bunch of updates out there, presumably good stock in the erp collection [or mgdx?] Can I get read access or a list of what's available now? [this thread has raised three of them. if you include 300234.] cjl

Now back to ending other confusionaries: I installed dcom98 DIRECTLY using KB165101's wisdom [direct install of DCOM98.EXE]. This update DOES NOT support the reboot-suppression switch[es] apparently; just install DCOM98 and reboot. However, 315575 DOES support the /r:n thus if it's gonna be the one to put dcom98 in, you can prevent the reboot as most updates should. [And I assume so does 300234, which I would like to use presumably in the same way, etc.] But this still requires a reboot so, as you described, wininit.exe can update which file is to become the final rpcrt4.dll taken from the .000 or .001 version, etc. Thus, if 315575 [or presumably 300234] is used as the way to get dcom98 installed once, you still need to reboot before attempting the 269874 or whatever to get a higher rev file installed last. Thus, the fact that you can defer the reboot is mostly moot; you have to reboot to finish it off before eventually doing 269874. Just that the KB165101 version doesn't give you the option of deferring said reboot. There is a "dirty 1/3-dozen" of updates that cannot be batched together which I install first. Some of them, such as 249973, are simply broken and bail out instead of doing their job due to flawed interaction with some other updates, such as IE 6.0 SP1 installation to name one. For these uglies I do them separately and firstly. After all of them are done, IE 6.0 SP1 updates can be installed, and then a large batch of most of the 98SE updates available in hotfix form. [And that ends with a single reboot, after which all of the files have their updated QFECHECK info correct.] Hope that clears up the confusion and doesn't strain your brain cjl

Sorry to cause headaches, but I really thought a guy who can juggle hundreds of updates on the forum and the great website could handle a few threads multi-tasking [and I do tend to ramble on when posting in the early am!] In any case, you are correct about the interaction between any updates trying to update the RPCRT4.DLL file and any updates specifically harboring DCOM98 as an internal update option [such as 315575 and 300234 as you mentioned: Can I get a copy of 300234; it clearly is a superset of 258191.] By first installing ANY update with dcom98 inside of it, the subsequent running of others ought to not try to do it again. Thus, a batch of updates all doing /q:a /r:n and only a single final reboot should install correctly. But only if the dcom98 install is performed EARLIER, rebooted, and apart from the larger batch of updates with the single reboot, etc. Thus, as you state, 269874 gets done "later" [as part of the big batch of updates that run unattended with a single final reboot] cjl (see next non-headache-provoking post)

Isn't 908531 an update that will give us a whole lot of grief because it must change SHELL32.DLL? [if so, affects 98lite, all the work to patch shell32.dll currently cosmetically and with regard to imbedded icons and transparent icon support, etc.] cjl (with sense of impending dread)