ENDE von Windows XP naht !

[ochmensch]

Ich hatte zum Glück nie ME oder 2000, ich bin von 3.1 auf 98 auf XP umgestiegen.
ME, pah!!

Ich hätte richtig Lust mir einen alten PC zu besorgen, mit DOS 6.2 und Win 3.1.
Das wusste man wenigstens noch warum das eigentlich "Windows" heisst. :]

[bernhard44]

Ich hätte richtig Lust mir einen alten PC zu besorgen, mit DOS 6.2 und Win 3.1.
Das wusste man wenigstens noch warum das eigentlich "Windows" heisst. :]

weil du ihn aus dem Fenster wirfst.......................?

[ochmensch]

weil du ihn aus dem Fenster wirfst.......................?

So ähnlich. Für speicherintensive Anwendungen war´s jedenfalls nicht zu gebrauchen. Aber das war die ganze DOSe nicht.

[John Donne]

Ab Version 3.11 gab's dann erstmalig Netzwerkunterstützung

Grüße
John

[GnomInc]

Eine

Traditionell werden Anwendungen und das Nutzungsverhalten von Anwendern jedoch immer speicherhungriger. Die Auguren, die einst prophezeiten, daß 640 KB für alle und immer ausreichen würden, werden heute zurecht belächelt. Die Phase, in der sich der Benutzer mehr als 3 bis 4 GB wünscht, können realistisch durchaus in die Zeitspanne bis 2014 fallen, in denen für Win XP Prof. noch Updates bereitgestellt werden.
Und ja, Proteinfaltung betreibt mein Rechner bei Folding@home auch, stimmt

Grüße
John

Die Anwendungen werden auch durch die Programmierstile immer speicherhungriger.
Ich glaube nicht , das noch maschinennah programmiert wird.
Spiele , die 6 MB Platz brauchen können nur aufgeblähte Scripts haben.
Und das so schnell als möglich neue Anwendungen auf den Markt geworfen
werden - das ist Geldgier und nicht Nutzen für den Anwender.
Irgendwelche Features dazugepackt und in der Werbung noch das
" Blaue " vom Himmel dazugeschwafelt - so läufts.
Was soll ich mit Vista und Direct X 10 ?
Fortschritt ist hier erlogen und erstunken.

[harlekina]

Ab Version 3.11 gab's dann erstmalig Netzwerkunterstützung

Grüße
John

Wenn man ein Netzwerk besaß.

[John Donne]

Die Anwendungen werden auch durch die Programmierstile immer speicherhungriger.
Ich glaube nicht , das noch maschinennah programmiert wird.
Spiele , die 6 MB Platz brauchen können nur aufgeblähte Scripts haben.
Und das so schnell als möglich neue Anwendungen auf den Markt geworfen
werden - das ist Geldgier und nicht Nutzen für den Anwender.
Irgendwelche Features dazugepackt und in der Werbung noch das
" Blaue " vom Himmel dazugeschwafelt - so läufts.
Was soll ich mit Vista und Direct X 10 ?
Fortschritt ist hier erlogen und erstunken.

