CharlotteTheHarlot

Unfortunately, this one is *not* a SysTray app. You just leave it open down on the Taskbar. DriveMeter by Joe Lippeatt . However, it is freeware and working in Win9x (unlike lots of these apps that either require .NET or XP/Vista for some reason). Whoops. Sorry, the homepage seems to be dead. So is the download link. homepage: http://www2.netropolis.net/domag/drivemeter file: http://www2.netropolis.net/domag/drivemeter/dmfiles.zip I'm sure it will turn up eventually. Google the given info and filename for leads.

Just a quick update regarding the use of McAfee v6 on Win9x. I extracted the latest DATs v6511 (see details explained above in post #40) ... ..... 640,057 . 10-26-11 . 1:40a Avvclean.dat ..... 445,913 . 10-26-11 . 1:40a Avvnames.dat . 125,551,486 . 10-26-11 . 1:40a Avvscan.dat As described previously, just strip the AVV prefix from the default filenames and replace CLEAN.DAT, NAMES.DAT and SCAN.DAT. The 32-bit engine file, Mcscan32.dll is once again identical to past versions so nothing need be done. As before, it took a LONGGGGG time for McAfee to initialize and load the DATs (over 5 minutes!). But all went well and McAfee scanned files and folders successfully! Pretty impressive really because the main executable McAfee file is VSMAIN.EXE v6.01.2000.1 is dated: 2001-11-16. Almost exactly 10 years old.

UPDATE TO POST #1 The top post has been re-written to describe the current ZIP package suite dated: 2011-09-20.. Win9x fans will notice that ONE more utility no longer operates. -CTH-

Agree fully with these comments. This timeframe, circa 2004 was when the hardware was perfect for Win9x (that is Win98se of course). Almost everything in this era came with WinXP naturally which allowed a nice comparison. You just slapped in another HDD, installed Win9x and booted from either the Win9x or WinXP drive to see the difference. The WinXP GUI would be much slower while the Win9x GUI was blazing fast (for lots of reasons but among these the fact that all the metrics controlling the GUI in WinXP were slogged into a gigantic registry). WinXP would not get fast IMHO until multi-core CPU's and DDR-2 were common. Microsoft is always selling the OS for the next generation hardware it seems. If I was intent on using Win9x a lot these days I would be snapping up all the i865 motherboards I could before they all wind up in dumps. For Win9x, i865 was a all-in-one solution. IMHO this would be the minimum I would find acceptable ... Pentium 4 @ 2.4 GHz DDR-1 Native USB 2.0 Most i865 boards I had included onboard Video, Sound and NIC, but they of course could be added separate to the barer motherboards. The intolerable things to me were USB 1.1 and SDRAM. P.S. when I said NT family earlier in this thread I obviously meant Win2k and above, not NT 4.0 or earlier (I had these back to OS/2)!!! I use the term WinXP more often because Win2k and earlier is very hard to come by for the average computer dabbler. WinXP was the first easily obtainable release for the average Joe! What I was talking about concerning stability is this: * On Win9x almost anything, hardware or software can kill the entire Operating System, that means locking it up, keyboard dead, no way out without a hard reboot from reset button. That leads to an infuriatingly long blue screen scandisk because of the dirty flag to a stale FsInfoSector. * On WinXP almost nothing, can kill the entire Operating System. But when it very rarely does, reboot and it is done. That is what I call stability, and was the very strength of the (albeit slower performance) NT kernel. The resource pool, memory management, IRQ juggling, NTFS, multitasking program isolation, all were well refined for server use. These are positive developments. If you run computers using both Win9x and WinXP side by side you cannot ignore these positive developments. This is why I suggest WinXP for the internet facing computer. If you are going to throw very active CPU and disk intensive software on a computer, like a realtime antivirus and a 2-way firewall, Win9x is going to have way more problems processing the constant activity than WinXP, (even though on the same identical hardware WinXP is slower it is more stable). This is before we even discuss Internet Web Browsers, which in my opinion all suck. But once again, the experts here (not everyone else) can just use Win9x with ethernet to a NAT router on broadband with the most modern browser that works, without antivirus or firewall and be ok. The average computer user is not equipped with the skillz or patience to deal with hour long scandisks after hard lockups when they were just twittering, facebooking or emailing. Not to mention the fact that they click on anything and everything. If you have friends and family members all around the world, and they ask you this: which computer should I use for my internet, my Windows 98/ME computer or my new WinXP/Vista/7? You know the answer! You do not want to be answering the phone to explain the crashes and lockups, and walking them through recovery and finding their lost files. Life is too short.

That's you're problem right there. Blaming the operating system for a slow computer (Pentium II or III ?) on a slow physical connection (dialup!) while using browsers (Opera 10, FF 3) that hate Win9x anyway since the developers were probably using WinXP+ on blazingly fast computers on broadband. No offense, but judging from your stated opinion you're likely ill-equipped with the required patience or tech skills for any flavor of linux. Perhaps something with an apple on the logo? In all seriousness, most people trusting critical information and solid online security to Win9x are not thinking clearly. You want a bombproof computer without blue screens from a flaky browser or network driver or hardware problems. This really requires Win2k or above OS because of the practically crashproof kernel which has the ability to quietly terminate buggy applications and resist corrupt or hostile websites and attacks. Well, that's the way I see it. But if you are just casually browsing *without* regard to critical data and banking and you couldn't care less about bluescreens and reboots then Win9x with ethernet to a router on broadband can work fine. But if online banking and security is required you should build a secure internet facing computer on the NT kernel using firewalls and the latest browsers. These are two completely different scenarios, and you wanted them combined into one on the cheap. I'm not saying it's impossible, there are plenty of people here who are using Win9x online on muscular hardware configurations, but you mention not wasting time, when I hear that I point to NT because they are pretty much 'fire and forget'. Of course, there is nothing stopping you from having two computers ... Computer-1 :: Win2k or WinXP for the secure and always updated internet appliance (people are throwing away WinXP computers everyday, one should easily be found). This one could even be a laptop and using something recent like Vista or Windows 7 I mean 6.1. You will not need to waste time maintaining this one because auto-updates can be left on. This computer would be off a NAT router and possibly have a firewall and antivirus for maximum security. Naturally the hardware specs should be high with at least a 2-core CPU and a few GB of RAM. Computer-2 :: Win9x for offline which is not connected so it removes all the screwing around with internet, browsers, security and such. Since it would not need a realtime antivirus, the computer will much snappier in its response. It can be tweaked for games and local file work and whatever. BTW, this operating system, Win9x is *not* slow and is actually faster than all it's successors on identical hardware because it does less work behind the scenes (less overhead). Of course that missing overhead includes better memory management and multitasking and device management that made the NT family hardened against crashes. Made me LOL actually!

Well, I have three icons in Quicklaunch for drag-dropping files or folders for comparisons, each with their options preset slightly different: for certain tasks. WinDiff ... ExamDiff v3 ... ExamDiff v2 Though I rarely need anything but the first two (WinDiff, ExamDiff3) for most comparisons. WinDiff is free from Microsoft and is simple but very effective. It does pretty much everything (text, binary, directories). But for binary you will not get the nice hex view of different bytes. ExamDiff is not free but worth every penny and has all the bells and whistles. They do seem to have a free version on their page but I cannot recommend it if it does not do binary or directory comparisons. Buy it if you want everything. WinDiff stores its settings in the registry, the others use a local file. This means that using multiple versions of WinDiff is problematic because they each read/write the same registry key. ExamDiff uses a local .TXT file (like an INI) for its huge selection of options so different versions can coexist. WinMerge is good and is free 3rd party Open Source software. I have too little experience with it to say much more. I have it but haven't really needed it. Visual Merge (link), Grigsoft Compare It! (link), and Scooter Beyond Compare (link) are three more non-free trial/purchase possibilities to consider, but I am not fully up to speed on them currently because the ones I have work and have not yet forced me to look elsewhere for other features.

(I meant to mention something in this thread a while ago, and now that it has been bumped ...) In my mind there are three ways to use the context menu registry shell keys to issue DOS commands to a folder (or files). ; ;;; Method 1 :: using Registry to issue an actual DOS command ; NOTE: you are limited to a single command line of course ; [HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell\Generate-FileList] @="Generate a FileList ..." [HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell\Generate-FileList\Command] @="CMD.EXE /C DIR \"%1\" /A:-D/B/O:GNE/-P/S>\"%%date:~-10,2%%-%%date:~-7,2%%-%%date:~-4,4%%_%%time:~0,2%%-%%time:~3,2%%-%%time:~6,2%%.txt\"" ; ;;; Method 2 :: using Registry to call a shortcut (PIF or LNK) to a batch file ; NOTE: trial and error to use %1 successfully ; [HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell\Generate-FileList] @="Generate a FileList ..." [HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell\Generate-FileList\Command] @="C:\\Dos\\FileList.pif %1" ; or ... @="C:\\Dos\\FileList.pif \"%1\"" ; ;;; Method 3 :: using Registry to call a batch file directly ; NOTE: trial and error to use %1 successfully ; [HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell\Generate-FileList] @="Generate a FileList ..." [HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell\Generate-FileList\Command] @="C:\\Dos\\FileList.bat %1" ; or ... @="C:\\Dos\\FileList.bat \"%1\"" Method-1 is already discussed at length here in this thread and really leads to some amazingly creative command lines strings due to the complex quoting and escaping of the characters. A bit complicated I think. The best thing about this method is that you only need to add the REG entry and your done. But, needless to say the limitation is of using a single command line because of the fact that the Shell COMMAND subkey is one single string. Offloading the commands to a batch file makes the editing easier and gives the advantage of using multiple command lines. This, for example would allow you to echo extra lines for a header and external commands to get date and time and other housekeeping information to also have in the filelist. It is great to be able to echo commands to the console like Generating Filelist, please wait! and other stuff to show status and whatnot. Method-2 is really an offshoot of the way we used to have a context menu entry for Open CMD window here ... which called a PIF or LNK shortcut (to COMMAND.COM or CMD.EXE) depending on the OS. The shortcut was hard-coded to its target, in this case a BAT file. The shortcut could accept a parameter. But shortcuts, especially PIF files are notorious for breaking later, particularly on WinXP. The biggest problem is that porting the filelist function from computer to computer involved not only the REG key and the BAT file, but also a pre-configured PIF or LNK. , so we can skip this method and go straight to ... Method-3 is (IMHO) the best way to launch stuff from the context menu. As mentioned above there will be no limitations on how many commands can be launched from the single registry shell entry. Besides multiple echo commands for output formatting in the actual filelist and console feedback for the user, it allows testing such as for OS (e.g., Win9x could use ANSI screen colors on the console), copy the output to multiple locations, insert date and time strings into the filelist, send the filelist immediately into an editor, create a unique filename using date and time strings so that the filelist is unique, (etc ...). But the most important advantage is that FileList.bat is the only place that needs any editing ever. Once the very simple shell entry is in place, there is no need to dicker around in the registry anymore. The strange escaping and quoting needed for commands in the registry can easily lead to errors, whereas the syntax of batch commands is tried and true. DISADVANTAGES: Porting the function involves the REG key *and* the BAT file (rather than a mere REG patch). NOTE-1: on some computers it is still necessary to set properties on the BAT file to close window when done, but not always. NOTE-2: some trial and error may be necessary to make use %1 in that REG string, but very often all that is needed is that one simple line: @="C:\\Dos\\FileList.bat %1" (with no escape). I've never been able to understand why this is inconsistent on some computers. It must be all the automated tweaking from REG patches that changes certain little aspects on every computer.

Some kind of analysis and report generator I would guess, but I cannot think of anything. You might want to scour around the MDGx site for starters. When I used to juggle hard drives between Win9x and WinXP systems a lot, I too would notice odd things, like illegal characters in filenames, shortcuts and such. I just chalked it up to the natural unicode-ness of NT5 and its probable lack of error checking which would be needed to ensure backwards compatibility to FATxx and Win9x. I figured Microsoft just stopped caring, and after a while, so did I. One could spend a lifetime correcting these mistakes. Anyway, what I would do when this would happen was to run a blue screen scandisk (never trusted the GUI version) with a highly edited SCANDISK.INI and switches to fix nothing except generate a report. I then took this LOG file and manually fixed everything that I felt I needed to correct. From that same website I noted above, see Understanding ScanDisk, and FAT File System Troubleshooting for some general information. Microsoft article #199557 gives the command line switches. I always used /checkonly and /custom. Those programs I mentioned previously ... ZealSoftStudio ChangeCase ... available here ... (completely free) Briggs Softworks DirectorySnoop ... available here ... (retail trial) Another possibility is X-Ways WinHex seen here (retail trial) which has some analysis functions and forensic ability. Thanks. So I had my 'logic' reversed. That is important to know. So the duhfault in Win9x was to display (false) mixed case until you checked the box to the Allow all uppercase names. This would force the GUI to display filenames as they are actually stored. Once this setting was enabled any uppercase filenames in Explorer would presumably be files that only had the standard 8.3 entry. Any mixed case filenames in Explorer would presumably be files that had *both* an 8.3 standard entry and the extra LFN entry(s). EDIT: added link to FAT32 section of MDGx site.

You're talking about the FAT32 file system here, viewed under both Win9x and Win2K/XP/+, am I correct? One answer to the last question is a disk file system browser, like DirectorySnoop, a trial/buy non-free utility (but infinitely useful for file recovery and exploration). Worth every penny. You get both a FAT32 module and an NTFS module in the package, they are Windows GUI apps and not command line. With it you can see every detail from cluster chains, to any sector contents, deleted files and folders and lots of technical stuff in the help. It is not a disk editor like Norton was (but almost nothing is :-)) although it replaces much of it. Directory entries and LFN on FAT32 gets complicated. Here is a very good refresher (at least a decade old!) ... Long File Names See especially the info on LFN Bloat. On FAT32 every file had a 8.3 directory entry which typically appeared all uppercase in Explorer, but I believe there was a setting to make them appear to be mixed case which is more aesthetically pleasing but did not actually alter the directory entries (can someone verify?). Now this *is* important: once you modify any standard 8.3 filename like capitalizing one letter (or use a 4 character extension, etc), then you just created a bona fide LFN and an extra, additional LFN directory entry was generated. Do this to a folder full of 1000 files and a thousand new additional LFN directory entries were generated. This could lead to bloat, and add in some fragmentation and things might slow down. I believe this is why the default was to stick with 8.3 uppercase and LFN generation was left to the user a la carte so to speak. I am not sure I understand fully your problem, but I am led to believe that you are using FAT32 disks in WinXP and setting them to proper LFN while in WinXP. I suspect that placing this disk back in a Win9x system will have different performance issues (because of the much better memory management in WinXP over Win9x). Win2K/XP+ will have no problem with huge FATs whereas Win9x gets flaky sometimes (e.g., coupled with a large registry, low resources, ...). But it seems everyone has different results. YMMV. To avoid digging into actual directory entries (walking the cluster chain), there is a nice free utility called ChangeCase (also a windows GUI app) that I always use when I wanted to purposely set entire directories or drives to Upper/Lower/Mixed/Title case (and of course create tons of LFN directory entries in the process). It allows you to set the case however you prefer. For example, I always found it useful to set all folders a certain way (attributes too) and then later I could quickly eyeball a change made by some other program behind my back. This utility works fine in both Win9x and WinXP. Is that what you are looking for?

(please note the spelling of the filename: McScan32.dll) 3,182,712 . 07-31-09 . 6:40a Mcscan32.dll File Properties | Version (under WinXP) ... v5.400.0.1158 File Properties | Version (under Win9x) ... v5.4.00 CRC in WinZip ... c2482d68 MORE INFORMATION ... I was able to search through a collection of McAfee DATs and determined that this file (McScan32.dll) has been identical since around the 5741 release circa 2009 September. In other words this file has been unchanged for almost two years. SUPPOSITION ... at some point this DLL will again be changed and will likely not work with Win9x any longer even though the 10 year old executables will function as always. The question will likely become, will the DAT files of some future time work with an older McScan32.dll on Win9x? Your guess is as good as mine. None of this would be necessary if all the antivirus vendors and virus research labs simply agreed on a standard DAT database while keeping their engines and applications proprietary. But that would be just too logical. I couldn't find the 5100 DATs on any hard drives I have stored. But I did see 5090 and 5110. McScan32.dll is identical in both of those releases ... 2,867,438 . 06-09-06 . 5:10a Mcscan32.dll File Properties | Version (under WinXP) ... v5.100.0.194 File Properties | Version (under Win9x) ... v5.1.00 (probably) CRC in WinZip ... ca1d76ed

Well, this thread gave me an excuse to tie up an old loose-end, to see if my old McAfee v6 scanner is still working on Win9x with the latest DATs. I haven't tried this in quite a while since I have other computers configured for AV security functions, mostly WinXP which crashes less and is quicker to recover from a BSOD. First, I should mention that I never allow these things to auto-update or even to update DATs, I was never interested in realtime protection or letting them automatically update engines or DATs. Instead, I always backed up the previous working DATs and then manually extract the *latest* available DATs and then place the files where they belong. This allows me to fall back to the previous set in the case of a McAfee screwup. Secondly, and more importantly, this McAfee installation had been highly tamed. Every part unrelated to ON-DEMAND scanning was removed. There was a ton of registry editing, killing all autostart entries and drivers, removing 99% of the MSI Windows Installer references, associations and hooks. Essentially it has been neutered so that it never ran unless I right-clicked a folder and selected the McAfee shell/folder registry entry I made. The executable McAfee file is VSMAIN.EXE and shows v6.01.2000.1 dated: 2001-11-16. The two McAfee FTP sites I located are: ftp://ftp.mcafee.com/pub/antivirus/superdat/intel/ ftp://ftp.mcafee.com/pub/datfiles/english/ Giving me three total files to download: ftp://ftp.mcafee.com/pub/datfiles/english/avvdat-6346.tar ftp://ftp.mcafee.com/pub/antivirus/superdat/intel/sdat6346.exe ftp://ftp.mcafee.com/pub/antivirus/superdat/intel/6346xdat.exe Man, they are really getting very large these days: - 111,632,528 . 05-15-11 . 2:03a 6346xdat.exe <------- use /e to extract - 109,750,272 . 05-15-11 . 2:05a Avvdat-6346.tar <---- just use WinZip - 117,434,304 . 05-15-11 . 2:05a Sdat6346.exe <------- use /e to extract Here they are extracted into folders. Note, all the extra hyphens or dots are to keep the columns aligned. The style sheet for this forum software insists on collapsing multiple spaces into one, there seems to be no way to imply the <PRE> tag. ;----------- Avvdat-6346(.tar) ..... 569,961 . 05-14-11 . 1:40a Avvclean.dat ..... 423,049 . 05-14-11 . 1:40a Avvnames.dat . 108,744,302 . 05-14-11 . 1:40a Avvscan.dat ....... 8,689 . 05-14-11 . 1:40a Legal.txt ;----------- 6346xdat(.exe) ..... 569,961 . 05-14-11 . 6:40a Avvclean.dat <=== IDENTICAL to Avvdat-6346.tar ..... 423,049 . 05-14-11 . 6:40a Avvnames.dat <=== IDENTICAL to Avvdat-6346.tar . 108,744,302 . 05-14-11 . 6:40a Avvscan.dat <==== IDENTICAL to Avvdat-6346.tar ......... 783 . 05-14-11 . 3:50a Globals.nsg ..... 157,696 . 05-14-11 . 3:50a Gsdsuper.dll ...... 34,644 . 05-14-11 .12:07p Naiscrip.nsc ......... 401 . 05-14-11 . 3:50a Sdatpack.lst ;----------- Sdat6346(.exe) ..... 569,961 . 05-14-11 . 6:40a Avvclean.dat <=== IDENTICAL to Avvdat-6346.tar ..... 423,049 . 05-14-11 . 6:40a Avvnames.dat <=== IDENTICAL to Avvdat-6346.tar . 108,744,302 . 05-14-11 . 6:40a Avvscan.dat <==== IDENTICAL to Avvdat-6346.tar ....... 5,644 . 07-31-09 . 6:40a Config.dat ......... 783 . 05-14-11 . 3:50a Globals.nsg ..... 157,696 . 05-14-11 . 3:50a Gsdsuper.dll ..... 159,744 . 07-31-09 . 6:40a Mcprodinfo.exe ... 3,182,712 . 07-31-09 . 6:40a Mcscan32.dll ... (engine) IDENTICAL to existing ... 4,706,936 . 07-31-09 . 6:40a Mscan64a.dll ...... 93,794 . 05-14-11 .12:07p Naiscrip.nsc ......... 562 . 05-14-11 . 3:50a Sdatpack.lst ....... 7,842 . 07-31-09 . 6:40a Signlic.txt ....... 5,644 . 07-31-09 . 6:40a __X64_Config.dat ....... 7,842 . 07-31-09 . 6:40a __X64_Signlic.txt ....... 1,056 . 07-31-09 . 6:40a __X64_License.dat So it looks like you only need to download that one TAR file to get the current DATs, the pertinent files are identical, the superfluous files are unnecessary. First I determined that the target location for the DATs and Engine is in here: <YourPath>\McAfee\Network Associates\Virusscan Engine\4.0.xx Then I compared the Mcscan32.dll from Sdat6346.exe against the existing old one and they are still identical. Cool! So I grabbed the three DAT files and realized that they are using new names these days with 'AVV' prepended, so first I had to rename them ... ..... 569,961 . 05-14-11 . 1:40a Avvclean.dat RENAME TO: Clean.dat ..... 423,049 . 05-14-11 . 1:40a Avvnames.dat RENAME TO: Names.dat . 108,744,302 . 05-14-11 . 1:40a Avvscan.dat .RENAME TO: Scan.dat Then off they go into the above-mentioned folder. Ok, fire up McAfee v6 by rightclicking a test folder. Note, this step from click to the McAfee GUI took a loooonnnng time, at least 5 minutes! Whatever. Finally ... "Security Status" page shows this ... Virus Definitions: 4.0.6346 Created On: 05/14/2011 Bingo! They were recognized. I let it scan the folder (fast as ever). Success! on this ten-year old engine. Hope this is good news for somebody.

UPDATE TO POST #1 The top post has been re-written to describe the current ZIP package suite dated: 2011-05-03.. Win9x fans will notice no functional changes among the very few remaining compatible utilities distributed in the Suite. -CTH-

If you are using Opera you may have a Content Blocker string enabled (other browsers may have similar). I had one computer whose Opera versions 10 and 11 that kept serving up Web Address Blocked for certain clicked links including roadrunner.com, and amazingly even for google searches of a string simply containing roadrunner! Turns out in the Tools > Advanced > Blocked Content list of strings (kind of like a hosts file) there was this filter: *adrunner.*. A simple change to *.adrunner.* fixed it. I mention this because many filters that target ads could easily be mistyped to catch adobe. So check it out.

I just updated that post #4 with some more info.

Cool! And, nice link.

The answer is yes, these are the correct files for you, they are just compressed. No, they are not 'ZIP files with unusual extension'. From Explorer, doubleclick on file using extension: ZIP ... No!, adding .zip to the extension will not work because for some reason WinZip does not understand MSCAB when called from Explorer (well at least WinZip v14.0), if you add/change the extension to ZIP, and then doubleclick it, WinZip will return: Cannot open file: it does not appear to be a valid archive. NOTE: but it will work in another fashion, see below. From Explorer, doubleclick on file using extension: RAR ... Yes!, You need to have WinRar installed (and everyone should IMHO). So if you take xxx.ex_ and rename it: xxx.rar (or better yet just add on the extension xxx.ex_.rar, which is so that you don't forget to rename the original back), then you doubleclick it, yes, WinRar opens up the file as an archive and you can drag xxx.exe out of the archive just like any archive. Just have to remember that the file is not a normal archive. Open from Archiver ... Yes!, I just tested this now. All three popular archivers: WinZip, WinRar, 7zip will open a xxx.dl_ directly. So open up your archiver (e.g. WinZip), CTRL-O for Open dialog, paste the filename (if current directory) or paste the full path from anywhere, hit Enter and the window shows xxx.dll. Again this is manually opening a xxx.yy_ file from your open Archiver. This has nothing to do with doubleclicking the file in Explorer mentioned above (WinZip fails!). Tray Icons ... well the sound icon (assume you mean the soundcard manager, NOT the volume control) varies wildly from computer to computer. That icon lives in an EXE that comes with the audio drivers which may be Realtek, Creative, ADI, probably many more). But it is possible to find out where some of them are, one way is to use Process Explorer from System Internals. Locate the running process. For this computer I see the Realtek icon so ProcExp shows a file called: Rthdcpl.exe, selecting it and clicking its properties gives the location: C:\Windows\Rthdcpl.exe. That would be the file you are concerned with. Follow the same steps for other '3rd party' icons. Now the WinXP system icons are much trickier. On this computer the Network icon has no fingerprint in ProcExp. So I tried something else. Process Monitor also from System Internals. I started logging and doubleclicked the icon, stopped logging, weeded through 100,000 events and found references to two files: Netshell.dll and Xpsp2res.dll in System32. They both contain lots of icons. Also note that there also are files called: Xpsp1res.dll, and Xpsp3res.dll also containing icons. Good luck with that! I don't have time to go further right now. I guarantee other commenters in this forum have actual experience with tray icons and where the files reside. Tell the truth, I have never touched them as far as I can remember. EDIT: Added some stuff. See: Open from Archiver

These are compressed files using the MSCAB format. It should be identified in a file sniffer as Microsoft Cabinet Archive. You should be able to drop to a CMD window and simply type ... expand xxx.dl_ xxx.dll expand xxx.ex_ xxx.exe ... minding your current directory of course. I got so tired of this myself (this has been going on since what, DOS 4 or 5?) that I did something else. I associated them with WinRar. It was complicated because of how many extensions can be used (i.e., .sy_ or .cp_) but it was worth it. So when I double-click in i386 on Explorer.ex_ and I get a typical WinRar window containing Explorer.exe.

I am not surprised that MSIE is involved. Personally I always install the latest MSIE on WinXP, but I never really use it. I was demonstrating this for a client who always uses it, by clicking on Start | All Programs | Windows Update, that is the closest I get to MSIE, I told him. If there is a URL to visit, I dump it into another browser. The only real reason I maintain MSIE on a computer is for Windows Update, and also for those wayward apps that manually start MSIE by themselves (probably hardcoded internally or finding some registry key that points to Iexplore.exe). Those few odd times that MSIE is running is the only reason I allow its updates. I do hope you solve this though. I personally cannot help on this exact topic, except to comment generically and wax philosophical (as always :-) ... If I were on a mission to say, catalog the entire XP boot process on a specific machine (*), well it would certainly take a long time. To do it thoroughly I would let ProcMon log the boot to desktop (**) with its settings set wide open (i.e., capture everything). I would parse this file in multiple passes, maybe first enumerating all file access. Later I would enumerate all registering files to get a complete list and their chronology. Then I would Windiff snapshot the manual un-registering and re-registering of each of these files in isolation, building a 'total' chronological REG script as I went along. At some point I would consider the job done, having this large REG script that constitutes all the interfaces that are effected at bootup. I would also have a corresponding file that collected all the [-HKEY un-registered actions as well. (*) Specific Machine is an important concept here because no two are alike (auto-update guaranteed this fact). Even two of identical hardware where you scrupulously installed the exact same Win setup and hardware drivers. Any single change to a minor user pref or hardware setting, especially BIOS can cause great differences in the two machines (I found a way to mitigate the BIOS differences by saving the CMOS and pushing it to the other machine, before installing Windows). System Restore and Disk Indexing greatly expand the level of differences once Windows is in play. Add in pseudo-optional complications like .NET, MSIE and Live Essentials, realtime antivirus and malware apps, firewalls, etc, and we get the current situation where a computer is more like a human being - no two are alike. In my experience it means that when porting apps from system to system by collecting the registry paraphenelia it means that I have to grab the bare minimum needed to achieve the goal, all the while making decisions whether a given REG key/value is 'safe' with respect to the myriad of differences from one PC to the next. And then we have some clever programmers who like to insert their secret registry settings hidden in plain sight, buried in Explorer keys or even among System keys. But that's another story! (**) To the desktop, this means IMHO after all startup activity has completed, the pointer has stopped animating, disk activity is done. The Start Menu is NOT clicked, not even a right-click on the desktop or a systray icon. This means that certain icons/shortcuts need be in place already on the desktop in order to accomplish things without 'disturbing' anything. A shortcut to ProcMon/FileMon/RegMon is vital to be able to turn it off without first going through a menu. Various shortcuts to Regedit need be in place as well, for example a shortcut to export it. The shortcut to stop logging can also be placed in a startup location to automate this somewhat, however this may cause it to miss something that delay loads. Unrelated to boot logging and the topic at hand, but very important item to note when dealing with CLSID interfaces and registry expertise in general ... I should first say that it probably gets close to touching the clean Forum rules here (mods: I promise I will keep this legal). Certain software licensing or copy protection schemes exploit the vast registry collection of CLSID classes and such by inserting clever dummy keys and values based on existing files on a HDD. At first glance from the layperson they make sense and ignore them. But 'registry cleaners for example cannot determine their validity and usually wipe them out. I am speaking primarily of Asprotect (this why sometimes a program they paid for stops working). Asprotect will find a DirectX or Windows or MsOffice file present on the HDD and construct a group of keys that reference these files all the while encoding its secrets in the naming of these keys and values. The keys themselves are fakes though. So it is possible to uninstall a program and still find references to it afterwords because of fakes constructed by Asprotect. Typically they construct in HKCR: keys under CLSID, Interface, TypeLib and others, sometimes many others. To fully understand this would require some snapshots of installing an app using Asprotect, before and after. To explore this on your own, I believe recent versions of DvdFab fall into this category, a little searching will point out many others.

Understood. There is nothing wrong with what they did, you can put the identical entry in over and over, don't matter a wit. It's just interesting that the last key is using HKLM but all previous were HKCR. The last one seems to have been tacked on later for some reason even though it needn't be there. Just a curiosity, nothing more. Anyone else reading this intending to use the script can ignore this!

########### METHOD-1 ... SnapShots - Export your complete registry ... SAVE0.reg - Immediately RESTART. At desktop, do nothing except ... - Export your complete registry ... SAVE1.reg - Windiff SAVE0.reg SAVE1.reg F8 skips to next difference, F7 is previous. Confine your scrutiny to keys containing CLSIDs, ignore the others. Red background color denotes statements in the BEFORE file, and yellow background color for the AFTER. Re-registered keys sometimes 'move', they will change location from the BEFORE to the AFTER. More often, just the 'case' of a few letters will shift, usually to upper, Red and Yellow colors accordingly. NOTE: this isn't a guaranteed method because sometimes a key in a safe cozy location can be re-registered without changing its case or its position in the surrounding keys. So they won't show up in a snapshot. But this method will definitely show all changes. The only way to get those others would be realtime capture ... ########### METHOD-2 ... RealTime There is a way to capture the changes in realtime (only XP and higher) using RegMon from System Internals (not available officially anymore, but it is around). It has a setting that inserts itself into the startup sequence. The log file will be rather large and weeding out the false positives will be aggravating! Here is the pertinent section of the REGMON.HLP file ... Monitoring Boot-Time Registry Access (Windows NT/2K only) To use Regmon's boot logging feature simply select the "Log Boot" menu entry. Regmon will indicate that starting the next time the system boots Registry activity will be monitored and recorded to a log file named REGMON.LOG in your system root directory. When you make this selection Regmon configures itself as the very first driver to initialize in the system, enabling it to capture the Registry startup activity of all other device drivers and services, including critical boot drivers such as SCSI miniport drivers and boot file system drivers. Regmon stops recording to the log file when you start the Regmon GUI, and it will only log a single boot. Logging is therefore also stopped when the system shuts down, unless you have re-enabled boot-time logging for the subsequent boot. The format of the log file is the same tab-delineated text as a standard Regmon output file that can be viewed with any editor. Before you use the boot-logging feature you should ensure that there is ample free space on your system drive. Capturing Registry activity from startup to shutdown on an NT 4.0 system will generate a log file with 90,000-120,000 records (7-10 MB in size), whereas an identically configured NT 5.0 system (Beta 2) will generate 140,000-160,000 records (15-25 MB's of log data). If Regmon fills the disk while writing to the log it will truncate the log file and leave a message in it indicating that the disk did not have enough free space. Regmon aborts logging and cleans up the log in such cases so that lack of disk space will not prevent a successful boot. If you do not have RegMon, you have some searching ahead of you unfortunately. Both RegMon and FileMon were superceded by the uber utility: ProcMon (link to SystemInternals). It also does boot logging, but it requires more configuring since it does double duty! Disable file access logging for sure. Here is the pertinent section of the PROCMON.CHM file ... Boot Logging Process Monitor can log activity from a point very early in the boot process during the initialization of boot-start device drivers. Configure Process Monitor to log the next boot by selecting Enable Boot Logging from the Options menu. Process Monitor's driver will log activity at the next boot into a file in the %Windir% directory and will continue logging through the shutdown or until you run Process Monitor again. Thus, if you don't run Process Monitor during a boot session you will capture a trace of the entire boot to shutdown cycle. On Windows Vista and higher, Process Monitor supports thread profiling capture in boot logging. When you enable boot logging on supported operating systems, Process Monitor will present a dialog that asks whether boot logging should include thread profiling, and if so, the rate of the profiling. Note that thread profiling will significantly grow the size of a boot log. When you run Process Monitor it looks to see if a previous boot log has been generated, and if so, asks you where you want to place the processed boot log output file. Process Monitor displays the trace after it has finished translating it. To see activity from the System process, which is the only process early in a boot, select Enable Advanced Output from the Options menu. If you configure boot logging and the system crashes early in the boot you can deactivate boot logging by choosing the Last Known Good option from the Windows boot menu (which you access by pressing F8 during the boot). Note: network events, which are based on ETW (Event Tracing for Windows), are not available in boot logs.

Just FYI, these two are the same thing ... [HKEY_CLASSES_ROOT\.htc] "Content Type"="text/x-component" [HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\.htc] "Content Type"="text/x-component"

UPDATE TO POST #1 The top post has been re-written to describe the current ZIP package suite dated: 2011-02-01.. Win9x fans will notice that ONE MORE utility no longer operates. The file LISTDLLS.EXE v3.0 fails on Win9x, so users would need to use v2.25 instead. -CTH-

This won't create a problem, if I delete both? I'm willing to try it but I don't have time right now. Maybe this evening or else tomorrow. No problem. Do exactly what submix8c said to do (I was going to suggest the same thing!). Easiest to do this after: reboot | F8 | Command Line Only, but I believe it depends on the current swap settings. If it is set to Let Windows Handle ... AND you have ConservativeSwapfileUsage=1 in 'system.ini' AND you have lots of memory, your swap file will likely be 0 bytes and timestamped to your last bootup time. This can probably be deleted anytime. In other situations where the swap is being written to often, I suspect it may be locked (but correct me if I am wrong as I never do this myself anyway) and may require the F8 treatment to delete it. Definitely delete them both at the same time and reboot. Then open some big programs and files to force paging to disk and then search for the swap file(s). If there are two after this experiment you will have discovered something that none of us have ever likely encountered. Likely explanation would be some very strange malware that did not cover its tracks very well.

Delete the older one (the one in \Windows). Are you saying it comes back with that old date/time? Or are you saying the last time it happened (comes back) was in 2008?

Take a look at the date/time of these two swap files, what do you see?