jds

Presumably your "sandbox" allows you to revert to your pre-FF10 system configuration? I'd guess FF10 has done something to your system that it doesn't like. Start over, reinstall Unicows, then KernelEx in default mode, then run the FF8 (or FF9) installer in W2000 compatibility mode. Don't try some work-around using file extraction, etc. Joe.

HoppaLong, I've not tried FF 10, because I've read reports of it not working readily/satisfactorily. However, FF 8 and 9 work very well under KernelEx, except the "new style" Java plugin which can't be made to work. All you have to do is install KernelEx with default settings and then run the FF installer in W2000 (not XP!) compatibility mode. Easy. I should point out that although FF 8 and 9 performance on my (now decommissioned) P2/333 machine was good, for some reason they were completely unusable on my Celeron-A/466 laptop (had to revert to FF 3.5), no idea why. As for UniExtract, it's a piece of cr*p, even if you get it working, some time later it will break for no apparent reason, just use it as a collection of extraction tools. Joe.

Cool, an alternative to 'ethereal-setup-0.10.14.exe', which was the last version to run natively on 9X. BTW, I notice their Personal Firewall lists W95 through W2008 compatibility. Joe.

The cavalry to the rescue! Fantastic! Perhaps the crash you're getting vs. the lock-up I'm getting is due to the differences between 3.5.19 and 3.5.20pre. I don't know what the differences are, but the respective packages are 7.9M and 11.1M in size, so that suggests lots of changes/additions. However, I'm sure the root problem will be the same. Aren't "PrintDlgW" and "PrintDlgEx" also being used, according to the above? Joe.

FWIW, 11.13 seems to work OK with these two apps together, with KernelEx. Joe.

Possibly. FWIW try : ftp://ftp.upf.br/arquivos/drivers/Notebook/NEC/NEC%20VERSA%20M340%20FM340/DEVICE/WLANCal2/OS/w2k/ and http://support.lenovo.com/en_US/downloads/detail.page?DocID=DS002818 Joe.

Hi MiKl, OK, I may try again. Which registry fix should I omit? Joe.

Original FF35 with none of my ComDlg32's. This is to confirm that the only effect of my ComDlg32 was to inadvertantly bypass KernelEx processing of PrintDlgW. This should explicitly bypass KernelEx processing instead of using my ComDlg32. OK, I undid everything then added the 'ComDlg32.PrintDlgW=std' line in KernelEx's "Core.Ini". Now, attempt to print #1 -> nothing happened; attempt #2 -> nothing happened; attempt #3 -> FF locked up (no hourglass). Next I removed the 'ComDlg32.PrintDlgW=std' line in "Core.Ini" and went looking for anything in the FF directory containing 'PrintDlgW', finding "xul.dll". The KernelEx properties were W2K, set this to Disabled, selecting not to pass the setting to child processes. No good, FF refused to start. Next, set "xul.dll" properties to Default, deselecting the "do not pass settings" option. Now FF started OK and attempting to print resulted in a "print dialogue", after which clicking OK caused FF to lock-up (without hourglass). So this change seems to have the same effect as when I used a patched version of your ComDlgEx/ComDlg32 from post #27. Later, I'll try the Unicows redirection (or patch "xul.dll"?) as you've suggested. I'll also try other versions such as from FF 8.01. However, now it's late, so I'm calling it a day. Joe. PS. Well, I've now tried the Unicows redirection with the following 'Kstub822.ini' setting, to no avail (FF hangs immediately on printing, no hourglass) : [Comdlg32.dll] PrintDlgExA=>ComDlgKs: PrintDlgExW=>ComDlgKs: PrintDlgW=>Unicows: I've also tried to incorporate different versions of 'xul.dll', however, FF has checks for the exact Ghecko version of files, which means 3.5.xx won't allow this.

