because if you were you should know all this. However a very detailed history lesson, but cut back as much as I think I can and get the message delivered.
In the beginning every hardware manufacturer and software company did things their own way. The CCITT, later called the ITU, the international standards body responsible for telecommunications etc organised a bunch of standards that all the hardware and manufacturer's were to use - some being the OSI model, OSI protocols, TCP/IP, SMTP, FTP, ISA, EISA, IDE, etc. They often lagged behind the actual hardware and software development activities.
In the early microcomputers (later called personal computers then PCs) when you put it together you had to enter the into the BIOS system details of the various hardware, the most involved being the hard drives - plater numbers, sectors, etc - so the motherboard would know how to control the hard drive properly. You installed DOS and the other drivers needed for the peripheral hardware like a mouse etc. You also fine tuned files that told DOS how to work with the hardware of the motherboard so it got the best use of the RAM etc.
The instruction commands for the hardware and protocols that came out of the various standards were collectively referred to as command sets, and still are. Many of the hardware command sets ended up being included in the BIOS so the motherboards could automatically recognise the basic level actions of standard components and peripherals, as the motherboards became more complex other command sets were included in the BIOS to help the motherboard to functions properly. This still happens, but the BIOS has the basic level commands and the higher function commands for the fancier peripherals are in the electronic controller cards of the peripherals or part of the OS. Due to advances the OS command sets have expanded, but the basic ones are supposed to be there. If you add a peripheral to a system with an older OS that doesn't have the commands for that peripheral or the higher functions, then extra software needs to be added to the OS, these are known as drivers (still). Thus a pre USB OS needs a USB driver added before it can use a USB device.
One of the standards that came out was for all hard drives to recognise and accept the same set of command functions, this resulted in the hard drives having a small controlling pcb being included in their construction with that converted the command set instructions into machine language and also control the HDD internal operations. Similar standards came out for many other peripherals and plug-in cards. The standards had the various commands and signals listed - the wiki article n ASCII gives a good example of what a lot of the looked like.
At the same time standards came out setting out the functions and processes of an operating system and programs. They included a set of command set instructions for common commands. The intent was to have all the programs issuing the same command for the same function and all the OSs would recognise the same commands. The long term intent was to make it possible for the one program to be written and run on any OS and the OS to tun any program written. For a short while in the early 1990s this system was in full use by all the major players in what was then known as the PC industry. All the new hardware and software was out of the box compatible with all the operating systems, programs, and hardware made to those standards.
However, with the release of Windows 95 Microsoft pulled away from those standards and also some software standards as well. Microsoft took two applications (the graphics user interface and the Internet browser) and embed them into the OS in an attempt to have them work faster than if they were on the outside of the OS kernel security wall. They also incorporated some non-standard commands in the browser operations code (most of which was still there in MSIE 7 and starting to be taken out in MSIE 8). Another change MS made at that time was to NOT use the industry standard commands for interaction between the OS and the applications, they created a set of their own and insisted that anyone wanting to create software for use on Win 95 use their commands. MS also told the hardware manufacturers the same thing and pressured them to make hardware out of the box compatible with Windows 95 and not the industry standards. Many hardware manufacturers did as asked by MS due to the economic pressure applied.
The result of the above was the inclusion of the notations "Windows compatible" on the hardware or software, and notes like "requires Windows 95 or later." Thus anyone wanting to use that hardware on a non-Win 95 system needed a driver for it, and anyone getting a peripheral made to the industry standard needed a Win 95 driver for it.
Then with Win 2000 MS change their proprietary command set again, and thus you now had two Windows standards and sets of drivers. The same occurred with Win Vista, and will probably occur again with Win 9 or Win 10 - whenever MS want to introduce a new level of incompatibility.
Another action MS took with Win 95, and they've kept up since, was to include fast back door access into the OS kernel functions for other MS application programs like MS Word, Excel etc. They also used proprietary command sets in those applications so they would NOT work on any OS except MS Windows. They also change those command sets when they change the Windows ones.
The result is MS created incompatibilities between variants of MS Windows compatible software and hardware and the need for drivers for almost anything.
it is this introduced changes from the standards that means software designed to work on Win XP does not just load and work on Win 7 or Win 8 - as the commands from the application are NOT recognised by the newer OS.
Now before you go off about newer hardware and commands, remember that the latest versions of Unix and Linux include all the newer hardware commands and work the hardware and the old software designed for use on Unix and Linux in the late 1990s runs perfectly well on the very latest versions of Unix and Linux because the command sets are to the industry standards and the latest not only have the commands for the newest stuff, but also the exact same commands as were created for the old stuff.
Adherence to the industry standards means cross OS operation for the software without the need for any internal changes.
Hope this helps you to understand the situation better and what I'm saying. I've been working and living with all this stuff since the days of DOS 2. It's only in recent years I've started to pull away from working heavily with MS Windows and MS Office, but my clients and friends won't let me drop it all, thus I keep checking out the new stuff so I can fix their new vendor supplied systems and software.
Keep Up with TechRepublic