Drugwash

Hmm, admittedly I didn't check the file deeply. I have a plug-in (FileInfo) in Total Commander which shows detailed information on executable files. The old mshtml.dll triggers an extra tab in the plug-in called Activex/OCX although there's an error regarding LoadTypeLib failure. The new mshtml.dll doesn't trigger that tab so I figured they must have changed its type. But it may just be because it can't be loaded. Too many assumptions, I should take it easy.

Ah, got here too late! I've had that problem myself a few times and everytime I had forgot the right way to fix it, banging my head on the walls. Apparently the easy way to do it is: - open a command prompt in the folder containing the offending file(s) a: • run a DIR /P command (in case there are too many files in the folder it will display a page at a time) • find the offending file(s)' SHORT name(s) in the list (cancel listing with CTRL-C if needed) or b: • right-click the offending file(s), select Properties and get the MS-DOS name (if present) - run DEL with those short names in the command prompt window. It should work without problems. Just make sure you don't get the wrong name(s), because they can be very similar.

Older mshtml.dll is an ActiveX itself, if nobody noticed. Newer one from the hotfix is not. It has been completely reworked, apparently. This brought in new dependencies. I tried it yesterday with KernelEx in Default mode and XP-SP2 mode and it didn't work; obviously the missing imports prevent the library from being loaded. For some reason I can't wrap my head around Kexstub.

Confirmed: everything is back to normal. Thank you!

My bad, got a habit of always inserting a blank space after the comma. Anyway, the idea was merely to point out that setupx.dll is being run through rundll.exe. Thanks for the correction though, someone might have accidentally followed the bad command formatting.

