jds

Slightly OT, but do you recall where this version of 'msvcr70.dll' comes from? (Mine is only at version "7.00.9466.0".) Actually DWMAPI (Microsoft Desktop Window Manager API) has nothing in common with MAPI32 and the substitution only works because RW doesn't seek to import any function from it as can be seen in Dependency Walker so any dll that is compatible with 9x will do (and the same goes with the windowscodecs.dll dependency). And this is unlikely to be an universal situation I guess. What?! Is this MS playing games with us, or what? Well, I'll definitely try substituting 'windowscodecs.dll' and testing RW again. Joe.

Another candidate for inclusion in the SP3 : Joe. Edit : Oops!!! I search this thread, but forgot to search : (which already includes the above)

Thanks, loblo. I'm sure that stub will come in handy! So, you substituted msvcrt.dll with msvrt70.dll (renamed as msvrt7.dll), because the same trick didn't work with msvrt80 or msvcr90. Then you also created a dummy dnsapi.dll. Gotcha. Good call. I tried msvcr71.dll, renamed as msvcr7.dll, and it worked! As for msvcr80.dll, that doesn't have those strange-looking identifiers. (Actually, when I initially saw them, I thought they were just garbage.) Joe.

Sure, but I won't get a chance to try this until Monday. Since I do use/rely on KernelEx, for the purposes of this experiment, I presume the following will be sufficient : * In "signtoo#.ini", I'll add : [Missing modules] msvcrt.dll=MSVCR90.dll Joe. Well, my first attempt was thwarted because the name "MSVCR90.dll" was longer than the original "msvcrt.dll". So I copied "MSVCR90.dll" locally as "MSVCR9.dll" and did the module substitution using that name. However, I can't get this to work. Here are the generated INI files in chronological sequence (the initial one generated by IP, my modified version, the subsequent one generated by IP) : [ImportPatcher.31] ;Edit parameters and replacement strings, then Retry or run again to patch. <= [Parameters] Walk dependencies=N Link to copies=N Target OS=4.10 [Module substitutions] [KERNEL32.dll] HeapSetInformation= [msvcrt.dll] __uncaught_exception= ___lc_handle_func= ___lc_codepage_func= ___mb_cur_max_func= __pctype_func= __iob_func= __crtLCMapStringW= __crtGetStringTypeW= [Patch list] E:\Winstall\Development\Vista\710_buildtools_signtool\SignTool.exe=OS subsystem, function names [ImportPatcher.31] ;Edit parameters and replacement strings, then Retry or run again to patch. <= [Parameters] Walk dependencies=N Link to copies=N Target OS=4.10 [Module substitutions] msvcrt.dll=msvcr9.dll [KERNEL32.dll] HeapSetInformation=HeapSetInformation [Patch list] E:\Winstall\Development\Vista\710_buildtools_signtool\SignTool.exe=OS subsystem, function names [ImportPatcher.31] ;Edit parameters and replacement strings, then Retry or run again to patch. <= [Parameters] Walk dependencies=N Link to copies=N Target OS=4.10 [Module substitutions] msvcrt.dll=msvcr9.dll [KERNEL32.dll] HeapSetInformation=HeapSetInformation * not found [Patch list] E:\Winstall\Development\Vista\710_buildtools_signtool\SignTool.exe=OS subsystem, function names, submodule names msvcr9.dll=OS subsystem [msvcr9.dll] ??0exception@@QAE@ABQBD@Z= ?what@exception@@UBEPBDXZ= ??1exception@@UAE@XZ= mktime= ??0exception@@QAE@ABV0@@Z= ??0exception@@QAE@XZ= ??1bad_cast@@UAE@XZ= ??0bad_cast@@QAE@ABV0@@Z= Probably a delay-load import. IP doesn't handle those yet. Try Dependency Walker--it should find it and report if it is a standard or delay load type. Sounds like a wide-char mapi library. Try doing a preemptive module substitution with mapi32.dll or tmapi.dll; then look at what functions are reported missing. Well, the good news is that substituting "mapi32.dll" for "dwmapi.dll" fixes that particular dependency. Unfortunately, after that there's a dependency on "WindowsCodecs.dll" that's more intractable. I can get this DLL online or from the dotNet 3 package, however, this has many missing function dependencies, from several other DLL's. Joe.

