CharlotteTheHarlot

If what you want is for each actual BMP file to show up as the icon for each actual BMP file (in Explorer, etc) yes, this is easy to do. You probably already have this behavior designated for ANI and CUR and ICO and EXE filetypes. You should also be aware that this is one of those tweaks that definitely slows down the display of a folder which contains lots of bitmaps. It would be a very good idea to first save these two keys from your registry (or just export the whole thing for safekeeping): [HKEY_LOCAL_MACHINE\Software\Classes\.bmp] [HKEY_LOCAL_MACHINE\Software\Classes\BMPfile] The reason that this is important is that BMP files might be mapped to a specific program like MS Paint or IrfanView or Photopaint rather than a generic filetype. What I am really asking is what happens when you doubleclick a BMP file? Having said all that, here is how I would do it ... REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Classes\.bmp] @="BMPfile" [HKEY_LOCAL_MACHINE\Software\Classes\BMPfile\DefaultIcon] @="%1" The first part designates .bmp files as being members of a class of objects called BMPfile. Again, on your system they might already be designated something else like IrfanView.bmp for example, if so, the above patch will break your BMP opening ability!). If you want to post back with your current entry, we can easily re-design the above patch to handle your circumstance. The second part sets the default icon for BMPfile objects as being "%1", which means whatever is contained within that object. SIDE-NOTE: I just tried it with double-quotes like I thought it should be: @=""%1"", and it did not work. Strange! Important! In order to see these types of changes, the Explorer shell must be re-started, not just the Explorer program. You should have something like NirSoft ExploRestart handy (a shortcut to this program belongs in your QuickLaunch). Just to repeat from above, you should post back here with your current entries for those two keys, and then registry patches to both enable and disable the bitmap icon can easily be posted. Hopefully this is what you were asking for! EDIT: @Chromatic47, honestly, your post wasn't there when I typed all that! Great minds ...

I'm glad you solved your problem! But, first, I must point out a correction to my above post. In order to test out Idea-3 you must SELECT the Do Not Cache Thumbnails checkbox and then APPLY. I had the logic reversed. DOH! It still might be useful to test that one out. Yup, I am well aware of that registry setting, the so-called Detect Accidental Double Clicks. That click timer thing was one of those horrible ideas in WinXP that I personally disengaged long ago. The theory was to protect the end-user from DOUBLE clicks that might execute a program when they meant to single click (i.e., all people are robotic internet browser web monkeys and MS will save them). What it actually did IMHO was to cause tons of files and folders to be renamed because the intended double-click often became a RENAME (like an F2 keypress) which selects and highlights the file/folder name and then, yikes. The next thing you see are strangely named objects side by side with all the typical New Folder accidents. Anyway, yes, this is a registry setting. It was found in the WinGuides XP Edition from 2002 and can be seen right here. REGEDIT4 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] "UseDoubleClickTimer"=- "UseDoubleClickTimer"="0" Presumably if that value does not exist ("UseDoubleClickTimer"=-) it would be the same as "UseDoubleClickTimer"="0". In other words, set it to "1" in order to activate the timer and thus prevent accidental double-clicks. Set it to "0" or remove it to NOT use the timer. HOWEVER, to further complicate things, like all per-user registry settings if this value does not exist here under HKEY_CURRENT_USER, it still would be active if it in fact existed under HKEY_LOCAL_MACHINE. Traditionally HKCU takes precedence over HKLM, so to be absolutely sure you are testing a registry hack, it should be done in HKCU. One more thing though. I went to my test machine (bare WinXP SP3) and carefully tested Single-Clicks with and without the registry hack and I see no visible difference in folder opening speed in Explorer. I believe this setting may work in conjunction with other tweaks. Either that, or this box is so fast (no McAfee, no Indexing, blazing CPU) that my eyes will not acknowledge any change.

Pentium 4 Prescott 3.4 GHz i925x with SATA Drives and DDR2. WinXP Home, full AntiVirus running. No USB plugged in and Ethernet not attached. Cold Boot to Desktop ... :58 seconds Restart Desktop to Desktop ... 1:20 Desktop to Shutdown ... :33 seconds

