News 27 Jahre altes Betriebssystem mit neuer CPU: So läuft Windows NT 4.0 mit Intel Raptor Lake

PCGH-Redaktion

Kommentar-System
Teammitglied
Jetzt ist Ihre Meinung gefragt zu 27 Jahre altes Betriebssystem mit neuer CPU: So läuft Windows NT 4.0 mit Intel Raptor Lake

CPU-Support und Windows waren zuletzt eher ein rotes Tuch, doch das in die Jahre gekommene NT 4.0 erfreut sich auch mit einem aktuellen Intel Raptor Lake bester Lauffähigkeit.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: 27 Jahre altes Betriebssystem mit neuer CPU: So läuft Windows NT 4.0 mit Intel Raptor Lake
 
Und genau dafür steht x86:
Nicht das alte Betriebssystem supported neue CPUs, sondern neue CPUs halten alle Standards ein, die alte Software kennen. Und damit läuft die auch, fertig.
Wenn das jetzt auch noch für die I/O-Hubs gelten würde... Wie wärs mit Windows-7-USB-Treibern jenseits Z270/Z370/X299 ... B460 @Intel oder mal jenseits des Ur-Promontorys @AMD? :stick:
Und doppelt-:stick: an die Grafikabteilungen, ohne die einem als Retrogamer die x86-Abwärtskompatibilität wenig nützt, denn irgendwas muss ja auch das Bild ausgeben.
 
Von der Hardwareseite interessant, aber Windows NT4 war wie Windows 95 das Grauen! Und dann mit den ganzen Service Packs. Gruseligst! Ja, ich verbinde damit Erinnerungen, aber bestimmt keine guten, in denen ich schwelgen mag. ;)
 
Oh ja ..
Das erste Jahr meine Berufsausbildung ...
"Windows NT installieren, dann SP4 installieren, dann Netzwerktreiber installieren, dann SP6 installieren" - "Wie du hast gleich SP6 installiert? Wenn du jetzt den Netzwerktreiber installierst, funktioniert er nicht richtig. Also noch mal von vorne ..."
 
Fairerweise soll auch nicht unerwähnt bleiben, dass NT4.0-Systeme nicht die erste Wahl für PC-Gaming darstellten. Zu der Zeit war dank Windows 95 gerade der Wechsel vom guten alten DOS (MS-DOS/DR-DOS, Treiber- und EMS/XMS-Speichergefrickel in "autoexec.bat" und "config.sys" für ideale "Gamingtauglichkeit" habe ich noch gut im Gedächtnis) vollzogen, während die "NT"-Windows eher für schnöde Firmenumgebungen mit ihren aufkommenden Anforderungen an vernetztes Arbeiten am PC standen... Aber möglich war damals vieles, ich hatte zu dieser ZEit M$ abgeschworen und beschäftigte mich lange Zeit intensiv mit "IBM OS/2" (woraus der "Böse Bill" ja einiges für sein erstes Windows NT "reused" hat....)
 
Oh ja ..
Das erste Jahr meine Berufsausbildung ...
"Windows NT installieren, dann SP4 installieren, dann Netzwerktreiber installieren, dann SP6 installieren" - "Wie du hast gleich SP6 installiert? Wenn du jetzt den Netzwerktreiber installierst, funktioniert er nicht richtig. Also noch mal von vorne ..."
Keine Hektik! Meine Wehrpflichtigen habe noch Dateien per Diskette vom Stab zu den Kompanien bringen lassen.
 
Nur frage ich mich dann warum MS für Windows 11 TPM Pflicht eingeführt hat? :ka:
Was erstmal nichts mit x86 Kompatibilität zu tun hat. Das ist eine bewusste Abgrenzung alter Hardware. Unter dem Deckmantel der "Sicherheit".
während die "NT"-Windows eher für schnöde Firmenumgebungen mit ihren aufkommenden Anforderungen an vernetztes Arbeiten am PC standen...
Und NTFS konnte Dateien jenseits von 4gb Größe handlen. FAT32 begann langsam an seine Grenzen zu stoßen.
Zu der Zeit war dank Windows 95 gerade der Wechsel vom guten alten DOS (MS-DOS/DR-DOS, Treiber- und EMS/XMS-Speichergefrickel in "autoexec.bat" und "config.sys" für ideale "Gamingtauglichkeit" habe ich noch gut im Gedächtnis) vollzogen,
Du unterschlägst Win 3.x :D Unter Win95 gab es auch noch recht viel gefrimmel. Ich erinnere mich gern an meine Matrox + 2x 3DFX Voodoo1 bzw. später Voodoo2 im SLI jeweils. Wollte man da Gilde nutzen war das auch oftmals mit etwas Aufwand verbunden.:lol:Der wirkliche "Durchbruch" für mich in Sachen PC Gaming ist nach wie vor DirectX. Nach dem MS es geschafft hatte es als "Standard" durchzusetzen nahm die Sache wirklich fahrt auf.
 
