jds

Hi schwups, et. al. Well, I still haven't found a version of 'msiexec.exe' with the same MD5 hash as you, although I have found two more files with the same timestamp and version number, yet a different MD5 hash. However, this too isn't the problem, as you'll see below. I have 512M of RAM, so that's much more than the 32M minimum figure you quote (so little RAM would be a rarity these days). Anyway, the only real progress I've made is that I've been able to install 6u39 without difficulty on a P4 machine. I also upgraded this to 6u41 successfully, albeit with some difficulties (6u39 didn't like being uninstalled). I've transplanted 'msiexec.exe' and associated DLL's from the P4 machine to the P3 machine, transplanted the whole KernelEx directory, compared the KernelEx compatibility settings for every file that seemed relevant, all to no avail. I still can't figure why 6u39 and 6u41 fail to install on the P3 machine. This thing is driving me crazy. Joe.

Avast 4.8 (if you download the pro trial edition and give it a free/home registration key, it turns into the free/home edition). ZoneAlarm 5.5.094.000 or 4.5.594.000. Joe.

Hi schwups, Thank you for that information, it's a great help in tracking down this problem. Our CAB and MSI files are the same, so the extraction is OK and I can rule that out. The 'msiexec.exe' file is a mystery. Mine has the same time stamp, version string and file size, yet clearly they are different. This might be the key. Note that I haven't yet managed to find your version, but I've got a number of archives to look through. Following your suggestion, I've deleted anything Java related from the registry and the applicable drive directories. But no luck yet. Yes, I do have the 'GetSystemWow64DirectoryA' setting (I mentioned this at the outset). I only mentioned the 300MB figure for drive C: for completeness. The relevant figure is 2G for drive E:. Also, I would have received an appropriate pop-up warning if disk space were to run low during the installation process. I have no doubts that the "low disk space" explanation given by Sun/Oracle is not applicable, just as it isn't for many others too, as your link makes clear. BTW, depending on the KernelEx compatibility setting for 'msiexec.exe', the error can be 1723 instead. I used to have this problem a while back and could never find either the cause or a fix. Now it works again and I don't know why. There was a workaround however and that was to install the corresponding JDK which installs the JRE as a subset of its installation and whose installer didn't suffer from this issue. Perhaps this still applies today. Worth a try anyway I guess. Good idea, loblo. Unfortunately however, I get the same error with the JDK. Joe.

Hi loblo, Yes, you're right! I've just deleted "GetUserDefaultUILanguage", "GetModuleHandleExA", VerSetConditionMask", "VerifyVersionInfoA", "DecodePointer", "EncodePointer" and "AllowSetForegroundWindow" from the list. I don't know why they weren't showing up last night, but they do today ("VerifyVersionInfoA" even shows multiple times). I might miss one or two, but not that many. Perhaps some subtle stability issue, even though shutdown was uneventful? Joe.

AFAIK, FF 10 can be made to work but requires some trickery. For trouble-free, there's 8.01 and (I've less experience with this one) 9.01. If you need Java (not to be confused with JS) support, then you need 3.5. Yes, IE is required by some other things, which may or may not be things required by you. I don't know much about HTML 5 or which browsers support it. BTW, Opera 12.02 works very well. Joe.

