Forum: PC-Programmierung Wenige 100kb aber alles drin?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 90erCrack (Gast)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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...

von Εrnst B. (ernst)


Lesenswert?

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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Herbert B. (Gast)


Lesenswert?

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.

von Udo K. (udok)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Udo K. (udok)


Angehängte Dateien:

Lesenswert?

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
von Programmierer (Gast)


Lesenswert?

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.

von Udo K. (udok)


Lesenswert?

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

von Udo K. (udok)


Lesenswert?

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...

von Programmierer (Gast)


Lesenswert?

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.

von Udo K. (udok)


Lesenswert?

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
von Programmierer (Gast)


Lesenswert?

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 ;-)

von Udo K. (udok)


Lesenswert?

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
von Programmierer (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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.

von Le X. (lex_91)


Lesenswert?

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.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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
von Programmierer (Gast)


Lesenswert?

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?

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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
von rbx (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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
von rbx (Gast)


Lesenswert?


von 90erCrack (Gast)


Lesenswert?

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ß

von Lothar (Gast)


Lesenswert?

"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

von W.S. (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.

von Pager (Gast)


Lesenswert?

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?

von Udo K. (udok)


Lesenswert?

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...

von c-hater (Gast)


Lesenswert?

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...

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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. ;-)

von Uwe B. (uwebre)


Lesenswert?

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

von Hirn statt Handydaumen (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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/

von rbx (Gast)


Lesenswert?

noch was vergessen: das ein oder andere gute Buch zu linearer Algebra 
oder zu Algorithmen anzuschaffen/zu lesen ist auch nicht so verkehrt.

von Früher war vieles (nicht alles) besser (Gast)


Lesenswert?

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.

von Früher war vieles (nicht alles) besser (Gast)


Lesenswert?

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ß

von Udo K. (udok)


Lesenswert?

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
von Früher war vieles (nicht alles) besser (Gast)


Lesenswert?

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ß

von rbx (Gast)


Lesenswert?

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

von Benedikt L. (Firma: Dem Ben seine Leiche) (dembenseineleiche) Flattr this


Lesenswert?

Da wurden doch nur paar Bits umgestempelt um das Spiel ohne was laufen 
zu lassen.
Der Rest war auf der CD.

von Lotta  . (mercedes)


Lesenswert?

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

von TotomitHarry (Gast)


Lesenswert?

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 ;)

von Programmierer (Gast)


Lesenswert?

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?

von Rolf M. (rmagnus)


Lesenswert?

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

von TotoMitHarry (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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".

von Bernd (Gast)


Lesenswert?

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.

von Lotta  . (mercedes)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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.

von Lotta  . (mercedes)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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.

von Maxe (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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).

von Nano (Gast)


Lesenswert?

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

von Nano (Gast)


Lesenswert?

Und wenn du mal sehen willst, wie das in einem Tracker aussieht:
https://www.youtube.com/watch?v=eeYyRAIJkkI

von Nano (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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
von Nano (Gast)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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
von 90erCrack (Gast)


Lesenswert?

Besten Dank euch für all die vielen Informationen und Verweise.

Hier sind wirklich viele nützliche Antworten zusammengekommen.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.