"98 SE SP 3.7" includes Kernel32.dll (version 4.10.0.2226, build RRL). Binary analysis shows that this is not the original file patched by Mr. Loew (version 4.10.0.2225, build RRL), not there is also a file of the COPY2GB patch (version 4.10.0.2226, build QFE). Does anyone know anything specific about the origins and characteristics included in the Kernel32.dll of the "98 SE SP 3.7"? Please read post #38 : Joe.

Hi jumper, To answer your last question first, the OpenFile and SaveFileAs functions were working fine with my previously described "post #27" hack. From memory, they were also working fine before any experimentation with ComDlg32.dll. To implement the hybrid hack as suggested, I've done as follows : 1. Reverted to the original ComDlg32.dll in the System directory. 2. Copied the above as ComDlg00.dll (again in the System directory). 3. Placed the "post #13" version of ComDlg32.dll in the KernelEx directory. 4. Added the registry value : \HKLM\Software\KernelEx\KnownDLLs\COMDLG32="ComDlg32.dll". 5. Placed the "post #22" version of ComDlgEx.dll in the FF directory and renamed this as ComDlg32.dll. 6. Deleted the registry value \HKLM\System\CurrentControlSet\Control\SessionManager\KnownDLLs\COMDLG32. Now if I attempt to print in FF, nothing happens but FF doesn't lock up (the first time). However if I attempt to print again, then FF locks up (no hourglass). Also, OpenFile and SaveFileAs no longer function (nothing happens). With regard the 'ComDlg32.PrintDlgW=std' line in Core.Ini, which configuration of ComDlg32.dll hack(s) should I use? Joe.

Hi jumper, Well, as you've found, the string "PrintDlgEx" is not to be found in any file within the FF 3.5 directory. Also, I changed the KernelEx "core.ini" per above and this had no effect (on this issue), which is to be expected. However, despite all this, the "ComDlg32.dll" hack does have some effect. Without it, FF hangs instantly when printing is attempted (showing an hourglass). With it, the print dialogue appears, and if you cancel at this point, FF appears OK. I've just reconfirmed this. Joe.

Good to know, but possibly academic. "scanreg /fix" fails when the registry exceeds something like 8M, so I expect "scanreg /opt" will fail similarly. Joe. PS. @ CTH : Great write-up!

Hi jumper, I had a look but didn't find 'ComDlgKs.dll'. I had probably uninstalled KernelEx and re-installed it for some reason (I do that sometimes). However, no "Options message box" (I presume that means the "print dialogue"?) had appeared. Neither had there been any new entry added to the KStub822 log file, as far as I could tell. I added the missing 'ComDlgKs.dll', and now (remember, I have the comdlg32 hack in place at this point) FF once again locks up instantly when I try to print, no "print dialogue". Furthermore, I can confirm that no entry is added to the KStub822 log file. Next I reversed the comdlg32 hack and the FF printing behaviour didn't seem to change. Sorry, my mistake. That was the post #27 version. I've corrected the previous posting. No worries, here's the IP35 ini file after walking the FF3 dependencies : FF doesn't seem to add anything to the Kstub822 log file when printing. Opera 12.02 adds the line : Incidentally, I should also point out that FF 8 was printing just fine before I removed it. Finally, I should point out that these are my Kstub822 entries in KernelEx's 'core.ini' : Joe.

PrintPDF Firefox extension: What are the symptoms of the printing problems Hi jumper, I've recently installed FF 3.5.20pre, partly due to need of Java support on the desktop, partly due to severe performance issues with FF 8 and 9 on my 466MHz Celeron laptop (strange, as FF 8 performed very well on my former 333MHz P2, which had FineSSE 29 installed, in case that's relevant). I first installed FF 3.5.19, then copied the 3.5.20pre files over this. Initially, any attempt to print would immediately lock-up FF with an hourglass showing. So I downloaded ComDlgEx from post #27, patched this with Import Patcher so that it called ComDlg00.dll instead of ComDlg32.dll and placed this in the System directory as ComDlg32.dll, having renamed the original as ComDlg00.dll. Now when I attempt to print, the print dialogue appears (it didn't before), but when I click OK, FF again locks up, this time without an hourglass showing. Incidentally, other applications including Opera 12.02 continue to print normally. Also note, the version of KernelEx is 4.5.2 and Kstub 822 is also installed. Joe. Edit : Corrected reference to post #22, now post #27.