@adabo, A couple of ideas, try them one at a time. It would be good to close Explorer, make the change, open Explorer, test the folder open. Then, close Explorer, make the change, open Explorer, test the folder open. yada yada yada ... ******** Idea - 0 ******** Still my best suggestion, if you can re-install Windows, test out the folder open speed right after that. You really need to know when the problem started. Then you should add the software apps one by one, testing each time until you find out who is causing the delays! ******** Idea - 1 ******** If checked, try un-checking the Control Panel > Folder Options > View item called Automatically Search for Network Folders and Printers then click APPLY and then OK. ******** Idea - 2 ******** This is the most obvious time waster in the log. In REGEDIT go to the key: HKEY_CLASSES_ROOT\Folder\Shellex\ColumnHandlers\{24f14f01-7b1c-11d1-838f-0000f80461cf} IF IT EXISTS you Right-Click directly on the key in the left pane and select RENAME then press [END] which moves the cursor to after the key name, and type in: -disable (you are adding the text '-disable' to the key name). It should now be named: {24f14f01-7b1c-11d1-838f-0000f80461cf}-disable This effectively disables the Windows Explorer function of extracting the version information from a file (described in MSKB 328170). To revert back you RENAME again and edit out the '-disable'. This change should cause some noticeable increase in speed because that ColumnHandler subroutine is iterating wildly in your ProcMon log. ******** Idea - 3 ******** There seems to be some wasteful looping with the cached thumbnails which involve ADS (alternate data streams) seen in your log like so: 'Program Files:Docf_' etc. This would seem to be the correction: Control Panel > Folder Options > View, SELECT the item called Do Not Cache Thumbnails then click APPLY and then OK. You can always set it back if you need to. I always use details view, for fancy thumbnails or previews there are much better file manglers than Windows Explorer. ******** Idea - 4 ******** I doubt this is the larger problem, but you seem to have 7-Zip installed (hey, it wasn't in your list!). I used to see problems with the shell extension DLL back in the day and disabled it leaving the program available through a normal shortcut. You might try to kill the shell extension through the program options menus. ******** Idea - 5 ******** * Double-check your Scheduled Tasks. One of the CLSID's seems related. Look for something that runs in the background. ******** Idea - 6 ******** A quick Google search turned up: Wierd File Browser Lag that seems similar in content. Don't have time to look into it myself but some there seem to believe that this delay is normal. That's all I got for now. Hopefully some others can jump in and help out! I'm kinda busy scrubbing another virus off someone's system here. EDIT: Idea-3 has been corrected to 'SELECT' Do Not Cache thumbnails . Dang double negatives. Doh! Thats from being in a hurry.

Hmmm. You're either a fast learner, or not really a noob. Anyway, before trying another capture, here is a question. Can you install WinXP again, and then test the open folders BEFORE you install any 3rd party programs? I understand it is a pain, but its not so bad if you do this kind of thing a lot. That single test would completely rule out all that 3rd party software as the culprit (the Torrent client is possible). I have a bare WinXP test machine here (from SP3 install CDROM) without any other programs setup at all, no Windows updates, and only the minimal chipset/motherboard drivers. I believe it is as bare as Windows XP SP3 can be. I see no visual difference in folder open speed with either single-click or double-click settings. If that is completely impossible for you, you should obtain a good ProcMon snapshot. Please follow the steps carefully so that the information remains as pure as possible. Here is how: Open Explorer. Push the window to one side with a folder visible for the single-click test, do not click it yet. Open ProcMon. If already capturing press the magnifying glass so it has a red slash through it, this stops any capturing. Press Ctrl-X to clear the current capture if any. Push this window to the other side and shape it so they are both visible and not overlapping. Make sure nothing else is running. Close any that are. Look in the tray for hidden icons! Now click that magnifying glass in ProcMon, it should begin capturing. Quickly click the folder in Explorer, wait for the folder to completely open, then ... Quickly stop the capture in ProcMon by clicking the magnifying glass so it has a red slash through it. In ProcMon again, click FILE > SAVE, make sure ALL Events is checked, make sure PML is checked, designate a filename/path and click OK. Throw it in a ZIP file. Doublecheck the size (should be small enough to attach here). If too big you will have to upload it elsewhere. Probably won't have time until tomorrow or next day to check the log, but others here are also familiar with ProcMon. CtH

Actually this is kind of good news. It is not a hardware problem. It is likely something added to Explorer (e.g., context and shell enhancements). You say Windows was installed yesterday, what other programs were installed after that? This is important. You didn't mention about any realtime AntiVirus though. Is there any? It is possible for McAfee to scan files that it sees in folders that you just opened in Explorer but to NOT do the same for some other file manager. Assuming you have no realtime AntiVirus, the next debugging step would be to use System Internals ProcMon, a utility that monitors both file and registry access (your delay could be from either). You would launch Explorer, then start ProcMon. Now jump over to Explorer and open a folder, as soon as it is open quickly jump back to ProcMon and stop the capture. The results found in the ProcMon window will contain all the magic clues necessary to solve this. But ... Please Note: this is really expert level debugging, it is not for noobs! You would do well to study this utility over at System Internals before attempting it. There is no way to teach this here in a few posts. Make sure that you first learn how to enable and disable captures before you ever even try it! EDIT: you added this last fact after I posted that reply ... I don't have time to Google right now, but I remember something about Urlmon or WebView or similar that is related to 'Active Desktop' maybe. The Single-Click vs Double-Click is the tip off that this ties into the Explorer WebView thingy. I'd say it is a registry setting and its likely that someone lurking here already knows the answer and will chime in shortly. Else, get over to Google and dig it up!

I would take those exact error messages to Yahoo and get them to answer since there is no way that you are the 1st person with this problem. It would be nice if Microsoft would answer you, but, ah never mind. To really dig in to this problem I would test your version of Yahoo Messenger on a freshly installed WinXP SP3. Then, I would install the latest MSIE plus patches and test it again. Then I would install the latest JRE and test it again. This procedure would rule out some legacy setting that still exists in the registry today from years past. At the end of this I might know where the problem lies. If I had to guess now I would say that the Java installation is not 100% and I would be looking for alternate versions to install and test. You may want to spend some time in Google also, because I still see nothing to disuade me that some obscure MSIE registry killbit has been set. Remember that it was not long ago that Microsoft's Java VM was installed by default and it was a time of general chaos for utilizing Java on Windows. Sorry I cannot be more helpful. Just do not give up, this is fixable. Whatever you do, please share the solution when you find it!

Need more information to answer that. I do not have 010 Editor, is there a link that you can point to?. To make this context menu entry we need to know: What program you want to have open from clicking in the Context Menu. Its exact name and location on your HDD is also needed. What types of files this program is capable of opening. Is it all files like UltraEdit or is it only text files like Pfe32. Please explain everything you can and go heavy on the details. Another screenshot or a link to an existing one online would be useful. More details!

Well, it was worth a try considering that the StartMenu structure is in fact also a set of folders on a HDD. It seems reasonable to assume now that the 'MenuShowDelay' setting only modifies the function used by Explorer to display so-called Special Folders but not 'regular' ones. I am not aware of any other registry setting that is related to this but I would love to hear of one. One useful check might be to enable the Control Panel > Folder Options > General item called Double-Click to Open an Item, test your folder open speed, and then set it back and test it again. Another thing I would try is to run a 3rd party file manager like Powerdesk or Tracker or XYplorer or other. See if a delay is noticed when opening folders within them. Since they are not Windows Explorer based they would certainly help to pinpoint the lag as being introduced by the Windows Explorer shell itself or something else altogether. This is important (and I should have asked earlier!). Do you have any realtime AntiVirus application running? It has been my experience that McAfee and others will scan files in realtime when a shortcut is executed or when a folder is opened. It could be that your delay is to be expected. Depending on CPU speed and some other variables, delays from realtime scanning could be anywhere from a tiny to substantial.

Minor correction, 150 and 300 to be exact, the numbers you show refer to the Frequency of the SATA bus. Of course it usually matters not since the drives themselves (at least at the 7200 rpm consumer level) are often the same units with only the connector and interface changing. In practice they are all limited to where the data is read/write (outside of disk vs center), fragmentation and 3rd party influences (maybe Norton AntiVirus burning up your resources). I agree with your generally positive view of SATA advancements and prefer them myself as long as the BIOS gives me proper access to them, their bootstrap priority, enable/disable, etc. However, on too many budget motherboards, SATA and PATA are no better than each other except for the hook-ups, and are practically indistinguishable to the end-user. And too often, SATA/PATA may not play nice together on a given BIOS (to artfully steer this back to the thread originators question!). Excerpted from WIKI: Serial_ATA SATA 1.5 Gbit/s. First-generation SATA interfaces, also known as SATA/150 or unofficially as SATA 1, communicate at a rate of 1.5 gigabits per second (Gbit/s). Taking into account 8b10b coding overhead, the actual uncoded transfer-rate is 1.2 Gbit/s, or 1,200 megabits per second (Mbit/s). The theoretical burst throughput of SATA/150 is similar to that of PATA/133, but newer SATA devices offer enhancements such as NCQ which improve performance in a multitasking environment. Sustained data transfer rates are limited by mechanical hard drives themselves, not the interfaces: the fastest modern desktop hard drives transfer data at a maximum of about 118 MB/s,[4] which is well within the capabilities of even the older PATA/133 specification. SATA 3.0 Gbit/s. Soon after SATA/150's introduction a number of shortcomings were observed. At the application level SATA could only handle one pending transaction at a time like PATA. The SCSI interface has long been able to accept multiple outstanding requests and service them in the order which minimizes response time. This feature, Native Command Queuing (NCQ), was adopted as an optional supported feature for SATA 1.5 Gbit/s and SATA 3.0 Gbit/s devices. First-generation SATA devices were at best a little faster than parallel ATA/133 devices. Subsequently, a 3 Gbit/s signaling rate was added to the Physical layer (PHY layer), effectively doubling maximum data throughput from 150 MB/s to 300 MB/s. SATA/300's transfer rate is expected to satisfy drive throughput requirements for some time, as the fastest desktop hard disks barely saturate a SATA/150 link. A SATA data cable rated for 1.5 Gbit/s will handle current second-generation SATA 3.0 Gbit/s drives without any loss of sustained and burst data transfer performance. I have yet to see a SATA drive that hits 150 MB/s in HdTach or anything else. IMHO what this all really means is that the available bandwidth on the SATA Interface is high but no drives exist to saturate it. It looks similar to the high-end SCSI interfaces. However, if some solid state technology HDD at a reasonable price comes along, those interfaces will really pay off. I tend to agree with you here. When you constantly chain up all kinds of combinations of drives Western Digital often causes conflicts. The IDE jumpers were always a pain to me when distinguishing between 'single' and 'master', the cable middle/end, and paired with non-WD drives. SATA seems to be OK so far, although I have only had a few of theirs to play with. If I had to make a purchase recommendation to the thread starter, I'd say go with a retail Seagate kit (to get the CDROM and cables). Their warranty is currently hard to beat as well.

Never seen those problems myself, and I'm always using "0" (WinXP and Win9x). It seems to me that "8" is as equally arbitrary as "1" or "200". From the WinGuides 2002 CHM file: [b]User Key:[/b] [HKEY_CURRENT_USER\Control Panel\Desktop] [b]Name:[/b] MenuShowDelay [b]Type:[/b] REG_SZ (String Value) [b]Value:[/b] 0-999 (milliseconds) So if those are in fact milliseconds, we're splitting hairs here. My assumption has always been that "0" does not just mean one millisecond less than "1", but ZERO delay ADDED to the GUI function that displays a given menu. Not saying you're wrong though. I can easily imagine quirky video display drivers that require some delay padding. By all means experiment with it and report your discoveries. That's what we all should be doing. I'll leave it at this: like all registry performance tweaks, your mileage may vary! YMMV. EDIT: This is great news: WinGuides is still around! Under new management right here. That registry entry is found here. There is a seriously useful knowledge base of information there.

I'm not certain of your knowledge level so I'll assume non-expert non-Hacker. Traditionally we use a registry script like so ... REGEDIT4 [HKEY_CURRENT_USER\Control Panel\Desktop] "MenuShowDelay"=- "MenuShowDelay"="0" READ ALL OF THIS BEFORE YOU DO ANYTHING ... Everything in that box there is saved to a ASCII text file with a name like: myreg.reg into a folder you can easily locate like your desktop. Then you click 'START' then click 'Run' then type REGEDIT.EXE and press [Enter]. Now in REGEDIT click 'File' and then ''Import" and click your way through the folders to that file you saved and when you see the file you created, double-click it. Then you should see a dialog box verifying that the information was successfully entered into the registry. To test that the menus have been sped up you might restart now to be sure. Note-0: If you know how, you should first check and see what "MenuShowDelay" currently is using as a value (if anything at all). Do this by going to that key before you run this script. If it already has string value of "0", this script will not do anything for you. If it does not exist or has some higher value, this script might just speed things up. There are many things that can bog down the menu speeds in the WinXP GUI, most often the registry is overloaded with context menu and other optionally added extensions. Note-1: This script is using REGEDIT4 which works fine in either Win9x or WinXP. Note-2: The 1st value string has a deleter ('=-' removes the "MenuShowDelay" and its data type completely) then the 2nd value string adds it back as data type 'string'. This may be un-necessary but it is guaranteed to remove a previously incorrect date type like DWORD or HEX etc. Note-3: There should be at least 2 CRLF's, (Carriage-Return Line-Feeds) immediately after that "MenuShowDelay"="0" entry. In your editor go to the end of that line and press [ENTER] twice to be sure. Note-4: There are some folks that insist that "MenuShowDelay"="1" is a better setting. However I myself have never seen proof of this. But feel free to try it out and report back if you think it works better. Note-5: If all of this seems like a foreign language, STOP and ask questions FIRST! Know exactly what you are doing before you mess with the registry. I am not responsible for anyone else's mistakes!

@BenoitRen ... Yup, InnoSetup v5203, extracted no problem. I placed all the extracted files into a ZIP which totals: 5,769,514 bytes. This presents a problem as I see no way to upload it here. I'll list the files and show you what it includes and maybe you only need a smaller one? If not, I'll also show you how to rip this thing yourself, only takes 5 seconds. Beta5 contents: ;;; Extraction of: [b]ffdshow_beta5_rev2033_20080705_clsid.exe[/b] 126,004 10-11-08 9:19p Install_Script.iss [b][color="#FF0000"]<-- this contains the setup script[/color][/b] ;;; Directory of [b].\{app}[/b] 2,433,024 07-05-08 1:25p Ffdshow,1.ax 547 07-10-07 6:10p Ffdshow.ax.manifest 2,494,464 07-05-08 1:26p Ffdshow,2.ax 221,184 03-28-08 8:14p Ff_Kerneldeint.dll 52,224 06-22-08 7:34p Ff_Liba52.dll 172,032 06-22-08 7:34p Ff_Libdts.dll 397,312 06-22-08 7:35p Ff_Libfaad2.dll 143,360 06-22-08 7:35p Ff_Libmad.dll 118,784 06-22-08 7:35p Ff_Realaac.dll 135,168 06-22-08 7:35p Ff_Samplerate.dll 177,664 06-22-08 7:34p Ff_Theora.dll 102,912 06-22-08 7:35p Ff_Tremor.dll 56,832 06-22-08 7:36p Ff_Unrar.dll 24,064 06-13-08 1:39p Ff_Wmv9,1.dll 23,552 06-13-08 1:39p Ff_Wmv9,2.dll 708,096 07-05-08 1:13p Ff_X264.dll 3,591,168 07-05-08 1:14p Libavcodec.dll 119,296 06-22-08 7:33p Libmpeg2_Ff.dll 456,192 07-05-08 1:14p Libmplayer.dll 20,480 06-12-08 8:37p Makeavis.exe 549 07-10-07 6:10p Makeavis.exe.manifest 1,708 10-20-07 1:04p Openie.js 200,704 06-13-08 1:35p Tomsmocomp_Ff.dll 710,656 06-22-08 9:30p Xvidcore.dll ;;; Directory of [b].\{app}\Custom Matrices[/b] 128 12-10-06 11:32p Andreas_78er.matrix.xcm 128 12-10-06 11:32p Andreas_Doppelte_99er.matrix.xcm 128 12-10-06 11:32p Andreas_Einfache_99er.matrix.xcm 128 12-10-06 11:32p Bulletproof's Heavy Compression Matrix.xcm 128 12-10-06 11:32p Bulletproof's High Quality Matrix.xcm 128 12-10-06 11:32p Cg-Animation Matrix.xcm 128 03-17-08 4:17p Eqm_Autogk_Sharp.xcm 910 03-17-08 4:17p Eqm_Avc_Hr.cfg 128 03-17-08 4:17p Eqm_V1.xcm 128 03-17-08 4:17p Eqm_V3hr.xcm 128 03-17-08 4:17p Eqm_V3lr.xcm 128 03-17-08 4:17p Eqm_V3ehr.xcm 128 03-17-08 4:17p Eqm_V3uhr_Rev2.xcm 128 03-17-08 4:17p Eqm_V3ulr_Rev3.xcm 128 12-10-06 11:32p Hvs-Best-Picture.xcm 128 12-10-06 11:32p Hvs-Better-Picture.xcm 128 12-10-06 11:32p Hvs-Good-Picture.xcm 128 12-10-06 11:32p Low Bitrate Matrix.xcm 128 12-10-06 11:32p Mpeg.xcm 128 12-10-06 11:32p Pvcd.xcm 2,697 08-12-07 4:30p Q_Matrix.cfg 1,244 08-12-07 4:30p Q_Matrix2.cfg 1,244 08-12-07 4:30p Q_Matrix_Def.cfg 128 12-10-06 11:32p Soulhunters V3.xcm 128 12-10-06 11:32p Soulhunters V5.xcm 128 12-10-06 11:32p Standard.xcm 128 12-10-06 11:32p Ultimate Matrix.xcm 128 12-10-06 11:32p Ultra Low Bitrate Matrix.xcm 128 12-10-06 11:32p Very Low Bitrate Matrix.xcm ;;; Directory of [b].\{app}\Languages[/b] 41,298 07-29-07 2:37p Ffdshow.1026.bg 14,348 02-24-07 2:33p Ffdshow.1028.tc 49,677 11-12-07 12:43a Ffdshow.1029.cz 39,202 10-28-07 12:50p Ffdshow.1031.de 9 12-10-06 11:32p Ffdshow.1033.en 57,660 05-16-08 6:46p Ffdshow.1034.es 34,929 12-31-07 7:26p Ffdshow.1035.fi 55,138 01-14-08 4:24p Ffdshow.1036.fr 5,317 12-10-06 11:32p Ffdshow.1038.hu 42,709 06-10-07 2:22p Ffdshow.1040.it 92,724 12-06-07 7:25p Ffdshow.1041.ja 62,969 12-06-07 7:25p Ffdshow.1041.jp 42,805 02-05-08 7:29p Ffdshow.1045.pl 5,541 02-24-07 2:33p Ffdshow.1046.br 31,097 04-01-07 2:06p Ffdshow.1049.ru 35,479 12-10-06 11:32p Ffdshow.1051.sk 4,900 02-24-07 2:33p Ffdshow.1053.se 51,627 02-02-08 2:57p Ffdshow.2052.sc ;;; Directory of [b].\{code_Getavisynthplugindir}[/b] 39 11-13-07 3:12p Ffavisynth.avsi 6,656 06-12-08 8:36p Ffavisynth.dll ;;; Directory of [b].\{code_Getvdubplugindir}[/b] 37,888 06-12-08 8:36p Ffvdub.vdf ;;; Directory of [b].\{code_Getdscalerdir_}[/b] 8,192 06-12-08 8:37p Flt_Ffdshow.dll ;;; Directory of [b].\{sys}[/b] 6,144 06-12-08 8:37p Ff_Acm.acm 7,680 06-12-08 8:36p Ff_Vfw.dll 547 07-10-07 6:10p Ff_Vfw.dll.manifest 499,712 12-10-06 11:32p Msvcp71.dll 348,160 12-10-06 11:32p Msvcr71.dll 60,273 06-08-08 11:58p Pthreadgc2.dll 258,352 12-03-07 2:58p Unicows.dll ;;; Directory of [b].\{tmp}[/b] 40,960 01-29-08 6:26p Ffspkcfg.dll 57,344 12-10-06 11:32p Wincpuid.dll To do it yourself. Get the file called innounp.exe from inside innounp020.rar. Place it in the same folder as the Beta5 setup EXE file. Copy the Beta5 setup EXE file to a friendlier name like BETA5.EXE. Execute this command in that folder ... innounp.exe -x -d.\Extract Beta5.exe Immediately below you will find a subfolder called \Extract which contains everything in the filelist in that first CodeBox. NOTE: Be sure to read that InnoSetup 'install_script.iss' as it contains the commands that the Installer EXE was programmed to run. There appears to be some strange stuff going on, for example there are several different copies of the same named file (this CodeBox contains wide lines, I hope it doesn't screw up anyone with MSIE! Let me know and I'll delete it) ... [size=1]Source: "{app}\ffdshow,1.ax"; DestDir: "{app}"; DestName: "ffdshow.ax"; Components: "ffdshow"; Flags: restartreplace regserver uninsrestartdelete ignoreversion Source: "{app}\ffdshow,2.ax"; DestDir: "{app}"; DestName: "ffdshow.ax"; Components: "ffdshow"; Flags: restartreplace regserver noregerror uninsrestartdelete ignoreversion [/size] It looks to me that they first create the file ffdshow.ax from ffdshow,1.ax, self-register it, set it to delete on restart and then replace it with ffdshow,2.ax, self-register it. Or something like that. Hmmmmmm I see ... The ffdshow,1.ax is v1.0.5.2032. The ffdshow,2.ax is v1.0.5.2033. Here is the breakdown: ;;; Ffdshow,1.ax +------------------------------file version info------------------------------¦ ¦FixedFileInfo file type: Dynamic-link library ¦ ¦FileDescription DirectShow and VFW video and audio decoding/encoding/process¦ ¦ing filter ¦ ¦FileVersion 1.0.5.2032 ¦ ¦InternalName ffdshow ¦ ¦LegalCopyright Copyright c 2002-2008 ¦ ¦LegalTrademarks GNU GPL ¦ ¦OriginalFilename ffdshow.ax ¦ ¦ProductName ffdshow ¦ ¦ProductVersion 1.0.5.2032 ¦ ¦Build Date 05/07/2008 - 00:00:00UTC ¦ +-----------------------------------------------------------------------------+ ;;; Ffdshow,2.ax +------------------------------file version info------------------------------¦ ¦FixedFileInfo file type: Dynamic-link library ¦ ¦FileDescription DirectShow and VFW video and audio decoding/encoding/process¦ ¦ing filter ¦ ¦FileVersion 1.0.5.2033 ¦ ¦InternalName ffdshow ¦ ¦LegalCopyright Copyright c 2002-2008 ¦ ¦LegalTrademarks GNU GPL ¦ ¦OriginalFilename ffdshow.ax ¦ ¦ProductName ffdshow ¦ ¦ProductVersion 1.0.5.2033 ¦ ¦Build Date 05/07/2008 - 11:25:02UTC ¦ +-----------------------------------------------------------------------------+ Also note that the script calls for a similar file replacement for ff_wmv9.dll. But since neither Ff_Wmv9,1.dll nor Ff_Wmv9,2.dll contain the version strings, I cannot tell for sure which version is which.

Having SATA and PATA easily co-exist (on computers equipped with both interfaces) is completely dependent on the BIOS authors and what they chose to give you access to. Sometimes the good options are not available in the BIOS menus on cheaper consumer class motherboards. The 'good options' offer easy re-arrangement of the bootstrap order specifically regarding SATA channels. I have seen good and bad BIOS on MSI mobos. Your motherboard has only two SATA ports (2 devices), and two PATA ports (4 devices). Usually this configuration gives generic choices. My guess is that it will be tricky, but do-able. However, were you my customer I would recommend this: get either the SATA 500 or the PATA 320 (no surprise there!) let the decision be based on speed/performance/budget ... but ... forget about the drives co-existing, which removes any headaches from your decision making and actual upgrading. Instead of making the drives work togther, do this: Install the new drive, Clone the old 30 GB main drive to the NEW drive (C: to C:). This means that the original WinXP configuration stays exactly the same on the NEW disk, the disk just gets bigger, faster and, younger. The old 30 GB gets removed and gets placed somewhere for safekeeping untouched. This buys you a sure-fire backup if the NEW drive happens to be defective and needs to be returned or in the event of some disaster like a virus outbreak or the computer is stolen. The older drive also happens to be, old. It is a detail worth pondering. Retire it, except for the odd emergency. What you really gain here is Piece of Mind' (sorry, couldn't resist ;-) The details of the cloning operation can be explained later if you decide to go this route. It involves a CDROM from the manufacturer of either of the two drives you are using. In a nutshell, for the cloning operation both drives are hooked up simultaneously in the computer and the CDROM is booted and menus on there are followed to completion. If you can buy a 'RETAIL' drive (as opposed to 'OEM') when you actually purchase, it should come with a CDROM for this purpose. But even if your new drive is 'OEM' (aka White Box aka Barebones) the CDROM is free from online sources Back at the beginning I said tricky, but do-able for them to co-exist, but this becomes a moot point when only one drive: PATA or SATA is detected. Referring to your self-description, in short, you cannot easily screw it up!

