ARM-Macs: Was bedeutet die Umstellung für Entwickler und was sind die Schwierigkeiten?

Schon Anfang 2018 kamen erste, ernstzunehmende Informationen zu einer größeren Umstellung beim Mac ans Tageslicht: Den Berichten nach wird sich Apple von Intel als Chiplieferant verabschieden und zukünftig auf die hauseigenen, ARM-basierenden A-Chips setzen. Statt dem x86-Befehlsschatz werden dann ARM-Kommandos ausgeführt. Dies wäre die vierte, große Umstellung beim Mac. Noch hat Apple nicht offiziell bekanntgegeben, dass ein solcher Wechsel stattfinden wird – doch die Anzahl der unabhängigen Berichte lässt darauf schließen, dass an den Gerüchten etwas dran ist.


1994: 68k zum PowerPC
1994 wechselte Apple zum allerersten Mal die Prozessorarchitektur des Macs aus. Statt Motorola-68k-Chips sollte der neue, zusammen mit IBM und Motorola entwickelte PowerPC-Prozessor den Vorsprung von Intel verkleinern. Die Umstellung lief von der Software-Seite her alles andere als glatt: Apple konnte noch nicht einmal ausgereifte Entwicklerwerkzeuge liefern, mit denen sich PowerPC-Programme erzeugen ließen. Glücklicherweise war Metrowerks damals mit einer angepassten Version der Programmierumgebung "CodeWarrior" rechtzeitig auf dem Markt, so dass Entwickler ihre Apps portieren konnten – doch dies war ein langwieriger Prozess, da einige Bestandteile der Software umgeschrieben werden mussten.

2001: Mac OS zu Mac OS X
Die nächste, große Umstellung beim Mac fand 2001 statt: Das betagte, klassische Mac OS wurde durch das auf NeXTSTEP basierende Betriebssystem Mac OS X beerbt. Der komplette Unterbau, die grafische Benutzeroberfläche und auch die präferierte Programmiersprache waren im Vergleich zum klassischen Mac OS unterschiedlich. Apple lieferte zwei Technologien, mit denen die Umstellung für Kunden und Entwickler einfacher wurde: Mittels der "Blue Box" (später Classic-Umgebung getauft) war es möglich, Mac OS als Programm unter Mac OS X auszuführen und darin ältere Programme zu starten – ähnlich einer Virtualisierungsumgebung. Von Spielen einmal abgesehen war die Kompatibilität recht gut. Doch Apple bildete auch einen Teil der klassischen Mac-OS-Programmierbibliotheken in Form von "Carbon" unter Mac OS X nach, so dass bestehende Software mit mittelgroßen Anpassungen nativ unter Mac OS X ausgeführt werden konnte. Diese Umstellung dauerte lange – viele Entwickler scheuten die Kosten einer teuren Anpassung oder gar Neuentwicklung und verwiesen Kunden auf die Classic-Umgebung. Ein besonders in Erinnerung gebliebenes Beispiel ist hier Quark: Die DTP-Software war erst viele Jahre später nativ auf dem Mac lauffähig. Erst lange Zeit später konnte Apple mit Mac OS X Leopard die Classic-Umgebung entfernen, weil genug native Apps verfügbar waren.


2006: PowerPC zu Intel
Die dritte Umstellung betraf wieder den Prozessor: Die PowerPC-Prozessoren entwickelten sich nicht wie erhofft – und Intel zog bezüglich der Performance wieder deutlich davon. Apple kündigte im Sommer 2005 an, statt PowerPC-Chips ab sofort auf x86-Intel-Prozessoren zu setzen. Eigentlich wollte man den Entwicklern ein Jahr Zeit für die Umstellung geben – doch Apple war zu dieser Zeit noch stark abhängig vom Umsatz der Mac-Sparte. Daher zog man die Einführung der ersten Geräte vor und bereits Anfang 2006 kam das MacBook Pro und der iMac mit Intel-Chip auf den Markt. Die Qualität des Rosetta-Emulators, welcher PowerPC-Apps auf Intel-Prozessoren ausführen konnte, war hoch – zwar liefen die Programme etwas langsamer, aber Kompatibilitätsprobleme gab es kaum. Da viele Entwickler kaum Code-Änderungen für das Erstellen von Intel-Anwendungen durchführen mussten, war die Umstellung recht schnell abgeschlossen: Bereits 2009 war Rosetta nicht mehr Teil der standardmäßigen Mac-OS-Installation.