Since there is no KernelEx to extend W95, you might be able to stub missing function calls with jumper's Import Patcher : Joe.

You can't export reg files from a backed up registry dat file with regedit AFAIK. RegExport is a great free tool and unique in its features. Besides letting you see differences between the live registry in ram with dat files or exporting from dat backups to selectively restore something you can use it to check out if you you've got a rootkit in the startup keys (run, runonce, etc...) for example. I am not aware of an other tool that lets you do that besides its big brother RegDat and I am nearly 100% sure that no other free tool lets you do any of that so it's definitively a must have IMO. Hi loblo, Regarding 9X 'regedit', it can work with backed-up DAT files as follows : REGEDIT [/L:system] [/R:user] /E filename3 [regpath1] where : /L:system Specifies the location of the SYSTEM.DAT file. /R:user Specifies the location of the USER.DAT file. /E filename3 Specifies the file to export the registry to. regpath1 Specifies the starting registry key to export from. (Defaults to exporting the entire registry). Now regarding RegExport, if it does have those extra features, then I'll change my mind and agree it's a "must have". I've just downloaded it from http://home.arcor.de/h.ulbrich/regexp.zip (another download I had found was truncated, useless). More toys.Thanks jaclaz! Sounds very useful, thanks for the tip loblo! Another useful looking tip, jaclaz, and (IMHO) definitely not off-topic. Hi CharlotteTheHarlot, 1) I checked the 6th file RegCompact.exe (at the bottom of your list, with MD5 fa3f9649f5f5f74b7036a48bcf205d42) with MiTeC EXE Explorer, it has a time stamp of 1-Dec-2000 9:33:06AM, very similar to the file modification date indicated for the 5th file. The time stamp by MiTeC EXE Explorer is more helpful than the file modification date for categorizing the various versions of RegCompact.exe. MiTeC EXE Explorer displays for file #6 in the Strings tab several error messages which were localized into Italian. I would speculate that file #6 is only a modification with a hex editor of file #5, not a new compilation. You beat me to it, Multibooter! I checked similarly and entirely agree about your conclusion. It should be possible to use a tool like the venerable BDIFF 1.01 by Morten Grouleff to get a patch that can recover the missing 2000-12-1 edition. Anyway, I tried the Italian-patched version with the following results : SYSTEM.DAT 12,943,672 -> 12,902,432 USER.DAT 1,830,944 -> 1,720,352 I was surprised that after some years of installing and uninstalling stuff, I had so little empty space to collapse! Looks like I'll have to do surgery if I want to reduce that registry size. The patched program worked just fine, so there should be no fears about code pages differences or whatnot. The only thing I had to take care of, is that, like almost all registry tools I've tried, they assume that 'system.dat' and 'user.dat' both live in the %windir% directory. However, if you install W9X on a drive other than C:, you end up with 'system.dat' on C: drive (in the %winbootdir% directory) and 'user.dat' on the main W9X drive (in the %windir% directory). Joe.

??? I think I kind of "implied" that in my post about REG.EXE??? I SPECIFICALLY remember creating a Boot Floppy with it for that exact purpose...Perhaps "Safe Mode" with REGEDIT.EXE -OR- "Safe Mode->Command Prompt"/BootFloppy with REG.EXE (same-o same-o)... Seriously... what am I missing here? Sorry if I've overlooked your posting, however, what you've missed is that I'm not a mind reader. I'm sure you may know what you were implying, but I couldn't see it. Seriously. If you could elaborate some, like the role of a boot diskette perhaps, or how 'reg' can work where (command line) 'regedit' fails, that may be helpful here. Joe.

