Drugwash

Totally understandable. I've had reports of some of my toys misbehaving or not working at all and couldn't reproduce and fix because I didn't have any x64 machine and/or OS to test on. Anyway, to keep it theoretical, your idea of pulling VIA-related commands from the inf and making a separate, VIA-only installation inf, combined with renaming the driver file as mentioned above, should allow for any combination of USB chipsets on a given machine. Unfortunately I can't test either, because the only working machine I have with VIA chipset is my main 98SE machine which works 24/7 and can't afford to botch the 6-year old installation. I hate to add to this issue, but recently, while trying to fix a video issue in my test machine by installing different video/AGP drivers on a SiS630 chipset, I got system lockups (Windows protection error blah-blah). After fiddling around, I discovered the AGP driver package installs its own openhci.sys USB driver overwriting the one in SP, which leads to these lockups. As soon as I replaced the SiS openhci.sys with the one provided by the SP, the machine started up and worked correctly. There still is the video issue that I cannot put the finger on, but on that I'll get back after some more testing. Right now I'm back at the NE Editor but it's coming out very slowly.

Renaming the VIA driver to USBHUB2V.SYS or something, should solve the problem (theoretically). The only downside would be wasting some memory, having to load duplicate driver files instead of a unique one. But where there's no unique solution, there must be a compromise. Better ideas, anyone...? I must apologyze for not being active lately - got some hardware issues to deal with in real life and therefore haven't been able to work on software (NE editor, SP installer and other projects I planned to deal with).

If you're using a download manager that splits the download into multiple streams, it won't work - I had the same problem, with FlashGet. The solution is to specify a single stream for this particular file, then it'll work.

Yeah, that too! It's all about the freedom of choice. If something can be done in more than one way, rest assured someone, sometime, will ask for that thing to be done differently, while others will ask for it to stay as it was. Give them the ability to choose for themselves and they'll be happy. Make it hardcoded one way and you'll get showered with tomatoes, rotten eggs and other such goodies. MS guys will never learn. Let us be smarter, for what it's worth. Oh, if only we could...

I know. But people are just different. Yesterday I was reading a long blog about Vista desktop icons and whether they're facing the wrong way. I mean, some people do care about minor details such as "why this icon and that icon have different shades of blue" or "why does the folder icon face right and the MyComputer icon face left". What are you gonna do when a couple guys will burst in here yelling that they have wrong icons for their USB controllers, even when everything else works perfectly? Oh, don't answer - I know it already. You're a Leo, after all...

Then we might as well put up a sign saying [For hire: skilled hacker] (sad joke) I'm fresh out of ideas.

OK, freeze! - Install 98SE fresh, without backup or other fancy options. - Install official drivers, bare minimum, at least for USB. - Replace original SYSDM.CPL with the Millennium one (4.90.3000 or 4.90.3001) - Remove all USB devices and drivers from Device Manager - Reboot Does any of the USB icons, upon redetection, change to something else than USB? If so, then it's definitely in the Millennium CPL. If not, then it's in NUSB or its components built into the Service Pack. Definitely. I was thinking of Lone Crusader. My mind is not quite home these days, sorry...

Possible. The backup option is selected in Windows Setup panel. But then again, how come you get the Tape icon for USB controllers too? Let's assume my setup was borked because of the backup option and all that manual mumbo-jumbo with the registry and drivers fixed it. But how about you? Do you have the backup option installed? Do you get such Tape entries in the registry? Did you try reinstalling USB drivers, changing anything in the registry in order to fix the icon issue?

