Hallo liebe Gemeinde, Einige kennen es vielleicht noch. In den 90ern und frühen 00ern gab es mal so Spiele CDs/DVDs. Darauf enthalten waren neben Spielen auch entsprechende Cracks. Diese Cracks enthielten Programmcode inkl GUI und so n 8bit Titelsong in einer einzelnen Datei. Alles zusammen wenige 100kb groß. Wie wurde das gemacht. Es sollen nun keine Spiele gecrackt werden, aber mal ein Taschenrechner oder eine andere simple Anwendung geschrieben werden. Welche Bibliotheken, welche Compiler, welche Strategien wurden damals genutzt / könnte man heute nutzen. Heutzutage ist oft alles direkt >MB groß. Und etliche DLLs müssen mitgeliefert oder QT installiert werden. Selbst bei sowas wie FLTK. (Erstmal unter Windows, aber gerne auch generell.) Gute Grüße
Sicher dass nicht auf der CD in einem zentralen Ordner Libraries waren die von allen Tools gemeinsam genutzt wurden? Ansonsten wurde da halt einfach direkt mit dem Win32-API gearbeitet und sonst keine Libs genutzt, z.B. auch nicht die C++ Standard Library. Das kannst du auch heute noch problemlos z.B. mit Visual Studio machen. Es ist nur halt ziemlich umständlich und der Code ist null portabel. Besonders aufwendige GUIs kriegt man so auch nicht in sinnvoller Zeit hin. Mit ein paar Hacks im Hex-Editor kann man die von VS erzeugten Executables noch um ein paar Bytes kürzen. Das Ganze lohnt sich aber kaum, denn PCs haben heutzutage viel mehr Speicher. Höchstens als lustige Fingerübung... Titelsongs und Hintergrundbilder legt man komprimiert in der Anwendungsdatei ab und entpackt sie beim Start in den RAM. Mit dem Code kann man das auch machen, wobei es da Probleme mit Sicherheitsmaßnahmen geben könnte...
90erCrack schrieb: > Alles zusammen wenige 100kb groß. Daraus hat sich die Demoscene entwickelt, die dann nur noch die Intros, ohne eigentliche Crack-Payload dahinter, gebastelt haben. Gibt Wettbewerbe mit verschiedenen Kategorien, 4 Kilobyte, 64 Kilobyte usw. https://de.wikipedia.org/wiki/Demoszene https://www.pouet.net/ Oder, auch passend zum Forum hier, Demo auf dem Atmega88: https://www.linusakesson.net/scene/craft/ => Video anschauen, das läuft alles incl. VGA-Signal-Erzeugung und Audio, auf einem 8-Bit µC mit 8kB Flash.
90erCrack schrieb: > Wie wurde das gemacht. Das wurde programmiert. > Welche Bibliotheken, Keine. Jede Zeile Code handgeklöppelt. > welche Compiler, Damals keiner. Assembler. > welche Strategien wurden damals > genutzt Damals kenne deine Hardware in- und auswendig. Insbesondere kenne den Prozessor in- und auswendig. Heute kenne auch dein OS in- und auswendig. > / könnte man heute nutzen. Ja, und wird auch: https://de.wikipedia.org/wiki/Demoszene https://2022.revision-party.net/competitions/pc/ https://files.scene.org/browse/parties/2022/revision22/ Wobei zum Teil auch Bibliotheken wie .NET und Runtimes wie Java erlaubt sind.
Hannes J. schrieb: > . > >> welche Compiler, > > Damals keiner. Assembler. So etwas simples wie einen Crack kriegt man auch in C oder C++ (aber Vorsicht mit der Library) in <100KiB hin. Wobei man noch unterscheiden kann ob man was nützliches (wie den Taschenrechner) mit vertretbarem Aufwand oder was schickes aber nutzloses (wie eine Demo) mit irrem Aufwand bauen möchte.
Für DirectX-basierte Demos gab es einen speziellen Kompressor, die Texturen wurden algorithmisch erzeugt, damit konnte man recht komplexe Demos basteln die nur wenige kB brauchten, das war damals die nächste grosse Evolution in dem Bereich.
0erCrack schrieb: > Wie wurde das gemacht. > > Es sollen nun keine Spiele gecrackt werden, aber mal ein Taschenrechner > oder eine andere simple Anwendung geschrieben werden. > > Welche Bibliotheken, welche Compiler, welche Strategien wurden damals > genutzt / könnte man heute nutzen. > > Heutzutage ist oft alles direkt >MB groß. Und etliche DLLs müssen > mitgeliefert oder QT installiert werden. Selbst bei sowas wie FLTK. > > (Erstmal unter Windows, aber gerne auch generell.) Ganz einfach: Ohne Bloatware-Framework. Ein "Hallo Welt" Konsolenprogramm hat da gerade mal 5 kByte. Windows Programme, die mit der Win32 Api gemacht werden sind oft unter 100 kByte gross. Das geht sehr einfach, wenn die Oberflächen aus einem Dialog oder nur einem Fenster bestehen. Schau dir dazu das Buch Programming Windows von Petzold an. Microsoft Foundation Class MFC (C++) Programme sind typisch unter 500 kB gross. Das war das Standard Windows Framework vor 20 Jahren. Das Buch "Programming Windows with MFC" von Jeff Prosise ist da ein sehr guter Einstieg. Und ich rede da nicht von einem einfachen "Hallo Welt", sondern die Programme haben schon eine beachtliche Funktionalität. Vielleicht kommt das wieder, wenn ernsthaft Strom gespart werden muss. Jeder unnötige CPU Zyklus braucht schließlich Energie. Gruss, Udo
90erCrack schrieb: > Welche Bibliotheken, welche Compiler, welche Strategien wurden damals > genutzt / könnte man heute nutzen. Am besten gar keine, sondern selber machen und ein passendes Konzept haben. Ich hätte da ein Beispiel: mein selbstgeschriebener Crossassembler für die PICs kann mit einer grafischen Oberfläche aufwarten und ist nur etwa 69K groß. Ohne irgendwelche Klimmzüge und Tricks nur mit Delphi 6 geschrieben. Das komplette Gegenteil sieht man hier selbst bei der Firmware für Mikrocontroller: Da scheut man sich (oder ist zu doof dafür) ein Portpin selber zu setzen und nimmt dafür eine Bibliotheksfunktion wie DigitalWrite oder so ähnlich - und dann kommen fette schwerfällige Ergebnisse dabei heraus, für die man Controller mit immer mehr Flash benötigt. Aufgedunsen durch Doofheit? Ja. Aber das gilt heutzutage als modern. W.S.
W.S. schrieb: > Das komplette Gegenteil sieht man hier selbst bei der Firmware für > Mikrocontroller: Da scheut man sich (oder ist zu doof dafür) ein Portpin > selber zu setzen und nimmt dafür eine Bibliotheksfunktion wie > DigitalWrite oder so ähnlich - und dann kommen fette schwerfällige > Ergebnisse dabei heraus, für die man Controller mit immer mehr Flash > benötigt. Aufgedunsen durch Doofheit? Ja. Aber das gilt heutzutage als > modern. Die Rechner sind heute sauschnell, und eine GUI kannst du auch problemlos skripten. Da ist alles unter 10 Millisekunden kein Problem, und das sind schon mal locker 30 Millionen CPU Zyklen, wobei eine moderne CPU vieles parallel machen kann... So schlecht kann man eigentlich gar nicht programmieren. Und soviel Speicher wie ein Einstiegs-PC heute hat, kannst du gar nicht vollmachen. Zum Taschenrechner: Im Buch von Petzold ist ein einfacher Taschenrechner drinnen. Der braucht glaube ich weniger als 30 kByte. Der Sourcecode hat unter 250 Zeilen. Ich habe dir den Source Code + die Exe angehängt... Das müsstest du auch mit einer aktuellen Visual Studio Studenten Edition kompilieren können.
:
Bearbeitet durch User
W.S. schrieb: > Aufgedunsen durch Doofheit? Ja. Aber das gilt heutzutage Wenn dein Kunde hinter dir steht und fragt "wann ist meine IoT-Anwendung mit WLAN-Cloudanbindung, signiertem OTA-Update, Secure Boot, Sensor-Fusion, KI, Multimedia-Funktion, 3D-GUI, Dateisystem... fertig???" sagst du bestimmt nicht "ich bastle noch an meinem eigenen Assembler", sondern suchst dir alles an Frameworks was du finden kannst. Und natürlich wollen die Kunden das. LED-Blinker und Temperaturregler sind der Stand von 1980. Das können die auch selber mit Arduino zusammenfrickeln. Heutzutage ist Cloud, IoT, Apps usw. gefragt. Dafür kann man noch Kunden finden. Udo K. schrieb: > Vielleicht kommt das wieder, wenn ernsthaft Strom gespart werden muss. > Jeder unnötige CPU Zyklus braucht schließlich Energie. Energieeffizienz bedeutet nicht einfach nur kleinere Programme schreiben. z.B. Android hat eine riesige Menge Code nur fürs Power Management. Und es funktioniert ziemlich gut. Die Apps müssen dazu mitspielen, und auch das funktioniert, sogar in Java/Kotlin. Eine gut programmierte Kotlin-App auf einem Android-Gerät ist viel energieeffizienter und leistungsfähiger als so ein Pentium 4-PC mit Win32-API-Apps. Das ziemlich komplexe und clevere Coroutinen-Framework z.B. von Kotlin ermöglicht übrigens auch noch mal effizienteren Code, indem es Threads spart.
Udo K. schrieb: > Zum Taschenrechner: Im Buch von Petzold ist ein einfacher > Taschenrechner drinnen. Der braucht glaube ich weniger als 30 kByte. > Der Sourcecode hat unter 250 Zeilen. Ich habe dir den Source Code + die > Exe angehängt... Das müsstest du auch mit einer aktuellen Visual Studio > Studenten Edition kompilieren können. Ich habe es noch mit Visual Studio 2022 ausprobiert: Läuft. Allerdings hat die statisch gelinkte 32 Bit Version statt 28 kByte 74 kByte. Die dynamisch gelinkte 32 Bit Version hat dafür gerade mal 12 kByte. Mit dem 64 Bit WinDDK 7.10 Compiler - der mit der alten MSVCRT linkt - hat die statisch gelinkte 64 Bit Exe 41 kByte, und die dynamisch gelinkte 9 kByte. Gruss, Udo
Programmierer schrieb: > Das ziemlich komplexe und clevere Coroutinen-Framework z.B. von Kotlin > ermöglicht übrigens auch noch mal effizienteren Code, indem es Threads > spart. Witzbold :-) Meine Win32 Anwendung hatte noch nie mehr als einen Thread. Nur das doofe Win10 macht nebenbei 4 weitere zum parallelen DLL laden auf...
Udo K. schrieb: > Meine Win32 Anwendung hatte noch nie mehr als einen Thread Dann war sie wahrscheinlich nicht besonders komplex oder musste sich nicht mit nebenläufigen Vorgängen auseinandersetzen... Und kann keine Multicore-CPUs ausnutzen! Zugegebenermaßen kommt man unter Windows dank Overlapped IO mit weniger Threads aus.
Programmierer schrieb: >> Meine Win32 Anwendung hatte noch nie mehr als einen Thread > > Dann war sie wahrscheinlich nicht besonders komplex oder musste sich > nicht mit nebenläufigen Vorgängen auseinandersetzen... Und kann keine > Multicore-CPUs ausnutzen! Zugegebenermaßen kommt man unter Windows dank > Overlapped IO mit weniger Threads aus. Etliche MFC Anwendungen waren durchaus sehr komplex und hatten trotzdem nur einen Thread. Wozu auch mehr, wenn alles wichtige in einer Zeitscheibe von < 100 ms ausgerechnet wird und der Prozessor sowieso nur eine CPU hat? Im schlimmsten Fall kommt halt für ein paar Sekunden eine Sanduhr... Heute ist ein aktueller CPU Core sicher 20x schneller, und davon gibt es 8, eine SSD kann in 100 Millisekunden 500 MByte lesen. Trotzdem laufen viele einfachen Programme nicht richtig flüssig (etwa Eagle)...
:
Bearbeitet durch User
Udo K. schrieb: > Etliche MFC Anwendungen waren durchaus sehr komplex und hatten trotzdem > nur einen Thread. Die hatten dann wahrscheinlich keinen Netzwerkkram. So etwas wird nämlich gerne in separate Threads gesteckt. Man kann es auch asynchron machen, aber das ist vielen zu aufwendig. Coroutinen machen asynchrone Programmierung viel beherrschbarer und sparen dadurch die Threads ein. Udo K. schrieb: > Im schlimmsten Fall kommt halt für ein paar Sekunden eine Sanduhr... Das mutet man Usern heute nicht mehr zu! Lang laufende Operationen gehören in einen Worker-Thread, oder sollten asynchron abgewickelt werden, sodass die GUI reaktiv bleibt. Udo K. schrieb: > Trotzdem laufen viele einfachen Programme nicht richtig flüssig (etwa > Eagle)... da frage ich mich manchmal schon, was da los ist... Mies programmiert ;-)
Programmierer schrieb: > Die hatten dann wahrscheinlich keinen Netzwerkkram. So etwas wird > nämlich gerne in separate Threads gesteckt. Man kann es auch asynchron > machen, aber das ist vielen zu aufwendig. Coroutinen machen asynchrone > Programmierung viel beherrschbarer und sparen dadurch die Threads ein.# Ich habe den Netzwerkram im Hintergrund nie vermisst. > Udo K. schrieb: >> Im schlimmsten Fall kommt halt für ein paar Sekunden eine Sanduhr... > > Das mutet man Usern heute nicht mehr zu! Lang laufende Operationen > gehören in einen Worker-Thread, oder sollten asynchron abgewickelt > werden, sodass die GUI reaktiv bleibt. Alle normalen GUI Operationen und praktisch alles an Mathematik im Bereich Messtechnik oder Office konnte man schon auf einem Single Core vor 20 Jahren in < 100 ms ausrechnen. Wenn wirklich viele Berechnungen anstehen (LTSpice etwa), dann muss man sowieso eine Art Sanduhr oder eine Message Box haben - das Programm kann nicht weitermachen ohne die berechneten Daten. Die Berechnungen laufen dann klarerweise auf allen Kernen. Der häufigste Grund für mehrere GUI-Threads ist User-Spionage im Hintergrund (Netzwerk) und miese Programmierung...
:
Bearbeitet durch User
Udo K. schrieb: > Ich habe den Netzwerkram im Hintergrund nie vermisst. Tippte er in einen Browser ein... Wenn du im Browser scrollst, oder schon etwas eingibst während die Seite noch lädt, passiert was im Hintergrund. Wenn du im Google-Suchfeld etwas eintippst und Vorschläge geladen werden, passiert was im Hintergrund. Wenn du in WhatsApp eine Nachricht eingibst und gleichzeitig Nachrichten ankommen, passiert was im Hintergrund. Die meisten Internetbasierten Apps, insb. Social Media, müssen jede Menge Dinge im Hintergrund übertragen. Dafür jedes Mal die GUI einzufrieren und eine Sanduhr anzuzeigen würde sie unbenutzbar machen. Udo K. schrieb: > Wenn wirklich viele Berechnungen anstehen (LTSpice etwa), dann muss man > sowieso eine Art Sanduhr oder eine Message Box haben - das Programm kann > nicht weitermachen ohne die berechneten Daten. Nö, man könnte auch im Hintergrund rechnen und die GUI weiter reaktiv haben. Viele IDE's beispielsweise können im Hintergrund kompilieren und man kann sogar weiter coden. Udo K. schrieb: > Der häufigste Grund für mehrere GUI-Threads ist User-Spionage im > Hintergrund (Netzwerk) Ist es Spionage wenn Facebook ein Bild lädt? Ohne die Anzeige von Inhalten macht Facebook keinen Sinn.
Udo K. schrieb: > Alle normalen GUI Operationen und praktisch alles an Mathematik im > Bereich Messtechni Wie würdest du denn Daten von z.B. einem USB-Messgerät empfangen, wenn dafür nur ein blockierendes API zur Verfügung steht? Die GUI dafür zu blockieren wäre ziemlich blöde, wenn ständig neue Daten reinkommen und man mit dem Programm interagieren können soll.
Udo K. schrieb: > Alle normalen GUI Operationen und praktisch alles an Mathematik im > Bereich Messtechnik oder Office konnte man schon auf einem Single Core > vor 20 Jahren in < 100 ms ausrechnen. Wenn Du Deine Daten noch mit einer Office-Software verarbeiten kannst sprechen wir über triviale Datenvolumina. Bei richtigen Daten geht der Trend heute sogar schon dahin, die Daten nicht mehr auf der CPU, sondern auf der GPU zu verarbeiten, weil die viel besser parallelisieren kann als jede CPU und jedes Betriebssystem. Dafür bieten einige Hersteller mittlerweile sogar spezialisierte Produkte an. Es ist auch völlig bescheuert grössere Datenvolumen mit einer Office-Software zu verarbeiten - auf so eine Idee kommt nur, wer nichts Besseres kennt. Alleine die Idee, n Millionen Datenpunkte einzulesen und jeden einzelnen davon dann in eine grafische Repräsentation zu rendern, ist nicht gerade klug.
90erCrack schrieb: > Einige kennen es vielleicht noch. In den 90ern und frühen 00ern gab es > mal so Spiele CDs/DVDs. > Darauf enthalten waren neben Spielen auch entsprechende Cracks. > Diese Cracks enthielten Programmcode inkl GUI und so n 8bit Titelsong in > einer einzelnen Datei. Alles zusammen wenige 100kb groß. > > Wie wurde das gemacht. Das Gros der Daten bei heutigen Spielen sind Multimedia-Inhalte, also Musik, Graphiken, 3D-Modelle von riesigen Welten sowie Videosequenzen (in 4k). Und da gilt, auch bei Verwendung von Kompressionen: mehr Qualität (lies: Bitrate, Detailgrad usw) => größere Dateien Der eigentliche Programmcode ist dagegen vernachlässigbar.
PureBasic macht z.B. mit seinem FASM - Assembler Output auch kleine GUI-Programme, meist so ab 20 KB. Threads braucht man eigentlich seltener. Meist reicht da auch ein Windows-Timer aus. Kommt natürlich immer auf die Aufgabe an. Wenn ich eine ser. Schnittstelle, die große Mengen an Daten liefert, ständig pollen muß, komme ich an einem Thread nicht vorbei. Wenn die aber nur kleine Datenmengen liefert und das nicht gerade im Millisekundentakt, genügt da auch ein Timer. Bei einem Timer ungefähr ab so 300 ms bleibt dann auch eine GUI bedienbar. So ist mal meine Erfahrung. Sowas sollte man dann immer abwägen und entscheiden ob Thread oder Timer.
Heinz B. schrieb: > Meist reicht da auch > ein Windows-Timer aus. Timer zum Pollen sind eine ziemliche Krücke. Ist das Intervall zu kurz, belastet es die CPU und die Bedienbarkeit. Ist es zu lang, gehen Daten verloren. Und sie wachen ständig die CPU auf, schlecht zum Energie Sparen. Nicht ohne Grund schränkt Android die Verwendung von Timern ziemlich ein. Für die serielle Schnittstelle kann man das HANDLE auch wunderbar in WaitForMultipleObjects stecken, sodass die Anwendung nur genau dann aufwacht, wenn Daten angekommen sind/abgesendet werden können. U.a. bei libusb geht das (unter Windows) leider nicht so schön, daher: Threads. Immer noch besser als Timer.
Programmierer schrieb: > Timer zum Pollen sind eine ziemliche Krücke. Da hast du was überlesen. Ich habe doch oben geschrieben, daß man zum Pollen besser einen Thread beutzen sollte. Pollen = ständig !
:
Bearbeitet durch User
Heinz B. schrieb: > Da hast du was überlesen. Ich habe doch oben geschrieben, > daß man zum Pollen besser einen Thread beutzen sollte. > Pollen = ständig ! Und für was benutzt du dann Timer?
Warum bieten denn die meisten Programmiersprachen so einen Timer an ? Wird wohl einen Grund haben. Für mich ist so ein Timer wie eine Eieruhr oder Sanduhr. Den kann man auch als Ersatz für ein Sleep nehmen. Oder auch, um im Sekundentakt jeweils ein anderes Bildchen anzuzeigen. Oder auch sonstige Grafikprogrammierung wie bei OpenGL, um etwa ein Objekt gleichmäßig drehen zu lassen. Oder vlt. ein Wecker, der alle x Minuten klingelt oder eine andere Aktion durchführt. Geht natürlich auch mit anderer API (ellapsedmilliseconds ?) aber so ein Timer ist in meiner Programmiersprache einfacher zu erstellen und zu behandlen. Und vor allem brauche ich dann z.B. die Sekunden nicht jedesmal neu zu berechnen. Da brauche ich einfach nur das Timer - Ereignis in meiner Eventschleife abzufragen. Ich denke, da gibt es noch mehr Möglichkeiten.
:
Bearbeitet durch User
90erCrack schrieb: > Welche Bibliotheken, welche Compiler, welche Strategien wurden damals > genutzt / könnte man heute nutzen. Oft Pascal, C++, C oder Assembler. Die Verbreitung ähnlich, sagen wie für jeden Ansatz 25%. Für Assembler etwas weniger, vielleicht 10-20 Prozent. Für die Musiktracks gab es wohl schon hochoptimierter Tracker oder Packer für die Programme. Für die Cracks brauchte man Assembler Know How, wie auch Know How über Windows - und Dosfunktionen. Sehr viel wurde mit Disassemblern und Debuggern gearbeitet - was sich wiederum günstig auf die Windowsfunktionen-Nutzung (und -Aushebelung) oder Nachprogrammierung auswirkte. Grundsätzlich muss man viel nachdenken, man kann aber seine Erleuchtung haben. Hochsprachenprogramme kann man selber noch ganz gut im Hexeditor zusammenkürzen. Teilweise wurde auch schon in Gruppen und mit Internet entwickelt, also gab es auch einiges an Teamressourcen. So ganz grob könnte man auch sagen, Programmierkunst. Analog zu Bildermalkunst. Man muss halt auch gut sein, um schöne Bilder zu malen. Wenn ich Code optimieren wollte, würde ich auf alle Fälle auch hier im Forum um Rat fragen. Zuerst sollte man aber selber loslegen, und sich ein paar Gedanken machen. Das heißt, auch heute gilt: Köpfchen anstrengen.
Heinz B. schrieb: > Für mich ist so ein Timer wie eine Eieruhr oder Sanduhr. > Den kann man auch als Ersatz für ein Sleep nehmen. Oder > auch, um im Sekundentakt jeweils ein anderes Bildchen anzuzeigen. Ja dafür macht es sicherlich Sinn. Wenn praktisch klar ist, dass bei jedem Timer-Event definitiv was passieren muss. Beim I/O-Pollen wäre das ja nicht so. Aber das würde man wohl auch nicht als nebenläufigen Vorgang sehen.
Früher, als es nur Disketten zum Weitergeben gab, hatte ich die Runtime, die vom Compiler meiner Interpretersprache dazu gelinkt wurde, zuerst mit einem Ressourcen- Editor bearbeitet. Da waren auch viele Icons, Bitmaps, Cursors und sonstiges drin, was nicht oft benötigt wurde. Das konnte man gut rauswerfen und hatte somit eine kleinere Runtime und somit auch ein viel kleineres Programm. Wenn man das ganze noch mit dem UPX-Packer verkleinerte, wurde es dann noch kleiner.
:
Bearbeitet durch User
Hallo Gemeinde, Vielen Dank für all die Informationen. Ich lese fleißig weiter mit, grabe mich jedoch auch bereits durch die verlinkten Informationen. In jedem Fall wollte ich einmal ein Piep und ein großes DANKE hinterlassen. Gruß
"In contrast to user interface libraries like GTK, Qt, and wxWidgets, FLTK uses a more lightweight design and restricts itself to GUI functionality. Because of this, the library is very small (the FLTK "Hello World" program is around 100 KiB)" https://en.wikipedia.org/wiki/FLTK
Programmierer schrieb: > Wenn dein Kunde hinter dir steht und fragt... Jaja. Der böse Kunde ist es also, der die Programmierer zwingt, sich ihr Zeugs aus "alles an Frameworks was du finden kannst" zusammenzusuchen und das Zeug, was sie abliefern sollen, von woanders zusammenzukopieren. Ich überlege mir grad, wie das wohl geklungen hätte, wenn sich Bach, Mozart, Beethoven usw. ihre Noten zusammenkopiert hätten, anstatt sie selber zu komponieren. W.S.
W.S. schrieb: > Programmierer schrieb: >> Wenn dein Kunde hinter dir steht und fragt... > > Jaja. Der böse Kunde ist es also, der die Programmierer zwingt, sich ihr > Zeugs aus "alles an Frameworks was du finden kannst" zusammenzusuchen > und das Zeug, was sie abliefern sollen, von woanders zusammenzukopieren. Natürlich. Kein Programmierer der Welt kann all diese Funktionalität in ein paar Monaten von Grund auf neu programmieren. Aber mit ein paar Frameworks geht's. Wenn man dem Kunden eine Rechnung über ein paar Jahre Arbeit stellt, aber die Firma nebenan nur ein paar Monate braucht weil sie fertige Frameworks und Libraries einsetzt, wo geht der Kunde wohl hin? W.S. schrieb: > Ich überlege mir grad, wie das wohl geklungen hätte, wenn sich Bach, > Mozart, Beethoven usw. ihre Noten zusammenkopiert hätten, anstatt sie > selber zu komponieren. Bach, Mozart und Beethoven haben die Musik nicht erfunden, sondern auf die Arbeit anderer aufgebaut. Wie es so schön heißt: Auf den Schultern von Riesen stehen.
W.S. schrieb: > Ich überlege mir grad, wie das wohl geklungen hätte, wenn sich Bach, > Mozart, Beethoven usw. ihre Noten zusammenkopiert hätten, anstatt sie > selber zu komponieren. > > W.S. Nicht alles was hinkt ist ein Vergleich.
Hieran kann man sich auch noch ein Beispiel nehmen: http://asm.sourceforge.net/asmutils.html (Linux auf einer Diskette!) http://asm.sourceforge.net/resources.html#projects https://bellard.org/tcc/ Dies aber nur zur Orientierung. So als Übung könnte man mal anfangen, Internetseiten so zu bearbeiten, dass sie weniger Speicherplatz verbrauchen.
Udo K. schrieb: > Meine Win32 Anwendung hatte noch nie mehr als einen Thread. > Nur das doofe Win10 macht nebenbei 4 weitere zum parallelen DLL laden > auf... Windows "lädt" DLLs nicht per mmap nach?
Pager schrieb: > Windows "lädt" DLLs nicht per mmap nach? Der Windows Loader oder eine der DLL Initialisierungsfunktionen erstellt mehrere Threads, die parallel die DLLs laden und initialisieren (die auch wieder Abhängigkeiten haben). Dazu wird wohl NtMapViewOfSection verwendet. Da werden auch bei einfachen Programmen >40 DLLs geladen, und 100'erte Registry Keys und Files gelesen. Nach einigen Minuten beenden sich die Threads von selbst. Windows protokolliert nebenbei mit, welche DLLs in welcher genauen Version gebraucht werden (WinSxS). Das nächste Laden soll dann schneller gehen...
Pager schrieb: > Windows "lädt" DLLs nicht per mmap nach? Im Prinzip: natürlich. Es heißt bei Windows eben bloß nicht mmap... Genau genommen ist die virtuelle Speicherverwaltung von Windows und den heutigen Unixoiden-Abkömmlings praktisch gleich in ihrer Funktionsweise. Was du Dummkopf scheinbar nicht begreifst, ist das, was Windows dort ZUSATZLICH tut: Nämlich die Initialisierungsroutine der DLLs im Adressraum eines neuen Prozesses, der sie benutzt, in zusätzlichen Threads abzuhandeln. Bei den fetten, aufgeblasenen DLLs, die heutzutage rumlaufen und den typisch vielen verfügbaren Cores kann das durchaus den Programmstart erheblich beschleunigen. Und ein entsprechendes Vorgehen würde auch bei heutigen Unixoiden-Abkömmlingen genauso positiv wirken, denn auch dort neigen die shared libs immer extremer zum bloat... Letztlich ist das aber nur ein Rumdoktorn an Symptomen. Was wirklich bekämpft werden müsste, ist der unsägliche, immer weiter um sich greifende Bloat der shared libs/DLLs...
W.S. schrieb: > Jaja. Der böse Kunde ist es also, der die Programmierer zwingt, sich ihr > Zeugs aus "alles an Frameworks was du finden kannst" zusammenzusuchen > und das Zeug, was sie abliefern sollen, von woanders zusammenzukopieren. Nenn ihn "Kunde", "Vorgesetzter", "Manager", "Geschäftsführer", oder meinethalben auch "Bittsteller": aber ja, hinter jedem Entwickler in der kommerziellen Welt gibt es einen kleinen Helden, der dem Entwickler sagt, dass das alle bitteschön schneller gehen muss. Sei glücklich, dass Du nicht in der Welt der kommerziellen Entwicklung von Hard- oder Software arbeiten musst. Tatsache ist nämlich, dass heute nur noch die OpenSource-Welt es sich leisten kann, angekündigte Releasezeitpunkte zu verfehlen. Hinter den meisten anderen Entwicklern steht irgendein... Mensch, der im besten Fall vor zwanzig Jahren mal ein "Programm" mit 45 Zeilen Visual Basic zusammengeklickt hat und heute denkt, wenn ein Entwickler täglich im Schnitt 50 Zeilen Code abliefern kann ist er besser, wertvoller, und muß besser bezahlt werden als einer, der zehn Zeilen löschen und damit die Laufzeit der Software in diesem Bereich um einen Faktor zehn verbessern konnte.
c-hater schrieb: > Genau genommen ist die virtuelle Speicherverwaltung von Windows und den > heutigen Unixoiden-Abkömmlings praktisch gleich in ihrer Funktionsweise. Wenn das zuträfe, würde es mich aber sehr wundern, warum die Speicherverwaltung von Windows nach unseren Messungen so viel langsamer ist. > Was du Dummkopf scheinbar nicht begreifst, ... > Letztlich ist das aber nur ein Rumdoktorn an Symptomen. Was wirklich > bekämpft werden müsste, ist der unsägliche, immer weiter um sich > greifende Bloat der shared libs/DLLs... Die Mehrheit der User wollen das, gewöhn' Dich dran und leb' damit. User interfaces sell Software, wie wir (nicht erst) seit Windows95 wissen. Und wenn die OpenSource-Leute dabei nicht zumindest bei den verbreiteten Desktops mitgingen, könntest Du noch viel mehr über OpenSource ranten, Du Oberfeldwebel aller Dummköpfe. ;-)
90erCrack schrieb: > Es sollen nun keine Spiele gecrackt werden, aber mal ein Taschenrechner > oder eine andere simple Anwendung geschrieben werden. > (Erstmal unter Windows, aber gerne auch generell.) LCC-Win mit Win32 Api Uwe
90erCrack schrieb: > Hallo liebe Gemeinde, > > Einige kennen es vielleicht noch. In den 90ern und frühen 00ern gab es > mal so Spiele CDs/DVDs. > Darauf enthalten waren neben Spielen auch entsprechende Cracks. > Diese Cracks enthielten Programmcode inkl GUI und so n 8bit Titelsong in > einer einzelnen Datei. Alles zusammen wenige 100kb groß. Du verwechselst da was, die kleinen Sachen wurden per Diskette verteilt, nicht CD. https://www.youtube.com/watch?v=50WWFEBsgfk Und so ne GUI unter DOS hat man damals im ersten Semester programmiert, einfach BIOS Routinen abgefragt oder direkt an die Hardware. Wie das geht stand in den damaligen Computermagazinen: https://www.kultmags.com/mags.php Wers langweilig aber professionel wollte nahm ASCII-GUI-Umgebungen. https://de.wikipedia.org/wiki/Turbo_Vision
Uwe B. schrieb: > LCC-Win mit Win32 Api Wenn man den zum Laufen kriegt. Beim Watcom-Compiler hat man mehr von einem 16/32 Bit-System. Läuft aber bei mir auch auf Windows 8 ganz ordentlich, und eine 64 Bit Version soll es auch geben. Früher wurde auch viel mit Pascal gemacht - Aber die Petzoldbücher (C-Programmierung) sind auch erste Wahl, allerdings waren die ersten Versionen noch überschaubar, jetzt sind die eher unüberschaubar und mehrere Bücher zur Qual der Auswahl hat man auch noch. Heute geht aber auch Visual C und Visual C++ (Express oder Community) Und bei Stackoverflow bei Fragen nachschauen ist auch nicht so verkehrt: https://stackoverflow.com/questions/31718375/visual-studio-express-edition-vs-community Und bei Grundbegriffen nicht vergessen, gleich hier oder da nachzuschlagen: https://de.wikipedia.org/wiki/Stack_Overflow_(Website) https://de.wikipedia.org/wiki/Puffer%C3%BCberlauf https://wiki.edu.vn/wiki15/2020/12/22/bios-interrupt-aufruf-wikipedia/ https://open-watcom.github.io/ Diablo2 wurde u.a. mit dem Watcom Compiler und Javascript entwickelt.
Ach so, und wenn man Langeweile hat, könnte man sich auch noch den bc Sourcecode ansehen, oder die Angner Fog - Seiten. http://ftp.gnu.org/gnu/bc/ https://www.agner.org/optimize/
noch was vergessen: das ein oder andere gute Buch zu linearer Algebra oder zu Algorithmen anzuschaffen/zu lesen ist auch nicht so verkehrt.
Uwe B. schrieb: > LCC-Win mit Win32 Api Dann vergesse aber bitte nicht dein Compilat bei VirusTotal immer auch einer Überprüfung zu unterziehen. Ich hab vor Jahren diesen Compiler (eigentlich ist es eine komplette IDE) und den Pelles C Compiler (auch IDE, nur besser) gerne gelegentlich zur Übung meiner überschaubaren Programmierkenntnisse benutzt und bin damit immer und immer wieder mit False Positiv Virusmeldungen vom AVIRA überzogen worden (die ich immer alle schön gemeldet habe, damit sie beseitigt werden). Irgendwann wurde es mir dann aber zu bunt und ich habe es aufgegeben zu Gunsten von Visual Studio. Dann hatte ich diesbezüglich wenigstens Ruhe. Ob das immer noch so ist weiß ich nicht.
rbx schrieb: > .. > Früher wurde auch viel mit Pascal gemacht - Aber die Petzoldbücher > (C-Programmierung) sind auch erste Wahl, Für mich immer noch eines der besten Einstiegsbücher in die Win32-Programmierung. Halt inzwischen stark überaltert aber noch immer sehr lehrreich. > Heute geht aber auch Visual C und Visual C++ (Express oder Community) Der Vorteil der ersten Visual C und C# 2010 Express Editionen war, die erzeugten Programme z.B. bei C# liefen noch in anderen als dem erzeugenden Ordnern Laufwerken Rechnern (natürlich auch dort nur mit .net Installation). Bei der aktuellen Community (die sehr mächtig ist) startet bei mir derzeit kein C# Compilat mehr, ohne einen Haufen Fehlermeldungen. Bei Visual C konnte man um solche Probleme zu umgehen einfach statisch linken (was bei C#/.net so wohl grundsätzlich nicht möglich ist). Ich hab allerdings jetzt auch länger nix mehr gemacht und muss mich erst wieder einarbeiten (alles immer nur Interessen mäßig). Gruß
Früher war vieles (nicht alles) besser schrieb: >> LCC-Win mit Win32 Api > > Dann vergesse aber bitte nicht dein Compilat bei VirusTotal immer auch > einer Überprüfung zu unterziehen. Ich hab vor Jahren diesen Compiler > (eigentlich ist es eine komplette IDE) und den Pelles C Compiler (auch > IDE, nur besser) gerne gelegentlich zur Übung meiner überschaubaren > Programmierkenntnisse benutzt und bin damit immer und immer wieder mit > False Positiv Virusmeldungen vom AVIRA überzogen worden (die ich immer > alle schön gemeldet habe, damit sie beseitigt werden). Irgendwann wurde > es mir dann aber zu bunt und ich habe es aufgegeben zu Gunsten von > Visual Studio. Dann hatte ich diesbezüglich wenigstens Ruhe. > > Ob das immer noch so ist weiß ich nicht. Heute arbeiten alle Virenprogramm so. Sie schauen in einer Onlinedatenbank nach, ob das Program OK ist. Wenn du dein Programm das erste mal auslieferst wirst du mit Virenwarnungen überzogen, die sind in der Regel alle falsch, führen aber zu endlosen Verwirrungen. Das ist eine ganz üble Branche, du kannst (musst) dich davon als "renomierter Hersteller" freikaufen. Ich würde aber Anfängern von solchen Speziallösungen wie dem Pelles-C abraten. Visual-C ist da einfach zu gut, und spätestens wenn man etwas exotischeres will (COM etwa, oder die neuesten Libs, oder 100% Kompatibilität), kommt man eh nicht darum herum. Wenn man weniger Overhead will, dann kann man eine alte Version wie den WinDDK 7.1 oder VS-2008 nehmen, die linken noch mit der bei Windows mitgelieferten msvcrt.dll, die zudem weniger Overhead hat. Und wie mein Test weiter oben mit Hexcalc zeigt, kann man damit auch heute noch Programme unter 10kByte bauen (dynamisch gelinkt).
:
Bearbeitet durch User
Udo K. (udok) schrieb: > Heute arbeiten alle Virenprogramm so. Sie schauen in einer > Onlinedatenbank nach, ob das Program OK ist. Wenn du dein Programm das > erste mal auslieferst wirst du mit Virenwarnungen überzogen, die sind in > der Regel alle falsch, führen aber zu endlosen Verwirrungen. > Das ist eine ganz üble Branche, du kannst (musst) dich davon als > "renomierter Hersteller" freikaufen. Die "Onlinedatenbank" hilft dir da nicht weiter. Es ging mir hier nicht um kommerziell, fertige zur Auslieferung bestimmte Programme, sondern um das Comlilat während der Programmerstellung. Mein AVIRA hatte mir sehr häufig direkt nach dem Compilieren in Pelles C die Exe sofort in Quarantäne geschoben, weil ihm bestimmte Bytemuster nicht gefielen bzw. verdächtig vorkamen. Das konnte ich zwar (mit Zeitaufwand) meistens ausmerzen, indem ich meine Exe an Avira zur Überprüfung schickte. Dann war nach deren Anpassung ihrer Signaturen auch erst mal Ruhe. Spätestens jedoch mit neuen, späteren Virensignaturen oder einem Update von Avira fing der "Spass" wieder von vorne an. Das gleiche bei LCC-Win32. Davon hatte ich irgendwann die Schnauze gestrichen voll (zu diesem Zeitpunkt traute ich mich noch nicht den Avira aufzugeben). Du kannst ja mal die Probe machen und eine kleine Exe aus Pelles C / LCC-Win32 zu Viraustotal hochladen. Falls dort was gefunden wird, das gleiche dann nochmal mit dem Compilat durch Visual C (sollte unauffällig sein). Gruß
https://de.wikipedia.org/wiki/Turbo_Assembler Turbo Pascal, bzw. auch mit Assembler und Debugger und praktischen Zusatzwerkzeugen und -Hilfen war ein ziemlich gutes lern- und produktivitätsfreudliches Packet, was auch viel Spaß gemacht hatte - zu DOS-Zeiten - wo teilweise auch noch die Grafikschnittstelle auf Assemblerebene gut dokumentiert war. Weiter unten auf der Wikiseite sieht man Asmcode, den man auch noch kürzer hinbekommt, wenn man auf das Segmentmanagement verzichten kann. Wenn die Nachricht nicht so lang ist, kann man diese auf die Register verteilen, und von dort (wie oben) ablesen, dann spart man sich noch den Speicherzugriff. Wenn man aktuell Buchstaben verändern muss, kann man schauen, wie weit man mit logischen Operationen kommt, und dann Spaß mit den aktuellen Erweiterungen haben: https://de.wikipedia.org/wiki/Advanced_Vector_Extensions Wenn man sich fragt, was ist eigentlich aktuell interessant, dann finde ich z.B. Linux 4K - Überlegungen ganz gut. Hier ist ein Video, welches einen recht guten Überblick bietet, welche Vorgehensweisen da zum Einsatz kommen: https://www.youtube.com/watch?v=-UQSiRg8Ra0 sollte man u.a. auch können oder wenigstens kennen: https://de.wikipedia.org/wiki/Datenkompression https://de.wikipedia.org/wiki/Huffman-Kodierung https://de.wikipedia.org/wiki/Endlicher_Automat https://de.wikipedia.org/wiki/Nichtdeterministischer_endlicher_Automat https://de.wikipedia.org/wiki/Markow-Kette
Da wurden doch nur paar Bits umgestempelt um das Spiel ohne was laufen zu lassen. Der Rest war auf der CD.
Hey!! Wenn Du wirklich ein90'er Crack bist, dann sind die Bücher "PC Underground" von Data Becker und "Effektives Programmieren mit Turbo Pascal 6.0" und Nachfolger ein Muß in Deinem Bücherregal. In Pc-Underground wird alles besprochen, was ein Scener wissen muß: - Vga unter Dos - Abspecken deiner Programme - Kopierschutz - Ton mit der Soundblaster - Kampf des Sceners gegen die Debugger - Patchen von Exen - Assembler vom Feinsten Zwar ist alles noch unter DOS, aber absolut geil, etwa wie die Ausnutzung des Prozessorcaches für den Kopierschutz... mfg
Bei den graphischen Sachen werden einfach nur zufälle und mathematische Tricks benutzt die wenig Code mit großem Effekt erzeugen. Opengl macht es noch einfacher.. Mandelbrot ist ein gutes Beispiel ;)
TotomitHarry schrieb: > Opengl macht es noch einfacher.. Vulkan ist aber effizienter und ermöglicht genaue Kontrolle über die Ressourcen und wann diese zwischen RAM und VRAM hin und her bewegt werden. Über die "ahead-of-time"-Definition der Grafik-Pipeline wird viel Overhead beim Rendern gespart. Blöd nur dass ein Minimal-Hello-World mit Vulkan (1 Dreieck darstellen) schlappe 1000 LoC braucht, und die exe entsprechend groß wird. Auch weil man noch zusätzliche Libraries wie GLFW zur Bereitstellung des Grafikkontexts braucht, und wahrscheinlich noch eine Loader-Library. Was ist das dann, Low-Overhead oder Bloat?
90erCrack schrieb: > Diese Cracks enthielten Programmcode inkl GUI und so n 8bit Titelsong in > einer einzelnen Datei. Alles zusammen wenige 100kb groß. Pah, die Star Port BBS Intro 2 von Future-Crew aus dem Jahre 1993 ist genau so groß (1993 Bytes): https://www.youtube.com/watch?v=060OuqrthqU
Programmierer schrieb: > Vulkan ist aber effizienter und ermöglicht genaue Kontrolle über die > Ressourcen und wann diese zwischen RAM und VRAM hin und her bewegt > werden. HowToMake für ein 64k Intro ;) Allerdings OpenGL.. http://www.lofibucket.com/articles/64k_intro.html
Lotta . schrieb: > ey!! > > Wenn Du wirklich ein90'er Crack bist, dann sind die Bücher > > "PC Underground" von Data Becker > und > "Effektives Programmieren mit Turbo Pascal 6.0" und Nachfolger > ein Muß in Deinem Bücherregal. Nicht zu vergessen "PC Intern".
Früher war vieles (nicht alles) besser schrieb: > Mein AVIRA hatte mir sehr > häufig direkt nach dem Compilieren in Pelles C die Exe sofort in > Quarantäne geschoben Ich hätte daraufhin Avira in Quarantäne geschoben. Dauerhaft.
Und wichtig ist der richtige Umgang mit den Bibliotheken. Fremde Libs zerlegt man mit dem Librarian in ihre Objektdateien, eigene Libs legt man so an, das jede Funktion oder Klasse in eine extra C-Datei kommt. So bindet der Linker dann nicht die ganze Lib ein, sondern nur die referenzierten Objektmodule. Dies spart ne Menge Platz in der EXE oder im Flash. mfg
Lotta . schrieb: > Und wichtig ist der richtige Umgang mit den Bibliotheken. > Fremde Libs zerlegt man mit dem Librarian in ihre Objektdateien, > eigene Libs legt man so an, das jede Funktion oder Klasse > in eine extra C-Datei kommt. Das ist schon lange nicht mehr nötig. Mit ein paar Compiler/Linker-Flags geht das alles vollautomatisch, es werden nur genau die Funktionen und globalen Variablen eingebunden die man braucht, sowohl aus statischen Libs als auch aus eigenem Code. Beim GCC: -ffunction-sections -fdata-sections beim Kompilieren, -Wl,--gc-sections beim Linken. -flto hilft zusätzlich. Das muss allerdings auch beim Compilieren der Lib angegeben werden, sonst passiert es auf Dateibasis statt Funktionsbasis. Bei Open-Source-Libs also kein Problem.
Boahhh! Ob das beim C-Lang auch ähnlich ist? Das spart ja dann ne Menge Arbeit! :-O ich werd also heut Abend mal nachschauen, Danke!! mfg
Lotta . schrieb: > Ob das beim C-Lang auch ähnlich ist? Ja, der kann das sogar noch besser, GCC hat das mit dem LTO "nachgemacht". Im Embedded-Bereich ist das quasi Standard so, die diversen IDEs (z.B. STM32CubeIDE) setzen diese Flags standardmäßig zum Flash-Sparen.
Das einzelne Bit zu zaehlen wie damals ist heute m.E. nicht mehr sinnvoll. Schlanke Programme ohne Abhaengigkeiten dagegen schon. Das Ziel laesst sich mit Lazarus erreichen, kompiliert unter Windows direkt fuers Win-Api, es wird keinerlei DLL oder andere Laufzeitbibliothek benoetigt, alles ist in einer kleinen* Exe vereint. Fuer Linux gilt im Grunde das gleiche, nur dass Linux keine einheitliche Api hat, je nach Distribution ist GTK oder QT vorinstalliert. Hat man in seinem Lazarusprogramm fuer das andere Widgetset kompiliert, muss man das fehlende halt auf Linux nachinstallieren, aber nur einmal. *aber auch nicht nur 100k fuer ein ausgewachsenes Programm.
Maxe schrieb: > Das Ziel laesst sich mit Lazarus erreichen Geht mit C oder C++ aber auch, wenn einem das so wichtig ist, auch mit den gängigen Compilern (GCC, Clang, MSVC).
90erCrack schrieb: > Diese Cracks enthielten Programmcode inkl GUI und so n 8bit Titelsong in > einer einzelnen Datei. Alles zusammen wenige 100kb groß. > > Wie wurde das gemacht. Die Musik wurde in der Regel mit Trackern erstellt und dann kleine eingebettete Tracker in den restlichen Programmcode geschrieben, die das dann abspielen konnten: https://de.wikipedia.org/wiki/Tracker_(Musik) Damit wurden dann auch Spiele untermalt: https://www.youtube.com/watch?v=26I-Pw-yPJ4 Das klang besser als MIDI und brauchte weniger Platz als MP3 und OGG. Was die DEMO Szene betrifft. Die beste PC Demo aller Zeiten und immer noch legendär ist diese: https://www.youtube.com/watch?v=rFv7mHTf0nA Die war so gut, dass sie sogar kopiert wurde: https://www.youtube.com/watch?v=-Da6e-BjhWM
Und wenn du mal sehen willst, wie das in einem Tracker aussieht: https://www.youtube.com/watch?v=eeYyRAIJkkI
Nano schrieb: > 90erCrack schrieb: >> Diese Cracks enthielten Programmcode inkl GUI und so n 8bit Titelsong in >> einer einzelnen Datei. Alles zusammen wenige 100kb groß. >> >> Wie wurde das gemacht. > > Die Musik wurde in der Regel mit Trackern erstellt und dann kleine > eingebettete Tracker in den restlichen Programmcode geschrieben, die das > dann abspielen konnten: > https://de.wikipedia.org/wiki/Tracker_(Musik) Korrektur, da ich das etwas unglücklich formuliert habe. Man brauchte natürlich nur einen einzigen eingebetteten Tracker in der Software und der hat dann die ganzen Trackerdateien abgespielt.
Nano schrieb: > Die war so gut, dass sie sogar kopiert wurde: Beeindruckend fand ich auch den Nachbau auf dem C64: https://www.youtube.com/watch?v=zVPW40ygds4 Übrigens gehört die Demoszene sogar zum UNESCO-Weltkulturebe: https://www.unesco.de/en/culture-and-nature/intangible-cultural-heritage/demoscene-culture-digital-real-time-animations
:
Bearbeitet durch User
Rolf M. schrieb: > Nano schrieb: >> Die war so gut, dass sie sogar kopiert wurde: > > Beeindruckend fand ich auch den Nachbau auf dem C64: > https://www.youtube.com/watch?v=zVPW40ygds4 Da bin ich ganz deiner Meinung. > Übrigens gehört die Demoszene sogar zum UNESCO-Weltkulturebe: > https://www.unesco.de/en/culture-and-nature/intangible-cultural-heritage/demoscene-culture-digital-real-time-animations Das ist gut zu wissen, danke für die Info.
Bezüglich wenige 100kb, hier mal wie viel mein Standalone 3D Renderer, der einen gelben Würfel Rendert, auf meinem Devuan Linux verbraucht. (https://github.com/Daniel-Abrecht/dparaster) Statisch gelinkt: 877K (O3, 874K bei Os) (Ist halt libc, mit musl wäre das sicher viel weniger) Dynamisch: 17K (Hauptanwendung) + 34K libdparaster.so (mit O3, 26K mit Os) (ldso usw. nicht mit eingerechnet) Also so ein simples 3D Programm, kriegt man auch heute noch in wenige 100kb, mit normalem C. Man muss nur die Libc und Linker Flags usw. richtig setzen, und darf keine Riesen Libs rein tun. Ok, das OS ist da auch nicht mit dabei. Aber auch das wäre machbar, man kann sowas auch zu einer EFI Firmware kompilieren, das sollte nicht viel mehr verbrauchen, und das EFI bietet meist auch einen Framebuffer.
:
Bearbeitet durch User
Besten Dank euch für all die vielen Informationen und Verweise. Hier sind wirklich viele nützliche Antworten zusammengekommen.
Lothar schrieb: > "In contrast to user interface libraries like GTK, Qt, and wxWidgets, Wer hat denn das aufgeworfen, dass die LIBs in wxWidgets groß seien? Es wird minimal nur das beigepackt, was an Funktionen benötigt wird und was man beim user eventuell als nicht vorhanden annimmt, bzw. weil es standalone arbeiten soll. Ansonsten kann man das ganz ohne großartiges bundle vertreiben, bzw. man verklickert dem Kunden, dass er einmal eine standard Lib aufspielt. Die redistris von Visual Studio werden ja auch oft und gerne mit beigepackt und blähen den Installer auf. Ich finde wxWindows / wxWidgets immer super! Leider ist das wegen QT ein wenig aus der Mode. Ich habe das aber öfters genutzt, z.B. auch in meiner damaligen Firma: https://web.archive.org/web/20040805132504fw_/http://www.wxwidgets.org/users.htm Parallele Entwicklung war damals groß in Mode gekommen. Neben z.B. dem Audiobearbeiter Audacity wurden damals einige Programme parallel in WIN und LIN entwickelt, z.B. das VHDL Studio: https://web.archive.org/web/20040810170124/http://gmvhdl.com/VHDLStudio.html Unter anderem darüber bin ich damals zum VHDL gekommen. Daniel A. schrieb: > mein Standalone 3D Renderer Ich hätte noch einen fertig abgepackten code zur Berechnung von Kühlkörperthermik mit optischer Simulation der Wärmeausbreitung auf der Basis von OpenGL. Waren so 150kB. Braucht sonst nix.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.