peter-dambier schrieb am 6. September 2007 14:59
> KatiH schrieb am 6. September 2007 8:49
> > peter-dambier schrieb am 4. September 2007 21:17
> > > DOS 1... CP/M abgekupfert, aber nicht nicht hingekriegt.
> >
> > *lach* Nicht jeder, der etwas abkupfert, will auch eine exakte Kopie.
> > Dass sie nicht sklavisch PIP kopiert habe, ist definitiv kein
> > Nachteil. ;-)
>
> Als Entwickler, sowohl unter DOS 1 als auch CP/M 86
>
> http://www.peter-dambier.de/
>
> dort gibt es noch ein paar CP/M 86 Basteleien von uns.
>
> Habe ich mit CP/M 86 wesentlich bessere Erfahrungen gesammelt, als
> mit MSDOS.
Ich habe zwar keine Erfahrungen mit CP/M-86 und auch nur wenige mit
CP/M-80, aber dafür umso mehr mit MS-DOS. Und ich sehe da keine
Probleme, die über die normalen Grenzen der Platform (z.B. keinen
Speicherschutz, kein Multitasking, ...) hinaus gehen. (Und die CP/M
ebenso hat)
> Es war beispielsweise einfach, eine beliebige NEC V20 oder Intel 8086
> Hardware mit einem BIOS auszustatten und CP/M 86 zu booten. Es hat
> sogar funktioniert, ein Bios fuer MSDOS zu schreiben, auf dem CP/M 86
> unter MSDOS lief.
Wenn dein Hauptanliegen ist, Betriebssysteme auf exotische Hardware
zu portieren, dann mag CP/M dafür meinetwegen besser geeignet gewesen
sein.
Das ist aber nicht wirklich _das_ Killerfeature, das die Entwickler
dieser Welt unter MS-DOS vermisst haben. ;-)
> Das Gegenteil war unmoeglich. Das MS-Bios war ein Krampf und anpassen
> an andere Hardware als den IBM PC war unmoeglich und ist spaetestens
> noch der naechsten DOS Version gescheitert.
Bei MS-DOS heisst das nicht BIOS, sondern IO.SYS.
Und es war definitv möglich, denn ich weis mindestens zwei PCs, die
eine andere IO.SYS hatten, den Siemens PC-D sowie den Olivetti M24.
Ein normales MS-DOS hat auf den Kisten nicht gebootet, MSDOS.SYS und
COMMAND.COM waren aber zum normalen DOS identisch.
Ach ja, CP/M hat ja auch jedes Jahr neue Releases auf den Markt
geworfen. Ein CP/M 3.0 wirst du auch nicht mit dem BIOS von 2.2
gebootet bekommen.
> Nachladbare Devicedriver haben erst mit der 3er DOS Version andere
> als die von Microsoft anvisierten Datentraeger akzeptiert.
Was sollen denn "von Microsoft anvisierte Datenträger" sein?
> > Ein anderes Beispiel ist das Dateisystem. FAT mag ja heute schäbig
> > und überholt sein, damals war das ein Fortschritt.
>
> FAT war die schlimmste Kathastrophe. Bei CP/M war es kein Untergang,
> wenn beim Schreiben etwas schief ging. Bei DOS mussten wir mehrmals
> taeglich chkdsk laufen lassen und haben jedesmal Daten verloren.
Keine Ahnung, was ihr gemacht habt, aber das kann ich nicht
nachvollziehen. Ich kann mich aber noch an lustige (damals ziemlich
ärgerliche) Probleme mit dem unflexiblen Disketten-Handling von CP/M
erinnern.
> > > DOS 2... und folgende, Unix abgekupfert aber nicht hingekriegt.
> >
> > Wie schon gesagt, niemand behauptet, dass MS-DOS ein exakter Klon
> > werden sollte. Dazu waren alleine schon die PCs damals noch nicht
> > leistungsfähig genug.
>
> Seit dem gab es zwei getrennte Interfaces, fuer ein und die selbe
> Funktion, entweder nach CP/M oder nach Unix Standart.
Genauer: es gab ein Interface nach "Unix Standart" und ein Interface
für File-I/O, eins für den Bildschirm, eins für Drucker, ... Merkst
du was? Das war eine sinnvolle Renovierung des "CP/M Standarts".
> > > Was ist Windos?
> > >
> > > Eine Sammlung von Rootkits, die sich um einen kaputten Unix-Kernel
> > > streiten.
> >
> > Für solchen Mist bekommst du zu Recht eine negative Bewertung.
>
> Es war ein Sammelsurium verschiedener Systemschnittstellen, meist
> Interrupts, die von unbekannten Programmen, sowohl aus dem Hause
> Microsoft, als auch von Fremden, verbogen und in unbekannte
> "Rootkits" entfuehrt wurden. Novell Netware und der IBM LanManager
> waren sollche Entfuehrer, oder auch 386 to the Max, Speichermanager.
Die Hälfte dieser Interrupts sind Altlasten von CP/M (INT20 z.B.),
insofern finde ich das API von MS-DOS ganz überschaubar. Und dass
Programme diese Interrupts verbogen haben, um zusätzliche
Funktionalität zu erweitert, ist wohl die einzige Möglichkeit, so ein
System aufzubohren. Und ich hoffe, du willst nicht behaupten, dass es
unter CP/M Hooks für alle möglichen und unmöglichen
Erweiterungswünsche gegeben hat?
> KatiH schrieb am 6. September 2007 8:49
> > peter-dambier schrieb am 4. September 2007 21:17
> > > DOS 1... CP/M abgekupfert, aber nicht nicht hingekriegt.
> >
> > *lach* Nicht jeder, der etwas abkupfert, will auch eine exakte Kopie.
> > Dass sie nicht sklavisch PIP kopiert habe, ist definitiv kein
> > Nachteil. ;-)
>
> Als Entwickler, sowohl unter DOS 1 als auch CP/M 86
>
> http://www.peter-dambier.de/
>
> dort gibt es noch ein paar CP/M 86 Basteleien von uns.
>
> Habe ich mit CP/M 86 wesentlich bessere Erfahrungen gesammelt, als
> mit MSDOS.
Ich habe zwar keine Erfahrungen mit CP/M-86 und auch nur wenige mit
CP/M-80, aber dafür umso mehr mit MS-DOS. Und ich sehe da keine
Probleme, die über die normalen Grenzen der Platform (z.B. keinen
Speicherschutz, kein Multitasking, ...) hinaus gehen. (Und die CP/M
ebenso hat)
> Es war beispielsweise einfach, eine beliebige NEC V20 oder Intel 8086
> Hardware mit einem BIOS auszustatten und CP/M 86 zu booten. Es hat
> sogar funktioniert, ein Bios fuer MSDOS zu schreiben, auf dem CP/M 86
> unter MSDOS lief.
Wenn dein Hauptanliegen ist, Betriebssysteme auf exotische Hardware
zu portieren, dann mag CP/M dafür meinetwegen besser geeignet gewesen
sein.
Das ist aber nicht wirklich _das_ Killerfeature, das die Entwickler
dieser Welt unter MS-DOS vermisst haben. ;-)
> Das Gegenteil war unmoeglich. Das MS-Bios war ein Krampf und anpassen
> an andere Hardware als den IBM PC war unmoeglich und ist spaetestens
> noch der naechsten DOS Version gescheitert.
Bei MS-DOS heisst das nicht BIOS, sondern IO.SYS.
Und es war definitv möglich, denn ich weis mindestens zwei PCs, die
eine andere IO.SYS hatten, den Siemens PC-D sowie den Olivetti M24.
Ein normales MS-DOS hat auf den Kisten nicht gebootet, MSDOS.SYS und
COMMAND.COM waren aber zum normalen DOS identisch.
Ach ja, CP/M hat ja auch jedes Jahr neue Releases auf den Markt
geworfen. Ein CP/M 3.0 wirst du auch nicht mit dem BIOS von 2.2
gebootet bekommen.
> Nachladbare Devicedriver haben erst mit der 3er DOS Version andere
> als die von Microsoft anvisierten Datentraeger akzeptiert.
Was sollen denn "von Microsoft anvisierte Datenträger" sein?
> > Ein anderes Beispiel ist das Dateisystem. FAT mag ja heute schäbig
> > und überholt sein, damals war das ein Fortschritt.
>
> FAT war die schlimmste Kathastrophe. Bei CP/M war es kein Untergang,
> wenn beim Schreiben etwas schief ging. Bei DOS mussten wir mehrmals
> taeglich chkdsk laufen lassen und haben jedesmal Daten verloren.
Keine Ahnung, was ihr gemacht habt, aber das kann ich nicht
nachvollziehen. Ich kann mich aber noch an lustige (damals ziemlich
ärgerliche) Probleme mit dem unflexiblen Disketten-Handling von CP/M
erinnern.
> > > DOS 2... und folgende, Unix abgekupfert aber nicht hingekriegt.
> >
> > Wie schon gesagt, niemand behauptet, dass MS-DOS ein exakter Klon
> > werden sollte. Dazu waren alleine schon die PCs damals noch nicht
> > leistungsfähig genug.
>
> Seit dem gab es zwei getrennte Interfaces, fuer ein und die selbe
> Funktion, entweder nach CP/M oder nach Unix Standart.
Genauer: es gab ein Interface nach "Unix Standart" und ein Interface
für File-I/O, eins für den Bildschirm, eins für Drucker, ... Merkst
du was? Das war eine sinnvolle Renovierung des "CP/M Standarts".
> > > Was ist Windos?
> > >
> > > Eine Sammlung von Rootkits, die sich um einen kaputten Unix-Kernel
> > > streiten.
> >
> > Für solchen Mist bekommst du zu Recht eine negative Bewertung.
>
> Es war ein Sammelsurium verschiedener Systemschnittstellen, meist
> Interrupts, die von unbekannten Programmen, sowohl aus dem Hause
> Microsoft, als auch von Fremden, verbogen und in unbekannte
> "Rootkits" entfuehrt wurden. Novell Netware und der IBM LanManager
> waren sollche Entfuehrer, oder auch 386 to the Max, Speichermanager.
Die Hälfte dieser Interrupts sind Altlasten von CP/M (INT20 z.B.),
insofern finde ich das API von MS-DOS ganz überschaubar. Und dass
Programme diese Interrupts verbogen haben, um zusätzliche
Funktionalität zu erweitert, ist wohl die einzige Möglichkeit, so ein
System aufzubohren. Und ich hoffe, du willst nicht behaupten, dass es
unter CP/M Hooks für alle möglichen und unmöglichen
Erweiterungswünsche gegeben hat?