Dear izzard-ga,
An interesting one!
Microsoft doesn't appear to directly list a maximum figure anywhere,
but digging out my copy of the Windows Device Driver Development Kit,
I find that game controllers are handled by Windows (2000 and XP have
the same driver interfaces) as "Interactive Input Devices":
"This section describes the Microsoft® Windows® architecture for
interactive input devices. Interactive input devices are devices that
humans use to directly control the operation of computer systems.
Examples of interactive input devices include:
* Keyboards and pointing devices such as standard mouse devices,
trackballs, and joysticks.
* Front-panel controls such as knobs, switches, buttons, and sliders.
* Controls that might be found on devices such as telephones and other
consumer electronics.
* Controls, games, and simulation devices such as data gloves,
throttles, steering wheels, and rudder pedals."
"To modularize and streamline input processing, the core of the
interactive input architecture is based on the USB Human Interface
Device (HID) standard. (For detailed information about the USB HID
standard, see the USB Implementers Forum Web site.)"
As this section continues to explain, non-HID devices such as PS/2
keybaord and mice, and analogue joysticks, which are processed through
the same HID architecture.
Under the USB HID standard, devices themselves are identified by their
USB descriptors (even the legacy devices are assigned one of these);
in turn, the HID class driver automatically creates a Physical Device
Object representing the input device, and the specific class driver
for that type of device creates a Functional Device Object based upon
that PDO to manage the specific device.
So where does this leave us? There are several points in the process
where limitations might come into play:
The available USB descriptors: These are created based on the device
type (vendor and product IDs), and then based on the interface
location where the device is connected; as long as devices are plugged
into different ports, these *can't* overlap. So this limitation
effectively reduces to the physical limitations of the bus.
The available PDOs and FDOs: Device objects of both kinds are managed
internally by the Windows executive's Object Manager. The limit here
is essentially the memory available to the kernel to store the objects
- which is an upper limit of 2GB on normally-configured versions of
Windows. In any case, it's not an effective limitation, as device
objects are tiny relative to that - for example, the total kernel
memory in use on the machine which I'm using now is in the region of
87 MB. Other limitations will come into play long before it's possible
to hit this one.
Physical capacities of the bus: This is likely to be the real issue.
To calculate a theoretical maximum, consider the USB bus, which can
sustain up to 127 devices per hub, and hubs can be stacked up to six
deep; a typical motherboard on sale today can run a pair of root hubs
supporting eight external sockets. Assuming maximum cabling and five
layers of external hubs, then, one could theoretically connect
264,306,955,256 devices to a single Windows machine, although the
power requirements would almost certainly be prohibitive (as would the
memory requirements, above). Assuming more reasonable self-powered
8-port hubs at each layer, this figure becomes 262,144 devices.
The practical limitation, however, is likely to be the ability of the
machine to service the requests of such a large number of devices -
handle all their interrupts - before becoming both a) unusably slow,
or b) unable to handle other device interrupts, and blue-screening.
That, unfortunately, is something that would have to be determined
empirically - as there are no kernel mechanisms to prevent one from
adding as many devices as one pleases until running into these
practical limits; and the limits themselves will be determined by the
processor and chipset of the machine used to perform the test.
I think we can safely say, though, that it's above 60, and below 262,144!
Thank you for the fascinating question!
cerebrate-ga
Additional links:
http://www.sysinternals.com/
An site with a number of interesting tools should you wish to dig
further into the Windows kernel and its devices.
Search strategy:
Windows Device Driver Development Kit
Developing Windows NT Device Drivers, Dekker & Newcomer, 0-201-69590-1
Inside Microsoft Windows 2000, Third Edition, Solomon & Russinovich, 0-7356-1021-5 |