Ab Version 3.11 gab's dann erstmalig Netzwerkunterstützung
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.
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
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:
Wie sieht das in Assembler aus?Code:int main (int argc, char **argv) { char *szString = "ABCDEFGHILKLMNOP"; char cChar; cChar = szString [5]; printf ("%c\n", cChar); return 0; }
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).Code: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
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.
Geändert von Rheinlaender (16.10.2007 um 05:41 Uhr)
Radikal Liberale Partei - Die Vernuenftigen
Unser Konzept zur Krankenversorgung und zur
Rentenreform
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
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)