Most likely, 'exporting' ( the ASCII output of the registry on a successfully booted computer ) will always work okay. I probably wasn't clear but what I meant was binary output from a registry tool that saves to a Win9x DAT on disk ( or a no-extension NT hive ) that is perfectly usable at a later bootstrap. Export is done while in protected-mode so by definition the registry was successfully read and loaded. At this point REGEDIT only has to write out the database. If you were to overload the registry with REG files, you could also export it out to a file. It's that next reboot which is scary. My understanding is that there are two major but separate registry problems in the Win9x family ... CREATION ... This occurs in DOS when the real-mode part of REGEDIT using /c cannot create one of the DAT files It is trying to rebuild a new registry ( output binary ) from a previously successful export ( input ASCII ). I discovered this way back in Win95 before the OSR updates corrected it ( temporarily ), when certain software moved all of its settings from private files into the registry and doubled the size. It was cat and mouse for the next few years but eventually even for Win98se large exports couldn't be /c created. Before WinME, the patching and backporting of a later REGEDIT version ( e.g., from 95osr to 95 ) allowed successful creation, but we ran out of luck when WinME changed REGEDIT ( it separated CLASSES out of the SYSTEM hive as a last ditch effort to make it manageable ). The reasons for this CREATION bug seem to be registry size, complexity, available RAM, ( and possibly CPU model, speed and cache ) so it is a chaotic and unpredictable problem, and pretty much unsolvable. Remember, this is the 16-bit universe and even before WinME Microsoft was already breaking things and leaving them broken. Microsoft could have fixed this in the 32-bit portion instead, but I am guessing that they did not want to give REGEDIT an option to output binary DATs to an arbitrary selected folder which would be necessary since it cannot overwrite the current in-use registry files. A 32-bit registry tool that can do this ( output binary DATs to an arbitrary selected folder ) would be very desirable for Win9x, hence my previous comment. LOADING ... BSOD protection error preventing successful bootstrap because one of the DATs cannot be successfully read or loaded. I had long thought that this was for all the same reasons, registry size, complexity, available RAM, etc, but here on MSFN RLoew has also discovered a connection to networking in some way. Consequently, a surprised and unprepared Win9x user is screwed at this point. However a well-prepared user has saved many DAT backups and thankfully in Win9x it is simple to change registries in F8 DOS command line. It is very possible while in Windows to absolutely overload the registry with imports ( or just install every SDK ) and it will appear fine as it fits within the protected-mode available memory space, but then it BSOD's on reboot. With great perseverance a person could manage this situation with lots of REG files used when in Windows and have REG 'deleters' to remove them before restart, and/or have fallback DATs ready to be copied in F8 DOS. Interestingly enough, one program that I never saw choke on a large registry was RegCompact by Daniel Werner, a 32-bit protected mode app which near as I can tell reads the currently loaded registry in memory and writes it out sequentially, removes any fragmentation 'holes'. It uses WININIT.INI to do this by outputting the DATs as C:\WINDOWS\TEMP\RCxxxx.TMP that are swapped in on next reboot. In my experience it was always successful in this 'defragmentation, and, on the following reboot I don't recall any problems either. But if you stop and think about there shouldn't be any problems because what you are loading in these new' DATs is just a likely smaller, and purified version of the previous working registry. Theoretically it should become problematic when you start pumping in REG files just before you RegCompact. The way I managed things on Win98se after the WinME registry change forked it up ... Boot Win9x normally without BSOD Backup DATs ( 'A' ) Import the required REG data in REGEDIT Backup DATs ( 'B' ) Run RegCompact Copy the newly created DATs cited in WININIT.INI, rename to DATs ( 'C' ) Now I have three sets of registry DATs, A, B, C Then I would try booting C having A to fall back on. Note that B was saved just for informational purposes, because C is a purified and smaller version of B. If this concept is understandable and makes sense, then you should be able to do this successfully. Just remember that A, B, C represent three points along the timeline. I never did have a problem here but I never did push it for experimentation's sake. In other words I never imported huge amounts just to learn the limits of that specific computer ( once again assuming the BSOD is related to registry size, complexity, available RAM, Networking, CPU model/speed/cache, etc ). Last registry size that I used on Win98se ... SYSTEM.DAT ..... 12,873,760 USER.DAT ........ 3,665,952 ASCII Export ... 21,261,267 I just want to repeat - that registry was highly managed. I didn't just throw stuff into REG files to experiment and explore the outer limits! What I imported was highly error checked and optimized ( some might say obsessively ) , paths shortened, ~SFN~ removed, font and other paths, etc. And I had a habit of deleting large chunks of unnecessary information ( Shared DLLs, Windows setup info, etc ). If I had left that all in plus all the MSI installer garbage with the absolutely insane amounts of entries ( for every single file found in every SDK ), I bet that registry export might be be closer to 50 MB. The point is, those sizes shown DO NOT REPRESENT any kind of upper limits. Please, don't anyone assume those numbers should be used as guidelines! NOTE: for RegCompact, there are four different versions that I have seen ... 73,728 ... 10-15-00 ... 4:36a ... Regcompact.exe_(2000-10-15) 73,728 ... 10-18-00 .. 12:39a ... Regcompact.exe_(2000-10-18) 73,728 ... 10-28-00 ... 5:16p ... Regcompact.exe_(2000-10-28) 73,728 ... 12-01-00 ... 8:33p ... Regcompact.exe_(2000-12-01) ... using this Hi Charlotte, Yep, you've hit the nail on the head, as they say. Your description of the creation problem is exactly where I'm stuck. Your description about protected mode 'regedit' gave me an idea : If, when you first install a system, and have the bare essentials and drivers working, save the 'system.dat' and 'user.dat' files away as a "minimal" registry. Later, when you need to rebuild, export everything with the protected mode 'regedit', then swap the 'system.dat' and 'user.dat' files with the "minimal" set. Reboot, then import all that you exported earlier using the protected mode 'regedit'. Should work, I think. I tried to find 'regcompact' of 2000-12-01 to no avail, the nearest I could find was the 2000-10-28 version, which is available in the "win95\util" directory of your favourite Simtel mirror under the name "regcmp1b.zip". Haven't tried it yet. I don't suppose the newer version is sufficiently similar that patching is an option? Joe.