Thanks for the suggestion. Well, this work-around sort of works. Sort of. However, now the Quick Launch icons are on the right side, with the divider to their left. At least now I can adjust the size of the Quick Launch area so that the icons fit. Strange to get this effect from RP when I specifically didn't select the skinning option during install. I'd consider this a bug. Joe.

Well, I've just installed RP 9.7.2 on two W98SE machines (mainly to improve GDI management). First, installing the RP Update package (this process reports that I am trying to substitute 'gdiplus.dll' with an older version, so I click the button to keep the existing DLL), then RP itself. I just install the base package, not skins, etc. However there is a small, but annoying problem/bug. The divider between the three areas of the taskbar disappears after installing RP, so if I want to add something new to the quick-launch area, the new icon (also the existing right-most icon) become hidden. Can this be fixed? Joe.

Yeah, everyone says that. Yet for me, the W98SE desktop's shares are not visible to the Vista laptop, let alone vice-versa! I recently added a WiFi adapter to a W98SE laptop, just to confirm that there was nothing wrong with the Ethernet/WiFi router configuration (similarly, the W98SE desktop configuration). Well, the W98SE desktop and W98SE laptop were happily sharing directories and files straight away. In other words, with a W98SE laptop via WiFi, network connectivity to the W98SE desktop works just fine, yet with the Vista laptop in exactly the same situation, it doesn't. I can ping between the W98SE desktop and Vista laptop, and set up FTP and HTTP servers on each machine and transfer files that way. Yet other suggestions here such as using the respective IP addresses or share names directly just don't work for me. In the Vista laptop's registry, I have set LmCompatibilityLevel to 1 (was 3) and even NoLMHash to 0 (was 1), all to no avail. I have also installed the DS Client on the W98SE desktop, again with no result. BTW, it should go without saying, but networking between the W98SE laptop and the Vista laptop are similarly dysfunctional. So I give up. If I can't see any W98SE shares on the Vista machine, there is no hope, except perhaps retrograding the Vista laptop to a less retarded version of Windoze. Joe.

The future of Import Patcher looks very promising! Anyway, I recently encountered what appears to be a bug/quirk with IP.29. I wanted to try the RW utility here : http://rweverything.myweb.hinet.net/ What I found was that, for versions 1.4.5 and newer of RW, there is a missing dependency on 'dwmapi.dll', a Vista DLL. However, IP didn't detect this missing dependency. Joe.

The previous version was dotNet4.0--even more recent. Because KernelEx won't always be up-to-date with the latest demands of new software, it would be nice to know if ImportPatcher can help fill the void. To that end, it would be great if you could test the dotNet4.0 version with the msvcrt->msvcr90 replacement I proposed. This might also really help out those who don't use KernelEx. TIA, jumper. Sure, but I won't get a chance to try this until Monday. Since I do use/rely on KernelEx, for the purposes of this experiment, I presume the following will be sufficient : * In "signtoo#.ini", I'll add : [Missing modules] msvcrt.dll=MSVCR90.dll Joe.

Well, I'm kinda dependent on KernelEx these days ... Anyway, I managed to get another (fairly recent) version of "signtool.exe" that doesn't have strange requirements for 'msvcrt.dll'. It's version "4.00 (longhorn_rtm.080108-2300)", obtained from the W2008 & dotNet3.5 SDK (6.0.6001.18000.367-KRMSDK_EN.iso). The file is "\Setup\WinSDKTools-WinSDKTools-common.0.cab", from which is extracted the file "signtool_exe.B68FF751_0B1A_4F33_B044_1871CB4B13CC". Also required is the "capicom.dll" file, extracted as "capicom_dll.970E4F94_546F_49F3_BF1F_18BE6B938B02". This version of "signtool.exe" seems to run OK with KernelEx. (ImportPatcher shows mismatched hints for many DLL functions, but performance isn't important for this application.) Joe.

