CLASYS

hopefully this will stablize this operating system's explorer interface. I cant remember how i did it exactly, but i did manage to achieve this on a clean install of windows ME. Im pretty sure i used a combination of IE radicator and 98lite 4.5/4.6 to achieve this. Im thinking i used IE radicator to remove IE 5.5 and then i installed IE6 and used 98lite to re-integrate it into the desktop. but last time i tried this with IE6 SP1 i ran into problems. i got an error wen i tried to install IE6 SP1 When I use 98lite 4.7 to install MElite, I have to first install IE55, then remove it, then it will install IE60SP1. Trying it first it gets an error because it [erroneously; I have all the files!] believes it has to contact an MS file server and it can't do it, etc. Also, the Help stuff that comes up [forcefully!] in safe mode is now fixed in MElite; however, it requires the WBEM option be set [MElite will prompt you warning you to NOT delete it, etc.] but the WMI interface is still optional. Additionally, I reported [just under the wire for the release of 4.7!] various other ME-isms that were broken in MElite SLEEK [V1] such as the OSK, etc. Improved in 4.7 but not totally fixed: MSCONFIG with SLEEK [V1] will apply correctly when you exit, but will create a minor crash and will not actually reboot. Manual reboot will work OK, etc. Anyway, try 4.7; most of the effort was placed on fixing ME past 4.6, etc. [sLEEK [V2] still on hold .] cjl

How about Q290831 for ME? The 98SE version is available on this one... cjl

