Tortoise Git, Dateien und Icons

Finnegan

@wob sagte in Tortoise Git, Dateien und Icons:

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

Naja, du kannst den Commit-Hash ja in die .git-blame-ignore-revs schreiben. Sowas haben wir z.B. gemacht, wenn wir den Code-Formatter gewechselt haben und einen reinen Formatierungscommit hatten.

Und wenn der Commit nur versehentlich drin war UND du eine kleine Anzahl Entwickler hast, kannst du auch "einfach" den Commit wieder aus dem Repo löschen. Nicht dass ich ein großer Fan davon wäre, aber in diesem Fall kann das tatsächlich sinnvoll sein. Und dann überlegen, warum es kein Review gab bzw. warum das im Review nicht aufgefallen ist.

Nutzt ihr z.B. pre-commit? Da würde man doch normalerweise sowas checken können.

Nein, es hat ja nicht mal ein Commit stattgefunden. Das war nur ein Beispiel wie schnell sowas passieren kann, wenn man nicht aufpasst. core.autocrlf = true war zumindest damals noch ne Default-Einstellung von Git für Windows. Das wird eher dann zum Problem, wenn man Neulinge im Team hat, die sich z.B. nicht wundern, weshalb so viele Dateien bei den Änderungen aufgelistet sind.

Finnegan

@john-0 sagte in Tortoise Git, Dateien und Icons:

Ganz ehrlich GCC ist deutlich besser gealtert als Borlands/Embarcaderos Produkte.

Zu letzteren kann ich nicht viel sagen, aber GCC ist allerdings nur ein Compiler ohne IDE und Windows-Support hatte GCC selbst auch nie wirklich (das kam vom MinGW-Projekt). Aber sie haben die Kurve dennoch durchaus gut hinbekommen und dabei eine ganze Reihe alter unterstützter Architekturen erhalten. Im Quellcode sehe ich da immer noch Support für z.B. den M68k. Wäre mal ne Probe wert, wie gut sich Amiga-Programme in C++23 schreiben lassen. Ein Test vor Jahren mit einer entsprechend zusammengestellten Toolchain hat allerdings gemessen an z.B. der originalen A500-Hardware ganz schön große Executables erzeugt (Hallo Welt). Die C++-Standardbibliothek ist denke ich nicht unbedingt für sowas ausgelegt - vor allem iostreams.

Bei einem aktuellen (Retro-) Hobbyprojekt von mir habe ich ein ähnliches Problem. Da baue ich mit GCC 14 DOS-Programme (MZ-Executables) mit dem Original i386 ohne FPU als Zielarchitektur. Mit C-Code kommt "Hallo Welt" da auf wenige KiB. Und das, obwohl da noch eine malloc-Implementierung und Teile der libc mit drin stecken. Mit C++ gehts kaum unter 200 KiB - hauptsächlich für Exception Handling für das der Compiler trotz -fno-exceptions/-fno-rtti immer noch jede Menge Code emittiert. Sobald ich das "Hallo Welt" mit cout mache, explodiert die Executable dann auf etwa 1.3 MiB. Dass man nicht für das bezahlt, was man nicht nutzt, scheint jedenfalls nicht immer zu stimmen - theoretisch sollte man ja meinen, dass sich das je nach Implementierung zu einem simplen write(stdout, "Hallo, Welt!", 12); optimieren lassen müsste. Da landet aber wohl doch noch nen Haufen ungenutztes Zeug mit in der EXE.

Damn, jetzt schweif ich aber ganz schön ab. Genug OT

SeppJ

Ja, ist ganz schön schlecht, wenn die Zielplattform nicht dynamisch linken kann. Da bleibt die ja eigentlich nur, die Standardbibliothek raus zu werfen, und eine enorm abgespeckte C++-DOS-Library für einfaches IO zu suchen. Oder selber schreiben? DOS hat ja nur ein paar Handvoll Syscalls. Und damit sollte dann ja die volle Macht von C++ als Sprache verfügbar sein. Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