Zuletzt bearbeitet:
Als Windows NT die Nachfolge von 3.11w antrat, während Heimanwender zu 9X gingen, spielten 4-GiB-Dateien vermutlich nicht einmal für professionelle Anwender eine Rolle. Digitales Video war damals noch nicht etabliert und Heimanwender hatten oft nicht einmal 1 GB Festplattenkapazität. Noch Jahre später störte es allenfalls, dass Fat32 die minimale Clustergröße nur bis meiner Erinnerung nach 1 GiB halten kann. Aber zum einen NTFS ist NTFS mit allgemein min. 4 KiB Clustern noch viel schlimmer/zieht mit FAT32 erst ab 8-GiB-Partitionsgröße auch nur gleich und zum anderen konnte man ja einfach mehrere Partitionen anlegen. War bei 9X ohnehin empfehlenswert, damit nach dem regelmäßigen "format c:" nur das Betriebssystem weg war und alles andere erhalten blieb/nicht ebenfalls neu installiert werden musste. (Ja, damals liefen nahezu alle Anwendungen und auch ein großer Teil der Spiele noch so weiter, die meisten haben sogar Spielstände und Einstellungen in ihren eigenen Verzeichnissen speichern können :top:)

Nur frage ich mich dann warum MS für Windows 11 TPM Pflicht eingeführt hat? :ka:
Grund: "Microsoft"
 
Zuletzt bearbeitet:
FAT32 hat folgende Merkmale:

Es werden bis zu 228 = 268.435.456 Cluster verwendet.
Die maximale Dateisystemgröße hängt von der Sektorengröße des verwendeten Mediums ab. Bei Festplatten, die typischerweise 512 Bytes Sektorengröße haben, beträgt die maximale Größe 2 Tebibyte; bei Datenträgern, die 4 KiB Sektorengröße verwenden, beträgt die maximale Größe 16 Tebibyte. Die Größe ist primär durch das vier Bytes große Gesamtsektoranzahl-Feld (Offset 20h) im Bootsektor begrenzt.
Die Cluster sind je nach Partitionsgröße zwischen 512 Byte und maximal 32 KiB groß.
Dateien dürfen max. bis zu 4 GiB − 1 Byte (= 4.294.967.295 Byte) groß werden. Diese Grenze ist eine Folge des nur 4 Byte breiten Feldes für die Dateigröße in der Directory-Tabelle.
Es können maximal 228 Dateien abgelegt werden; da jede Datei mindestens einen Cluster belegt, beschränkt die maximale Anzahl der Cluster die maximale Anzahl Dateien.
Das Haupt-(Root-)Verzeichnis muss sich nicht an einer bestimmten Position auf dem Datenträger befinden und hat vor allem keine festgelegte Größe; bei den anderen FAT-Varianten wird die maximale Anzahl der Einträge im Hauptverzeichnis bei der Formatierung festgelegt (und kann nachträglich nicht geändert werden).

Wikipedia ist doch manchmal ganz nützlich :-)
 
An diesen Windows NT 4.0 Zeiten kann ich mich noch gut erinnern. Am Besten waren die SP Installationen.:haha:
Auf neuen CPUs läuft es schon, nur braucht man heute kein NT 4 mehr. Das schlichte Design machte es damals schon gut bedienbar, sodass man seine Verwaltung & Co fertig hatte. Leider waren trotzdem Bugs nach SP6 weiterhin gegeben. Ist heute aber ein alter Hut...:-)
 