[Note to other readers of the thread: Gape and I are pm'ing each other as we are posting here!] ok, 'nother one: On the exuberant website is a reference to an update Q321467 which is without an MS link. However, there IS a link to Q321467: http://support.microsoft.com/default.aspx?scid=kb;[LN];321467 and I believe it has been recently added by MS! [Note to reader, the forum software doesn't underline the complete link above ] [As previously published as Q321467] BUG: Swenum.sys PortCls devices do not work correctly in Microsoft Windows 98 Second Edition This will help your list of 70 [eventually 73 not counting other "adjustments"!] However, the contents of the article doesn't indicate any updated files; just a procedural work-around for a problem that cannot otherwise be fixed but gets an adequate alternate result, etc. Inside of SP1.6.2 there IS a reference to Portcls.sys [4.10.2224] as coming from 321467. Can you give any details to explain this?

I looked within the SP1.6.2 .inf file, and it appears there is a second reference to the file Rpcltscm.dll after the one associated with Q315575; dunno if this is a mistake or whatever [just me meddling!] In any case, I notice a lot of file replacements from DCOM98 1.3 release. Thus the questions: Is this a COMPLETE equivalent release of what DCOM98 1.3 accomplishes? And if not, what has to be missing/why? Assuming that this is complete, is there any reason the registry version isn't updated beyond 1718? [HKEY_CLASSES_ROOT\CLSID\{BDC67890-4FC0-11D0-A805-00AA006D2EA4}\InstalledVersion] @="4,71,0,3328" Is what belongs if DCOM98 1.3 is installed; but you find it's at 4,71,0,1918 etc. cjl

[98lite SLEEK [V1], [V2] and MICRO compatibility issues handled separately] 'nother one: The stock system apparently has DCOM98 at revision 1718, same as 98 "Gold" [or as we call it 98FE]. Should the SP 2 apply DCOM98 1.3 [which is available as a "crackerjack prize" within Q315575] which raises the rev to 3328? cjl

Regarding SHELL32.DLL: Can I therefore assume that the replaced icon/bitmaps are smaller, but the STANDARD ones are NOT smaller? Thus, after installation, what size is SHELL32.DLL relative to choice of original or replaced icon sets? And what about compatibility with that translucent icon modification [covered on Axcel216 site about how to patch the Q313829 shell32.dll to be functionally compatible with the original shell32.dll. If feasible, it would be desirable to NOT introduce additional incompatibility, etc. Also, it is conceivable that the translucent icon patch could depend on the overall file length?] From what I read about the notepad key bindings enhancements, it's clearly a matter of patching it to get a quite similar binary, thus you only need to patch the original; I assume there are no official updated notepad.exe files to otherwise consider, etc. In 2.0 which EXPLORER.EXE will be used? The original or the one from IE50SP2? Also I believe there is somewhat of an icon/bitmap consideration within this file as well? What was the advantage [if any] of using the IE50SP2 version? Regarding 98lite shell options: I have been working with Shane Brooks on this [literally for years!] so, for those who don't know how it works: 98lite has 4 shell options [5 if you count current development!]: CHUBBY and OVERWEIGHT are the same thing; the differences are found elsewhere, but not within the SHELL32.DLL file. It is presumed to be the original file from 98se release, but it's perfectly fine to apply Q313829 under CHUBBY or OVERWEIGHT. When you use SLEEK [V1] or MICRO, you get an alternate scheme that replaces all references to COMMDLG.DLL, EXPLORER.EXE and SHELL32.DLL to the equivalent files taken from Win95b. The differences between the two options are as in the above two, except that SLEEK [V1] is more like CHUBBY in scope, while MICRO is a quite stripped down system that has been demonstrated to TOTALLY run without a hard disk when created onto an LS-120 [i was one of the original people to do this, first with Win95B itself.] Other than various registry mods, the main thrust is to replace the 3 files with their Win95b forebears, etc. However, there is a problem with a bunch of files included within Windows that have managed to require a small set of calls that CANNOT be handled by the Win95b shell. One source of incompatibility would be to determine if Active Desktop is in effect, a function call totally unknown to the 95b shell for which it makes a debugging-type gui-based complaint for an unknown function, etc. However, for all of the files built-in to 98 or 98SE or ME that have this problem, there is a common solution: All of the files have an analogous patch where the reference to the dynamic link call filename string "shell32.dll" is changed to "shell32.W98". The file SHELL32.W98 is indeed the original SHELL32.DLL renamed [and perhaps updated from the Q313829 package and any additional followon you might provide in the SP, etc.]. The calls these programs need to be satisfied work fine when calling the "dead" shell file SHELL32.W98, thus allowing the app to move forward, etc. without "upsetting" the 95b "real" shell32.dll, etc. Indeed NOTEPAD.EXE is one of these files that 98lite will modify whenever the SLEEK [V1] shell comes into effect, either at initial install or shell swap operations later, etc. To my knowledge, no other file involved in the process taken by 98lite overlaps the SP files. Indeed, it would have to be an .EXE file just to qualify, etc. There are other files that also have to be patched for SLEEK [V1] operation, but they are NOT part of the original 98SE install, most notably the sore-point file LOADWC.EXE, which is multipurpose when installed within IE60 or later. In order to get it to work in SLEEK [V1], you have to also make an analogous patch to LOADWC.EXE within the IE installation to avoid various [minor] crashes which prevents some proper updates from being carried out, etc. My personal choice is to install IE60 [or IE60beta or IE60SP1 or IE6 whatever] the "normal" way, and just before the reboot at the end of the install, manually slip in the PATCHED copy of LOADWC.EXE, so that after the reboot, the patched version does all the good stuff it needs to. Shane is trying to work out some more automated way to do this for release in an updated 98lite, but clearly my method gets the job done, etc. [in theory, you can replace a .CAB file member and get the same result, but then you cannot install it in a CHUBBY or OVERWEIGHT system, etc.] A question: As I understand it, you can override during installation of 98SE or perhaps even later when looking in the .CAB files' directory for updates, if you place a "loose" file there, it will override the attempt to locate it within the known .CAB file of the original file, etc. Is there a parallel for IE6x installs, or must the .CAB file be patched? Obviously, placing the file is easier than updating a .CAB file! I have additional files for patching other apps, such as early versions of Kazaa-lite [version 2.43 corrected the problem!], Adobe Acrobat Reader 6.00 and 6.01, and an obscure MS release of WUPDMGR.EXE much newer than that provided by 98SE that was distributed by MS as part of the XP release disk check-for-upgrade-to-XP-worthiness program. [You got the file from Windows Update, not on the CD itself; current Windows Update no longer does this, but I have the file from when they did this, and yes, it has to have a patched version for SLEEK [V1], etc.] I have run into at least one hopeless case where SLEEK [V1] ain't gonna cut it. Symantec Norton AntiVirus 2003 gets the shell complaint if you do not patch it, but if you DO patch it, it gets a self-check error because NAV checksums its own files, thus damned if do or don't, etc. PowerArchiver versions past 8.80 also have the problem, but I haven't yet figured out how to patch it for SLEEK [V1], in part since there are 5 separate call sets to SHELL32.DLL within the binary. All I can tell is that patching NONE and patching ALL leads either to shell complaints or failure of the app to work. Perhaps someone wants to try the other 30 combinations of patched/unpatched? [Or can we contact the author and point out that his program is now incompatible, presumably with Win95 as an additional, albeit simpler to explain, side effect?] Finally, to explain why I call it SLEEK [V1], well, we are working on SLEEK [V2]. It avoids all of the patching problems entirely. The idea is that instead of patching all programs to use an alternate SHELL32.DLL, the "innards" of Windows insteads calls SHELL32.W95 leaving the original SHELL32.DLL alone to handle things more "normally". [in part, this involves using a patched set of the same three files, comdlg32.dll, explorer.exe, and shell32.dll from Win95b, but with new names, etc.] and part of it actually DOES work! Unfortunately, as we try it, we get stuck on yet other things that do not! When Shane gets back from "the drawing board" hopefully we will try again, but SLEEK [V2] remains on hold pending remedying about 3-4 incompatibilities we know of [all in odd places!], etc. In ME, it gets more "interesting" in that certain UPDATES from Windows Updates, etc. also need additional patching for SLEEK [V1], and 98lite has no mechanism for fixing them [other than knowing what I present here and doing it yourself!], because it was anticipated that SLEEK [V1] would go away. This apparently isn't happening in the immediate future! SLEEK [V1] is totally immune to that reported shell "crawl" with regard to deleting many/large files regardless of IE 6 update level, perhaps because it doesn't care what browse??.DLL files are present? It empties the recycle bin virtually instantly. For those of you who like to turn off all of the shell frills, the SLEEK [V1] shell doesn't even have most of them! In exchange for using this option, you get a smaller, leaner and meaner, faster, more stable system that can be stripped down to its MICRO cousin as long as you don't mind the permanent loss of IE [more people these days like that notion!] that uses resources better and more sparingly, etc. Unfortunately, it also means that a few newer-type apps don't run there: WMP9 [perhaps something needs to be patched, but the stock version "hates" SLEEK [V1]] Norton AntiVirus past 2002 [2002 works totally fine!] PowerArchiver past 8.80 [perhaps rescueable] Adobe Acrobat Reader 6.02 [perhaps patchable, haven't checked] Certain proprietary Sony Vaio apps [that can be patched with difficulty, lots of files need the patches, but it does work, etc.] cjl

SP 1.6.2 has some modified files. The modification is done by Resource Hacker. These files are: EXPLORER.EXE: 256-color tray icons hack, and desktop icons hack. SHELL32.DLL (based on Q313829): Desktop icons hack. NOTEPAD.EXE: Key-bindings hack. SP 2.0 doesn't contain ANY modified file, it will use patching method for the modification. So it will contain a not-modified version of SHELL32.DLL from Q313829. OK, then please explain the following: Q313829 file shel95.dll [later renamed to shell32.dll] Length: 1,388,816 bytes SP1.CAB file shell32.dll Length: 1,386,256 bytes Both claim version 4.72.3812.600 I located the PCPLUS article on the notepad.exe control-key shortcuts; thus the similarity between the stock notepad.exe and the one provided in SP1.CAB. I assume this is the one that will be in SP2.CAP as well? If so, I do have the patch that makes it compatible with 98lite SLEEK [V1], which is essentially just doing what 98lite does to the original, i.e., if you compare my patched new notepad.exe to the unpatched one, you get the same differences listed as comparing the original notepad.exe to the 98lite-SLEEK [V1]-patched version of the original notepad.exe, etc. Can you indicate where EXPLORER.EXE comes from? I believe it's not the stock one from 98SE. [Again, is it the same base in SP2.CAB as in SP1.CAB?] cjl

To Gape: I posted something on the "Better Notepad" thread, and I assume you saw/will see it [when you get a chance]. I noticed that the SHELL32.DLL file seems not to be the one associated with Q313829 in that it's a different length. I know there are the icon considerations that are hard-patched in SP 1.6.2 [where I am still checking things out; end in sight soon!] but is this based on the same file as the hotfix or what? I am concerned because I read something a while back on Axcel216's site about someone complaining that the Q313829 version broke someone's idea about how to add transparent icons or somesuch using the original released SHELL32.DLL file, and that there was a way to patch the Q313829 version of SHELL32.DLL to regain the former functionality. However, these instructions have absolute offsets, so unless we can get an update for the file you prefer to use, is there any reason to break this compatibility yet again? [Or is it already handled by yet something else I don't grasp?] Or is all of this irrelevant because 2.00 is different from 1.6.2 regarding the SHELL32.DLL issues? cjl

It's only better than original Win9x/WinME's Notepad. I've only added some missing shortcuts. Can you elaborate on what about it is better? Assuming we are talking about the file notepad.exe within SP 1.6.2. I notice that it is the same length as the standard one, but clearly different internally, etc. Also, I have patched it to be compatible with 98lite SLEEK [V1] if anyone needs that as well. It is noteworthy [but not NOTEPAD-worthy ] that the difference between the unpatched and patched is precisely the same as the difference between the unpatched and patched original NOTEPAD.EXE as is normally encountered when using the original 98lite SLEEK [V1]. Installing SP 1.6.2 and 98lite SLEEK [V1] is in effect: In order to install the SP 1.6.2 [i assume that 2.0 won't be different in any regard to this!?] all of the following apply. Run the SP same as any other system. Eventually, after the reboot, you will have a non-functional system that appears to be 98lite CHUBBY but you cannot get any input from mouse or keyboard. [Tell-tale sign it's CHUBBY, not SLEEK: To the immediate right of the Start key is a slightly thickened double-vertical line. Anything beyond that is optional, and since this is a non-functional system at this point, you couldn't look any further if you wanted to, etc.] Not to worry, boot to command prompt only or a boot floppy. You need to retrieve the Win95 EXPLORER.EXE and SHELL32.DLL that are installed within the 98lite subdirectory where you created the 98lite-modded win98 files. Curiously, the COMDLG32.DLL file survives the SP upgrade, so don't worry about that. Replace %winbootdir%\EXPLORER.EXE with the one from that 98lite directory and replace %winbootdir%\SYSTEM\SHELL32.DLL with the one from that 98lite directory as well. Reboot to a now working SLEEK [V1] system with the SP installed as well. At this point you have to either restore the NOTEPAD.EXE from that 98lite directory to %winbootdir%\NOTEPAD.EXE or replace it with the one I can provide that is patched ala the way 98lite generally patches files for SLEEK [V1] usage based on the one the SP provides, etc. cjl

