N
Naja, es gibt zumindest Normung hinsichtlich des Betriebssystems. Der Kernel darf in und out benutzen, Usermode Proggis nicht, und das hat auch seinen guten Grund.
Wie Nobuo schon schreibt...viele zugrundeliegende lowlevel-Funktionen(auch Highlevel) in Windows z.B. kann man sich als Workarounds und undokumentiertes Gedöns vorstellen.
Also ein richtig gutes Basisfundament für Transparenz und KnowHow Didaktik...
Das gleiche gilt für Linux, viele Workarounds, viele Funktionen sind gar nicht vorhanden, die viele Vorhandenden Funkionen oft nur spärlich dokumentiert. KnowHowfragmetierung in vollendeter Kunstform, durch diese Art von Codedschungel kann man sich nicht ohne professionellen Führer, unerschrockenes und erfahrenes Abenteuerteam und guter Kommunikationsverbindung zur Basis wagen...
(aber man kann sich zumindest mal anschauen, was bei dev/ so alles herumliegt).
Macht aber oft nicht viel Sinn, da beispielsweise für das Ansprechen/manipulieren der Tastatur Treiber und verschiedene Funktionen des Betriebssystems vorliegen. Auch unter DOS war es einfacher, Interrupts zu benutzen, als Datenblätter und Kommunikationsstandards und -protokolle zu studieren. Statt Interrupts benutzt man jetzt eben Systemfunktioncalls und Bibliotheken wie Directx, welche letztlich auch den hier gesuchten "Standard" darstellen.
Linux ist für hardwarenahe Geschichten vorzuziehen, da letztlich einfacher, dokumentierter und flexibler und so näher dran - sag ich mal so.
Und im Gegensatz zu Windows gibt es bei Linux mehr Systeme zur Auswahl, die man auf die eigenen Bedürfnise zurechtfrickeln kann (falls sie nicht eh schon gut passen).
Wenn man jetzt noch näher heran will, etwa weil man ein eigenes Betriebssystem schreiben möchte, dann muß man sich näher mit den Peripheriebausteinen und den Bausteinen der Schnittstelle befassen - was letztlich heißt, Entwicklungsboards für Mikrokontroller/Usb und Co und Protokolle für Schittstellen usw. besorgen. Gerade Usb ist vielversprechend, aber auch ganz schön umfangreich. Man möchte aber auch nicht unbedingt das Rad neu erfinden, also ist auch Reversing und weiteres Informieren über dokumentiertes/undokumentiertes Material angesagt.
(das hat aber Nobuo oben auch schon gepostet)
Bei Linux gibt es eine gute Möglichkeit, Assemblermathe zu plotten, über den Framebuffer:
siehe:
https://secure.wikimedia.org/wikipedia/de/wiki/Framebuffer
http://asm.sourceforge.net/articles/fb.html
http://net.pku.edu.cn/~course/cs201/2004/Assembly/asmutils-0.17/src/mandelbrot.asm
http://asm.sourceforge.net/articles/modex.html
und allgemein:
http://www.weblearn.hs-bremen.de/risse/RST/WS06/Grafikkarten-Programmierung/Ausarbeitung.pdf
http://www-vs.informatik.uni-ulm.de/dept/staff/weggerle/pubs/Hardwarenahe_Analyse_von_Grafikfunktionen_und_Shadern.pdf
Falls man selber per IN und OUT die Graka und den anderen Kram programmieren möchte, braucht man auch das entsprechende Betriebsystem dafür, z.B. Dos (+Extender), und die dazu passende Hardware. Aber man tut gut daran, erstmal die vorhandenen Schnittstellen dieser Tage (Cuda, OpenCl) auszunutzen.