*john 0

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Zu letzteren kann ich nicht viel sagen, aber GCC ist allerdings nur ein Compiler ohne IDE und Windows-Support hatte GCC selbst auch nie wirklich (das kam vom MinGW-Projekt). Aber sie haben die Kurve dennoch durchaus gut hinbekommen und dabei eine ganze Reihe alter unterstützter Architekturen erhalten. Im Quellcode sehe ich da immer noch Support für z.B. den M68k. Wäre mal ne Probe wert, wie gut sich Amiga-Programme in C++23 schreiben lassen.

Wenn man eine Turbokarte oder eine Vampire (die gibt es mittlerweile mit 1GB RAM) mit halbwegs ausreichend RAM hat, könnte das gelingen. Mein alter Amiga müsste ich erstmal wieder betriebsfähig machen, wahrscheinlich sind die Elkos hinüber.

Ein Test vor Jahren mit einer entsprechend zusammengestellten Toolchain hat allerdings gemessen an z.B. der originalen A500-Hardware ganz schön große Executables erzeugt (Hallo Welt). Die C++-Standardbibliothek ist denke ich nicht unbedingt für sowas ausgelegt - vor allem iostreams.

Ich hatte mit dem cc65 Compiler für 6502 Plattformen herumgespielt "Hello World!" für C128 2,7kB und das war nur C89. Wenn man da an den VIC20 denkt. Der Emulator kann natürlich wunderbar viel RAM zur Verfügung stellen, weil

Dass man nicht für das bezahlt, was man nicht nutzt, scheint jedenfalls nicht immer zu stimmen - theoretisch sollte man ja meinen, dass sich das je nach Implementierung zu einem simplen write(stdout, "Hallo, Welt!", 12); optimieren lassen müsste.

Optimierende Linker scheinen nicht wirklich in Gebrauch zu sein. Templates, so toll sie auch sind, sind leider richtig übel was den Speicherverbrauch fürs Executable betrifft. Es gab da mal ein Versuch im GCC (RTO oder wie hieß das nochmal?) das zu optimieren, was aber in endlos langen Compile Orgien endete.

*john 0

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

Tja, es hat schon seine Gründe, weshalb man den Kontext beachten sollte (DOS API vs. Win16, Win32s, Win32 bzw. Win64 API oder UNIX 32Bit bzw. 64Bit API). Viele Jüngere sind sich einfach nicht bewusst, was für ein Murks es war früher Programme zu schreiben, bzw. weshalb die x86 Plattform so verabscheut wurde/wird.

Ich hatte nie einen DOS Rechner sondern einen Amiga und da kam Freunde bei den C Compilern auf, da Lattice/SAS C int als 32Bit und Aztec C als 16Bit definierte, d.h. ILP32 vs. LP32 bei zwei verschiedenen Compilern.

Tyrdal

@wob sagte in Tortoise Git, Dateien und Icons:

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

Naja, du kannst den Commit-Hash ja in die .git-blame-ignore-revs schreiben. Sowas haben wir z.B. gemacht, wenn wir den Code-Formatter gewechselt haben und einen reinen Formatierungscommit hatten.

Und wenn der Commit nur versehentlich drin war UND du eine kleine Anzahl Entwickler hast, kannst du auch "einfach" den Commit wieder aus dem Repo löschen. Nicht dass ich ein großer Fan davon wäre, aber in diesem Fall kann das tatsächlich sinnvoll sein. Und dann überlegen, warum es kein Review gab bzw. warum das im Review nicht aufgefallen ist.

Nutzt ihr z.B. pre-commit? Da würde man doch normalerweise sowas checken können.

Man könnte im diff auch einfach die whitespaces ignorieren lassen.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Ja, ist ganz schön schlecht, wenn die Zielplattform nicht dynamisch linken kann. Da bleibt die ja eigentlich nur, die Standardbibliothek raus zu werfen, und eine enorm abgespeckte C++-DOS-Library für einfaches IO zu suchen. Oder selber schreiben? DOS hat ja nur ein paar Handvoll Syscalls. Und damit sollte dann ja die volle Macht von C++ als Sprache verfügbar sein.