2020: Wechsel von Intel zu eigenen ARM-Prozessoren?
15 Jahre nach Ankündigung des Intel-Umstiegs könnte Apple auf der diesjährigen Worldwide Developers Conference die Bombe platzen lassen und den Einsatz von eigenen Apple-A-Chips im Mac ankündigen. Doch wie glatt wird der ARM-Umstieg im Vergleich zu den drei anderen Umstellungen ablaufen?


Weichen bereits gestellt
Apple hat bereits angefangen, die Weichen zu stellen: Mit macOS Catalina hat Apple 32-Bit-Programme beerdigt – Entwickler mussten manche Apps umschreiben, da in der 64-Bit-Umgebung einige wenige Programmierbibliotheken fehlen. Doch die allermeisten Nutzer haben von dem Wegfall der 32-Bit-Unterstützung kaum etwas mitbekommen – seit weit über 10 Jahren bieten Apple volle 64-Bit-Unterstütztung an, so dass Entwickler hier genug Zeit hatten, notwendige Anpassungen vorzunehmen. Apple hatte hier aber wohl einen Hintergedanken: Man wollte wohl Entwickler frühzeitig dazu zwingen, auf die modernen Programmierbibliotheken umzusteigen.

2018 kündigte Apple an, dass die Tage von OpenGL auf dem Mac gezählt sind – Entwickler sollen zukünftig auf Apple Metal setzen, um die Grafikleistung von GPUs zu nutzen. Auch hier wird der ARM-Umstieg eine Rolle spielen: Apples A-Chips werden höchstwahrscheinlich viele Funktionen nicht unterstützten, welche sich über die Dekaden in OpenGL angesammelt haben – daher will man auch hier frühzeitig Entwickler dazu zwingen, Metal einzusetzen. Womöglich steht OpenGL nicht oder nur mittels Emulation auf ARM-Macs zur Verfügung.


Sollten sich die Gerüchte bewahrheiten und Apple tatsächlich bereits Ende 2020 erste Macs mit A-Chips ausliefern, könnten viele Programme noch nicht umgestellt sein. Bei modernen Programmen, welche weder über Assembler-Code verfügen noch auf OpenGL oder andere, ältere Programmierbibliotheken setzen, dürfte der Aufwand für Entwickler sehr moderat sein: In vielen Fällen wird eine erneute Kompilierung des Programmes ausreichend sein.

Setzt die App allerdings noch OpenGL ein und bietet Apple auf ARM-Macs keine Emulation der OpenGL-Bibliothek an, wird die Umstellung schwerer: Der gesamte Zeichen-Code muss neu entwickelt werden, da sich Metal in der Herangehensweise deutlich von OpenGL unterscheidet.

Wie viele native Apps wird es geben?
Sollte Apple auf der WWDC 2020 im Sommer ARM-Macs ankündigen, hätten Entwickler etwa 6 Monate Zeit, die notwendigen Anpassungen vorzunehmen. Da viele Apps durch eine erneute Kompilierung angepasst werden können, dürfte es bereits zum Start der ARM-Macs eine Fülle von nativen Programmen geben. Wie lange jedoch größere Hersteller wie Adobe sich für die Umstellung Zeit lassen, steht in den Sternen. Die Vergangenheit hat gezeigt, dass meist größere Hersteller träger in der Anpassung der eigenen Programme sind als kleinere Software-Schmieden.

Portierte Windows-Software
Manche Windows-Programme fanden mit Tools wie CrossOver von CodeWeavers ihren Weg auf den Mac. Hier handelt es sich eigentlich noch um Windows-Software, welche aber in einer speziellen Umgebung laufen, die Windows-Kommandos auf den Mac "übersetzt". Die Programme führen native Programmierbefehle aus, aber Kommandos wie "Zeige ein Fenster an" werden von Windows-Kommandos auf Mac-Befehle weitergeleitet. Schon bei der Umstellung von 32 auf 64 Bit schluderte CodeWeavers – erst 6 Monate nach der Ankündigung von Catalina und über 10 Jahre nach der Einführung einer 64-Bit-Umgebung auf den Mac steht eine Beta bereit. Daher ist damit zu rechnen, dass solch portierten Programme nicht oder nur per Emulation auf ARM-Macs funktionieren.