What is the Setup app they used? Got a URL for the EXE?

I do not currently use Yahoo Messenger myself, but have lots of clients that do. Several ideas ... After you get the current JRE installed and working (in my case JRE_1_6_0), sometimes, probably always, the previous version sticks around. Perhaps you need to look into a conflicting version. Search the entire HDD for JAVA.EXE and JAVA.DLL for clues. Double-check your registry for references to other versions than the one you are using. To check that your Java is indeed up to snuff visit some sites that have Java apps and games in both MSIE and Firefox/K-Meleon and look for differences. I would also suggest installing Opera a double-check: visit same sites in both Opera and MSIE and look for differences. It seems possible to me that there is some PITA killbit for Java from MSIE that affects Yahoo Messenger but not Opera or Mozilla (can you say Sun lawsuit?). Another possibility is to try another version of Yahoo Messenger. I recently had to try several older versions for a picky customer. We settled upon 7.5 because it seemed smoother. Not to say that this will solve your problem because I don't think that this person used any Java games anyway. Since Yahoo didn't keep previous versions hanging around, I looked for and eventually found two excellent repositories for Yahoo Messenger: YAHELP and OldVersions. It may simply be that the new version of Yahoo you are using is buggy and going back to 8.1.0.415 or 8.0.0.716 might help. Whatever you do, please report back with the solution since so many people are using this IM program these days.

