Dazu folgender Blog-Beitrag:
https://cloudblogs.microsoft.com/openso ... s-dos-4-0/
Zu finden auf:
https://github.com/microsoft/MS-DOS
Quelltexte für MS-DOS 4.0 freigegeben
Mal abgesehen davon, dass der MS-Server bei mir timeout gibt:ak120 hat geschrieben: ↑Fr 26. Apr 2024, 13:26 Dazu folgender Blog-Beitrag:
https://cloudblogs.microsoft.com/openso ... s-dos-4-0/
Zu finden auf:
https://github.com/microsoft/MS-DOS
Für was könnte der Sourecode eines Betriebssystem-Sauriers heutzutage von Nutzen sein, zumal noch in einem OS/2-Ökosystem?
MS sollte lieber die eigenen Bestandteile, die weiland zur Entstehung von OS/2 führten (und AFAIK noch heute Bestandteile des OS/2-Objektcodes sind) freigeben. Das könnte sicher helfen, den einen oder anderen Knoten im heutigen AOS, vor allem im Netz-Bereich (Samba?) zu lösen.
Gruß,
Lutz W.
Erst mal danke an Andreas für die Info!
Ein weiterer interessanter Link hierzu:
https://www.os2museum.com/wp/how-not-to ... #more-6574
Nicht dass ich mich mit Assembler auskennen würde. Aber ich finde solche Sachen extrem interessant. Außerdem hatte ich mit DOS 4 meinen allerersten Kontakt mit einem PC überhaupt. Also Nostalgie pur.
Ein weiterer interessanter Link hierzu:
https://www.os2museum.com/wp/how-not-to ... #more-6574
Nicht dass ich mich mit Assembler auskennen würde. Aber ich finde solche Sachen extrem interessant. Außerdem hatte ich mit DOS 4 meinen allerersten Kontakt mit einem PC überhaupt. Also Nostalgie pur.
nix, es geht nur darum ihn aus "historischen Gründen" zu erhalten.
Selbst wenn es den Quellcode gäbe, wer sollte etwas damit anfangen, gibt doch praktisch niemanden mehr.MS sollte lieber die eigenen Bestandteile, die weiland zur Entstehung von OS/2 führten (und AFAIK noch heute Bestandteile des OS/2-Objektcodes sind) freigeben. Das könnte sicher helfen, den einen oder anderen Knoten im heutigen AOS, vor allem im Netz-Bereich (Samba?) zu lösen.
Außerdem is OS/2 eine einzige große "Baustelle", wenn man auch nur ansatzweise daran denkt, es auf einen aktuellen Stand zu bringen. Angefangen mit dem völlig veralteten 32-Bit-Kernel, dann die Subsysteme für Netzwerk, Multimedia und allerlei Schnittstellen, das Treiber-Problem läßt sich damit auch nicht lösen und (nicht) abschließend die Oberfläche, die zwar genial, aber eben auch alles andere als fehlerfrei und völlig veraltet ist.
So oder so ist da nix mehr zu machen
![Traurig :-(](./images/smilies/icon_e_sad.gif)
Grüße,
Thorolf
Thorolf
Dies wurde doch zumindest teilweise getan. Wegen der Umbenennungen und der Form der Veröffentlichung (die Verknüpfung zu Michals Blog wurde bereits erwähnt), wäre es vielleicht sinnvoller gewesen, die Quelltexte nach den entsprechenden Entwicklungszweigen getrennt feilzubieten.DonLucio hat geschrieben: ↑Mo 29. Apr 2024, 13:16Mal abgesehen davon, dass der MS-Server bei mir timeout gibt:ak120 hat geschrieben: ↑Fr 26. Apr 2024, 13:26 Dazu folgender Blog-Beitrag:
https://cloudblogs.microsoft.com/openso ... s-dos-4-0/
Zu finden auf:
https://github.com/microsoft/MS-DOS
Für was könnte der Sourecode eines Betriebssystem-Sauriers heutzutage von Nutzen sein, zumal noch in einem OS/2-Ökosystem?
MS sollte lieber die eigenen Bestandteile, die weiland zur Entstehung von OS/2 führten (und AFAIK noch heute Bestandteile des OS/2-Objektcodes sind) freigeben. Das könnte sicher helfen, den einen oder anderen Knoten im heutigen AOS, vor allem im Netz-Bereich (Samba?) zu lösen.
Das frühe M/T MS-DOS 4, welches aus MS-DOS 2 abgeleitet wurde, kann als direkter Vorfahr des OS/2 1.0 angesehen werden.
Die eigentlichen Quellen des späteren MS-DOS 4.0 von 1988 enthalten die Realmode-Bestandteile des OS/2 1.1/1.2. Erst ab OS/2 2.0 und NT war die noch heute genutzte DOS-5.0-Umgebung enthalten. Leider genügt der Platz hier nicht, um zumindest auf die wesentlichen Änderungen bzgl. des DOS-Treibermodells und weitere Besonderheiten einzugehen.
Heißt das, dass auch im heutigen OS/2 4.x bzw AOS so etwas wie ein DOS-5.0-Kernel enthalten ist?
Dann wundert's mich erheblich, dass unser System auf heutigen Prozessoren überhaupt noch läuft. Das kann doch eigentlich nur bedeuten, dass die heutigen x86-Nachfolger alle einen erheblichen Kompatibilitäts-Ballast in ihrem Microcode herumschleppen, oder? Das macht Intel doch nicht nur für uns paar OS/2-Hansel auf der Welt.
Oder sind wir vielleicht gar nicht so wenige?
Danke für deine interessanten Ausführungen.
Gruß,
Lutz W.