Hi loblo, If that's true, then something's wrong with my system (hey, that's a distinct possibility!). I checked them all with 'ktree9'. Joe.

Hi jumper, Wow! I didn't realize 'kernel32.dll' has to load at a specific address. That's a fly in the ointment! Hmmm ... back to ReactOS ... I had tried a similar experiment with those DLLs in the past with the same apparent result. But I only half know what I'm doing, so another attempt may be worthwhile ... Joe.

Hi jumper, I've recently compiled a list of missing API's in a bunch of bits and bobs that don't presently work : [KERNEL32.DLL] "FlsAlloc" "FlsGetValue" "FlsSetValue" "FlsFree" "SetProcessDEPPolicy" "LocaleNameToLCID" "LCIDToLocaleName" [OLE32.DLL] "DcomChannelSetHResult" "CoGetClassInfo" "CLSIDFromProgIDEx" [USER32.DLL] "SetProcessDPIAware" "GetGestureInfo" "CloseGestureInfoHandle" "GetGestureExtraArgs" "SetGestureConfig" "GetGestureConfig" [NTDLL.DLL] "LdrUnloadDll" "LdrLoadDll" [MSVCRT.DLL] "_get_terminate" [SHELL32.DLL] "SHGetKnownFolderPath" [GDI32.DLL] "GdiRealizationInfo" "FontIsLinked" [USERENV.DLL] "EnterCriticalPolicySection" "LeaveCriticalPolicySection" The next step will be for me to look up the parameter counts and figure out the most appropriate return codes for these thingies. Joe. Edit 1 : Deleted some functions that shouldn't have been listed. Edit 2 : Added 'userenv.dll' functions.

Hi Den, I have 6u7 installed. I've also tried uninstalling this first, but it doesn't help. MsiX isn't doing too well for me, it extracts about 10 files, some only partially renamed to their final names. AFAIK, MsiX uses the API's of the installed MSI stuff on the system. When that's not working properly, neither does MsiX. At least that's what I've concluded just now. BTW, the MSI stuff on my system does work properly for other MSI files that I've previously installed, it's only this Java stuff that it has issues with. I wonder what version of 'msiexec.exe' others have, and what KernelEx settings it has? Mine is version 2.0.2600.2 (MD5 = 53223ff3012db1ac5a35cae4720bdd46). I get a different error message depending on what KernelEx compatibility settings I use, but it seems to bomb out at around the same point either way. Speaking of MD5 hashes, these are the hashes of the files I get after attempting to run the 6u39 installer : Data1.cab = 4ce133f19d40787a5548a6afcf15541e jre1.6.0_39.msi = 606aac2b60cf3e37baebd8a744cf300c Perhaps someone can confirm these are OK (else it would mean the installer extraction process is the problem). Hi schwups, I tried this just now (deleted 3 or 4 occurrences). Unfortunately, it didn't help. It's frustrating, but I don't seem to be the only one having problems with this Java stuff. Anyway, there's now a new version of this thing - that also won't install for me : 6u41. Joe.

Thanks for confirming this, schwups. That means it's not these missing keys that are the problem. As for 'PendingFileRenameOperations', no I don't have this key. It seems to be something the installer checks for very early in the process, and the fact that it continues with most of the installation from that point means it is happy that the key is missing. I suspect it would be less happy if the key was present. OK, so I've now ruled out the P3 CPU and the missing registry keys as the cause of the non-installation. Progress of sorts. Joe.

Hi jumper, I can confirm that HoverIP, SAPGUI for Java, Open Office 3.2.1 and Dependency Walker all seem happy with this set of definitions. Joe.

The error should be logged in your temp folder. OK, here are the log file contents : In summary, an "PendingFileRenameOperations" RegOpenKeyEx event occurred at about 10:56:07 and the Error 26011 occurred at about 10:56:25, about 18 seconds later. I also started 'RegMon' just prior. This indicated the "PendingFileRenameOperations" RegOpenKeyEx event at about 18.2s into the capture log, so the Error 26011 must have occurred at about 36s into the capture log. Now, looking at missing keys shown around this time, I see the following : HKCU\Software\Policies\Microsoft\Windows\Installer HKLM\Software\Policies\Microsoft\Windows\Installer HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts\ScriptsDisabled 0xC1C600F0\WINREG 0xC1C50D40\WINREG HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Folders\E:\WINDOWS\Installer\ HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Folders\E:\Config.Msi\ 0xC1C600F0\CRYPT32 0xC1C50D40\CRYPT32 0xC1C600F0\MSASN1 0xC1C50D40\MSASN1 HKLM\SOFTWARE\Microsoft\OLEAUT HKLM\SOFTWARE\Microsoft\OLEAUT\UserEra So, does anyone have these keys? Alternatively, has anyone succeeded in installing 6u39 without them? Thanks, Den! It's a process of elimination, so at least I don't need to wonder about my hardware. Joe.

Installing Kext is a little off topic. But yes, GetSystemWow64DirectoryA=z2e120 must added to the .ini file. 1. Paste the downloaded Kstubxxx.ini and Kstubxxx.dll in your KernelEX folder. It doesn't matter which version you use 626, 730 or 822 it should work. 2. Add GetSystemWow64DirectoryA=z2e120 to the ini file under [Kernel32.dll]. 3. Add Kstubxxx to the core.ini in the kernelEX folder: contents=Kstub626,std,kexbases,kexbasen 4. reboot => msi or silent and check out the vulnerability on 98 Hmmm ... I've tried installing recent versions of Java 1.6, following the Wiki instructions (mostly the MSI method, but also the silent method) but without success. I have KexStubs installed with the "GetSystemWow64DirectoryA=z2e120" setting, etc. However, I can't even get 6u30 to install, let alone 6u39. Here's a typical attempt : 1. Run 'jre-6u30-windows-i586.exe', let it crash and die. 2. Navigate to the "%windir%\Application Data\Sun\Java\jre1.6.0_30" directory. 3. Start 'jre1.6.0_30.msi' ... 4. Installation proceeds to about 75% then fails and does a "roll back". 5. The end. Running the 6u39 installer version is similar, except that the MSI gives an Error 26011 (Unpacking rt failed), whereas 6u30 gives no explanation. According to the Sun/Oracle information, this means I don't have enough free disk space and to allow for at least 100M - rubbish, I have about 300M free on drive C: (which should not be relevant) and about 2G free on drive E: (which in my case is the installation drive, also where temporary files live and die). Running the installation executable with the "silent" option is, well, just a more "silent" version of failure. Anyone have some idea on this? Does the newer Java stuff need a P4+ processor with SSE2 or some such (I'm running a P3)? Joe.