Es ist durchaus richtig, daß heutzutage anders - und nicht immer nur besser - programmiert wird, zumindest definitv nicht in Bezug auf Speicherverbrauch. Maschinennahe Programmierung ist auf dem PC für die meisten Probleme eher "out" - und das zurecht: Große Softwareprojekte lassen sich bei maschinennaher Programmierung kaum durchführen - abgesehen davon, daß Portabilität so nur sehr schwer errreicht werden kann. Die Vielzahl an Hardwarekonfigurationen ist immer überschaubarer, ohne einigermaßen stark von der Hardware an sich zu abstrahieren wird ein Programm heute nur auf wenigen Maschinen laufen. Nichtzuletzt basiert die Stabilität heutiger Betriebssysteme zu erheblichen Teilen auf dieser Abstraktion von der Hardware. So läßt es kein modernes PC-Betriebssystem zu, daß direkt in den Speicher geschrieben wird. Alle Operationen unterliegen einem vergleichsweise zeit- und ressourcenintensiven Mapping.
Gerade was Spiele angeht, läßt sich die Entwicklung sehr gut beobachten: Wurden Ende der 80er Spiele noch in sehr kleinen Teams oder auch mal allein entwickelt, stehen die heutigen Produktionen großen Hollywood-Blockbustern im Aufwand an Zeit, Geld und Arbeitsintensität kaum nach. In 6 MB lassen sich allenfalls das Titel-MP3 oder einige wenige kleinere Texturen unterbringen...
Wofür Industrial Light & Magic für "Terminator 2" noch einen Oskar bekam und etliche Millionen in die Miete von Super-Großrechnern investierte, leistet heute jede gängige Workstation. Ich sehe aufgeblähte Anwendungen (wer nutzt tatsächlich die Fülle der Features von Officeanwendungen?) durchaus kritisch. Ich würde auch definitiv niemandem raten, momentan auf Vista und DirectX umzusteigen. Daß die heutigen PCs jedoch wesentlich komfortabler, ergonomischer und leistungsfähiger sind als frühere Generationen, wird niemand wirklich bestreiten können. Ich zumindest sitze deutlich lieber vor meinem momentanen, leisen Rechner mit Großbild-TFT als vor einem Pentium I mit 14"-Goldfischglasröhrenmonitor.

Grüße
John

[Rheinlaender]

Es ist durchaus richtig, daß heutzutage anders - und nicht immer nur besser - programmiert wird, zumindest definitv nicht in Bezug auf Speicherverbrauch. Maschinennahe Programmierung ist auf dem PC für die meisten Probleme eher "out" - und das zurecht: Große Softwareprojekte lassen sich bei maschinennaher Programmierung kaum durchführen - abgesehen davon, daß Portabilität so nur sehr schwer errreicht werden kann.

Du wirsft ein paar Sachen durcheinander: Maschinencode und Machinennahe Programmierung. Eine Hochsprache wie C ist Maschinennah. D. h C wird ziemlich eins-zu-eins in Maschinencode umgesetzt. Mal ein einfaches Beispiel - ein primitives C-Program:

int main (int  argc, char **argv)
{

   char         *szString = "ABCDEFGHILKLMNOP";
   char          cChar;

   cChar = szString [5];

   printf ("%c\n", cChar);

   return 0;

}

Wie sieht das in Assembler aus?

0804846c <main>:
 804846c:       55                      push   %ebp
 804846d:       89 e5                   mov    %esp,%ebp
 804846f:       83 ec 08                sub    $0x8,%esp
 8048472:       83 e4 f0                and    $0xfffffff0,%esp
 8048475:       b8 00 00 00 00          mov    $0x0,%eax
 804847a:       29 c4                   sub    %eax,%esp
 804847c:       c7 45 fc c8 85 04 08    movl   $0x80485c8,0xfffffffc(%ebp)
 8048483:       8b 45 fc                mov    0xfffffffc(%ebp),%eax
 8048486:       83 c0 05                add    $0x5,%eax
 8048489:       8a 00                   mov    (%eax),%al
 804848b:       88 45 fb                mov    %al,0xfffffffb(%ebp)
 804848e:       83 ec 08                sub    $0x8,%esp
 8048491:       0f be 45 fb             movsbl 0xfffffffb(%ebp),%eax
 8048495:       50                      push   %eax
 8048496:       68 d9 85 04 08          push   $0x80485d9
 804849b:       e8 00 ff ff ff          call   80483a0 <_init+0x48>
 80484a0:       83 c4 10                add    $0x10,%esp
 80484a3:       b8 00 00 00 00          mov    $0x0,%eax
 80484a8:       c9                      leave
 80484a9:       c3                      ret

