You've got some excellent answers here already, but let me add another that might help a bit. Back in the good old days when we didn't have to deal with Windows I did a lot of programming devices; specifically, measuring devices to test military hardware. There were no standards then, not as we know them today. The operating system was customized for every machine model, and already "knew" how to send bits over a serial link or HPIB bus. But the languages used had constructs like READ_VOLTS(DC, 100, AVG, 10) to return the measured DC volts on a line, up to 100 Vdc, averaged over a period of 10 milliseconds. But every oscilloscope, DMM, millivoltmeter, etc, recognized a different set of commands, unique to each manufacturer, and often each model. Usually these were in the form of text strings, and often the device listened for commands on a different physical address than the one used for data. For each device, we had to write a subprogram to translate what the operating system sent into a form the device could recognize. Today we'd call that subprogram a driver, and its job remains the same in the modern world. If you were to design a new programmable device, a toaster perhaps, it would have built in commands that Windows knows nothing about. You might have a syntax containing something like: ATDDSSSSHHMM# where AT = Attention (new command setting follows) DD = Darkness (1 - FF) SSSS = Active slots (0001 - 1111) HHMM = Start time (HH, hours; MM, minutes) # = execute command Your Toaster application program - the software your user runs to make toast - might output a command like: Toast (Medium, 2, 5:30AM) You would need to provide a driver to convert Medium to 80, 2 to 0011, and 5:30AM to 0530, then string them together into a command the toaster recognizes: AT8000110530#. On installation, your driver would register with Windows the addresses it listens to, and you would provide the port to which the physical toaster is connected. The driver would then ask Windows to send the commmand string it constructs using the assigned port when your program requests toast. Ideally, your driver would also notify Windows when the toast is done, so that the OS can tell your application program the status of the job. In the Windows world, devices are not physical things, but software entities called drivers. The driver software does the actual manipulation of real objects, which adds layers of confusion for users trying to play with Device Manager. :-D Writing drivers is a difficult job,