Dunno the name of the thing, but there was a file patching utility with really old versions of Partition Magic called, I am guessing "PATCH" used to updated minor version revisions. I think I have somewhere a file package that raises it from say 3.00 -> 3.05 or something like that. I assume it has a script that checks out the before and after of applying some file portions within the patch package, etc. If this sounds like something useful, I'll look for it for you, unless someone has this beastie floating around as well? cjl (Collector of various things)

IExpress's EXE-header simply calls SPUPDATE.INF for installation. For more information about IExpress, look at this link. It's similar to install a INF manually. (If you select a INF with right mouse button, you'll see the "Install" option on the menu.) So, other than not seeing the license agreement, right-click INSTALL on SPUPDATE.INF is the same as running the .exe of the released SP? Correct? cjl ps: Is MSINSTaller pre-needed for this to work?

I see the pieces [used powerarchiver on the .exe] but I don't see what ties it together. Where does it start? cjl

Currently, we don't see what you are working with, just the "innards". I assume that for the W32 self-extracter package itself you are writing some kind of script file to for it to carry out a few list items [run batches, use .inf files, etc. I would presume], and it supports EULA's and options like /C, etc. Can you give us an example of "what's under the hood" that particularizes the package as you are releasing it currently [say for 1.6.2 since 2.0 is not yet stable, etc.]? For the future, what's wrong with just using self-extracting .ZIP archives? That way we can unzip and not execute [analogous to /C] or just let 'r rip, etc.? cjl

The need to avoid confusion is noted. But that's not the point of my post: This is a documentation of an aberration. You CANNOT install the latest version! All attempts to get past the EARLIEST update fail to actually do ANY update. It's just that as an aside, QFECHECK also gets confused in that it's perfectly fine with the older file, as long as it exists, even though in the usual case, this would be red-flagged as an out-of-date file, etc. However, when the file is absent/hand-updated to newer, the seemingly brain-dead QFECHECK rejoins the living and correctly reports the newer-still file revision it would want to be present as actually absent, etc. In the case of these simple overlapping hotfixes, clearly what should be installed is the one that agrees with the highest revision to be installed, and presumably that is done by the SP. That way, the SP is in agreement with the relevant QFECHECK info. [And if earlier updates are left in, they become redundant to the latest one because there is no field within QFECHECK to report the MINIMUM acceptable version, just the current level as long as it meets or exceeds said minimum, etc.] Problems develop when there are updates that replace whole groups of files that are partially redundant to other updates, but not a complete superset/subset relationship. In this case, you HAVE to have both [sometimes there are more than two interdependencies!] updates in QFECHECK to account for all that has been installed. In the interest of getting the latest SP release issues closed, that's why I pointed out "problem-case" updates such as Q238329 and Q249973, both of which apparently have installation problems. Q249973 doesn't change what the SP should do, but it should be noted that attempts to actually install it will fail if a SUBSET of its three files [i am guessing USP10.DLL is the culprit) are already at/past the level Q249973 is attempting to upgrade to. You wind up with no QFECHECK information nor any actual file update should any of the three still need to be updated. [i believe that Q249973 provides one or perhaps two of them still higher than say a vanilla install followed by IE60SP1; clearly the IE install gets at least one of them still higher, but since all three ought to get upgraded, Q249973 still has work to do; doing no file upgrade nor QFECHECK-related housekeeping is clearly NOT its intended function!] [Note: If you want QFECHECK information for Q249973, fully expecting all relevant further updated files reflected eventually at their ultimate respective revisions, you have to install Q249973 hotfix BEFORE you upgrade to any updates of IE60SP1 and/or the SP. Apparently, one or more of the 27 known [to me at least!] available updates to IE/OE provides one or more [but not all three!] of these files that hoses the Q249973 installer logic, so installing it "earlier" gets you there, etc. Alternatively, you can patch the registry faithfully to Q249973 to "synthesize" the update; this can be done at any time.] [A side topic: Since QFECHECK doesn't support the notion of a "high-watermark" revision level, I would recommend some means of adding QFECHECK information that demands the known-highest level that SHOULD be present; this would then be a useful tool to locate accidental file corruption, etc. As currently implemented, any file "back-dated" to a revision merely adequate to a revision demanded by QFECHECK is NOT indicated as corrupted! Indeed, perhaps the SP itself needs a "master" QFECHECK entry!!!] However, Q238329 represents a more insidious case: It literally prevents ALL methods from performing the file update, including the SP! Perhaps what is needed is some way to eradicate what Q238329 does, presumably to the registry to make VIP.386 4.10.2223 so "permanent" in the first place. I merely pointed out that I discovered that if you manually delete VIP.386 [at 2223] after you have [unfortunately!] installed Q238329, then you can use any method you want to update the file [presumably to 2226 using the SP would be the goal, etc.]. cjl