I know exactly how export forwards are implemented, but it's not a small change for Import Patcher to support them. IP is architectured to patch Imports, not Exports. "It's impossible. But doable." Hi jumper. Ah, I see. And if I'm interpreting this correctly, the "ntdll.RtlDeleteCriticalSection" and similar functions seen in 'k2rnel32.dll' (W2K 'kernel32.dll') are export forwarder thingies. So what we actually need (ignoring the other issues here) is an Export Patcher tool? I didn't try the KexStubs path because there were so many missing dependencies involved and because there was no chance that they could all simply be stubs. As regards the 'ntdll.dll' and 'kernel32.dll' OS compatibility, alas, I do believe you're right. I guess that's why the whole thing came crashing down in the end. As regards not being able to have two versions of 'kernel32.dll' loaded at the same time, does not renaming the W2K version (theoretically) make this possible? Joe.

Hi jumper, I tried a little experiment recently to graft the W2K version of 'mpr.dll' into a W98 system, in an attempt to map network drives using domain-based DFS, where a fully qualified domain name (I think that's what it's called) is used instead of a NetBIOS hostname and (as if that wasn't enough) the share is on a subdirectory of the root. I don't know if 'mpr.dll' is the correct target, this was largely based on guesswork. The plan involved also taking the W2K versions of 'NTDLL.DLL', 'rpcrt4.dll', 'advapi32.dll' and 'kernel32.dll', renamed to 'N2DLL.DLL', 'r2crt4.dll', 'a2vapi32.dll' and 'k2rnel32.dll', respectively. This was in order to satisfy all the dependencies of the W2K version of 'mpr.dll'. Anyhow, after applying Import Patcher 37 to all these files, to substitute these DLL names, I found that 'k2rnel32.dll' (formerly 'kernel32.dll' of W2K) still had a run-time dependency on 'ntdll.dll' (instead of the renamed 'n2dll.dll'), from a call to "ntdll.RtlDeleteCriticalSection". Looking via a hex editor, I found a number of similar function calls, which I manually edited to suit the renamed (and patched) 'n2dll.dll'. So it seems that Import Patcher doesn't detect DLLs that are called this way, when you try to do a DLL substitution. Hopefully this can be addressed in a future version of IP, when time permits, of course. There were also one or two instances within most of these patched DLL files, where the names of DLL files such as 'ntdll.dll' remained unpatched. I don't know the significance of these strings still being present, so I manually edited these too. BTW, this experiment was a failure. Even with the dependencies of these DLLs apparently addressed, this house of cards just crashes. So I still cannot tell if 'mpr.dll' would have helped with this newfangled drive mapping syntax. Joe.

Hi jumper, I've just tried these ActCtx definitions in 'Kstub822.ini' and "contents=Kstub822,std,kexbases,kexbasen" in 'core.ini'. Starting Open Office 3.2.1 'SCALC.EXE' produced an error R6034 and the follow-on error about 'MSVCR90.DLL' not starting. I expect the solutions from post #144 would be able to resolve this. I then tried 'HoverIP' - worked fine. However, when I tried SAP GUI for Java, I got the following error : Joe.

For NOT from Service Provider - https://www-secure.symantec.com/norton-support/jsp/help-solutions.jsp?ct=us&lg=en&product=home&pvid=f-home&version=1&docid=20080710133834EN You must pick a product... - same products though... and gives same link. Yep, I have versions 2007.2.0.11 (2007/1/12) and 2007.2.0.14 (2008/2/9). They both exhibit this expiry problem. Humbug! If you run the tool in Safe mode, it tells you it won't run in Safe mode. Here's something interesting though... Unpacked with WinRAR/UniExtract, it gives a file named "all.cpr" that lists everything that it deletes/services/etc-etc. Be aware that it appears that some fields are "<stringvalue>". Sadly, you would have to manually perform all of the operations within (stop services/processes/etc). edit - also found this with a different set of procedures and files (BAT/REG/Manual Delete) to "get rid of" Norton/Symantec (the links inside work as well) - http://filesharingtalk.com/threads/111599-Remove-Norton-*completely*-safely Checked those alternative procedures, downloaded the files, turned out to be for NT only, not compatible with W9X. Den, you're a genius! Thank you. That was the missing piece of the puzzle - SAV is now vanquished! Joe.

Hi Den, Alas, I still get the same expiry problem. Here are the stats : PE = 2008/2/9, signature = 2008/2/9, certificate expiry = 2010/11/25, file (directory) = 2009/1/14, BIOS (system) = 2009/1/22, network disconnected. I think that complies with the above recommendation. I can only think the security system (already) knows the certificate is expired and that the tool uses that fact to decide it is too. Joe.

Hi Aru, Could you please explain that paragraph, I'm having a bit of trouble understanding it (also having trouble getting ClamWin to actually work, eg. detect the EICAR test signature). Joe.

That statement put me in action. And I have good news: the following procedure works. I have just tested it for you. Disconnect the machine physically from the internet. Reset the machine date to some day (I used 19) in January, 2009. Turn off the machine. Wait 10 minutes. Turn it on and boot Win 9x (if it runs Scandisk or NDD, abort the scan or it'll find many "wrong dated" files). Once at the desktop, run Norton_Removal_Tool_9x.exe and it'll run OK. Nothing will be installed, the Norton_Removal_Tool_9x.exe is stand-alone. It removed all Norton products all right, except the Norton CrashGuard, which it didn't touch (then again, I'm possibly the last user of the much maligned CrashGuard, but it works all right for me)! Sure. And in the present case they actually are. Hi Den, Thanks for trying this out for me. Unfortunately however, MMDV (think YMMV). I tried many times and also with several "variations on the theme" (disabling the NIC in Device Manager, re-installing SAV, installing NAV, double Ctrl-Alt-Delete, reboot, changing date in DOS), but always the result was the same expiry error. The version I have of this tool has an MD5 hash of 316b61ce6f827a8ee48944e5b076f37c. BTW, I didn't get any "invalid date" errors from ScanDisk. If you get this, it means Symantec has usurped 'scandisk.exe'. If I recall correctly, the way to restore normal ScanDisk behavior is to delete a file called 'scandisk.alt'. Joe.

Four ideas, though I'll bet you tried the first two already ... - It may simply read the date/time. Set the clock back ( I know, it's obvious ) - It may phone home. Disconnect internet first, prevent it from getting the current date/time or status from a server somewhere. - It may have flagged itself as expired. Use a clean original non-executed copy of the Symantec file if you have one, this is to prevent self-modification which happens more frequently than people might imagine. It can easily flag a bit in itself as expired which would make the clock setting irrelevant. - It may have flagged an external bit as expired. Use a clean original non-executed copy of the file on a computer that has never seen the program run before. Save registry export and filelist before and after. The idea is to capture any changes such as a registry value or even a changed file date/time somewhere that it reads before execution. Unless I am completely senile I cannot imagine any other avenue it could use to stop working on Win9x. But I could be wrong. Hi Charlotte, Yes, you're right in thinking I'd have already thought of the first two ideas. Alas, so have Symantec, evidently. (Sigh, why can't things be easy for once?) The file doesn't self-modify. I downloaded a fresh copy (hoping it was actually an updated version) but it was in fact byte-identical to my existing copy. Unfortunately, I don't have a spare machine to risk installing this now worse-than-useless Symantec bloatware. However, I have used RegMon and FileMon to try to see what this Removal Tool is looking at. I can see it takes a keen interest in some encryption stuff in the registry (apart from looking up what Symantec packages are installed) and also seems to rewrite WIN.INI, however, nothing in either place seems relevant to my eyes. Because of its keen interest in encryption, it occurs to me that this Removal Tool may actually use its signing certificate to decide if it's expired. Looking at this, I see that it was signed on 2008/2/9 with a certificate valid from 2007/6/15 to 2012/6/15. Now normally, if the signing timestamp is within the validity period, the package is deemed to be valid in perpetuity. However, I suspect Symantec have chosen to use the certificate expiry date as the expiry date for this tool. No doubt when it checks for the validity of the signing certificate, the system will report it is valid but also that the certificate is expired. I'm sure the security checks used on certificates can't be fooled into thinking an expired certificate isn't, by setting the system date or any other simple means. Going with the "signing certificate validity date" theory, I signed the tool with my company's code signing certificate (which is still current, of course). Unfortunately however, the tool then reported that it wasn't signed, which in other words, meant it was specifically looking for Symantec's signing certificate. Grrr! Joe.

Instead of editing the INF, you may be able to just add the printer as an MP800 (no, I haven't looked at how good a choice you've made in selecting this particular driver for your MP250) via Start/Settings/Printers/AddPrinter. I'm using an iR-ADV-C5045 (over a network) by pretending it's an iR-C3220. Joe,

To echo everyone else - Welcome! Now, I'm a little confused by this "desktop", "window station" and "Explorer ... doesn't start a new instance" stuff. Is this something that will affect the normal behaviour of the W9X GUI? Lastly, if I remember correctly, TeamViewer 6 runs natively on W98. Joe.

I have previously reported that Symantec Antivrus 9 "real time" (auto protect) functionality was broken if you installed virus definitions post ca. Aug. 2009, although "on demand" (manual) scanning remained functional. I can sadly report that "on demand" (manual) scanning is now also broken with the latest virus definitions. To add insult to injury, their 'Norton_Removal_Tool_9x.exe' tool now reports it's expired and I can't figure a way to convince it otherwise. Typically, it directs you to a Symantec site for an updated version, but it's still the same version and it still reports it's expired. As some of you will know, the normal uninstall for SAV still leaves behind lots of files and registry settings, which is why the removal tool was created. Joe.

That's unfortunate. The other option would be to adapt the W2K drivers, however, the older drivers such as '1vwc27ww.exe' require a missing function "NdisInitializeString" (which would need to be added to the WdmStub project for a chance at W98 compatibility), while the newer drivers require several more missing functions. Looking at some of the file naming conventions for the 2100 and 2200 drivers, we typically see 'w70n9x.*' for W9X 2100, 'w70n5.*' for W2K+ 2100, 'w22n50.*' for W2K 2200 and 'w22n51.*' for WXP 2200. From this pattern, we would expect to see 'w22n9x.*' for W9X 2200 drivers. However, there are no signs that such files exist (or have existed), hence nothing to indicate that W9X drivers ever existed for the 2200. BTW, the oldest 2200 driver I've found for the 2200 is version 8.0.12.9000 at : ftp.upf.br/arquivos/drivers/Notebook/NEC/NEC%20VERSA%20M340%20FM340/DEVICE/WLANCal2/ The 2100 drivers seem to have version no. 7.*, while the 2200 drivers seem to have version no. 8.*. Joe.