Ich verwende als C-Library picolibc und bei dieser werden auch nicht sonderlich viele Symbole mit in die Executable gelinkt, sofern man die Funktionen nicht nutzt. Wie gesagt, in C war "Hallo Welt" nur um die 30-40 KiB gross. Das war hauptsächlich die dlmalloc-basierte malloc-Implementierung von picolibc. picolibc macht für printf & Co bei der Initialisierung einen kleinen malloc-Aufruf (500 Bytes oder so). Ohne den könnte der malloc-Code wegfallen (tut er auch, wenn man printf nicht aufruft. Mit purem write(stdout, ...) schafft man auch unter 10 KiB.). Ich hab da noch einen in Assembler geschriebenen Loader-Code mit drin, der so gelinkt wird, dass er als erstes gestartet wird. Der detektiert den Speicher, wechselt in den 32-Bit Protected Mode, lädt mit DOS-Systemaufrufen das mit GCC kompilierte Hauptprogramm (damit dessen Größe nur durch den Speicher und nicht durch DOS-Funktionen limitiert wird) und implementiert von der libc benötigte OS-Aufrufe (open, close, read, write, sbrk, etc). Der Loader ist auch nochmal etwa 3 KiB.

Das ist alles soweit kein Problem. Gross wird es erst mit C++. Dann landen nämlich auch mit -fno-exceptions Exception-Handling-Tabellen in der EXE (.eh_frame_hdr und .eh_frame_entry.*-Sektionen im Linker). Die sind in Relation ziemlich groß und enthalten Daten zu jeder Menge Objekten und Funktionen der libstdc++. Das bläht das Ganze dann auf etwa 200 KiB auf und ich habe noch nicht herausgefunden, ob und wenn ja warum die benötigt werden (ich habe in GCC DWARF-Exception Handling aktiviert, das sind die "zero cost"-Exceptions von GCC, also mit fetten Tabellen fürs EH+Unwinding statt setjmp/longjmp). Dazu kommt dann auch noch der Stack Unwinding Code aus der libgcc, der auch noch einen nicht unerheblichen Anteil an der Größe hat. Ich muss allerdings auch erwähnen, dass ich einen Teil des Loaders in C++ geschrieben habe und dort schamlos moderne Features nutze wie std::span, std::string_view, Ranges, Views und Algorithmen. Mein Verdacht ist, dass vor allem daher die ganzen EH-Daten kommen. Ich werd's demnächst nochmal mit einer Multilib-Variante der libstdc++ versuchen, die ich dann ebenfalls mit -fno-exceptions baue.

Alles in allem jedenfalls ein lustiges Hobbyprojekt, bei dem man ne Menge über die Funktionsweise des Compilers lernt und was alles benötigt wird, damit so ein C++-Programm ausgeführt werden kann

Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

Eine lustige Eigenschaft in diese Richtung hat mein Projekt schon: Ich verwende ein flaches Speichermodell ohne Paging (virtueller Adressraum), d.h. der physische Speicher lässt sich direkt adressieren und die Speicheradresse 0x0 ist eine gültige Adresse, die keine CPU-Exception oder sowas auslöst. Dort befindet sich bei x86 standardmäßig der Interrupt Vector Table für den 16-bit Real Mode ... auto ivt = reinterpret_cast<ivt_entry*>(0); ... ich mach solche Zugriffe dann aber doch lieber in Assembler. Keinen Bock, dass mir der Optimizer da irgendwann ein Bein stellt, weil nicht sein kann, was nicht sein darf ... und ja, da hab ich eine ganze Menge Code drin, bei dem mir bezüglich C++ sehr unwohl wird. Ich Versuchs aber nach bestem Wissen und Gewissen standardkonform zu halten.

@john-0 sagte in Tortoise Git, Dateien und Icons:

Optimierende Linker scheinen nicht wirklich in Gebrauch zu sein. Templates, so toll sie auch sind, sind leider richtig übel was den Speicherverbrauch fürs Executable betrifft. Es gab da mal ein Versuch im GCC (RTO oder wie hieß das nochmal?) das zu optimieren, was aber in endlos langen Compile Orgien endete.

Doch, ich hab das schon mit LTO gebaut und auch mit -ffunction-sections/-fdata-sections und -Wl,--gc-sections. Ich weiss schon, wie ich unnötigen Code aus der EXE heraushalte. Immerhin hab ich das Linker-Skript geschrieben, mit dem ich überhaupt erst MZ-Executables erzeugen kann (GCC kann das nicht von Haus aus) und ich schau mir mit -Wl,--print-map genau an, was alles wo in der EXE landet. Das Problem scheint tiefer zu liegen. Da bin ich noch dabei herauszufinden, warum das so ist... wenn ich wieder Zeit für das Projekt finde

