Drugwash

Since DBGENG.DLL 5.1.2430.1 will only load DBGHELP.DLL with the same version and nothing else (it most likely performs an internal version check on the available dependencies and discards anything that doesn't match version and/or location), I'd say just forget about it. I do have a newer version of DBGENG here (from Debugging Tools for Windows) - namely 6.6.0007.5, but I have a hunch it may not be fully compatible with Win9x since it only imports the Unicode versions of certain API from other modules and that usually is a sign that ANSI compatibility does not exist (at least in portions of the internal code). Might not even be redistributable, if I read the licence correctly. Now, all XP flavors I've looked into, used DBGENG.DLL 5.1.2600.0 and it was also bound to its own paired DBGHELP.DLL, so that one is a no-no too. However, a couple of Windows 2003 versions - namely 5.2.3790.1830 and 5.2.3790.3959 - loaded fine with the default DBGHELP 6.8.0004.0 from my System folder, which means they're not bound to any particular version, therefore any of them may be a worthy replacement for the "stubborn" 5.1.x.x series. In regard to the four missing APIs, I've performed a couple of searches on my 98SE machine (Program Files and Windows\System) and on a XP-SP3 machine (whole C drive). Query keyword was "SymGetModuleInfoEx", which is one of the missing APIs. • On the 98SE machine I found it mentioned in ApiViewer 2004's database. Opening the application, I found all four APIs complete with prototypes but no details on them. • On the XP machine I found it mentioned inside a virtual machine image (.vhd) that holds a long forgotten Windows 95 test installation. • MSDN 2005 doesn't list it, nor is it mentioned anywhere (a search turned out empty). Actually none of the four appear anywhere in my local MSDN. Based on the above, I would safely assume that the four missing APIs in IMAGEHLP.DLL are not widely used - if at all - and might be safe enough to upgrade this library to a newer version, provided it matches its dependencies. If anyone else knows better, please come forward with details.

I think tomasz86's IMAGEHLP.DLL 5.1.2430.0 version is safe to use (roughly checked though). Some of the API are either duplicated between imagehlp and dbghelp, or forwarded from one-another - my tool still cannot differentiate between original exports and forwardings. I'll make the tool available as soon as I clean the current bugs. Certain options will need much more work but at least basic functionality will be there in first public version. I'll need some more attachment space here, otherwise it'll have to go through e-mail.

I say: unless it breaks anything, let it in. I got it there as part of my home network (which does involve Win7 and is not perfect but still workable using simple workaround - see my input in the Win98-Win7 connection thread). Let's hear from other people now.

Those four API are (apparently) exported by IMAGEHLP.DLL 5.00.2178.1. Later XP-SP3 version 5.1.2600.5512 does not export them anymore. Therefore best combination seems to be IMAGEHLP.DLL 5.00.2178.1 and DBGHELP.DLL 6.8.0004.0, unless there's other intermediary version that still exports them APIs. I'm working on a tool that'd automatically find best choice, but it's still in alpha stage, incomplete and with a few bugs. Please bear with me, I'm well-intended but very slow.

@PROBLEMCHYLD: Please check your PMs...

You're welcome! Please read here for more details on the load failures you mentioned. It's a good thing to have the boot log enabled during SP installation, it may offer clues as to what may fail in case of a hung boot sequence.

Indeed it was indeed Autopatcher I was thinking of, when I wrote UBCD. Thanks for the input, I corrected my post above. Yes, it is batch-driven, but that man knew his way around them. Is anybody else up to par with soporific în this regard?

The only possible way I see to log the full installation would be a main batch file that launches everything and writes the progress to a text file. This way, we may find which package (or file) failed to install, which file failed to register and at which point during the installation the machine may have hung. I realize this could be a tedious process, requiring many changes in the SP architecture and unfortunately I am not familiar with the complex syntax that would be required. Unless someone comes up with a better idea.

Here's an article that includes several links to useful tips related to the reboot/shutdown issue: link Here is the MS KB 187607 explaining how to disable fast reboot in registry: link

Ideally, the SP should implement its own installation log system, but that would require quite a fair amount of work. Tracking down each selected option and acknowledging its (un)succesful installation would easily allow for debugging. If I remember correctly, the defunct UBCD Autopatcher project (thanks Dave-H for reminding me) used to have such logging system, to some extent. Otherwise I'm afraid it's hard to impossible finding exactly what went wrong and why. A simple failed registration on a dll, ocx or other kind of file may screw a lot of things up, not to mention failed file copy and a possible dll-hell raised as a consequence. Hard to perform file/version comparison as it all depends on the options selected at launch time.

Just to be on the safe side, try to check your hard drive(s) with HDAT2, HDD Regenerator or any other similar tool that can find and fix bad sectors. The thrashing may be the result of such hardware failure. Additionally, any errors encountered during SP installation may well lead to incomplete installation of a feature or system file(s), thus forcing the system to search for the missing file(s) elsewhere or to gather information over and over again. If we knew exactly what the error message was, we might be able to correct the problem or at least fix it for the next release. One reason for a slightly longer boot time is the network card loading its drivers, logging onto the network and performing whatever functions it has to. A vanilla installation without network drivers will usually boot faster. Oh and the failed warm reboot is fairly common (black screen reading "Windows will now restart" or similar). I remember there is a setting somewhere in the registry that disables fast reboot but don't know its exact location off the top of my head. Some tweaking tools have it though. I've done it long ago and still, in certain circumstances (installations/uninstallations/updates/etc) some application may force a warm reboot, leaving the machine in a hung state. That's bad programming, nothing we can do.

In Win9x, the PING window will not run hidden; therefore, a series of calls to PING.EXE will result in a very disturbing flashing of a DOS window. For this reason, two years ago I have written a utility that can ping only one IP or address repeatedly and notify through message box (and speech, if enabled) when the ping failed. It uses IcmpCreateFile(), IcmpSendEcho(), IcmpCloseHandle() plus WSAStartup(), WSACleanup() and a couple other functions, which makes PING.EXE unnecessary. However, the utility only runs under Windows (definitely 9x/XP, not sure about Vista/7/8). If I remembered what I did back then, I could probably modify it to loop through a list of IPs/addresses, but I'm not sure what the usefulness of such tool would be and neither do I feel like coding right now. If anyone thinks it'd be needed as is, say so and I'll try attaching it here.

Ooops, I was about to forget... HAPPY BIRTHDAY!!! Thanks for all the effort you've put into this project! You deserve the best in life and I hope you get it! Cheers!

Now, why did I even bother to build this tool then? ( download )

With the invaluable help of our MSFN colleague Elvi and my home-made cherry brandy, I managed to get Compare SP to yield correct results. Therefore, whoever tried any version prior to 0.5.0.0, please download the latest and try agan, this time it should work. Download link is in post #1518. For any problems, questions, requests, etc. please use PM or e-mail (tray menu > About). Thank you and apologies for the off-topic.

Well... are they identical installations? I suspect at least some drivers might be different, not to mention whatever VM adds to the system by its own. Also I guess you didn't install HTML Help in the VM, while the real machine seems to have it (hhctrlui.dll belongs to it). On the bright side, I think I found the error culprit: ODBCCONF.EXE. That one returns an error for the Translation block, error which I missed catching. It's fixed now in the upcoming version. Still got a few details to fix - this subfolder search is kinda slow and not 100% accurate. Seems highly unlikely for all of your installed system files to be English versions (since none of them popped up in the list). So what am I doing wrong...? EDIT: Application has been updated, version 0.5.0.0 is now available in the same post above. This one really works! (this editing thing has become quite a bad habit of mine... but better than double-posting, more so when we're not exactly on-topic. )

It should get past it anyway, no biggie. I got a couple such errors myself when comparing two folders over the network between 98SE and XP - there's probably some odd file that doesn't want to be queried, locked by the system or something. Error 87 means 'invalid parameter'. However, if it happened to you in 98SE while under that VM, that could mean the application receives altered file/folder paths and that may be the reason for the empty list. If you could run it in a regular 98SE environment I'm sure it'd work OK. It does work fine here but I got an English system so can't find much difference between files unless one of them has no VersionInfo or the installed copy is accidentally of a language other than English. For example, I get hhctrlui.dll in the list, because it finds one of the multiple versions in the System\mui folder. I was just kidding. Don't worry, I'm not easily scared by a bunch of caps. But careful with those ricoches, they might hit the really wrong guy at some point.

Promise you won't yell at me if I tell the truth? Graphical objects have impact on resources. If something isn't absolutely necessary, then better scratch it. I'm not one of the minimalists or purists that don't use skins in Revolutions Pack and stick to original 98 icons and stuff, but other than that I'd hate seeing 98SE become as bloated as its younger relatives since XP (that one included). Anyway, that's just a blunt personal opinion, nothing more, so feel free to disregard it. While I'm here, please note that I've updated the Compare SP utility in the post above to v0.2.0.0 which includes the ability to search in subfolders too.

The two [ ... ] buttons at the top, upon pressing Compare!, should display the count of files in each folder and right below them there should appear a countown instead of Ready. If the countdown ends and there's nothing in the list, then all the file versions would be compatible. But be careful what you select in [Accepted language], better let it on system locale and also leave file type to any. I'm now working on an improved version that would also search subfolders in the main selected folder. However, the whole Windows folder might have too many files and would take quite a long time to complete. But you can always select it if you want, using the first [ ... ] button at the top. Just that it won't look in subfolders (in the current version). EDIT: Just make sure you selected the appropriate folders, because the program loops through the files in Folder 2 and compares with what finds in Folder 1. If you copy the exe in the folder where you unpacked the SP, it will automatically detect it and won't require any other adjustments. Could you post a screenshot of the app after selecting folders (if needed)? Also, I'm not sure if this app works correctly in a VM, can't test in such environment personally.

I've cooked a simple application to compare the language of files in two different folders. Please test and report if you encounter any problems. EDIT 2014.05.04: - attachment replaced with download link for v0.5.0.0 The package contains the executable (no installation required), source code (runs in AutoHotkey 1.0.48.05) and change log. DOWNLOAD CompareSP 0.5.0.0 Change log: 0.1.0.0- initial version0.2.0.0- added icons in list- added options to search in subfolders0.3.0.0- added more info to error message in GetLocaleInfo()- added Help message and menu item- added About message and menu item- fixed folder and subfolder search0.4.0.0- added options to list and save folder contents info (considering file type selection)- added option to include full paths when saving list- replaced <unknown> with dash (-) to save space- added 'Copyright' field (for the occasional suspicious user)- added more file types to selection list (386, cpl, flt, pdr, sys, tlb, vxd)- replaced vague 'system locale' with actual locale name in 'Accepted language' selector*known bug: non-printable chars in fields can screw up the saved list0.5.0.0- invalid language ID will be displayed as Hex number in list, instead of error messagebox- slightly changed comparison formula

Do your system use USBHUB20.SYS 5.0.2195.6891 or USBHUB20.SYS 4.90.3000.11?<br /><br /><br /><br />Mine has 5.0 but it may well be a botched install (see my old posts with the complete listings). It does work but not at the speed it should for a USB 2.0 hub. I just am too reluctant to mess with the registry again.

@Elvi: OK, I see paranthesis don't get recognized by DOS7. Well, we might just have to try a different approach, since I'm not a fan of batch files myself either. Let me think about it, see what I can come up with. And never dispair! @PROBLEMCHYLD: That key would only exist for that exact USB chip. By the numbers, it's an Intel USB EHCI controller. If you want to recognize a VIA chipset you have to hunt for VEN_1106 in the PCI section.

Elvi, as a first step, please carefully replace in all the batch files, the following texts and try running them in the exact places and order mentioned in that Win2000 topic: systemroot --> windir system32 --> system Before that, place the filever utility in the SYSTEM folder, not in SYSTEM32! Please post the results afterwards. Oh and pay attention to script bugs (see post #84 in the aforementioned topic).

There's still the possibility that a certain download manager that were able to download the file could alter the file timestamp; FlashGet does that when a download was paused and resumed so any other such app can do that. Exact file size would be a 99% secure pre-download indication, while an MD5 hash would ensure post-download file integrity and also version confirmation. If it were to use standard MS versioning convention, it should be major.minor.build.revision, where any of the members may range between 0 and 65535.

<br /><br />I've tried yesterday, precisely at the time of posting. Took me almost two hours to download through IE's simple download, since any other kind of download manager that'd accept resume would be banned for "too many connections" or whatever that PHP script may be filtering for. I've been using FlashGet for about ten years now, precisely for the resume feature, because anyone would go crazy when their large download would break at 98% due to bad connection. But that's not your problem, since you're not the website manager.Anyway, what I said above is based on those two dozen or more testing releases for the previous version, when one never knew which is what. And funny thing is, I could download those versions just fine through FlashGet, at the time. Now, I won't even try it again - I got a limited download quota and can't afford download attempts that may fail at any time, without a resume option ("thank you", Microsoft!!!!!).