Wir haben damals mit NT rumexperimentiert, weil Win95 jenseits von twisted pair so gut wie nicht netzwerkfähig war (zumindest in der Anfangszeit).
Aber ja, wilde Zeiten, als man noch für jedes größere Spiel seine eigene autoexec.bat geschrieben hat. Doppelklick aufs Icon und der Rechner hat sich erstmal runtergefahren um neu zu booten.
Heutzutage stellt man sich bei Steam ins Forum und weint, weil man 3 Sekunden Ladebildschirm hat, wenn man bei Starfield eine Tür aufmacht...
Jedenfalls war es immer einen versuch wert, ob man z.B. Duke Nukem 3D nicht doch auf NT zum laufen kriegt, anstatt an einer stabilen Netzwerkverbindung unter 95 zu frickeln.
War unter 98SE kein Thema mehr und XP ist eh GOAT ;)
 
NT war cool. Mein Vater hatte es beruflich auf seinem Firmenrechner. Ich war total angetan von dem Start Sound. Ich besitze sogar noch edie original CD mit Lizenz Key. Aber heutzutage kann ich es nicht mehr benutzen. Zumal die meisten Games die ich besitze nicht für NT vorgesehen sind.
 
Ich finde es ein bisschen schade das Programmierer heite so ineffizient arbeiten. Früher musste man um jedes bit Kämpfen was sehr schlanke Software hervorbrachte. Nicht auszudenken wie performant ein moderner Rechner mit einem entsprechend sparsamen OS laufen würde man stelle sich mal vor ein Windows 10 oder 11 hätten die gleichen Anforderungen wie nt4.0 .
 
Ja das PRoblem seinerzeit mit NT (und auch OS/2) war, das diese Betriebssysteme mit ihrem "Protected-Mode" mit den damaligen Spielen, die fast alle nur im "Real-Mode" liefen bzw. dafür den direkten Zugriff auf die PC-Hardware benötigten, nicht performant genug "zusammenpassten". Erst mit WinXP setzte sich der "NT-Unterbau" in der vollen Breite v.a. auch im Consumer-BEreich endgültig durch, die alten Zöpfe des "DOS-Unterbau", die bis Win98 immer noch im Hintergrund präsent waren, wurden mit XP engültig und irreversibel gekappt. Die inzw. etablierte Hardware-PErformance erlaubte inzw. auch beim Gaming trotz "Betriebssystem-Zwischenschicht" zw. Applikationsebene und HArdwareebene ausreichende PErformanz bzw. hatten die Spielehersteller auch gar keine andere Wahl dank des Quasi-Monopols am PC-Markt von Windows(XP)-Systemen fortan über dessen Schnittstellen (u.a. "DirectX") auf die HArdware zuzugreifen...
 
Ich finde es ein bisschen schade das Programmierer heite so ineffizient arbeiten. Früher musste man um jedes bit Kämpfen was sehr schlanke Software hervorbrachte. Nicht auszudenken wie performant ein moderner Rechner mit einem entsprechend sparsamen OS laufen würde man stelle sich mal vor ein Windows 10 oder 11 hätten die gleichen Anforderungen wie nt4.0 .
Selbst wenn sie gleich effizient arbeiten bekommst du das nicht hin.
Windows 10 & 11 haben so viele Optische, oder Backup Stellen die ein runden Ablauf Garantieren und auch beim Systemneustart schnell wieder verfügbar geladen werden... :ka:

Selbst wenn man wie gesagt genau so effizient um jeden Bit gekämpft programmiert aber den aktuellen Standard einhalten möchte hat man höhere Systemanforderungen als damals bei NT4.0
 
Früher(TM) hatten die Programmierer von Spielen den Zugriff auf die PC-HArdware komplett in eigener Hand (exklusiver Direktzugriff über die Schnittstellen der hardwarenahen Treiber) und konnten je nach Kenntnis sehr schlanken, effizienten und schnellen Code auf der damaligen Hardware (IBM PC-AT/-386) realisieren.