Here is a prototype ... [HKEY_LOCAL_MACHINE\Software\Classes\*\Shell\[color="#FF0000"]SomethingUnique[/color]] @="[color="#FF0000"]LabelInContextMenu[/color] ..." [HKEY_LOCAL_MACHINE\Software\Classes\*\Shell\[color="#FF0000"]SomethingUnique[/color]\Command] @="C:\\[color="#FF0000"]FilePath[/color]\\[color="#FF0000"]FileName.exe[/color] \"%1\"" For example, you have an application called XYZeditor by XYZ Software (these are completely fictitious names and paths!) ... REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Classes\*\Shell\My XYZ Program] @="Edit with XYZ Program ..." [HKEY_LOCAL_MACHINE\Software\Classes\*\Shell\My XYZ Program\Command] @="C:\\Program Files\\XYZ Software\\XYZeditor.exe \"%1\"" Later if you choose to delete this you can simply ... REGEDIT4 [-HKEY_LOCAL_MACHINE\Software\Classes\*\Shell\My XYZ Program] Those scripts are for REGEDIT import. I used REGEDIT4 arbitrarily because it will import into both Win9x and WinXP. If you supply the information like the name of the program and the exact path it can be easily created and posted here.

Appreciate the nomination but I suspect there are better candidates lurking right here! Anyone else want to do a new thread please go right ahead, I'll join in eventually. I did download that Paragon package but its gonna be a while before I can get to it. Sorry about that. Wasn't thinking about it and almost hijacked the discussion! Good call about a new thread Molecule. That's good news about the WinTricks edited INF. Whatever works is what I go for. Having Win9x utilize all these modern USB devices a full 10 years after it was born is astounding. My Win9x boxes handle most USB devices even more smoothly than my WinXP boxes. Love it. Flash drives are not comparable to any previous RAM or DASD storage. The difference is that they employ a layer of hardware programming which performs the critical task of wear-levelling. In essence it tries to write data to different 'sectors' each time using some algorithm to keep track of recently written cells to ensure that any given area stays as young as possible (if you can think of age as how many times a cell was written to). You cannot really decide where to write data like you can on a HDD (with some effort we can strategically place important data using a variety of methods). What we visualize as directories or 'sectors' is a metaphor here, behind it is real world of solid state cells and gates. That is my own convoluted explanation, you would be well-served to read more authorative info from places like WIKI: Flash_Memory and Wear_Levelling. As usual they have good offsite links to their sources and more in-depth follow-up information.