Virtualisierungslösungen
Die Intel-Macs brachten Nutzern neue Möglichkeiten: So ist es auf modernen Macs möglich, Windows parallel zu macOS in einer Virtualisierungslösung zu betreiben. Zwar hinken diese Programme in der Performance einem nativ ausgeführten Windows hinterher – für viele Aufgaben ist die Geschwindigkeit aber vollständig ausreichend, zumal parallel mit macOS und Windows gearbeitet werden kann. Noch ist es zu früh, um zu erkennen, wie Apple den Nutzerkreis zufriedenstellen wird, welche auf Virtualisierungslösungen angewiesen ist – und somit ist es auch kaum abzuschätzen, wann und ob überhaupt angepasste Lösungen auf den Markt kommen.

Kommentare

Mendel Kucharzeck
Mendel Kucharzeck13.03.20 08:49
Erinnert sich einer der Entwickler hier noch an CodeWarrior? Ich fand die Umgebung damals klasse, war so schön direkt und schnell. Auch die CD-Cover von Metrowerks waren schön anzusehen
+7
macfreakz13.03.20 09:00
Aber sehr sehr teuer, ich früher als Schüler war so traurig, dass ich es mir nicht leisten konnte. Habe dann mit Apple Script usw. angefangen.
0
Mendel Kucharzeck
Mendel Kucharzeck13.03.20 09:02
macfreakz
Die hatten doch Schüler-Versionen – die hatte ich früher. Das war nicht sonderlich teuer.
+1
macfreakz13.03.20 09:06
Wirklich? Dann war ich wohl falsch informiert. aber nicht dramatisch, alle Wege führen nach Rom
0
Mendel Kucharzeck
Mendel Kucharzeck13.03.20 09:07
macfreakz
Wenn ich mich ganz richtig erinnere, waren das rund 150 Mark.
+1
sonnendeck13.03.20 09:31
150 DM wäre als Schüler 2 mal Weihnachten und Geburtstag gewesen also unerreichbar

zum Topic: da scheint eh ein grosser Umbruch stattzufinden und das X86 Design wohl ein schleichendes Ende.

https://www.anandtech.com/show/15578/cloud-clash-amazon-grav iton2-arm-against-intel-and-amd

Endlich mal wieder spannende Zeiten
+4
misc13.03.20 09:53
Die Puzzleteile aus den vergangenen Jahren scheinen ja ganz gut zusammenzupassen. Ich würde aber einen Umstieg auf AMD-Prozessoren noch nicht ganz ausschließen.
0
sonnendeck13.03.20 10:00
misc13.03.20 09:53
Die Puzzleteile aus den vergangenen Jahren scheinen ja ganz gut zusammenzupassen. Ich würde aber einen Umstieg auf AMD-Prozessoren noch nicht ganz ausschließen.

Könnte aber ganz anders kommen als man bis jetzt dachte und Apple AMD dafür nutzen würde ARM Prozessoren und passende Mainboards, Grafikkarten Einheiten zu produzieren, da sie kleinere Strukturbreiten kann im Gegensatz zu Intel
-1
piik
piik13.03.20 10:02
Ich bin mal gespannt. Wenn die Auguren wieder mal voll daneben liegen, bin ich gespannt, wie sie sich rauswinden.
+3
gfhfkgfhfk13.03.20 10:03
Ein paar Anmerkungen
  • Die Entwicklungsumgebung für 68k und PowerPC Software war Apples MPW mit dem Framework MacApp. Insbesondere MacApp war in die Jahre gekommen. MPW selbst war zwar nicht mit einer aktuellen IDE wie dem Codewarrior vergleichbar, aber durchaus tauglich für die Entwicklung von PowerPC Programmen. Codewarrior war eben nicht nur eine IDE sondern brachte ein eigenes Framework für die Entwicklung von Mac Programmen mit PowerPlant. Dieses Framawork war die große Stärke von Codewarrior. Borlands C++ Umgebung für 68k kam ebenfalls mit einem eigenem Framework (TCL). Das wurde nie auf PowerPC portiert. Die Konsequenz war der Tot etlicher 68k Programme.
  • PowerPCs waren am Anfang deutlich schneller als Intel CPUs, aber Apple hat das nicht nutzen können, weil ein Großteil des Mac Systems immer noch 68k Code war und in Emulation lief.
  • Programme für das klassische MacOS ließen sich mit vertretbaren Aufwand auf Carbon portieren, das betraf sowohl MacApp wie PowerPlant Programme. Nur Programme auf Cocoa zu portieren bedeutete sie de facto neu zu entwickeln, da es von Apple weder einen Pfand von MacApp oder PowerPlant zu Cocoa gab. Der Programmcode war damit wertlos.