Du siehst schnell, dass der C-Code wirklich fast eins-zu-eins ungesetzt wurde. Wobei der call 80483a0 einen Zugriff auf diese Abstraktion darstellt. Hinter ih steht das printf. Ich brauche mich als Programmierer nicht mehr darum zu kuemmern, was dahinter passiert. Du kannst aber in C sehr umfangreiche Projecte schreiben (so besteht der Linux-Kerne; oder auch Gnome aus C-Code).

In Plattform-Crossreference wird definierte API geeben. Diese basieren z. B. auf Poxis-Standard, oder auf der glib und aehnichen API.

Nichtzuletzt basiert die Stabilität heutiger Betriebssysteme zu erheblichen Teilen auf dieser Abstraktion von der Hardware.

Das hat ueber weite Teile nichts mehr mit dem Betriebssystem zu tun. Die Graphikkarte z. B. wird ueber den X-Server angesprochen, diese gehoert aber nicht zum Betriebssystem, andererseit sind bestimmte Driver fuer Graphikkarte in den Kernel als Modul integriert (z. B. svga). Das hat aber nichts mit der Stabilitaet des Betriebsystem zu tun, sondern mit der Vereinheitlichung der Schnittstelle zur Hardware - und hier soll man die Rolle der Compilerbauer auch nicht unterschaetzen. Erst ihre arbeit ermoeglicht ueberhaupt eine solche Schittstelle.

[John Donne]

Du wirsft ein paar Sachen durcheinander: Maschinencode und Machinennahe Programmierung. Eine Hochsprache wie C ist Maschinennah. D. h C wird ziemlich eins-zu-eins in Maschinencode umgesetzt. Mal ein einfaches Beispiel - ein primitives C-Program:

int main (int  argc, char **argv)
{

   char         *szString = "ABCDEFGHILKLMNOP";
   char          cChar;

   cChar = szString [5];

   printf ("%c\n", cChar);

   return 0;

}

Wie sieht das in Assembler aus?

0804846c <main>:
 804846c:       55                      push   %ebp
 804846d:       89 e5                   mov    %esp,%ebp
 804846f:       83 ec 08                sub    $0x8,%esp
 8048472:       83 e4 f0                and    $0xfffffff0,%esp
 8048475:       b8 00 00 00 00          mov    $0x0,%eax
 804847a:       29 c4                   sub    %eax,%esp
 804847c:       c7 45 fc c8 85 04 08    movl   $0x80485c8,0xfffffffc(%ebp)
 8048483:       8b 45 fc                mov    0xfffffffc(%ebp),%eax
 8048486:       83 c0 05                add    $0x5,%eax
 8048489:       8a 00                   mov    (%eax),%al
 804848b:       88 45 fb                mov    %al,0xfffffffb(%ebp)
 804848e:       83 ec 08                sub    $0x8,%esp
 8048491:       0f be 45 fb             movsbl 0xfffffffb(%ebp),%eax
 8048495:       50                      push   %eax
 8048496:       68 d9 85 04 08          push   $0x80485d9
 804849b:       e8 00 ff ff ff          call   80483a0 <_init+0x48>
 80484a0:       83 c4 10                add    $0x10,%esp
 80484a3:       b8 00 00 00 00          mov    $0x0,%eax
 80484a8:       c9                      leave
 80484a9:       c3                      ret

Du siehst schnell, dass der C-Code wirklich fast eins-zu-eins ungesetzt wurde. Wobei der call 80483a0 einen Zugriff auf diese Abstraktion darstellt. Hinter ih steht das printf. Ich brauche mich als Programmierer nicht mehr darum zu kuemmern, was dahinter passiert. Du kannst aber in C sehr umfangreiche Projecte schreiben (so besteht der Linux-Kerne; oder auch Gnome aus C-Code).

In Plattform-Crossreference wird definierte API geeben. Diese basieren z. B. auf Poxis-Standard, oder auf der glib und aehnichen API.