One thing for certain, you cannot use 4 GB in this dual-boot configuration since one OS is Win9x (ask the RAM experts in this thread: Day-to-day running Win 9x/ME with more than 1 GiB RAM who are all over this). You'll have to physically pull most of it out each time you want to boot in Win9x and replace it when going to WinXP (get a computer case with a easy-open hinged door! Actually, you'll kill the memory itself by handling it constantly). It would be nice if the BIOS let you turn-off sticks of RAM, but to my knowledge it hasn't yet been done. However, I doubt the ESDI_506 error comes from too much RAM ... Assuming your strategy is to use only the 80 GB drive when booting to Win9x (i.e., never using the 160 GB while Win9x is running) ... you have no need to replace ESDI_506 as that 80 GB drive is fine for Win9x. And, if the WinXP 160 GB drive is NTFS, it should be naturally invisible to Win9x when it successfully boots from the 80 GB drive. So theoretically, the 160 GB drive could remain powered up and online while the 80 GB boots to Win9x and not cause any problems with ESDI_506 ... you still have no need to replace ESDI_506 as it will not need to address the 160 GB drive. Of course the BIOS needs to be told which drive to bootstrap first. For Win9x it must be set to use PATA for this to work. However, if that WinXP SATA 160 GB is powered up and also happens to be FAT32, this may be what ESDI_506 is choking on ... you must replace ESDI_506 with the LLXX Version as the SATA 160 GB FAT32 would be seen and addressed under Win9x regardless of what OS is installed on it. IMHO, the perfect solution is found in some really good BIOS's (apprx 2005 and on) where there is great SATA/PATA control. Specifically you want a simple choice of ENABLE/DISABLE any given SATA channel. In your configuration, I would just disable SATA0, and voila! Pure joy. The PATA drive will boot, the SATA drive isn't even powered up. Reverse the logic to boot WinXP. Hopefully you have these options. Lesser BIOS's just offer PATA ONLY or SATA ONLY or BOTH or HYBRID (or similar nomenclature) and you would need to try PATA ONLY for Win9x or SATA ONLY for WinXP for this to work. However I have had much less success here as the settings somehow get corrupted.