+4
Mendel Kucharzeck
Mendel Kucharzeck13.03.20 10:14
gfhfkgfhfk
1) MPW war, als die PowerPCs vorgestellt wurden, eigentlich nicht einsetzbar. Es gab quasi keinen Debugger und sogar der Compiler war fehlerhaft
2) Du hast recht, es gab eine Phase, da waren die PowerPCs durchaus konkurrenzfähig – nur das war bald auch wieder andersherum
3) Carbon: Das hängt SEHR vom Programm ab. Manche Apps waren mit sehr wenig Aufwand zu portieren, aber das Carbon-Framework hat sich auch vielen Altlasten entledigt – dann war mehr aufwand möglich
0
wolfgag
wolfgag13.03.20 10:35
Weiss nicht ob ich mir das nochmal antun möchte. Die bisherigen Umstiege waren allesamt holprig und teuer und in meinem beruflichen Umfeld hat Apple leider eh schon lange den Anschluss verloren - da überlegt man es sich schon zweimal, einen Haufen Geld auszugeben, nur um auf einer ohnehin benachteiligten Plattform zu bleiben.

Hoffe ich muss auf meine alten Tage nicht doch noch auf Windows umsteigen.
+4
LoCal
LoCal13.03.20 10:38
Mendel Kucharzeck
Erinnert sich einer der Entwickler hier noch an CodeWarrior? Ich fand die Umgebung damals klasse, war so schön direkt und schnell. Auch die CD-Cover von Metrowerks waren schön anzusehen

Meinen ersten Kontakt mit CW hatte ich unter BeOS, das war es die mitgelieferte Standard IDE.
Jahre später, in meinem ersten kommerziellen OS X-Projekt hatte ich dann wieder Kontakt mit CodeWarrior. Die eigentliche App hab ich zwar mit ProjectBuilder (der Vorgänger von Xcode, dem ich, wenn es um UI geht, ab und an nachweine) gemacht. Aber für ein Plugin für Quark musste ich CodeWarrior nutzen.
Das ganze war eine sehr spannende Zeit für mich …
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+1
gacki13.03.20 11:13
gfhfkgfhfk
Ein paar Anmerkungen
  • Die Entwicklungsumgebung für 68k und PowerPC Software war Apples MPW mit dem Framework MacApp.

Bei 68k war später Symantec Think C sehr weit verbreitet. Gefühlt wurde das jedenfalls öfter eingesetzt als MPW. Ich hatte seinerzeit eine Migration eines Projektes von Think C nach CodeWarrior mitgemacht.
+1
Mendel Kucharzeck
Mendel Kucharzeck13.03.20 11:15
gacki
MPW war aber auch der letzte Mist. Instabil, schwer zu verstehen und der Debugger war schon auf 68k-Macs einfach nur ärgerlich.
0
germansnowman13.03.20 11:18
Mendel Kucharzeck
Erinnert sich einer der Entwickler hier noch an CodeWarrior? Ich fand die Umgebung damals klasse, war so schön direkt und schnell. Auch die CD-Cover von Metrowerks waren schön anzusehen

Ich hatte es mir irgendwann Mitte der 90er mal gekauft, ich war aber mit meinen Programmierkenntnissen noch nicht so weit, daß ich es wirklich nutzen konnte. Ich denke, das wäre anders gelaufen, wenn es das Internet in seiner heutigen Form (vor allem mit den Inhalten) damals gegeben hätte. (Ich bin in einer sehr kleinen Stadt auf dem Land aufgewachsen, da gab es niemand, den ich sonst hätte fragen können.)
+1
germansnowman13.03.20 11:22
gfhfkgfhfk
Ein paar Anmerkungen
  • PowerPCs waren am Anfang deutlich schneller als Intel CPUs, aber Apple hat das nicht nutzen können, weil ein Großteil des Mac Systems immer noch 68k Code war und in Emulation lief.