BEi dieser Zugriffsart gab es aber kein Multitasking und Bugs in der laufenden Applikation oder einem der Treiber hatten verheerende Auswirkungen: i.d.R. Kompletter Systemabsturz inkl. Datenverlust, Schäden am Dateisystem u.ä. Dann musste man auch immer erst mal mit den "Norton Utilities" drübergehen, um "verlorene Sectoren" udgl. wiederzufinden, wenn man weitere "Folgeerscheinungen" (i.d.R. auch wieder Total-Abstürze) vermeiden wollte.

Heutzutage liegt aber das "Betriebssystem" als Schutzschicht zwischen mehreren parallel laufenden Applikation und der Hardware, was den Vorteil bietet, dass bei Bugs in einer Applikation i.d.R. nur diese eine Applikation abstürzt (Crash to Desktop statt Totalcrash), alle anderen der mittlerweile zahlreichen parallel ausgeführten Apps (Multitasking!) inkl. des Betriebs- und Dateisystems aber vor der "amoklaufenden" abstürzenden App geschützt werden und weiterlaufen. Das bedeutet einen enormen Zugewinn an Systemverfügbarkeit und Datenintegrität auf dem Gesamtsystem. Siehe auch "Protected Mode" bis herunter auf CPU-Ebene.

Im Prinzip ist das Konzept des "Protected Mode" der x86-Architekturen noch deutlich "vielschichtiger", aber zum besseren Verständnis sei das mal so simpel dargestellt.

Der NAchteil hierbei liegt aber natürlich in der reduzierten PErformance, die App (Spiel) kann nicht mehr mit auf die eigenen Anforderungen hochoptimierten Direktzugriffen auf die Hardware zugreifen, sondern ist gezwungen, diese Zugriffe ausschließlich(!) über die nun "zwischengeschaltete" Betriebssystemschicht durchzuführen, was natürlich vor allem früher deutlich zu Lasten der Performance ging.

Deswegen war es relativ lange v.a. aus PErformancegründen "verpönt", Games auf entspr. "restriktiven" Betriebssystemen wie "NT" oder auch OS/2 aber auch UNIX-/LINUX-Derivaten zu entwickeln. Im ungeschützten Direktzugriff unter "MS-DOS" und Co. konnte man selbst aus der damaligen, kaum auf Grafikverarbeitung und Gaming ausgelegten Standard-IBM-PC-Architektur (im Gegensatz zu den dedizierten Spielekonsolen oder selbst dem Amiga500, der ja von der Architektur urspr. auch als Spielekonsole konzipiert war) eine viel bessere, gamingtaugliche Performance herausholen.

Ein IBM-PC war ein "Alleskönner", aber das bedeutete auch, dass "Spezialisten", wie Spielekonsolen zum Zocken besser geeignet waren, auch wenn sie rein rechnerisch auf dem Papier dem PC deutlich unterlegen waren.

Heutztage ist die PC-Architektur eines Gaming-PC v.a. mit einer leistungsfähigen 3D-Grafikkarte hardwaremäßig viel mehr auf "Gaming" spezifiziert bzw. durch die Leistungssteigerungen der letzten JAhrzehnte derart leistungsfähig geworden, dass diese "Einschränkungen" von Einst(TM) nicht mehr relevant sind bzw. die o.g. Vorteile bezügl. Systemstabilität und Datenintegrität bei Weitem wichtiger geworden sind...auch am zum Zocken genutzten Consumer-PC.

Der Aufwand bei der Applikationsentwicklung ist aber ebenso deutlich gestiegen und der "Zwang" zur Nutzung von vorgegebenen generischen "Betriebssystem-Schnittstellen" und API's lässt halt die Komplexität heutiger Softwareprojekte und deren Codeumfang enorm anschwellen...
 
Zuletzt bearbeitet:
damit nach dem regelmäßigen "format c:" nur das Betriebssystem weg war und alles andere erhalten blieb/nicht ebenfalls neu installiert werden musste. (Ja, damals liefen nahezu alle Anwendungen und auch ein großer Teil der Spiele noch so weiter, die meisten haben sogar Spielstände und Einstellungen in ihren eigenen Verzeichnissen speichern können :top:)

Da fang ich fast an zu weinen. Ja so war das damals. Ich wünschte es wäre heute auch noch so. Ich könnte mich auch heute noch mit einem Kommandozeilen basierten BS abfinden. Damals hat man in wenigen Dateien alles gefunden, was zum Start geladen wurde.