I didn't understand the above problem. Is it a particular hotfix? Which one? If a file's revision 2223, it contains only one fix. If it's 2224, it contains two fixes etc. Of course, 2224 revision has 2223's fix. Adding QFECHECK information is a difficult process because of the SP's mechanism. I need a more powerful installer such as InnoSetup or NSIS for these complex processes. But they are some disadvantages, too. (For example, you can't see inside of a InnoSetup file with WinZip/WinRar). Sorry about the confusion, but I wasn't at my home machine when posting! [From memory, was making theoretical scenario, etc.] Here's the EXACT info and the EXACT problem: There are a series of updates that affect VIP.386 and bring it to various revisions: Q238329 - Fragmented IGMP Packet May Promote "Denial of Service" Attack [brings VIP.386 to 4.10.2223; I have this update] Q238453 - Data in Route Pointer Field Can Bypass Source Routing Disable [brings VIP.386 to 4.10.2224; I have this update] Q242962 - "BUG CHECK Error in VIP" Error Message When Obtaining a DHCP Lease [brings VIP.386 to 4.10.2225; I do not have this update] Q259728 - MS00-029: Windows Hangs with Fragmented IP Datagrams [brings VIP.386 to 4.10.2226; I have this update; SP 1.6.2 also does this] In any "normal" situation, one would expect that installing any of the above in any order would always do the correct thing, i.e., if the file is at the correct revision or higher, update the QFECHECK info and otherwise do nothing. If the file is at a lower revision, then update it to the revision provided within the hotfix, etc. Unfortunately, this is a "pathological" case in that should Q238329 ever be installed, all attempts to change VIP.386 from revision 4.10.2223 will fail short of manual removal of the file! All of the following have been observed: Attempts to install either Q238453 or Q259728 or SP 1.6.2 after Q238329 is already installed will fail to change the file from revision 4.10.2223! One way to fix it is to manually delete the file then do any of the above actions and they will succeed [provisionally]. The weird thing is that the QFECHECK program only "complains" correctly when the file is removed, i.e., the QFECHECK section for example Q238453 would indicate that the file is missing and it expects 4.10.2224; same for Q259728 except wants 4.10.2226. But when Q238329 is already installed, and then these other updates are applied, not only does the file stay at 4.10.2223, but the QFECHECK information shown on all of the updates shows the file is indeed at 4.10.2223 [which is the truth!], but weirdly enough there are no QFECHECK warnings of any kind! If you delete the file, and then update [which then works!] all QFECHECK info is as expected. The maximal case would be: 1) Install Q238329 2) Delete VIP.386 3) Install Q238453 4) QFECHECK now correctly shows VIP.396 at 4.10.2224 in both UPD238329 and UPD238453 sections. 5) Install Q259728 6) QFECHECK now correcly shows VIP.386 at 4.10.2224 in UPD238329 and UPD238453 and UPD259728 sections. Alternatively to 6) use SP 1.6.2 and you get to the same place; all installed QFECHECK sections correctly show that VIP.386 is at 4.10.2226 courtesy of SP 1.6.2, which of course is the expected value, etc. But if you have Q238329 installed, and you do NOT delete VIP.386 at 4.10.2223, all subsequent steps will fail to upgrade the file seemingly with the "approval" of any installed QFECHECK info that should be complaining about inadequate version level, etc. Thus, it would appear that in order for the SP to correctly install, something like the following has to be done: Delete VIP.386 unless it is already at 4.10.2224 level or greater; then install 4.10.2226 [or greater should that ever exist; doubtful!] There's got to be some explanation of how the installer within Q238329 causes the file to be overly "permanent" or something like that, etc. Hope that explains it! cjl (Long explanations 'r us) PS: Since Gape [besides his millions of other talents!] is THE .inf guy, here is what's inside of the Q328329 update [besides all the usual files including 3304UPSE.cat] which is usually distributed as 3304upse.EXE. Contents of 3304UPse.inf: ; 3304UPSE.INF ; This is the Setup information file to install the Windows 98 Second Edition IGMP Security Update. [Version] AdvancedINF = 2.5, %AdvPackWarn% signature="$CHICAGO$" [DefaultInstall] CopyFiles=W98Upd.Copy.qfe,W98Upd.Copy.Sys,W98Upd.Copy.Hlp,W98Upd.Copy.inf,Win98.Copy.cab AddReg=W98Upd.AddReg [DestinationDirs] ; 10=Windows, 11=SYSTEM,17=INF, 18=Help, W98Upd.Copy.Sys = 11 W98Upd.Copy.qfe = 10 W98Upd.Copy.Hlp = 18 W98Upd.Copy.inf = 17,QFE Win98.Copy.cab = 10,Options\Cabs [W98Upd.Copy.Sys] vip.386,,,32 [W98Upd.Copy.qfe] QFECheck.exe,,,32 [W98Upd.Copy.Hlp] QFECheck.hlp,,,16 [W98Upd.Copy.inf] 3304UNSE.INF [Win98.Copy.cab] vip.386,,,32 [W98Upd.AddReg] ;msinfo32 HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%",,,"%UpdName%" HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","IsInstalled",0x10001,01,00,00,00 HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","Locale",,"%LANG%" HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","Version",,"%VERSION%" ;qfecheck HKLM,%UpdateKey%\%UpdateSubKey%\,,,"%UpdName%" HKLM,%UpdateKey%\%UpdateSubKey%,%11%\vip.386,,"4.10.0.2223" [strings] ;Non-localizable GUID = "{2a1700c0-5c86-11d3-a7ad-0000f804e326}" LANG = "EN" VERSION = "4.10.0.2222" UpdID = "UPD3304" UpdateKey = "Software\Microsoft\Windows\CurrentVersion\Setup\Updates" UpdateSubKey = "W98.SE.IGMP.SECURITY.UPD" UninstallKey = "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" ;Localizable strings UpdName = "Windows 98 Second Edition IGMP Security Update" AdvPackWarn = "You need a newer version of advpack.dll." [sourceDisksNames] 55="IGMP Update","",0 [sourceDisksFiles] QFECheck.exe = 55 QFECheck.hlp = 55 VIP.386 = 55 3304UNSE.INF = 55 That's it! I can provide any and all of the portions of the thing [or the entire original 3304UPse.exe] to anyone who wants it. Unfortunately, this is one update we wish NO ONE had!