Finnegan

@Tyrdal sagte in Tortoise Git, Dateien und Icons:

Man könnte im diff auch einfach die whitespaces ignorieren lassen.

Hah! Auch ne gute Idee. Danke. Werd ich mir merken, falls irgendwann doch mal so ein Commit duchkommen sollte

SeppJ

Wo wir über Embarcadero/Borland zu dem Thema gekommen sind: Weiß jemand, wie groß so eine minimale mit Turbo C++ erzeugte Executable war? Konnte Turbo C++ überhaupt Exception Handling? Bei der GNU Implementierung von C++ kann ich ja voll verstehen, dass sich niemand die Mühe gemacht hat, die Größe von DOS-Executables zu optimieren, aber für das Borland-Produkt war das ja sicherlich wichtig. Die erste Version ist von 1990, da mussten Programme noch mit allem drum und dran auf Disketten passen.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Wo wir über Embarcadero/Borland zu dem Thema gekommen sind: Weiß jemand, wie groß so eine minimale mit Turbo C++ erzeugte Executable war?

Meine Erinnerung ist sehr trübe und bezieht sich auch nur auf Turbo Pascal ... da müsste "Hallo Welt" eigentlich so grob zwischen 2-4 KiB gelegen haben. Auf jeden Fall ein, zwei Größenordnungen unter dem, was heutige Compiler so fabrizieren... vielleicht teste ichs nochmal aus die Tage.

SeppJ

Aber Pascal braucht ja keine Laufzeitumgebung für Exceptions, RTTI und so, um die volle Sprachdefinition voll umzusetzen, oder? Ist aber auch ewig her, dass ich Pascal gemacht habe, und dann auch nur auf primitivem Niveau, daher verzeiht, wenn ich mich da irre.

Turbo C++ kann solche Sprachfeatures natürlich auch weggelassen haben, oder optional gemacht haben, um Platz und/oder Laufzeit zu sparen. Selbst in heutigen Implementierungen ist RTTI ja noch abschaltbar, für wenn man sie nicht braucht und nicht dafür bezahlen möchte.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Aber Pascal braucht ja keine Laufzeitumgebung für Exceptions, RTTI und so, um die volle Sprachdefinition voll umzusetzen, oder? Ist aber auch ewig her, dass ich Pascal gemacht habe, und dann auch nur auf primitivem Niveau, daher verzeiht, wenn ich mich da irre.

Pascal ist bei mir auch zu lange her, dass ich das sicher beantworten könnte.

Ich war zu neugierig und habs grad ausprobiert: Borland Turbo C++ 3.0:

// TEST.CPP
#include <iostream.h>

int main()
{
    cout << "Hallo Welt!\n";
    return 0;
}

-> TEST.EXE 23.156 Bytes

Schon etwas größer als erwartet.

Hingegen:

// TEST2.C
#include <stdio.h>

int main()
{
    printf("Hallo Welt!\n");
    return 0;
}

-> TEST2.EXE 8.675 Bytes

Alles mit Default-Settings direkt nach Installation. "Optimization" war für "size".

Nachtrag: Debugging war aktiv. Ohne sind es nur 9.478 Bytes für C++ und 6.446 Bytes für C.

Exceptions scheint Turbo C++ 3.0 nicht zu können: Undefinded symbol 'try'.

Turbo C++ kann solche Sprachfeatures natürlich auch weggelassen haben, oder optional gemacht haben, um Platz und/oder Laufzeit zu sparen. Selbst in heutigen Implementierungen ist RTTI ja noch abschaltbar, für wenn man sie nicht braucht und nicht dafür bezahlen möchte.

Ich hab bei meinem DOS-Projekt schon einiges an Arbeit reingesteckt, um überhaupt Exceptions ans laufen zu bekommen, aber genau aus dem Grund wurmt es mich, dass ich die ganzen Tabellen immer noch drin habe, wenn ich Exceptions ausschalte. Ich denke aber mal, dass ich das irgendwann noch in den Griff bekomme. Gut möglich, dass es nur daran liegt, dass die C++-Standardbibliothek mit Exception-Support gebaut wurde. Ich hätte aber vermutet, dass ich hauptsächlich Header-Only-Teile davon verwende, wo das egal sein sollte.