Hi MB, It's OK to disagree, however, my comment was "For the moment, Avast 4.8 is still the best complete solution, IMHO." Since you don't use KAV6 for real-time protection (my guess is you'll encounter the same stability issues as I did if you try), that doesn't qualify. As regards your false positives, I'm surprised. I've used Avast for quite a few years and on many systems, and I've only encountered a single instance of this. Do be sure to double-check with 'virustotal' in case these aren't nasties that KAV6 is missing. Joe.

No, actually. I blame you. If you have nothing constructive to contribute, why open up a hornet's nest? I hope some day you encounter a problem and when you report it, you are told that you're the only one to report it, etc., etc. I gave all relevant details concerning the issue, so anyone can replicate it if they so wish. Reasonably, any component of the SP that may break things should be optional. Making things optional just for someone's personal preferences could be considered unreasonable, since we don't want a myriad of install options without good reason. Joe. PS. That last comment is not meant to imply that there aren't other legitimate reasons for something to be made optional in the SP (for example, any stuff that goes beyond the scope of a service pack).

The Win9x version does not have any binary output that I can see which is a shame because this would solve many of the problems mentioned in this thread. Yes, however, I have no problem exporting from the registry using 'regedit', even when it's about 13MB+2MB. The difficulty is doing the reverse, either "live" or "offline", as 'regedit' crashes and other utilities seem to neglect an import capability. FWIW, I found this info somewhere on the web : As for RegExport, alas, I've seen a few other utilities with this capability, which as I've stated above, can be done quite satisfactorily with 'regedit'. Now, if he'd written an import utility, I'd consider that a "must have". Joe.

Great find, shae! Joe.

Cool. The more, the merrier! Thanks jaclaz. Anyway, since what's left of my former P2 system is now packed away in storage while the house is being renovated, it'll be a while before I'd be able to rebuild it and try out these alternative APSI Layer drivers. Joe.

It seems to me like you are still missing a point. The Registry (online) is nothing but an assembly of 2 (win 9x) or 5 (NT) "databases" (or actually IMHO "filesystems") files. See also: http://www.911cd.net/forums//index.php?showtopic=24370&st=0&p=168043entry168043 Since you are seemingly old enough to remember good ol' DOS databases, you have to think to it as you would at a good ol DBaseIII (not that more modern databases are that much different ). You had a number of tables containing DATA, that were assembled and accessed in an "assembled" way through a form, and the results (still coming form the assembly) were visualized through a report. The normal online registry editor is nothing but a combined form/report "DBase" or "Clipper" app. Of course, like you could use *any* dbase uility to access directly the tables, you can use *any* registry tool to access the single files composing the Registry (offline). If you prefer, the Registry (online) as you are used to see it, is a building erected on-the-fly when booting with a number of bricks (and broken again into single elements when shutting down). Nothing prevents you to access the bricks when they are not assembled all together. jaclaz Hi jaclaz, I read this several times and gave it much thought. It is clear that there is something I don't understand, which to you is obvious. Perhaps it's this? : The 9X and NT versions of 'regedit', when operating in offline mode, operate on 2/3 or 5 registry files simultaneously, placing each key/value/etc in the appropriate registry file, following some rules based on the particular hive or whatever. So when you create/update an offline registry, it is either 2/3 or 5 files, depending if you used the 9X or NT version of 'regedit'. So in my mind, that's how I figured other offline tools would also work. So then the problem of converting 5 files into 2 ... could I simply use something like "copy /b a+b+c d"??? But I suspect now that other offline tools just work on a single registry file at a time, and it's up to the user to make sure it's the right one. Have I got it now? Anyway, subsequent posts indicate more fundamental compatibility issues between 9X and NT registry files ... Thanks, loblo. The descriptions for the two versions of RegDat here imply that you are correct (about the structure/format thing) : http://web.archive.org/web/20110202154630/http://regdat.com/ Joe.

More on the Adaptec Windows ASPI driver (version v4.71.2/4.71a2) compatibility issue ... I first encountered this incompatibility between the above Adaptec ASPI Layer and the Domex DTC3181X (et. al.) SCSI card/driver a few years back, when building my former P2 system. I started with the HD's from my previous 6x86L system which had W95C installed. I installed W98SE over this (I may have trashed the Windows directory first, I can't remember), then all the drivers, then all the app's. Then it was a matter of testing if everything worked. The scanner worked OK (via the SCSI card), but ImgBurn didn't. Investigating why revealed that this needed an "ASPI Layer" driver, so the obvious choice seemed to be the above Adaptec driver. That solved the ImgBurn problem. However, due to the association between ASPI and SCSI, I then retested the scanner. Oops! No good! I tried for a couple of days to undo the changes caused by installing the Adaptec driver, to no avail. Without another solution, I resorted to trashing the Windows directory and doing everything again (except the Adaptec bit)! This restored the SCSI/scanner operation. Then to resolve the ImgBurn problem, I installed the Nero ASPI Layer instead of the Adaptec one. Bingo! Everything worked OK. From this I conclude : 1) There is no ASPI Layer (at least, as far as ImgBurn's needs are concerned) after a full/clean install of W98SE. 2) The Adaptec driver breaks Non-IRQ (I presume that's the issue) SCSI card drivers. 3) The Nero driver doesn't break such drivers. Note, since the Nero driver is now impossible to find via their web site, here's the direct link for anyone interested : ftp://ftp6.nero.com/NeroASPIen.exe Joe.