I'm still slightly confused: 1) How did you test an uncompressed version if it's a compressed file? What process makes it an uncompressed variant? Or is this just the "natural" result of adding in the updated component .VXD files necessitated by the SP? 2) What performance improves? Is this possibly merely because there is redundant resources being used, i.e., for both the VMM32.VXD monolith being in memory as well as the authoritative drivers also being in memory [i.e., the ones you added because they are updated per the SP, etc.] "wasting" memory space? 3) Can I assume that if we carry out the infinisource-based method on the updated collection of files [after the SP] we can get both the performance and the resources back? Part of why I ask is that my test example indicates at least the possibility that Tarun suggests, i.e., the installation failed to make a non-corrupted VMM32.VXD. Thus, to fix the problem, I have no choice but to rebuild the VMM32.VXD file anyway. Thus, it would be best to defer this to the point where all the driver considerations are stable to avoid having to do this multiple times, correct? cjl

This has been discussed in this thread and many others. Remember, the Search feature is your friend. Article on how to rebuild VMM32.VXD A utility for those who do not wish to use VMM32.VXD titled WinPatcher. Basically scans the system and VMM folders and allows extraction of the files from the CAB files. Searching through the forum as you suggested, I realize there has been some furor over this subject. Since this is the time to "get it right" for the benefit of releasing the new SP, I just want it stated succinctly: 1) There are factions for and against the notion of even having VMM32.VXD and whether or not it either helps some things or hurts others. Within this discussion are claims of performance improvements/lack thereof and in particular case a report of a vanilla system build that probably creates the file initially corrupted, thus the "loose" files are better than the corrupted one, or at least this is the theory behind what I have observed. 2) There is the possibility that it gets created wrong when the system was first installed or somehow gets corrupted later. 3) There is an article from the people who insist that MS is correct and that there are no benefits whatsoever from displacing VMM32.VXD, for the purpose of rebuilding VMM32.VXD when it is discovered to be corrupted for whatever reason, etc. 4) There is posted a utility to carry out the method of eliminating the need for VMM32.VXD entirely. 5) There is posted a link to a VMM32.VXD known to be stable, but was created for Win ME; does this particular file apply to 98SE? 6) The SP will include several VXD files in part because it is necessary as the files are updated by the SP itself, and partly because Gape believes that there is a performance boost if certain others are additionally added in "loose" form despite not being updated. Are there any other files that would be considered as a portion of VMM32.VXD beyond this set? 7) Most importantly, what is the method the SP will use to best implement a stable result after applying it? Part of what I read here is that unless you can prove that VMM32.VXD isn't corrupted, it's always safer to run with all of the "loose" files, albeit it boots slower. Conversely, rebuilding VMM32.VXD to a known non-corrupt state should be as good as having the loose files with the added benefit of shortening boot-up times. However, some report that VMM32.VXD eats some resources as compared to some form of perhaps selective override at least some "loose" files, etc. Do I have it right or what? Someone please show me the errors of my ways, if any. cjl