Nachtrag für Turbo Pascal 7.0:

program hello;
begin
    writeln('Hallo Welt!');
end.

-> HELLO.EXE 2.192 Bytes

hustbaer

Probier nochmal puts statt printf. Ich würde mich nicht wundern wenn's damit nochmal kleiner wird.

Ich meine mich zu erinnern dass der Hauptgrund warum Echsen von Miniprogrammen mit modernen Compilern so gross werden der ist, dass es da kreuz und quer Dependencies beim ganzen IO Zeugs gibt, inklusive Locale Support. Ich vermute dass man das besser entkoppeln könnte, wenn man gezielt auf kleine Programme optimieren will. Nur dass zahlt sich bei Runtime Libs für moderne Compiler halt kaum aus mMn. - und daher wundert es mich nicht dass ein "Hello World" Programm vergleichbar riesig wird.

Bei älteren Compilern könnte das aber u.U. noch ein wichtiger Faktor gewesen sein. Und vor allem war's vermutlich auch einfacher, weil die Libs viel weniger konnten (älterer Standard, weniger supportete Locales etc.).

hustbaer

@Finnegan verwendest du auch "moderne" Compiler für DOS? Also vielleicht Open WATCOM oder gar irgendwas auf Clang- bzw. GCC-Basis?

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

@Finnegan verwendest du auch "moderne" Compiler für DOS? Also vielleicht Open WATCOM oder gar irgendwas auf Clang- bzw. GCC-Basis?

Als Hobbyprojekt baue ich gerade ne GCC14-Toolchain zum crosscompilen auf DOS. Darüber hab ich in meinen längeren Abschweifungen hier berichtet.

hustbaer

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Als Hobbyprojekt baue ich gerade ne GCC14-Toolchain zum crosscompilen auf DOS. Darüber hab ich in meinen längeren Abschweifungen hier berichtet.

Haha OK, sorry, hab ich verpennt
Aber cooles Projekt!
DOS 16 Bit oder 32 Bit oder beides? Falls 32 Bit, welcher Extender?

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

Probier nochmal puts statt printf. Ich würde mich nicht wundern wenn's damit nochmal kleiner wird.

// TEST3.C
#include <stdio.h>

int main()
{
    puts("Hallo Welt!\n");
    return 0;
}

-> TEST2.EXE 4.956 Bytes

Ich meine mich zu erinnern dass der Hauptgrund warum Echsen von Miniprogrammen mit modernen Compilern so gross werden der ist, dass es da kreuz und quer Dependencies beim ganzen IO Zeugs gibt, inklusive Locale Support. Ich vermute dass man das besser entkoppeln könnte, wenn man gezielt auf kleine Programme optimieren will. Nur dass zahlt sich bei Runtime Libs für moderne Compiler halt kaum aus mMn. - und daher wundert es mich nicht dass ein "Hello World" Programm vergleichbar riesig wird.

Ja. Auch der printf-Code dürfte relativ gross sein. Schließlich weiß man ja nicht ob man nur nen blanken String oder ne komplexe Formatierung bekommt. Ich denke da landet bei so nem "Hallo Welt" ne menge toter Code in der EXE.

Bei älteren Compilern könnte das aber u.U. noch ein wichtiger Faktor gewesen sein. Und vor allem war's vermutlich auch einfacher, weil die Libs viel weniger konnten (älterer Standard, weniger supportete Locales etc.).

Wenn ich das direkt in Assembler schreibe komme ich locker unter 100 Bytes. Da macht das der MZ-EXE-header mit seinen 32 Bytes den größten Teil aus. Der eigentliche Code ist lediglich ein paar Register auf Länge, File Handle und Adresse des Strings setzen und eine INT 0x21-Instruktion um den String nach stdout zu schreiben. Dann noch nen weiterer INT 0x21 um das Programm zu beenden. Das sind nur eine Handvoll Bytes an Code.

