Originally posted by: kylef
In Windows, the PnP subsystem finds the unique HW identifier advertised by the device and matches it to a Devnode that has been previously installed.  This devnode has associated with it a bunch of persisted metadata (friendly name, icons, policies, drive letters, etc) that is remembered for that device.  Therefore,  it doesn't matter which port you pick: Windows matches the ID, recognizes it as a device it's seen before, and loads the proper configuration.  So, Windows can remember which webcam is pointing at the traffic intersection, and which one is hidden in the girls locker room.  
		 
		
	 
Hehe. That earthquake must've been divine retribution for your team's secret antics, hmm? 
	
	
		
		
			Originally posted by: kylef
The catch is, this ONLY WORKS if the device implements this unique identifier.
		
		
	 
That's interesting, I didn't know that Windows' did that at all, guess none of my devices have that "USB GUID" built-in. Strange though, that they wouldn't likewise be able to use the hardware MAC address for things like USB netcards, it's a PITA when I plug in my USB WiFi NIC, and I have to re-input all of the "connection profile" info again, SSID, etc., just because I forgot where I had plugged it in before, or re-configured my USB setup. Perhaps you could consider suggesting that as an enhancement? (Plus, every time you plug it into a different "USB hardware path", it installs additional driver instances, like the "Packet Scheduler Miniport" on XP. The total number installed (not just currently present, but installed in total ever) used to be limited to something like 8 instances in Win9x. Not sure if there is a limit in NT-based OSes for Network protocol-drivers, but if there is, then this issue is even all the more important. It's fun (not) installing so many NICs into a Win98se box, and having the system not able to install and bind an instance of the TCP/IP protocol to it, because all of them have been used up previously. :| )
	
	
		
		
			Originally posted by: kylef
There really is no excuse for USB devices not to have a serial number.  The official USB spec doesn't explicitly state you must have one, but it does strongly recommend it.  Subsequent specifications from many related USB working groups (such as the USB Mass Storage Class Bulk Transport) do in fact require unique serial numbers for compliance.
		
		
	 
Thankfully, the NT storage stack seems to properly identify volumes by their IDs or a hash of the values of their initial sectors, and can properly assign a persistant drive letter to an IDE disk or a USB key, no matter which IDE port or USB port they are plugged into.
	
	
		
		
			Originally posted by: kylef
There are several inexpensive options available to implement a unique ID.  
Here is an example of a low-cost chip to store the unique ID..  Those cost about ~$0.50 in bulk and will plug into many USB stack implementations, from what I understand.
		
 
		
	 
I guess I don't bloody understand why that "serial number" ID can't be implemented totally integrated into the USB device's USB-interface controller chip itself? Seems rather silly, since they can uniquely identify RFID tags with something like 128 or 192 unique ID bits, and those cost like $0.013 each or something.
An alternative workaround, would be to store the persistant data state for those USB devices in an enumerated form, attached to the friendly-name string assigned, and then when one of those devices is plugged in an enumerated, no matter what "USB hardware path" (port/hub/etc.) it was plugged into, that the first device would get matched to the first persistant driver instance, etc.
The odds of the user having two of the identical devices is less common than the case of the user moving a single device between USB ports occasionally, and having to re-install the drivers and re-configure associated vendor-specific software is a royal PITA. Perhaps a user-selectable behavior for "USB device matching style" would be useful, kind of how XP and later finally allow you to set the write-cache policy for removable storage devices.