Ich meine mich erinnern zu können, daß das Thema »Performance per Watt« zentral war. Bei den Power Macs konnte man noch einiges mit komplizierten Lüftern machen, aber die PowerBooks konnten wegen der Hitze schon den PowerPC G5 nicht mehr bekommen. Das war dann der Punkt, an dem auf Intel umgestellt wurde.
+1
LoCal
LoCal13.03.20 11:46
germansnowman
gfhfkgfhfk
Ein paar Anmerkungen
  • PowerPCs waren am Anfang deutlich schneller als Intel CPUs, aber Apple hat das nicht nutzen können, weil ein Großteil des Mac Systems immer noch 68k Code war und in Emulation lief.

Ich meine mich erinnern zu können, daß das Thema »Performance per Watt« zentral war. Bei den Power Macs konnte man noch einiges mit komplizierten Lüftern machen, aber die PowerBooks konnten wegen der Hitze schon den PowerPC G5 nicht mehr bekommen. Das war dann der Punkt, an dem auf Intel umgestellt wurde.

IBM hat Apple wohl zu lange mit neuen Prozessoren hingehalten. Am Ende musste ja enorme Anstrengungen unternommen werden, um überhaupt eine Leistungssteigerung (hier nichts anderes als Erhöhung des Taktes) zu erreichen. Apple hat eine sehr aufwendige Wasserkühlung verbaut, die ihnen trotzdem nach ein paar Jahren auf die Füsse lief.
Einen G5 für den mobilen Einsatz hat IBM nie geliefert und wahrscheinlich nie liefern wollen.
IBM hatte wahrscheinlich auch überhaupt keine Lust mehr, denn die CELL-Plattform versprach IBM mehr Geld und Ruhm. Allerdings war CELL dann nicht der Heilsbringer den sich viele davon versprachen. Sony und Microsoft wendeten sich mit ihren Konsolen in der nächsten Version auch wieder davon ab.

Es wurde auch gerüchtet, dass Apple auf CELL umsteigt, letztendlich ging man zu intel, was zum damaligen Zeitpunkt die beste Wahl gewesen sein dürfte.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+1
gfhfkgfhfk13.03.20 12:01
Mendel Kucharzeck
gfhfkgfhfk
1) MPW war, als die PowerPCs vorgestellt wurden, eigentlich nicht einsetzbar. Es gab quasi keinen Debugger und sogar der Compiler war fehlerhaft
Ohje Debugging auf dem klassischen MacOS – ein leidvolles Thema. Ich hatte meinen ersten Kontakt mit PowerPCs in Form von IBMs RS/6000 Model 7011-250, mit der kompletten IBM Compiler Suite. Ich hatte dann auf meinem PowerMac 6100 MkLinux laufen lassen, das war zum C Programieren deutlich besser. Da musste man nicht jedesmal rebooten, wenn ein Programm Unsinn machte.
Mendel Kucharzeck
2) Du hast recht, es gab eine Phase, da waren die PowerPCs durchaus konkurrenzfähig – nur das war bald auch wieder andersherum
Das Hauptproblem war Apples Kurzsichtigkeit und die Unfähigkeit gute Computer zu entwickeln. Während IBM bei der RS/6000 250 das komplette System um den PowerPC herum baute, und nur für die legacy Schnittstelle eine virtuelle ISA Karte nutzte, war es bei Apple andersherum. Da wurde CPU, RAM und PDS Slot an ein 68k Design rangefrickelt, so dass die IBM Maschine mit dem gleichen Prozessor deutlich schneller war.
germansnowman
Ich meine mich erinnern zu können, daß das Thema »Performance per Watt« zentral war. Bei den Power Macs konnte man noch einiges mit komplizierten Lüftern machen, aber die PowerBooks konnten wegen der Hitze schon den PowerPC G5 nicht mehr bekommen. Das war dann der Punkt, an dem auf Intel umgestellt wurde.
Das wurde damals von Jobs so behauptet, nachdem er die Entwicklung der PowerPCs zusammen mit Motorola in den Sand gesetzt hatte. Der G5 war ja nicht der G5 wie er sein sollte (der wurde zusammen mit Motorola entwickelt), sondern wurde von IBM in einer Nacht- und Nebelaktion aus dem POWER4 entwickelt. Der POWER4 war ein Prozessor explizit für IBMs BigIrons entwickelt (extrem hohe Performance/Watt Leistung nur auch hohe Stromaufnahme) und so wurde IBMs G5 in den drei Iterationen immer mehr auf Stromsparen optimiert, nur verlor Jobs die Geduld und wollte alle Risiken auf IBM abwälzen. Davon war BigBlue nicht angetan.
+2
Dubidu13.03.20 14:51
Mal im Ernst, as glaube ich erst, wenn es offiziell von Apple verkündet wird. Der Mac hat ganz andere Baustellen als den Prozessor. Außerdem besteht hinsichtlich Performance keinerlei Druck bedingt durch die momentane CPU-Familie, da die Konkurrenz auf die gleichen CPUs setzt. Ein Mix aus AMD und Intel, das wäre angebracht, einfach immer die passendste aktuelle x86 CPU verwenden und niemand beschwert sich.
-1
Marcel_75@work
Marcel_75@work13.03.20 15:03
Ich habe da aber auch eine etwas andere Sichtweise in Erinnerung:

Apple (wahrscheinlich ausschließlich der Sturkopf Steve Jobs) weigerte sich, IBM bei der Entwicklung eines Laptop-geeigneten G5 finanziell zu unterstützen. Das war dann der Grund, warum es keinen Laptop-geeigneten G5 von IBM gab.
0
Michael Lang13.03.20 17:49
Noch hat Apple nicht offiziell bekanntgegeben, dass ein solcher Wechsel stattfinden wird – doch die Anzahl der unabhängigen Berichte lässt darauf schließen, dass an den Gerüchten etwas dran ist.

Natürlich gibt es viele Berichte (Gerüchte!) und letztendlich wird es wohl irgendwann auch so kommen.
ABER...nur weil ein Gerücht(!) oft wiederholt wird, wird es nicht richtiger.

Ich persönlich glaube, dass Apple diesen Schritt wohl gehen wird, aber der Zeitpunkt wird nicht 2020 sein, ich glaube noch nicht mal 2021. So etwas braucht Zeit und es wird konkretere Vorboten und auch Ankündigungen geben.

Gruß
Michael
- Das größte Maul und das kleinste Hirn,wohnen meist unter derselben Stirn. - Hermann Oscar Arno Alfred Holz, (1863 - 1929), deutscher Schriftsteller
0
LoCal
LoCal13.03.20 18:24
Michael Lang
ABER...nur weil ein Gerücht(!) oft wiederholt wird, wird es nicht richtiger.
Ceterum censeo Carthaginem esse delendam
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+1
MikeMuc13.03.20 18:25
Mendel Kucharzeck
Erinnert sich einer der Entwickler hier noch an CodeWarrior?
Ja, damit programmiere ich noch heute in einer VM Extras für das tote Freehand
+1
koehler13.03.20 18:31
MikeMuc
Mendel Kucharzeck
Erinnert sich einer der Entwickler hier noch an CodeWarrior?
Ja, damit programmiere ich noch heute in einer VM Extras für das tote Freehand


Das klingt interessant. Ich habe Freehand geliebt!
Erzähl doch bitte mehr davon!!!
0
MikeMuc13.03.20 18:38
was willst du genau wissen?
Freehand und der alte CodeWarrior teilen sich eine VM von VM-Ware.
Als Kartograph sind meine sämtlichen Kartenbestände und die aller meiner Kunden in FH entstanden, die ältesten Karten dürften mit FH 2 und 3 gestartet sein. FH ist heute noch an vielen Stellen besser als Illustrator, auch wenn der viel moderner ist und man an so mancher Stelle über FH flucht. Aber die Bearbeitung in FH ist halt deutlich schneller als in Illustrator.
Und was die Extras betrifft: Sind nahezu alles Spezialanwendungen für die Kartographen in meinem Umfeld bzw Werkzeuge für mich
+1
gfhfkgfhfk13.03.20 19:33
gacki
Bei 68k war später Symantec Think C sehr weit verbreitet.
Sorry, Symantec Think C/C++ meinte ich auch. Irgend wie habe ich das mit Borland durcheinander gewürfelt. Es gab damals zu viele C Compiler.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.