These are the ones (re)created after first removal. They will always be created after them or USB controller(s) being deleted from Device Manager. At least when the SP is already installed (because I'm testing this on a system that has SP 3.8 already installed).

Not exactly. On my main 98SE machine, I've replaced the original CPL with a few interim versions while working on getting a stable one and currently there's neither a TapeDetection branch in Device Manager, nor wrong icons for the two USB controllers, even after reboot(s). However, I have not removed the USB devices and controllers from Device Manager to have them redetected upon reboot, therefore I can only speculate that this detection that is being performed after deleting USB devices, will also add TapeDetection branch, with the wrong driver for one of the subitems and the wrong icons for the USB controllers. I'm not gonna verify this theory on my main system though, as I have a whole lot of USB devices installed, including the Bluetooth that took me a long time to figure out which drivers to install. @LoneCrusader: The icon you see in PROBLEMCHYLD's screenshot will only appear if you manually delete the Tape-related branches in the registry at the places I've mentioned above. In the beginning there were the regular Tape icons for the USB controllers, on my test machine; after I deleted those registry keys, the icons changed to the one shown in PROBLEMCHYLD's screenshot. They can be brought back to normal by following the procedure detailed in my post above - at least I did it succesfully.

Oh I know... and somehow I managed to bring back the correct icons, but only by doing some chaotic moves. Can't even remember all of them! I know first thing was to delete the registry keys that deal with tape drives/tape controller/etc. HKLM\Enum\Tape*. Then HKLM\System\CurrentControlSet\Services\Class\Tape* (there were three of them). Then I removed (backed them up previously) a bunch of VXDs from C:\Windows\System\VMM32, specifically those that were already present in VMM32.VXD (the whole list of files that are bundled with VMM32.VXD can be found in HKLM\System\CurrentControlSet\Control\VMM32Files). Dunno if this was really necessary, but since it's related to the Tape drivers, it may have helped. Then, upon reboot, the Device Manager redetected the TapeDetection category with two subitems of the same name. Looking in driver details, I noticed both of them had the same driver, namely DRVWQ117.VXD. On a whim, I started a driver update, chose manual update > Show all hardware and chose the simple TapeDetection driver (not the one dated 4-23-1999, but the one with no date). Did that for both TapeDetection items. I noticed one of them got a different driver than it had previously, namely DRVWPPQT.VXD. Then, I did the same for the USB controllers (in my case, SiS7001 PCI to USB Open Host Controller). Surprisingly, the USB icons came back from where they were hiding. Now, I didn't place the VXD files back in the VMM32 folder. If anything, I'll do that, see if icons remain correct and there's no other new issue, then will try to combine the VXD files into VMM32.VXD. The information on how to do this can be found - guess what!? - through Wayback Machine, of course! Here is the link to old Infinisource page. Needless to say, do all this with extreme caution, on a test/virtual machine, not like me. EDIT: Added back the VXDs, all seems fine, icons are still in place. Just that there's only one entry for TapeDetection in HKLM\System\CurrentControlSet\Services\Class. I vaguely recall about a modification done by someone to remove tape detection and other supposedly useless stuff, for a faster boot. But can't remember what exactly was all about.

That's not the Tape Device icon. Where on earth did this one come from? Gosh, weirdness!

I figured you'd do something like that. I'd do it too, if I weren't so stubborn in making a tool that can do it without introducing bugs. Open Watcom may be open source, but it's way too much code to analyze and find the proper place(s) to fix, so I'd rather build my own limited-purpose tool from scratch. It's incredible how Microsoft hid away all the information regarding older files (such as the segmented executables - the 16 bit NE that SYSDM.CPL is part of). The page can only be found through Wayback Machine. And there is very, very much similar information that has been (and is being) removed from the Internet, leaving us with no source of information whatsoever, other than what we managed to save locally on our own storage devices.

So, did you find out why the wrong icon in Device Manager and why dialogs are not centered? Personally I've had a weird day, can't figure out how I wasted it but somehow managed not to do anything useful. Only thing I found out is that the wrong icon pertains to a Tape device which somehow gets installed by the ME CPL and is found in pnpwprop.dll. Wasn't able to write a single line of code for the CPL reader/editor I intend to build. (ah, these typos...)

Good, we cleared this up. Another question: does the abnormal icon (screenshot, anyone?) show with the CD version of sysdm.cpl 4.90.3000? I'm trying to find out if this is a default mismatch between ME and 98SE or if it's been introduced with the updated 3001 version. We should be able to analyse the two versions and hopefully pinpoint and fix the issue, if it turns out 3000 works OK compared to 3001. Otherwise it will be a little harder to find out why it's happening.

Question is: where does version 4.90.3001 in NUSB 3.6 come from? Is it a MS official update/QFE/etc or is it the default 4.90.3000 from the CD and has been hacked by someone else prior to adding it to NUSB? The answer to this question may explain the abnormal icons you're seeing and possibly other issues yet to surface. I mean, if the file has been modified using a tool that breaks the structures just as OpenWatcom does, we'd be better off using the official 4.90.3000 in our modding attempts, considering the changes that have been made previously (if any) that made it into 4.90.3001. At this point, only Maximus-Decim may be able to provide the answer, unless someone else can prove the origin of the 4.90.3001 file. I also agree to splitting the discussion pertaining to sysdm.cpl modding, to a separate thread.

OK, that's dialog 501 alright. Please read my edited post above.

That explains it. I've walked around those zips as they were just too many for my taste, but I've downloaded all the installers (.exe) and extracted the same set of files from each and every version, from 1.0 to 1.9. That's why the file sizes didn't match, as you compressed them afterwards. Strange thing is that the Center flag appears as set in VC6, ExeScope and OpenWatcom 1.9, for the 501 dialog (New Hardware Found). Just to make sure: PROBLEMCHYLD, could you please post a screenshot of the dialog you say it's top-left aligned instead of centered? Maybe we're looking in the wrong place. EDIT: OK, we're wasting time. As I suspected and already mentioned somewhere above, OpenWatcom cannot deal with CPL files correctly. One may fool it into thinking a .cpl is a .dll by changing extension, but internally .cpl files are structured differently and an editor that cannot recognize a certain structure will most likely destroy it. As a test, I've loaded with ExeScope a .cpl renamed into a .dll. Looking at dialog 10009 (for example) I noticed 5 Static, 2 RadioButton and 1 PushButton. Then I renamed the file back to its original .cpl extension. Loading it in ExeScope revealed dialog 10009 actually has another 3 SysListView controls that didn't show up in the list previously. I noticed this issue of missing control types much earlier but blamed it on a possibly incomplete installation of OpenWatcom. However, now I unpacked the whole contents of the binnt folder such that no possible dependency would miss and the issue is still there. Therefore, as a conclusion I would say editing Control Panel Extension files (.cpl) in OpenWatcom using the extension change trick, is bad and will damage the internal structure. The wrong start position of a dialog is just a minor example of what can happen if we continue to do it. We need another tool, a stable and reliable one, other than Visual Studio and ExeScope, neither of which can perform the full job without errors or shortcomings.

That may be a waste of time. I've edited the original 4.90.3001 file from NUSB 3.6 directly in Open Watcom without any interference from other editor and the bug is there. From my point of view, there may be a bug in Open Watcom that inadvertently clears the Center flag. I'm currently testing Open Watcom 1.9 and all the earlier ones. The files posted by loblo pertain to some 1.3 version, although the file sizes don't quite match the ones in the archives I've just downloaded (possibly privately compiled from sources).

Easy, don't get a heart attack! I've considered users' wish to keep everything in its original form. If I put this out, it will be in two versions: one containing original resources (icons, bitmaps, avi etc) and one containing updated resources, for those who want modern look, possibly for use in conjunction with Revolutions Pack's themes.

If they fully supported CPL files, there would've been a choice in the dropdown to select *.cpl. Since it's not, I wouldn't hazard myself into editing and then distributing a system component which might fail on user's computer in unknown/untested circumstances. It's bad enough that MS' own tool can't correctly edit their own files.

Thanks but those tools won't recognize .cpl files. Will stick to those already known to work, caveats included.

First of all, thanks loblo for reminding me about Visual Studio being able to edit resources. Then... I've been messing with this file all night. One thing I've learned is that Visual Studio 6 (possibly other versions too, dunno) will definitely screw up any and all dialogs that contain older versions of controls, such as SysTreeView, msctls_trackbar and others. It will replace them automatically and without any notice with the newer 32bit versions (i.e. SysTreeView32, msctls_trackbar32 etc), definitely trashing the edited file. Therefore, do not attempt to edit any dialog that contains older 16bit controls in Visual Studio - if they need to be modified in any way, use a different tool. ExeScope can modify those dialogs without problems. However, ExeScope has additional issues in working with dialogs. I've had it constantly crashing when trying to view or edit a certain dialog in SYSDM.CPL. Then, it will not delete any controls or resources whatsoever, leaving the user with only the choice to move/resize controls. So deleting unnecessary controls such as the ones pertaining to System Restore, can only be done in Visual Studio. I have not even attempted to install Open Watcom because an 80+MB of an installer doesn't look good to me, while all my partitions are full up to the brim. That said, after lots of crashes and failures I have succesfully rearranged statics on main tab, deleted System Restore-related controls, replaced bitmap resources with some home-made ones for a modern look and plan to replace icons as well. However, I also tried to resize the driver selection dialog 10009 which always seemed too short for the very large lists (try to replace display driver, see how large the Manufacturer list is), only to find out that the whole driver update (and Find new hardware) process would show taller dialogs even though those have never been enlarged. Seems like the largest dialog size in the process will be retrofitted to each and every pertaining dialog. So I'm gonna have to take it back to its original size. No comment! All in all: things can be done, but with extreme care and thorough testing. If I ever get to a stable working version, it will be published somewhere (since I reached my upload quota here). I would kindly ask that such work-in-progress versions as the ones above be distributed privately, for testing purposes, as to avoid any issues with beginners messing with their sytems. A final version should reach the official distributors (Maximus-Decim, PROBLEMCHYLD), should they want to include it in their packages and maybe MDGx, for an unofficial package hosted at his site.

Remove the WS_VISIBLE (0x10000000) style and that'd do - no tab gap, no errors. Anyone can recommend a good, Free/Open-source NE editor for such 16-bit libraries? I've edited my CPL about 6 years ago and forgot which tool I used. Could've even been some shareware in trial mode, at the time, but I'd like to avoid such things now. Got no time (and enough knowledge) to build a tool from scratch right now.

I'll be looking into this as soon as I can take a break from the other projects (most importantly Dll Details, which must be brought to a better level). The issue popped up earlier in the SP thread and I've mentioned there the care that must be taken when building such tool, not to break something else or allow its usage for malicious purposes. Anyway, it's good that the USB input devices issue came up now as it offers the necessary edge to approach the subject in the right manner. Problem is, I don't have a USB keyboard to test with - actually there is one Logitech G15, but it's defective and couldn't fix it as it needs spare parts. I do have a working USB mouse but that's not enough to test such tool, if/when I get to work on it. And come to think about it, there might not be any spare machine around for testing, with a USB 2.0 controller... Ugh!