Well, if you say so. However, I did install the SP3 without errors, with IE only at version 5.01SP2, as described previously : Joe.

NetLimiter v1.30 supported W9X, try : http://wayback.archive.org/web/*/http://www.netlimiter.com/download/nl_v130.exe Not sure if "NetLimiter 2 Monitor" does (officially, it doesn't). Joe.

IKB yes. 2KB yes. 4KB no. There is also the issue of Partitioning and Formatting them as well. I stand corrected. I guess MS were catering for CD-ROM support, where 2K sectors are the norm. BTW, I finally found your previous comment on this 2K limit : Joe.

Well, for full anti-virus protection, Avast 4.8 is still supported, despite long-standing warnings from Avast that they will be discontinuing it. You can find the last freeware/home edition at : http://www.filehippo.com/download_avast_antivirus/6635/ I have also read that you can install the professional/business trial edition, apply for a freeware/home registration key, then if you enter this, your installation converts to the freeware/home edition. You can find the download link here : http://www.avast.com/download-software#tab2 If you want to manually download the virus definitions, see here : http://www.avast.com/download-update As for a firewall, I did try the Sygate Personal Firewall (the last supposedly "good" version) and it was completely unstable. I also tried Kerio 4.X and again, it was completely unstable (lovely interface, though). Finally, I tried ZoneAlarm 5.5.094 and that worked great! However, if you use the "site blocking" feature in ZoneAlarm 5.5.094, it starts to become less stable, but you can use the %windir%\hosts file instead to block a few sites. Joe.