You were thinking in XP. I've done the same sitting here surrounded by a hodgepodge of PC's.

BUMPING THIS THREAD. Looking for MSIE 6/7/8 users to examine this page, specifically the page width on the first post (read above discussion). Need advice and if possible comment on my ideas in Post #17 Also, have any users of Firefox/Mozilla/Opera/(other) noticed any page width anomolies? So far they seem immune. Thanks! CTH

Yikes, I think you're reading too much into it! Song lyric from Iron Maiden! album: Seventh Son, track: 4. Could be a double entendre but I highly doubt it. You may want to consider editing that thing I [sNIP!]ed!. (phew, not a paragraph I expected to see on MSFN!). No problem. Wtgenusb.inf just got renamed to WinTricksWTGenUSB.INF. It's perfectly fine and business as usual. I usually rename them back and move them into INF (and modify the registry too) so I have a trail back to the original distribution file. Leave it as it is because there is a data value in the registry hardcoded to that name and path now (infother). Drvidx.bin and Drvdata.bin are the windows INF generated database. They are dynamic and reflect the last detection. I back these up often. Some situations require you to delete these two files, which causes re-detection of practically everything. Don't do this unless you are prepared for a very long night. Size looks ok to me. Mine are currently 539 KB and 1,943 KB. Definitely skip USB below 2.0 speed! If you still have that system just grab a $9 NewEgg USB 2.0 PCI card. Or grab a new Mobo. Dang, first time I have seen this! Doh! I'm gonna feel real stupid if this was already mentioned in galahs Last Versions of Software for Windows 98SE thread. As mentioned above by Molecule it apparently has full Read/Write, the cost is nada, details here. NTFS for Win98 (Non-commercial use only) Full Transparent Access to NTFS Disks. FREE! Still using Windows 98 in parallel with XP? Can't access disks created with XP from Windows 98? With NTFS for Win98 you can share important files and documents between both operating systems. This product will give you full transparent access to NTFS disks through a regular and conventional drive letter. Read and change any file, browse and search for files, copy and create new files and folders. Does anyone have personal experience with this? Pluses and Minuses? Advantages and Disadvantages? Love to hear it!