Noch kleiner gehts mit ner COM-Datei. Das ist direkt der Maschinencode ohne Header. Maximal 64 KiB, der wird dann direkt in ein Segment geladen und ausgeführt. Da macht dann der String den größten Teil aus. Ich denke das könnte man durchaus auf 20-30 Bytes drücken

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Als Hobbyprojekt baue ich gerade ne GCC14-Toolchain zum crosscompilen auf DOS. Darüber hab ich in meinen längeren Abschweifungen hier berichtet.

Haha OK, sorry, hab ich verpennt
Aber cooles Projekt!
DOS 16 Bit oder 32 Bit oder beides? Falls 32 Bit, welcher Extender?

Kein Extender. Ein eigener Loader-Code in einer Bibliothek, die per Default dazu gelinkt wird. Der Loader startet in 16-Bit und versetzt die CPU dann in 32-Bit Protected Mode ohne Rücksicht auf Verluste. DOS-Calls werden über Interrupt Thunks gemacht, die für den Aufruf kurzzeitig wieder in den Real Mode wechseln. Das hat gewisse Ähnlichkeiten mit einem DOS Extender ist aber wesentlich simpler und kleiner (~3KiB, direkt in die EXE integriert). Dafür aber auch nicht "kompatibel" mit irgendwas. Unter nem DOS-Ära-Windows würde das nicht laufen.

GCC kann keinen 16-Bit Code erzeugen (lediglich der Assembler hat rudimentären Support mit dem ich z.B. den Loader implementieren kann) und erwartet auch ein "Flat" Memory Model. D.h. ich brauche 32-bit Protected Mode, damit der GCC-kompilierte Code überhaupt lauffähig ist. Speicher wird auch ohne Paging (Virtueller Speicher) konfiguriert und die Programme laufen alle in Ring 0. Da hat man dann direkten Zugriff auf alles zum rumspielen... Pointer adressieren direkt den physischen Speicher

Funktioniert recht gut bisher. Modernes C++ und Exceptions laufen. malloc und libc-Funktionalität kommt von picolibc. bin aber noch mit Details im Loader beschäftigt. Die Hardware-Interrupts machen noch ein paar Probleme. Man soll eigene IRQ-Handler definieren können (für Hardware-Zeug wie Soundkarten und sowas), aber per Default soll an die von DOS definierten Interrupt-handler weitergeleitet werden (auch wieder switch in Real Mode für den Aufruf). Das ist alles schon ein wenig fummelig, macht aber Spass.

Wenn das einigermaßen rund läuft, lad ich es mal auf Github hoch für Leute, die auch Spaß an sowas haben. Meine ursprüngliche Motivation war, dass ich nen modernen C++-Compiler wollte mit dem man die ganzen coolen Hardware-Spielereien aus DOS-Zeiten machen kann, ohne gleich ein eigenes OS entwickeln zu müssen. Diese "Spielereien" sind ja heutzutage nur noch kernel-Entwicklern vorbehalten

hustbaer

Haha, ja, ist schon klar. Hab damals selbst sowohl mit C(++) Compilern als auch x86 Assembler für DOS gespielt. Schnell mal mit int-keine-Ahnung-mehr-welche-Nummer in den 8 Bit 320x200 Mode wechseln und mit ein paar wenigen Instruktionen Pixel auf den Bildschirm klatschen. Und das .COM File hatte dann gerade ein paar hundert Byte.

War schon cool irgendwie. Und um Welten einfacher als das selbe am Amiga zu machen
Wobei der Amiga natürlich viel viel cooler und kultiger war. Aber die ganze Plackerei mit den Bitplanes, Copperliste, Blitter-Registern & Co. hab ich nicht vermisst.

hustbaer

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Meine ursprüngliche Motivation war, dass ich nen modernen C++-Compiler wollte mit dem man die ganzen coolen Hardware-Spielereien aus DOS-Zeiten machen kann, ohne gleich ein eigenes OS entwickeln zu müssen. Diese "Spielereien" sind ja heutzutage nur noch kernel-Entwicklern vorbehalten

Haha, cool!

Ich hab mir seit Jahren vorgenommen mal was mit der Amiga GCC-Toolchain zu machen. Also irgend ein kleines Spiel. Aber irgendwie ist mir die Einstiegshürde zu hoch. Also kombiniert mit meiner Faulheit.