Heute haben selbst "Computerprofis" keine Ahnung mehr was alles versteckt oder nicht versteckt beim booten und starten vom Betriebssystem geladen wird. Sollen sie auch gar nicht.

"Vertraut Microsoft, vertraut den Hardwareherstellern. Ihr seid doch eh zu dumm, die Hintergründe zu verstehen" :-D


PS. Das einzige was ich nicht wirklich gut fand damals, war das gefrickel mit der Vergabe von Interrupts und DMA Adressen. Seit Plug & Play richtig funktioniert hat, war das schon ein Meilenstein für den reibungslosen Hardwaretausch. In den Anfangszeiten von P&P war aber auch das nicht gegeben. Da gabs oft Probleme, vermutlich weil Board (BIOS) und BS noch nicht ordentlich darauf abgestimmt waren, sich diese Bereiche zumindest teilweise zu teilen bzw. sie dem BS zu überlassen.

Ach und funktionierende Netzwerke waren zu Windows 9x Zeiten auch nicht so einfach zu realisieren. Der erste Tag bei einer LAN Party ging meistens dafür drauf, auch noch den letzten Rechner in das Netzwerk zu integrieren. Hehe, das waren noch Zeiten.
 
Genau dieser "Komfort" moderner Betriebssysteme (funktionierendes P&P, Vernetzung,...) erfordert halt gegenüber den guten alten DOS-Zeiten einen erheblichen Managementaufwand "hinter den Kulissen" des Klicki-Bunti-Userinterfaces. U.a. dieser Aufwand lässt Betriebssysteme und dazu "konforme" Apps extrem anschwellen. Damit man den "Normaluser" mit diesem steigenden Managementaufwand aber nicht überfordert, wird das Meiste davon vor ihm verborgen, solange es geht. Andere Gründe dafür mögen aber durchaus auch bestehen ;)

Es ist aber eben beim genauen Hinsehen widersprüchlich, sich auf der einen Seite nach den "guten alten einfachen Zeiten" zu sehnen mit "Norton Commander", "Autoexec.bat" und "Config.sys", auf der anderen Seite aber die reibungslose Integration von HArdwarekomponenten unterschiedlichster HErsteller(!) in ein stabil lauffähiges System oder die reibungslose Vernetzung mehrerer hardwaremäßig ganz unterschiedlicher lauffähiger Systeme nicht missen zu wollen...

Um nichts falsch zu verstehen, ich habe früher auch mit Genugtuung am System herumoptimiert, um alle HArdware (Sound, Mouse, Joystick, 3D-BEschleuniger udgl.) unter Ausnutzung von möglichst viel XMS (Treiber in den Speicherbereich oberhalb 640kByte laden) zum laufen zu bekommen damit auch speicherhungrige Spiele genug Arbeitsspeicher zur Verfügung haben. Dieses "Gefrickel" machte uns damals zu kleinen Betriebssystem-"Experten", man wählte neue Komponenten auch mit ganz anderen Schwerpunkten (möglichst flexible Treiberunterstützung) aus usw. heutzutage ist RGB-BEleuchtung für viele wichtiger geworden...

Aber ich erinnere mich auch an viele Stunden Frust, wenn man bei einem neu gekauften Spiel nicht gleich losspielen konnte (einlegen und loslegen, ein damals enormer Vorteil von Spielekonsolen ggü. dem PC), sondern erst mal stundenlang am System herumoptimieren musste, sich irgendwo angepasste Treiber besorgen musste (damals gabs kein Internet, also nix einfach irgendwo downloaden, man brauchte i.d.R. Datenträger vom Hersteller oder Kopien davon von irgendwoher...), bevor man das Spiel auf der eigenen Maschine mit Sound, Mouse-/Joystickunterstützung und im 3D-Grafikmode überhaupt starten konnte
 