Excellent point about total clusters. Several partitions on a 500 GB (even more on 1 TB) would seem to be a smart tradeoff. I prefer single partitioning myself but this compromise may be unavoidable. You know, someone should pool all this data of the various limits of common tools (FDISK, Format, Scandisk, Scandskw, NDD32, Win9x/WinMe versions, etc etc etc) into a nice table. I think RLoew offered some insight into these limits on that LLXX patched ESDI_506 thread. I also just thought of a peculiar scenario that may happen in this configuration ... Given a Win9x system plus LARGE Hard Drive on USB. The user has done some work involving the USB HDD. Later in the session something goes awry and a hard lockup (or a plain old power blackout). On restart the DOS Scandisk catches the ATA Hard Drive(s) as dirty and scans, and of course ignores the USB Hard Drive connected or not (I always disconnect them). When the system gets back to Windows, the user must remember to immediately run a Windows based Scandskw on the USB drive (WinME version no doubt, or Norton) or they will be making a big mistake by possibly writing to a 'dirty' disk. Certainly someone has come across this?

That is a great link with lots of useful information in one place. Excellent implementation as well. I use a slightly different strategy for a slightly different purpose. Rather than picking only the commonly written areas containing structural information, instead I grab the big continuous chunk from Absolute Sector 0 to the first FAT, 95 sectors in all, the sum total is a tiny file of only 48,640 bytes. This is done in data collection snapshots, which also include registry and system files and log information. Snapshots are compared often, especially after running suspect apps and installers. Previously I grabbed only those key sectors described in the link. That lasted until I figured out that some programs were writing information outside of the proper file system, into those supposedly empty areas. PowerQuest was one. The infamous C_Dilla protection schemes another. Some burn-in programs and computer makers tattoo information in here. I find it real interesting to track these changes, hence I make these snapshots often and diff the files and then crosscheck logs to nail down the culprit when a change is detected. I formerly used a batch file myself but switched over to InnoSetup to be able to compile a single portable EXE that includes within itself all necessary files. The EXE executes programs like FindPart and RegEdit, collects the output of these programs and then uses RAR or WinRar to roll them up into a nice dated snapshot package. Right you are, I stand corrected! I just verified by comparing the FATs of three Seagate 120 GB drives as dumped by SrcFat. Each were in fact 14,650,880 in size, but were filled to different levels reflecting the different amount of files per disk. So the FAT size is clearly related to the size of the drive, not the contents of the drive. Thanks.