Indeed it does sound like your VMM32.VXD had problems when it was built during install. You may want to try and reconstruct it. This is a testbed system created thus: Format drive C: Install 98SE on C: drive selecting all options allowed except WebTV After last reboot, resolve Realtek 8139 NIC using latest (616) driver on D: drive Don't bother enabling DMA on Opti Hard Disk Controller because it will make system lockup predictably [Tested on a previous otherwise identical test installation on this machine] Add files indicated as being imbedded in VMM32.VXD into IOSUBSYS and SYSTEM directories. System Device Manager acknowledges them as now independent of VMM32.VXD Reboot; takes longer to come up; this was expected! Enable DMA in hard disk and CD-ROM After reboot, major speed improvement since DMA enabling makes it run faster as expected; no system lockup whatsoever. System behaves exactly like similar systems based on Intel chipsets. DMA can be enabled and disabled at will with predictable performance changes. Yet, if you do NOT remove the VMM32.VXD dependancy, you cannot ever enable DMA! Clearly, there is no bug per se in the 98se built-in support code for the Opti chipset, or else it couldn't ever work. However, something gets "lost" in the process of creating VMM32.VXD by Windows itself when it self-creates that file, etc. So, what would you have me reconstruct? What are the files Gape is adding to \...\VMM32 to override VMM32.VXD? As I understand it, some are specifically because of hotfixes beyond 98SE release, but some are because he also noticed something "works differently". [Note: "works differently" is official MicroSpeak for any change in how something works, no matter how big or small, important or not important. It is part of MS UML [user Manipulation Language] SP2 as used with Windows XP Service Pack 2 to deflect and minimize the impact SP2 has on many people's systems after installing SP2. UML cannot be uninstalled and all support contracts are automatically entered into and cannot be cancelled. ] cjl

Thanks to George [Axcel216] for pointing me to this forum! Gape [Alper I presume]: I am still working on my auditing of 1.6.2, but I have been side-tracked by having to fix FAR TOO MANY XP-based machines that come to me to be de-malwared, etc. Hopefully, I will have all of my points in order fairly soon. Here are a few highlights: Relative to the list of the first seventy [not counting the last three added to make 73] hotfixes, I would dispute the "dominant" hotfix number in a few instances simply because of the quirky way MS defines them. I don't have access to the specifics here [as I am typing on an "alien" machine at the moment], but there is at least one occurance of something like the following: KBxxxxxx refers you to download hotfix yyyyyy. However, there also is KByyyyyy which also references hotfix yyyyyy. In my view, that means that hotfix xxxxxx is unavailable and replaced by yyyyyy. As such, the dominant article is the yyyyyy one, not the xxxxxx one, etc. In some cases, there are "co-dominants" where there are multiple KB articles that all point to the need for the same file revisions. If applicable, perhaps in this case they are either equally dominant or perhaps only one of them has an obtainable hotfix? Whatever the outcome, I think there needs to be an alternate way of categorizing these cases, etc. In at least one instance, you are taking a file from a known package [such as dsclient] and as such, there doesn't appear to be a KB article to attribute the SP upgrade of the file to. In point of fact, there IS a KB article that precisely fits the description. Thus, this allows the number to be upgraded to 74 [Whether or not the hotfix is actually available is irrelevant to any rollup package, but it's nice to have the individual hotfixes as well.] As I understand the overall action of the SP, files that aren't currently installed are not immediately upgraded. As needed, they are installed from the SP1.CAB file to prevent taking from the original .CAB collection, etc. A prime example would be a machine where there is currently no USB hardware, but later a USB add-in card could get installed. My point is that the installation of the relevant, for example, USB-oriented upgrades from MS as hotfixes ALWAYS install these files, while the SP merely only ULTIMATELY might install them as needed. The subtle point is that if you include QFECHECK information for the hotfix, then installing only the "necessary" files leads to false-positive errors in the hotfix info for that update, which in turn causes the confusion and waste of time reconciling out which red-flags are merely for not-yet-installed hardware specific updates, as opposed to genuine errors regarding corrupted files, etc. A related point is: Can the QFECHECK information be installed along with the hotfix-related files? This would work exactly like a fairly recent update rollup that MS did for XP months before SP2 was released, etc. Other topics: I can pass along some horror stories related to MS's installers of certain hotfixes, mostly covered by the SP [other than the QFECHECK issues I raised above]. For example, Q249973 cannot be installed unless you haven't upgraded to IE60 or higher due to some internal logic error; it just bails and fails to upgrade any file or provide the QFECHECK program or relevant registry updates. The root cause seems to be the mislogic that because one of the files it provides is already updated to a higher-still revision by the IE6 install, it just exits, even though there are two other files that still need to be upgraded as well as the other QFECHECK and registry stuff, etc. [Note that the SP correctly installs the higher rev files!] Again, I apologize, but not being at "home base" I cannot get details I don't have committed to memory, but there is a serious problem with an available hotfix that disrupts the SP and even other MS-provided hotfixes. Goes something like this: hotfix xxxxxx installs 4.10.2223 of a file; hotfix yyyyyy installs 4.10.2224 of same file; hotfix zzzzzz installs 4.10.2226 of same file. However, if xxxxxx is installed BEFORE yyyyyy or zzzzzz or the SP, then the file stays at 4.10.2223! If the file is manually deleted, QFECHECK info for each hotfix correctly state what rev of the file they require. Yet, if xxxxxx gets installed, then each QFECHECK section gladly accepts 4.10.2223 as the revision they "like". If xxxxxx is never installed, all else works as intended. Apparently, something within the installer for xxxxxx makes the installation of the file at 4.10.2223 too "permanent". Should this update already be installed, the only way to fix it is to manually delete 4.10.2223 of the file, then apply any other update [yyyyyy or zzzzzz or the SP] I suppose an appropriate mod to the SP would be to check if xxxxxx is installed and pre-delete the file? Or perhaps delete some "overly strong" reg info? Yet another topic [so I can get off of this machine which is not mine!]: I have periodically heard references to this "heresy" topic about either VMM32.VXD is always a faster-loading panacea as compared to providing the relevant "component" files, presumably loaded into either \windows\system directory or perhaps elsewhere? [iosubsys? vmm32? both? all three?] and people reporting either no change or dramatic loading time changes or performance changes or all of the above or none of the above, etc. I have a concrete example of something that makes be a bit "nervous": I am testing out the SP on a slightly souped-up Compaq Presario 7212 [now has a mighty 64 MB and a P133; originally was 16 MB and a P75]. [The main reasons to test on are: a) It's available and now not being used as a doorstop, B) It has virtually none of the "optional" hardware thus allowing me to document which files the SP doesn't initially install.] Specifically, this machine uses the OPTI "Viper" chipset instead of the more common Intel versions. This is not a problem per se, as 98SE has full support built-in. I initially installed a quite vanilla 98se system on this box, and all built-in stuff was totally recognized [all except my Realtek 8139 NIC for which I added the latest driver and no problems there]. However, I noticed that DMA is not set on the hard disk controller, so I enabled it, got the standard warning, etc. Unfortunately, with DMA set, the machine became quite unstable as can be the case, etc. In safe mode, I was able to get things reset, etc. and basically ignored DMA mode for some time. Later, I was reinstalling the same basic system, but had run across the whole VMM32 .VXD debacle, and noticed that the drivers for the hard disk controller referenced a few files included inside of VMM32.VXD, so I decided to follow someone's directions and placed the de-CAB'ed originals into a couple of relevant directories. After a reboot, I do notice that it DOES take a bit longer for the system to come up, which is what most of us would expect, since VMM32.VXD is being thwarted, etc. However, I was able to set DMA on the controller and IT TOTALLY WORKS NOW! Thus, it would appear that the compaction process that creates VMM32.VXD could be buggy; the fix in that case is to not use it! Have I blown any holes into anyone's "theories" about this? cjl (will write more when I get back to my own machine!)

I occassionally install ME with 98lite and want to upgrade to Ie60SP1. With 98lite you can have all things IE pre-removed. However, unlike 98/SE, you CANNOT install IE60SP1 over "nothing". [i assume the same would apply if using Shane's IEradicator.] When you run IE6setup.exe, it makes some kind of net-oriented complaint and never installs. [i am on permanently with cable modem at the time and things like PING and TRACERT and WINIPCFG all work fine; I can even install Netscape and it will work fine, etc.] The only way I can get it to work is to put back/never take out in the first place the IE50, THEN remove it [again]. At that point, IE60SP1 amazingly does install! Any clues? cjl

If "better" means playing russian roulette with a system that can be wiped out with the latest zero-day attack [like on 24-Jun-2004] then by all means choose "better". I'll stick with "not better" which means things like survives still-unfixed security holes because they only apply to NT-family disasters, etc. Anyone bothered to tally up the big difference between security problems that apply to ALL [meaning 9x and NT] Windows as opposed to just NT-family-only Windows gets killed? [Even better numbers if you don't use IE and OE which is fine by me on 9x since Netscape/Mozilla works fine there!] I use 98se by choice and support the folly of others who like to play with XP. Eventually, many of them come to me to get their XP systems fixed after it gets broken by the spyware/virus-of-the-week. The repair inevitably involves using 9x to get all of the malware removed because XP has "great" features where malware can more easily hide within. Booting to a 9x system to ferret out the bugs gets rid of problems that the XP system doesn't even realize it still has! A recent example: Ran Trend Micro Housecall on the XP system itself [after ridding it of Sasser and other problems] and I get a clean bill of health. Problem is that it just ain't so. Run Trend from a 9x system that views the XP system drive as a non-system data drive. Turns out that SVCHOST.EXE has a trojan in it. Still want to pretend which is "better" ? cjl (real world, not fantasy land)