Because a lot of updated files require IE 5.5 or IE6. And yes I did revise the page to specify IE versions so people who is running IE 5.01 would update their browser files. I'm sorry you having trouble, but there is a simple solution, update IE to one or the other version. Let me just clarify. The version of IE that comes with W98SE is 5.0, not 5.01 (version numbering for IE is confusing). Since the corresponding install error for the SP3 package disappeared after I installed IE5.01SP2, this suggests that's the minimum required version of IE (although I didn't try other iterations of IE5.01). Yes, that had been my expectation for the current release of SP3. I suppose that is still the case for the alternative builds of SP3 which are intended for "non-IE" installations. Joe.

Quite interesting trick... I'll sure try it next time I need to find why some driver is refusing to work on XP. @jumper: BTW, WDMCHECK's companion, Walter Oney's WDMSTUB.SYS, can make some WDM drivers work with 9x/ME, and might be updated to include more stubs inside it. It's like KernelEx, but caters for .SYS WDM drivers, specifically. it could very well be the long sought-for solution for getting the printer drivers to work. The sources are provided in Oney's drivers book. Note that the "printing problem" often mentioned regarding KernelEx is specific to the printer driver being used, and not a universal problem. In my case, I was able to identify the offending DLL from the printer driver and disable KernelEx for it, so now printing works fine for me. Well, if I remember correctly, USB drives with sectors up to 4K are already supported. I had an MP3 player with 1K sectors and that worked fine on W98 (until it developed a hardware fault). Any yes, let's wish for a better, peaceful world! <sigh> I was skeptical about it but seeing that tool I thought we might just pull it off with a wrapper. Anyway, thanks for the clarifications ! I've heard about this problem for quite some time but I never managed to find any detailed information about it. Would you happen to know where I can find more details as to why 98/ME supports only a subset of the features specified in the WDM model ? The DDK had lots of info on supported stuff, but nothing regarding why video drivers don't work. PS: For clarification : I understood what you said only that I'd like to read the technical details so-to-say. As far as I could understand what little I've read, WDM drivers share common source code for bot W9X and WNT, but use some different build setting or libraries or some such. Joe.

My 2c (these probably fall into the KernelEx domain) : 1. Fix the XP SP2 (+) emulation, so it is as stable as the 2000 SP4 emulation. Many applications and their installers (Opera 11, Acrobat Reader 7.09, etc.) work pretty well using the latter, but crash with the former. Missing/buggy functions? 2. Solve the "new style" Java plug-in problem, so we can get Java on Opera 11, FF 3.6+, etc. 3. Get other FF plug-ins, such as the 20-20/Ikea "kitchen planner" to work (with NT5, this even works with FF 2.0.0.22pre). 4. Solve remaining issues with Opera, such as crashing when a new instance is attempted, or when it is the default browser and you double-click on a HTM file. 5. Solve remaining issues with Acrobat Reader 7.09, such as crashing when you right-click within a File-Open or File-Save dialogue, or the blank text in the search results when you use the "binoculars". 6. Get Adobe Air version 1.5 or higher (and Adobe Air applications) to work. Joe. PS. : 7. Fix the history & bookmark problem with FF 5/6/7/8. PPS. : 5a. Stop Acrobat Reader 7.09 crashing when you select "Document Properties" in the "File" menu. PPPS. : 8. Office 2007 File Format Converters (Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint File Formats).

It's quite amazing, really! Well, I found a version "7.0.6002.18005 (lh_sp2rtm.090410-1830)" on a Vista machine, dated 2009/4/11. However, although this version only reported "[Need patching? ... msvcrt.dll=Y (OS subsystem)" in ImportPatcher (with 'Walk dependencies=N'), after being patched for the OS subsystem, it looked like a descent into DLL dependency hell. Does this relate to the "Link to copies=Y/N" option in the INI file? Would this also require "Walk dependencies=Y"? IP.28 reads parameters from an .ini file that can be edited between passes. I think that ImportPatcher.27 gave the impression that it would load and execute a file, while satisfying missing dependencies. Since that doesn't seem to be the case, my earlier question was null and void. Joe.

I'm sure if you have installed the right version then you shouldn't get any of the errors you posted above. rsabase.dll is not included in the SP3 so I don't know where this error is coming from. No, I didn't download/install the wrong version. The original SP3 page stated : That corresponded to my starting point. You say (here) that "rsabase.dll is not included in the SP3". Perhaps so, but presumably SP3 has some dependency on "rsabase.dll" that doesn't quite work for a baseline W98SE+IE5 installation? Now, I see that you've just revised your SP3 page to state : I wonder, why is IE 5.5 SP2 being specified as a requirement, when (i) this isn't the starting point when you install from the W98SE CD-ROM and (ii) at least IE 5.01SP2 seems to be sufficient (not sure if "ie501dom" was also required, but I installed this just-in-case, so as to enable 128 bit encryption)? Joe.

I tried installing the SP3 (2011/12/13 edition) on a laptop yesterday. It (the laptop) seemed to have little or no updates over the W98SE installation CD, including for IE5. There were two errors reported during installation, one for "rsabase.dll" and one for "msxml3.dll". To fix the "rsabase.dll" error, I installed "ie501dom.exe" (downloaded some time ago from MS) then "ie501sp2.exe" (downloaded from 'evolt.org'; BTW, not sure where to find updates to reach the ie501sp4 level). To fix the "msxml3.dll" error, I installed : This suggests the SP3 may be missing a couple of things, to be able to install over an original W98SE installation. Joe.

Thanks, loblo. I see now there is a new thread for Import Patcher : I'll try this again once version 29 is released (apparently imminent). Joe.

Not wishing to take this thread too far off-topic, I've just tried the Import Patcher on the "signtool.exe" utility from http://www.microsoft.com/download/en/details.aspx?id=8442 (Microsoft Windows SDK for Windows 7 and .NET Framework 4). Image file = GRMSDK_EN_DVD.iso, Path = \Setup\WinSDKTools\cab1.cab, Extract file = WinSDK_signtool_exe_B2E1011D_2F14_488D_A056_C5BD55106409_x86. Executing 'signtool.exe' by itself (with KernelEx 4.5.2) produces the error : The SIGNTOOL.EXE file is linked to missing export MSVCRT.DLL:__uncaught_exception. Executing with Import Patcher gives a bunch of "Importing from module ..." messages, but not the above message. It also produces a file "signtoo#.exe" which has patches but seems to behave the same as "signtool.exe". In addition, a log file is produced, from which the following is an extract : Importing from module: 'msvcrt.dll' __wgetmainargs: 225 != 142 # _cexit: 276 != 173 # _exit: 354 != 215 # _XcptFilter: 106 != 75 # exit: 1167 != 607 # _initterm: 469 != 282 # _amsg_exit: 257 != 162 # fgetpos: 1175 != 615 # __p__commode: 185 != 109 # __p__fmode: 190 != 114 # __set_app_type: 210 != 132 # ??1type_info@@UAE@XZ: 17 != 14 # msvcrt.dll: __uncaught_exception (db) * No match memmove: 1260 != 686 # _unlock: 934 != 495 # __dllonexit: 141 != 88 # _lock: 578 != 329 # _onexit: 747 != 403 # ?terminate@@YAXXZ: 55 != 48 # _controlfp: 295 != 186 # isleadbyte: 1218 != 651 # isupper: 1223 != 656 # _itoa: 561 != 319 # islower: 1219 != 652 # __badioinfo: 133 != 84 # __pioinfo: 207 != 130 # _fileno: 367 != 226 # _lseeki64: 587 != 337 # _write: 1096 != 555 # _isatty: 478 != 287 # ??0exception@@QAE@ABQBD@Z: 9 != 7 # ?what@exception@@UBEPBDXZ: 57 != 50 # ??1exception@@UAE@XZ: 16 != 13 # fwrite: 1201 != 636 # setvbuf: 1287 != 708 # fflush: 1173 != 613 # ungetc: 1341 != 749 # fputc: 1185 != 623 # fgetc: 1174 != 614 # malloc: 1246 != 679 # _callnewh: 274 != 172 # setlocale: 1286 != 707 # msvcrt.dll: ___lc_handle_func (7f) * No match msvcrt.dll: ___lc_codepage_func (7d) * No match msvcrt.dll: ___mb_cur_max_func (80) * No match abort: 1142 != 586 # ungetwc: 1342 != 750 # msvcrt.dll: __pctype_func (ce) * No match __crtLCMapStringA: 138 != 87 # msvcrt.dll: __iob_func (93) * No match __mb_cur_max: 176 != 100 # msvcrt.dll: __crtLCMapStringW (8b) * No match wctomb: 1390 != 778 # Now two questions come to mind : 1. Is there a way to pass command line parameters to "signtool.exe" when using the Import Patcher? 2. Should the "signtoo#.exe" application run OK (not exhibit the same missing import/export message)? Joe. PS. A really neat way to access content from ISO files (such as GRMSDK_EN_DVD.iso) is with the freeware MagicDisc driver (build 105 is the current version for W9X). Just be sure to (1) Configure the virtual drive letter(s) as desired via the MagicDisc context menu and (2) Disable its/their "Auto insert notification" option in Device Manager.

Well, I just had in mind that these stubs could be added to the code when convenient, pending the next KernelEx release. However, your suggestion to have an INI file and add new stubs "on the fly" is so much better! What flexibility! You mention only having VC5. I recall asking if VC4 or VC6 would be suitable, but don't think anyone offered an answer. Do you know what the minimum VC version is for building KernelEx? I might have a play with your Import Patcher, next time the need arises. Joe.

Likewise for me. Seems quite stable with KernelEx 4.5.2. Thanks Xeno86! Thats great news! And Steven W's workaround ought to work for everyone, too, because it appears that what we have here is just an installer-imposed limitation. You rock! Yes it does (work). BTW, the en-GB version I posted in the above thread is already FF8.01 compatible. Joe.

Just wondering ... has anyone (with the skills/capabilities to build KernelEx) seen this? : It suggests that the breadth of KernelEx application compatibility can be usefully expanded with a few added stubs. Joe.