Das hat ueber weite Teile nichts mehr mit dem Betriebssystem zu tun. Die Graphikkarte z. B. wird ueber den X-Server angesprochen, diese gehoert aber nicht zum Betriebssystem, andererseit sind bestimmte Driver fuer Graphikkarte in den Kernel als Modul integriert (z. B. svga). Das hat aber nichts mit der Stabilitaet des Betriebsystem zu tun, sondern mit der Vereinheitlichung der Schnittstelle zur Hardware - und hier soll man die Rolle der Compilerbauer auch nicht unterschaetzen. Erst ihre arbeit ermoeglicht ueberhaupt eine solche Schittstelle.

C gilt zwar offiziell als Hochsprache, das liegt jedoch vor allem daran, daß die Einteilung in Hochsprachen und low-level-Programmiersprachen sehr alt ist. Verglichen mit nacktem Maschinencode oder Assembler ist C in der Tat relativ hoch. Andererseits fehlen C diverse grundlegende Abstraktionsmechanismen, die sich in den letzten Jahrzehnten herausgebildet haben, und das Ziel, leicht wartbare, verständliche und wiederverwertbare Software (-> separation of concerns) zu schreiben, deutlich vereinfachen. Ich betrachte Objektorientierung, Genericity, Garbage Collection, Typklassen, die Überladbarkeit von Operatoren und typsichere Containerstrukturen keineswegs als Luxus, sondern als der Höhe der Zeit angemessen. Im Zweifel geben ich immer der abstrakteren, maschinenferneren, expressiveren Sprache den Vorzug, solange das Projekt es zuläßt.

Daß C-Code in sehr ähnlichem Assemblercode resultiert ist gewollt, schließlich war das eines der Designziele von C. Zweifellos kann man in C sehr umfangreiche Projekte schreiben. Das liegt m.E. aber sicher nicht daran, daß C aus softwaretechnischen Gründen so überragend für große Projekte geeignet wäre. Es liegt daran, daß C die verbreitetste Programmiersprache ist, in der man tatsächlich alles programmieren kann. (Ich rate davon ab, alles in C zu programmieren. Wenn der Hammer das einzige Werkzeug ist, neigt man dazu, alle Probleme als Nägel zu klassifizieren.) Das liegt nicht zuletzt an ihrer Hardwarenähe, die C mächtiger macht als die meisten anderen Sprachen. Es zeigt sich allerdings, daß sehr viele Programmierer der großen Verantwortung, welche die Mächtigkeit von C beispielsweise in Bezug auf Speicher mitbringt, nicht gewachsen sind, zumal diverse C-Standardfunktion (z.b. strcpy oder strcat) schlicht fehlerhaft arbeiten in dem Sinne, daß sie keine boundary checks durchführen. Die Folge zahlreicher fehlerhafter oder unsicherer Code (C-Programme sind gute Kandidaten für buffer-overflow- Attacken). Für Betriebssystemcode, Treiber oder hochperformanten Code ist C - auch bei großen Projekten - klar die Sprache der Wahl (die insgesamt sehr beschränkt ist), ich bevorzuge und empfehle für große Projekte aus softwaretechnischer Sicht jedoch andere - in jedem Fall objektorientierte - Sprachen.

Was die Stabilität angeht, hätte ich mich präziser ausdrücken können. Ich spielte insbesonder auf Win 9x an. Ein wesentlicher Punkt mangelnder Instabilität war (und für die Benutzer, die diese Betriebssysteme noch anwenden: ist) hier definitiv, daß diese Betriebssysteme nicht grundsätzlich direkte Hardwarezugriffe unterbinden. Das führte in großer Regelmäßigkeit dazu, daß im Falle eines Crashes dieser Prozesse die komplette Maschine mitgerissen wurde. Das ist mit XP deutlich besser geworden.

Grüße
John