Hallo zusammen, ich habe eben versucht, die fakecom auf http://hugi.scene.org/online/hugi27/hugi%2027%20-%20coding%20corner%20darkblade%20creating%20a%204k%20windows%20intro%20-%20part%201.htm mit NASM zu erzeugen. Das hat denke ich auch geklappt. Allerdings meckert Windows10/64Bit beim Starten: "Das Programm bzw. das Feature "...com.com" kann aufgrund einer Inkombatibilität mit 64Bit-Versionen von Windows nicht gestartet bzw. ausgeführt werden. Wenden Sie sich an den Softwarehersteller, um zu erfahren, ob eine mit 64 Bit-Windows kompatible Version verfügbar ist." Am Ende des Tages würde ich mich gerne mal an einer 4k-Demo versuchen. Hab schon einige Seiten im Netz gelesen und mir auch schon ein Projekt angesehen: http://jet.ro/visuals/4k-intros/andromedary/ Allerdings würde ich erstmal das Tooling verstehen und eine einfache lauffähige main{return 0;} kleinstmöglich erzeugen... Viele Grüße, Peter
Die aktuellen 64Bit-Windows-Versionen können prinzipiell keine 16-Bit Programme mehr ausführen. Damit fallen .com-Programme schon mal aus. Du brauchst also einen 32Bit-Compiler/Assembler, damit ist dann aber der Maschinencode schon mal nicht mehr so kompakt. Ansonsten virtualisieren, mit Vmware oder ähnlichem.
Peter schrieb: > Allerdings würde ich erstmal das Tooling verstehen Was da erklärt wird wie EXE to COM, COM komprimieren usw. geht als 64bit alles nicht, das ist ein Relikt aus einer fernen Vergangenheit. Such dir was anderes als Einstieg, MSDOS ist mausetot. Georg
Heiko G. schrieb: > Die aktuellen 64Bit-Windows-Versionen können prinzipiell keine 16-Bit > Programme mehr ausführen. Damit fallen .com-Programme schon mal aus. Du > brauchst also einen 32Bit-Compiler/Assembler, damit ist dann aber der > Maschinencode schon mal nicht mehr so kompakt. Der Grund, warum für die 4k-Demos immer .com-Files verwendet werden, ist vor allem, dass man sich den .exe-File-Header sparen kann, da der in dem Fall schon erheblich Platz verbraucht. Die .com-Files enthalten einfach direkt den Code, ohne jegliches "drumherum".
Mit DOSBox lassen sich auch alte DOS-Programme weiterbetreiben, das ist also auch die richtige Umgebung für 4k-Demos etc. Nein, die Windows-Eingabeaufforderung ist keine Dos-Box, auch wenn sich der Irrglaube hartnäckig hält. Das war nur unter den 16-Bit- und den Pseudo-32-Bit-Frickelversionen so (d.h. 95/98/Me). http://www.dosbox.com/ Mit DOSBox lassen sich auch andere Dinge veranstalten; ich habe hier mal beschrieben, wie ein alter Parallelport-EPROM-Programmierer damit unter Windows 8.1 x64 weiterverwendet werden kann: Beitrag "[Anleitung] DOS-Parallelport-EPROMer unter Windows 8.1 (x64)"
...also Emulation (DOS Box) möchte ich definitiv nicht. Es soll ein
möglichst kleines Windows - von mir aus - Console Programm werden.
Was kann man noch optimieren? Das Kleinste was ich gestern mit
Compilereinstellungen in VisualStudio startbar erzeugen konnte war eine
main {return 0;} mit ca. 3,8 KB. Was kann man denn sonst noch machen?
Würde C etwas daran ändern?
Viele Grüße,
Peter
Peter schrieb: > Es soll ein > möglichst kleines Windows - von mir aus - Console Programm werden. Nur so aus Interesse? Praktisch bringt das ja bei vielen GB Speicher nichts, wahrscheinlich reserviert auch dein Mikroprogramm erst mal unzählige MB Stack- und Heap-Speicher. Peter schrieb: > Würde C etwas daran ändern? Eher zum Negativen - der C-Compiler bindet als erstes Bootup- bzw. Init-Code ein, den du nicht brauchst, wenn dein Programm nichts tut. Und wenn du Pech hast, wird gleich die ganze Runtime-Library mit eingebunden, ob benutzt oder nicht. Georg
Schau Dich mal bei Free-DOS um. Habe damit ein paar Antiquitäten unter Fenster 7 zum Laufen bekommen. Ich glaube die ursprüngliche Intension war wohl, ein paar alte Spiele wiederzubeleben. Bei mir geht’s aber auch mit normalen Programmen.
Georg schrieb: > Eher zum Negativen - der C-Compiler bindet als erstes Bootup- bzw. > Init-Code ein, den du nicht brauchst, wenn dein Programm nichts tut. Und > wenn du Pech hast, wird gleich die ganze Runtime-Library mit > eingebunden, ob benutzt oder nicht. Das kann man aber alles mit einem eigenen C run-time (crt.o) umgehen.
Peter schrieb: > Am Ende des Tages würde ich mich gerne mal an einer 4k-Demo versuchen. ich kann dir keine Konkreten Tipps geben, aber als einstieg solltest du dich mit dem Windows-PE-Format und dem Vorgang beim Laden eines Programms beschäftigen. zB ein treffer, der auf den ersten Blick interessant aussieht. http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc/pefile2.html Dann kannst du versuchen herauszufinden, an welchen ecken und enden man am Header sparen kann. Als assembler kannst du masm32 benutzen. und am Anfang damit experimentieren. Der ist recht komfortabel. Dann könntest du auch versuchen, ob du das Visual Studio davon überzeugen kannst, den ganzen C-Standard-Quatsch wegzulassen und dich direkt nach den Laden ran zu lassen. Du könntest versuchen eine eigene minimale Variante der c-Runtime zu bauen. Dazu musst du dem Linker sagen: /NODEFAULTLIB und selbst die benötigten Synbole bereitstellen. Edit: Konkrete Optimierungsansätze: - MSDos-Programm rausschmeißen, - optional Header raus - Ressourcen sowieso raus - dll-imports über Zahlen anstatt Funktionsnamen.
:
Bearbeitet durch User
...hab eben mal http://mathimaaran.angelfire.com/helloworld_tutorial.htm getestet. Ist schon mal für eine MSG-Box nicht so schlecht (wenngleich ich das immer noch einen ziemlichen Hammer finde, für im Endeffekt einen Funktionsaufruf): 2576 B. Werd' mal sehen, ob man da was mit OpenGL oder DirectX hinbekommt...
Hier hat einer mal versucht unter Linux ein möglichst kleines Binary zu erzeugen. Vielleicht ist das eine hilfe für dich im Prinzip musst du das gleiche für Windows machen. (oder auf Linux Wechseln, wenn das eine Option ist) http://timelessname.com/elfbin/
Peter schrieb: > Das Kleinste was ich gestern mit > Compilereinstellungen in VisualStudio startbar erzeugen konnte war eine > main {return 0;} mit ca. 3,8 KB. Das geht besser. Eine leere main ergibt bei mir 1k, ein HelloWorld 2k (VS2013). Bei letzterem sind dann von den 2k grob geschätzt etwa 400 Byte Header und 1,4k sehen aus wie Füllbytes (0x00), da dürfte also noch mehr gehen.
1 | #include <Windows.h> |
2 | |
3 | void main( void ) |
4 | {
|
5 | WriteFile( GetStdHandle( STD_OUTPUT_HANDLE ), "Hello World!\n", 13, NULL, NULL ); |
6 | }
|
guest schrieb: > da dürfte also noch > mehr gehen. Sag ich doch... Die exe-Datei des obigen HelloWorld hat jetzt 1k. Entscheidend war die Linker-Option "/merge:.text=.rdata". Und wenn man dann noch den Hexeditor zur Hand nimmt. dann sind es nur noch 662 Bytes. 512 Byte für diverse Header und 150 Byte Daten+Code.
Da ergibt sich nur die Frage, ob man sowas noch als 4k-Demo bezeichnen kann. Die Besonderheit war ja gerade, dass man alles in den 4k unterbringt. Wenn man sich nun ein Programm baut, bei dem das Executable zwar kleiner als 4k ist, das aber noch Megabytes an Bibliotheken mit komplexen Funktionalitäten nutzt, wäre da für mich der Reiz verloren. Die Demos damals unter DOS haben ja tatsächlich alles komplett selber gemacht, bis hin zur Ansteuerung der Hardware, ohne Nutzung jeglicher Bibliotheken.
guest schrieb: > guest schrieb: >> da dürfte also noch >> mehr gehen. > > Sag ich doch... > Die exe-Datei des obigen HelloWorld hat jetzt 1k. Entscheidend war die > Linker-Option "/merge:.text=.rdata". > Und wenn man dann noch den Hexeditor zur Hand nimmt. dann sind es nur > noch 662 Bytes. 512 Byte für diverse Header und 150 Byte Daten+Code. Hi! Kannst Du bitte das Projekt anhängen? Das würde ich mir gerne auch mal ansehen.
Rolf M. schrieb: > Die Demos damals unter DOS haben ja tatsächlich alles komplett selber > gemacht, bis hin zur Ansteuerung der Hardware, ohne Nutzung jeglicher > Bibliotheken. Sie liefen ja auch nicht unter einem Betriebssystem. Nein, DOS war kein Betriebssystem, sondern nur ein Programmlader mit Dateisystemverwaltung. Wenn man den "4k"-Ansatz heute verfolgen will, dann nicht unter einem Betriebssystem wie Windows (oder Linux), sondern z.B. als UEFI-Modul. Oder eben auf einem µC ...
Rufus Τ. F. schrieb: > Wenn man den "4k"-Ansatz heute verfolgen will, dann nicht unter einem > Betriebssystem wie Windows (oder Linux), sondern z.B. als UEFI-Modul. Wobei du selbst dort Protokolle und Schnittstellen nutzt, und nicht direkt die Hardware angesprochen wird.
Rufus Τ. F. schrieb: > ... > Sie liefen ja auch nicht unter einem Betriebssystem. Nein, DOS war kein > Betriebssystem, sondern nur ein Programmlader mit Dateisystemverwaltung. > ... Kommt drauf an wie man den Begriff 'Betriebssystem' definiert. DOS hat über sein INT21h sehr wohl eine hardware Abstraktion angeboten, nicht nur für file I/O. Im Ansatz ist genau das der Job eines Betriebssystems. Programme durften aber auch ohne diese Schnittstelle die hardware direkt ansprechen.
The D. schrieb: > DOS hat über sein INT21h sehr wohl eine hardware Abstraktion angeboten, > nicht nur für file I/O. Ja, aber wie unbrauchbar die war, zeigte sich daran, daß sie für wenig mehr genutzt wurde, und eben doch jedes Programm seinen eigenen Kram gemacht hat.
Rolf M. schrieb: > Da ergibt sich nur die Frage, ob man sowas noch als 4k-Demo bezeichnen > kann. Die Besonderheit war ja gerade, dass man alles in den 4k > unterbringt. Wenn man sich nun ein Programm baut, bei dem das Executable > zwar kleiner als 4k ist, das aber noch Megabytes an Bibliotheken mit > komplexen Funktionalitäten nutzt, wäre da für mich der Reiz verloren. > Die Demos damals unter DOS haben ja tatsächlich alles komplett selber > gemacht, bis hin zur Ansteuerung der Hardware, ohne Nutzung jeglicher > Bibliotheken. Das sehe ich anders. Wenn es Libs sind, die auf einer Plattform vorhanden sind, sollte man die auch verwenden dürfen (z.B. DirectX OpenGL etc). Man kann mit 4K unter Verwendung von vielen Libs auch etwas erzeugen, was schlecht aussieht und/oder sich schlecht anhört. Auf dem 64er kommt ja auch niemand auf die Idee Sprites "selbst zu malen"... Für die Sportlichkeit sorgen dann die Teilnahmebedingungen, was man darf und was nicht.
Peter schrieb: > Hi! Kannst Du bitte das Projekt anhängen? Kein Problem. Die t.exe im Zip ist so von VS2013 erzeugt, per Hexeditor entstand dann daraus die t2.exe (0x00 Bytes am Ende entfernt und Größe der Section im Header angepasst).
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.