An easier way to unpack would be to download MSPatchGUI from my repository (check the sig below), run it, select the original exe at the top, destination folder below (no need to create a special folder, it'll automatically create one by the name of the exe file) and click 'Apply patch'. It won't actually apply it to the system, it'll merely unpack the files and process the deltas to create the true final files. The main file is mshtml.dll in the SP3QFE folder and there are others in the update folder. IE8: 6,022,144 bytes dated 2014.04.30 11:13 IE7: 3,628,032 bytesdated 2014.04.30 11:01 IE6: 3,094,528 bytes dated 2014.04.30 08:23 The mshtml.dll file in the IE8 and IE7 packages have a lot of unsatisfied dependencies in various system libraries. The one in the IE6 package has missing dependencies in four libraries: SHDOCVW.DLL, SHLWAPI.DLL, SHELL32.DLL, urlmon.dll. Last two ones are delayed imports. It may - and I say may - work in 9x, possibly under KernelEx.

Yep, it's probably setupx.dll's fault. And I figured you were gonna build the ultimate 9x installation disk. BTW, dunno if you're aware but there's been a similar operation going on for some time already, only it's for the NT family, at DriverPacks.net. Maybe you could learn a few things about shortening paths, filenames and organization of files from them. We could all use a good and most complete driver database for 9x.

No crash is good news. Apparently the loading is not very intuitive, which is my fault. Load themes folder means select a folder containing one or more unpacked/installed themes, not the theme folder itself. I haven't tested it in that situation before and right now I see it doesn't work although theoretically it should. My bad, I'll see to fix that. On a 98SE+RP system, the program should automatically detect and load the WINDOWS\Resources\Themes folder at startup. The dropdown list doesn't show anything, leaving it for the user to choose a theme from the list of available ones. So right after starting the program, all installed themes should be ready for selection in the dropdown box at the top (or top-left, when resized). Only after a theme has been selected in the dropdown, its contents will be parsed and shown in the tree below and upon selecting a branch, its contents will be displayed on the right side, allowing the user to view/change the available items. If no theme has been selected/loaded, there will be no file saved. The fact that it still attempts to do so is a bug that has to be fixed; I made a few stepts towards that but obviously there's more to be done. Thanks again for testing, apparently you're the only brave one! New versions will be uploaded to the same location when possible.

Yep, noticed that too. But now we see own warnings.

As submix8c pointed out, it appears that setupx.dll deals with those two driver database files. It's a 16bit (NE) library and it may be referenced by sysdm.cpl among many others. There may be a hardcoded limit of 2MB (2048kB) on the file size. Can't say more as I never managed to finish that NE editor. An interesting fact I noticed is that a few other files of different types also deal with the database files: - a couple of .dat (ME Setup.dat and W2K Setup.dat) pertaining to C-Media audio driver - WINPPPOE.DLL pertaining to Robert Schlabback's PPPoE driver - fppinst3.exe pertaining to pdfFactory - lxbkun9x.exe pertaining to Lexmark printer/scanner driver - daemon.msi pertaining to Daemon Tools 3.47 setup - a couple of .inf (NETRT.INF and NETRTF.INF) pertaining to Realtek 8029/8129 LAN card driver Those were all inside the Windows folder, in various subfolders. Most likely other packages (all 9x-compatible?) that install/uninstall drivers should have similar entries. Theoretically, I believe a driver uninstallation should completely remove all traces of its presence, including the entries in the two driver database files we're talking about. However, I think a lot of third-party driver packages fail to remove themselves from the database and/or leave behind inf files and possible their binaries, which is why after supposedly uninstalling a driver, upon reboot it will be redetected and reinstalled exactly as it was before uninstalling. For the issue at hand, a patch would be critical if one would attempt to build a custom OS installation media packed with all possible drivers. Edit: just seen setupx.dll being called in a lot of infs through rundll.exe in the form: StubPath = "rundll.exe %11%\setupx.dll, InstallHinfSection [...]" There's a chance the limitation may be within rundll.exe. But that's just guessing. (typos, typos, typos...)

And I found the very same string in the above-mentioned Realtek pack, in Alcwdm12.inf and also Alcxau12.inf. That's definitely what you need. The Creative card may come in handy at some later time, who knows...

You've cut out on the most important part of the information. The Description field for Audio Controller Hardware ID would specify the exact match for your card. However, I found many entries in a Realtek WDM driver (incidentally it's 4.06 which has been mentioned recently around as not working for some reason) that match the partial string 0C in the SUBSYS section. Therefore I believe you should go to the Realtek site and grab whatever may still be available for your version of the OS (which again you didn't mention so we cannot possibly know). If the earlier reports are correct, you may wanna search the web for Realtek driver packages older than 4.06, considering many manufacturers have gotten a bad habit of (intentionally?) offering bad/mismatched drivers for "retired" versions of Windows, probably trying to induce the idea that either the hardware, the OS or both may be defective, thus leading the user into buying "the newest and shiniest"... oh well, enough ranting. Good luck hunting for drivers!

New version is up. Should work in Win7 too, with one minor issue: when saving, file extension must be specified as .ini even though it appears to be selected below the name in the Save dialog - otherwise it'll save an extensionless file. Thank you, MS! Hopefully it won't crash anymore in 9x although I didn't exactly find the culprit; it must be a bad timing somewhere, trying to use a memory location that has been freed or something. Maybe the workaround will do. Still lacks stuff so don't get high hopes.

Presumably you can use expand.exe to decompress this file. I had tried that at the least, seeing it was right next to the said file. Won't budge. No idea. My files are actually on HDD, I've copied them over years ago when working with soporific on one of his projects. Timestamp is Jan 31 1999 while most other files and cabs are April 24 1999. It jumped at me first, didn't bother to search the cabs as I presumed it must be there for a reason and while being there it might actually be used sometime in the process. Thank you, Den, haven't got the time to search around - I'm a little bit swamped right now. I'll see what UnSzdd can do. Anyway, since a compressed file (presumably) belongs to the installation and might be used in the process, there should at least theoretically be a tool to uncompress such file right in that package/media. Possibly bundled inside some other executable.

Ah, darn, I'll have to turn on a Win7 machine and check it! On which system does the saving error happen (98SE/XP/7) and what eactly was the location you tried to save the file? If on 7, it may be a privilege restriction. Anyway, I'll see if I can reproduce it. Thanks again! Oh and maybe we should get to PMs or e-mail, to avoid cluttering this thread.

I've performed a comparison between the versions of advpack.dll on the 98SE CD and SP3 v3.33. The difference is the former is linked to ntdll.dll while the latter links to msvcrt.dll. Oddly (or not), I couldn't unpack msvcrt.dl_ from the 98SE CD, which seems to be compressed with the old Diamond ot something (header says SZDD, didn't look it up). Therefore I can't check if it exports the required APIs. Also, the newer advpack.dll from SP3 calls a few extra APIs in kernel32.dll and user32.dll, compared to the old one. Dunno if that's part of the problem. Thing is, both of them export LaunchInfSection so the problem may be somewhere else. Unfortunately I don't have the means to debug this.

thanks, they may prove useful with the Editor. When I get to the cursors part, that is. Too bad some schemes are incomplete and there hasn't been an update in... four years or so.

Ah, feedback... finally! Thank you very much, Charles! Now, good news is the issues you presented are known and should definitely be gone in a public working build. • That naggy warning on exit is there just to remind me to implement an overall switch that would indeed warn the user when closing the application without saving the changes. Hopefully I manage to do it right. • Skinning is in random mode only now, for testing purposes. In a working build, the user will obviously have the choice to save a particular skin color or keep using the random mode. Contrary to MS' advices, it will use an .ini file to store its settings, for portability. • Same goes for toolbar icons: their chosen size will be remembered between sessions through that .ini file. About tooltips: they could probably be implemented, at least for the color picker buttons. As for the Default and Original buttons, I'm still looking for the best choice to hint their usage by column, while also allowing the user to change all the settings at once (such as "All back to default" or "All back to original"). Same tooltip for each button in a column would be annoying since they have the same function, don't you think? I'm a little worried about the color pickers (black buttons). Did you actually load any theme from the toolbar list or tried to change the color of an element? The respective button's color should change to the selected one immediately and also on loading a theme, all buttons should reflect the colors set by the corresponding values (if the respective options are enabled and they should be when loading existing themes and colors are set). So could you please confirm whether the color picker function works correctly? Oh and the application should also work in XP, at least; haven't tested it under other OS versions but may also work in 98Gold/ME/2000/2003/Vista/7. So if anyone is preparing RP themes on another system, they can simply use 'Load theme folder' from toolbar or menu and work on them. Have you tried loading a theme folder other than the (auto-detected) installed themes folder? Or saving a modified theme and comparing results with the original? BTW, the "Save" function is for now in 'safe mode', saving as "mod_" <original filename.ini> to avoid any accidental overwriting of the original file. "Save as..." allows for choosing the output file name. Thanks again and please let me know how the above goes. edited a minor typo

The initial version of advpack.dll is too old and misses the API mentioned in the error box, while during setup it is being replaced with a newer one that allows the command to be executed...? Dunno, just guessing. Find Dll Details here, run it, drag both versions of advapi.dll onto it and check the Exports section. If I'm right, you may have to slipstream the newer library onto the installation media to be used instead of the old one. Don't ask me how to do that, slipstreaming is not my expertise.

Personally I think that article is an outright advertising for that hosting (or whatever) company. I also think the recent bubble burst on privacy that started with Snowden's so-called whistleblowing was just the kick required to start implementing worldwide tracking, loss of privacy and so on and for that, an IPv6 network would be required. So don't worry about being too old when it happens, because it'll happen sooner than you believe. And I do wish I was wrong, but usually when it comes to bad things, I'm not.

It's not the rendering that bothers me, it's the connection itself. I've raised the topic some time ago and others did as well: when IPv6 will become the de-facto connection standard, Win9x will be kicked out of the Internet instantly. Nobody seems to have improved/ported that Win95 Hitachi IPv6 driver to the whole 9x family. Browsers can be built/modified/rebuilt to work around the standards and limitations but if one can't even connect to the Internet in the first place, what would one need a browser for? Drivers are the main, extremely important issue and those who put out extensive efforts to forbid creation and distribution of 9x-compatible drivers knew that very well. Hardware manufacturers don't hand out the specs publicly so not even the best developers out there could face the challenge of creating 9x drivers for newest hardware. When old hardware dies of old age (or lousy quality components as it recently happened with my most powerful motherboard) it'll be strike three and out for 9x. And no, running in a virtual machine does not count.

The Internet is not the primary (or only, as it seems looking around) goal for a computer usage. If/when faced with the choice, I will give up Internet without blinking, rather than losing 98SE. Simple as that. I don't use Google, I don't watch YouTube, I don't do banking or shopping. Flash is permanently disabled in my browsers, Java is not installed (and the 98SE machine has MS Java runtime uninstalled). Admittedly, I am forced to use another computer with a different OS for my current Internet connection, because the chinese manufactures obviously wouldn't produce 9x drivers for the GPRS modem I have, which is my only means of connection. But I've lived without Internet and I will continue to survive without it when time comes. As for software, I either go search for open-source projects that I can use as-is or modify freely, or just build it myself according to my own desire and specs.

That may be hardware/driver dependant. I've had some Office installed for years and can't remember having experienced such issues. However, I've extremely rarely used any of its components, to the extent that I actually had to open a blank document right now to check the About box, which says: Microsoft® Excel 2002 (10.6501.6714) SP3. Maybe you're using a different version, some common system dependencies are different or - as I mentioned in the first place - your drivers or the motherboard itself behave in an incompatible manner. If anybody else has (had) similar issues and fixed them, maybe they could share the experience (and solution, if any).

The stability thing may be quite true for Win95. I remember having such problems when I used 95OSR2 after Win3.1. Those butterfly cursors came from a Desktop Theme designed for Win95 Plus!, if I recall correctly. System used to freeze often and needed reboot. However, 98SE and later aren't so sensible; I settled for the standard Animated scheme long ago in my 98SE and never had any problems. Animation is a good visual feedback while waiting for an ongoing operation to finish or show the process is hung. Still, cursors do have quite strict requirements in the 9x OS family. I've worked on a project where I needed to create cursors from resources. For the life of me, I never managed to get animated cursors work in such situation, but only when loaded from file on disk. There must be some trick involved, if at all possible. Oh well, sorry for digressing.

There used to be Desktop Themes long time ago. They contained cursor schemes, sounds, wallpapers. For a long time I've used on my computers the cursor scheme from the Mariah Carey theme - a very nicely drawn animated butterfly. After a long time I discovered there was an inconsistency in the color depth between frames which sometimes froze the system. Cursors are essentially bitmaps. Static ones can be created from standard bitmaps by simply changing extension to .cur and setting the hotspot with a hex editor. Or something like that - I already forgot.