Zuletzt bearbeitet:
Plug & Play ist in erster Linie eine Firmware-Sache. Das Betriebssystem macht bis heute nichts weiter, als passend zur Hardware-ID einen Treiber zu suchen – und, bis einschließlich Windows XP SP1 in der Regel nicht zu finden, worauf hin der User ihn installlieren muss. Aber die Hardware-Erkennung und -Initialisierung ist Aufgabe der Firmware. Da haben Schnittstellen sowie BIOS/UEFI im Laufe der Zeit immer weitere Fortschritte gemacht, ganz ohne Betriebssystem respektive zu alten kompatibel. Wenn du DOS auf eine Jahrtausendwende-System packst, musst du auch keine DMA-Adressen oder Interrupts von Hand setzen; wenn du ein [möglichst modernes Betriebssystem] auf einer ISA-Plattform zum laufen bringst, musst du es weiterhin.

Auch bei Netzwerken war und ist nicht die Hard-, sondern die Software das Problem: Ethernet-Verbindungen sind leicht herzustellen; ohne DHCP-Support muss man halt mal IP-Adressen von Hand eintragen. Aber Windows, möglicherweise gar verschiedene Versionen anschließend dazu zu bringen, sich gegenseitig Dateizugriff zu gewähren, das ist die wahre Kunst. (Insbesondere wenn man nicht Microsoft-Automatiken die Entscheidung überlassen will, welche Dateien zugänglich sind.) Würde man auf diverse (Sicherheits-)Beschränkungen, Automatiken, etc. verzichten, wäre es überhaupt kein Problem ein System mit voller Nutzerkontrolle nach DOS-Vorbild mit aktuellem Hardware-Support zu kombinieren. An der Zusammenarbeit verschiedener Komponenten haben Windows & Co nämlich so gut wie keinen Anteil. Im Gegenteil: Der regelmäßige Wechsel von Betriebssystemgenerationen und Treibermodellen wird da eher zum Hinderniss. Theroetisch könnte man fast alles mit allem in einem Rechner kombinieren, weil die Hardware letztlich sowie nur aus nebeneinander exisiterenden Schnittstellen besteht und alles andere Treiber machen, mit denen die jeweils nutzende Anwendung so oder so umgehen muss. Aber real ist es z.B. unmöglich einen PC zu bauen, der ein natives DOS-Spiel auf einem aktuellen Bildschirm ausgibt, weil es kein Betriebssystem gibt, dass sowohl die bei neueren Grafikkarten ("hat schon HDMI oder DP") verwendeten Treibermodelle unterstützt als auch einen DOS-Modus bietet. Letzterer endet mit 98SE, erstere beginnen mit XP. (Und VRR kann schon unter Windows 7 zum Problem werden.)

P.S.: Der Protected Mode wird nötig, sobald man mehr als 1 MiB RAM nutzen will oder was neueres als Windows 3.1. Als Heimanwender NT 4.0 links liegen ließen und aus Kompatibilitätsgründen lieber 9X nahmen, war der Protected Mode längst standard und auch für alle Spiele okay. Was bei 9X noch fehlte, was dadurch ermöglichte, mehrstufige Sicherheitskonzept. Da durfte jeder Kernelmode-Rechte haben, der wollte, und viele, insbesondere viele Spiele wollten. War bei der Enwicklung einfacher und es war performanter das Sicherheitskonzept lautet damals sowieso noch "installier halt keine Malware, du Depp". Daraus resultiert übrigens maßgeblich auch der Ruf von Windows 9X, instabil zu sein. Das war es, zumindest ab 98, selbst eigentlich nicht mehr; ich kenne PCs damit die hatten ein Jahrzehnt lang nicht einen Bluescreen. Aber das waren PCs, auf denen nur wenige (und offensichtlich sauber geschriebene) Anwendungen liefen, keine Gaming-Systeme. Bei denen führte die Ring-0-Ausführung von Anwendungen dazu, dass ein Crash im Spiel oft einen Absturz des ganzen Rechners nach sich zog. Das "viel stabilere" Windows XP machte nichts weiter, als Spiele, Betriebssystem und Treiber zu trennen. Die Spiele stürzten weiterhin genauso oft ab, aber statt einem Bluescreen sah man dann den Desktop. (Aber der Spielfortschritt war genauso weg und bei der lächerlichen Boot-Zeit eines sauber konfigurierten 9X sparte man sich brutto vielleicht 30 bis 45 Sekunden je Absturz, von denen man dann netto aber noch die deutlich längere XP-Bootzeit beim regulären Start des Rechners abziehen muss.)
 
Zurück