That would be a lot of partitiions! Actually 120 GB drives as a single partition is fine in Win9x operating under the ATA/IDE port ESDI_506 interface. Above 136 requires another driver or a patched one. BUT this is not the ATA/IDE interface. This is the USB interface. This exact topic: Large Drives on USB and SATA is what I would like to see fleshed out! Even the famous http://48bitlba.com/ website artfully dodges this issue. Watching this thread closely for authorative information that up to now has been very sparse. Anyone with links and references about large drives under USB and SATA jump in! No driver software is needed (software defined as some added device or port driver or IoSubSys component typically of file type PDR, MPD, SYS, DRV, 386, VXD). This is a USB drive, the driver was already shipped with Win98se in the form of the USB port drivers. Now, those original files from the CDROM have received a healthy update in the form of the Maximum-Decim Native USB Drivers, read that thread! Then go to AXCEL216 / MDGx to get the NUSB file. It contains all the required updates to USB related .SYS and .PDR files. In summary, NUSB handles the so-called driver that you asked about. Now to get Win9x to add a given USB device (in this case your 500 GB HDD) to its tree of devices in the registry a .INF (just a plain ASCII text) file is used. This sometimes requires some extra loving care though. When I first used NUSB it did not work for me on a certain HDD, but that was back in the NUSB 2.x days. I subsequently added the so-called WinTricks package from here which did work. It adds two new system files plus a very important INF file (NOTE: this package is actually a modified Lexar driver with a different .INF plus the same two system files). What it does is to cause most mass storage attached to USB to be added as BULK (this is what we want), and it also effectively bypasses any 3rd party software from being required to operate the device. BULK is like a giant floppy drive, it requires no 3rd party access software. If you add the Lexar/WinTricks package, these files should wind up on your system: Jdusbpd.pdr .... Windows\System\IoSubSys Jdusbms.sys .... Windows\System32\Drivers Wtgenusb.inf ... Windows\Inf (aka Jdusbms.inf) Yup, this is where it gets interesting: the size of your 500 GB HDD. If you were to pop it out of the enclosure and attach it to the onboard ATA interface (assuming it is SATA/PATA), the built-in ESDI_506 driver is in control and would choke on access above the 136 GB barrier. Since you are under USB and *not* doing this, my understanding is that you will not need to mess with ESDI_506 because it (or the LLXX patched driver) only comes into play when a disk is attached to the ATA interface. If you take it out of the enclosure, yup. On the USB, nope. But I am waiting to hear some cold hard facts about this. Forget the partitioning idea, unless you want the extra drive letters. Partitions have no bearing on this problem, it relates to TOTAL SECTORS ON THE DRIVE and how this very large number is subsequently handled by the Windows drivers which were programmed to use smaller numbers. In essence, it is a math problem. No matter how many partitions you have, the total sectors remains the same. And yes, Google will find you a million people who insist otherwise, but they are all wrong, period. What is unclear to me is how that ATA port driver is bypassed for both USB and SATA based drives, if at all? It must be bypassed if USB and SATA drives are ok. I've read what most others have read, but the authorative sources are scarce.