Hallo zusammen,
mein Anliegen klingt nach einem Scherz, ist es allerdings nicht. Ich
brauche eine 16-Bit-EXE für Windows 3.11, Programmiersprache wäre C
(oder notfalls Pascal). Habe ich mit dem GCC eine Chance, oder muss ich
mich auf die Suche nach einem alten Compiler machen?
Viele Grüße
W.T.
Walter T. schrieb:> (oder notfalls Pascal)
Delphi 1 müsste mit 16-bittigem Windows gearbeitet haben. Erst ab Delphi
2 war das 32-bittig. Übrigens enthielt Delphi 2 eine Kopie von Delphi 1.
Modernes 64-bittiges Windows hat keinen Support fürs 16 Bit Subsystem.
Da müsste man zu Dosbox oder einer 32-bittigen VM greifen. Das gilt
AFAIK blöderweise auch für die Delphi 1 IDE.
Beim GCC habe ich grade keine Idee wo man Header Files und LibC für
16-Bit Windows klauen könnte.
Walter T. schrieb:> Ich brauche eine 16-Bit-EXE für Windows 3.11
Tatsächlich für Windows, d.h. mit Fenstern etc.?
Das wird eklig.
Oder reicht vielleicht auch DOS?
Übrigens gab es für Win 3.1x das Win32s Subsystem Add-On.
Damit konnte man einige Win32 Anwendungen fahren.
Die Wikipedia Page (https://en.wikipedia.org/wiki/Win32s) listet Borland
C++ 4.x als kompatiblen C Compiler.
Walter T. schrieb:> Habe ich mit dem GCC eine Chance
Nein, GCC ist 32bit aufwärts.
Es gab aber auch Opensource-Compiler für 16-bit-Code, außer den
genannten kommerziellen (die nun teilweise kostenlos zu haben sind).
Rufus Τ. F. schrieb:> Tatsächlich für Windows, d.h. mit Fenstern etc.?
Nein, DOS reicht.
Um noch spezifischer zu werden: Ich brauche eigentlich nur ein "Hallo
Welt" als 16-Bit-EXE, spricht: Ein Programm, das bei Start auf einem
16-Bit-kompatiblen System ein "Error - could not run application (Code
01)" und auf einem nicht-16-Bit-kompatiblen System die entsprechende
Fehlermeldung, dass die Datei nicht auf einem 64-Bit-System ausführbar
sei, zurückgibt.
Das klingt völlig bescheuert, und vielleicht ist es das auch.
Veiele Grüße
W.T.
Genau das produzieren die Compiler doch schon. Baue ein simples ganz
normales 32bit Hello World-Programm; der Compiler wird an den Anfang ein
16bit-Programm legen welches die Meldung "this program cannot be run in
dos mode" ausgibt.
Ansonsten organisiere dir den NASM und kopiere hier eines der Beispiele:
https://de.wikibooks.org/wiki/Assembler-Programmierung_f%C3%BCr_x86-Prozessoren/_Das_erste_Assemblerprogramm
Dürfte schneller gehen als eine komplette IDE für C zu installieren.
nimm den Watcom Compiler. Der hat auch einen netten Vi-Clone mit an
Board.
Für ein altes Windows ist es aber nicht zu viel verlangt, das Programm
in assembler mit debug zu erstellen.
(+ die notwendigen Anpassungen im Hexeditor ;)
Walter T. schrieb:> Um noch spezifischer zu werden: Ich brauche eigentlich nur ein "Hallo> Welt" als 16-Bit-EXE
Muss es dafür denn unbedingt ein Compiler sein?
Ausgabe einer Zeichenkette unter MS-DOS geht doch mit einem INT 21h, die
paar Register, die man dafür braucht, kann man wirklich im Assembler
zusammenhacken.
Walter T. schrieb:> mein Anliegen klingt nach einem Scherz, ist es allerdings nicht. Ich> brauche eine 16-Bit-EXE für Windows 3.11, Programmiersprache wäre C
Darf es auch eine .COM sein? Wäre dann wirklich einfach mit debug
machbar.
Christian M. schrieb:> Wieso muss es denn immer dieses völlig veraltete C sein?!
Weil das für den Anwendungsfall eine völlig untergeordnete Rolle spielt?
Christian M. schrieb:> Wieso muss es denn immer dieses völlig veraltete C sein?!
Fängst Du jetzt auch noch mit diesem ... Unfug an? Wir haben eigentlich
genug von der Sorte.
Christian M. schrieb:> Ja eben!
Ja eben. Warum soll man sich dafür dann extra noch was antun, was man
noch nicht kennt? Da wird doch die Soße teurer als das Fleisch.
Hallo Walter T.,
würde es Dir nützen, wenn ich Dir mit Turbo Pascal eine EXE erzeuge?
Ich habe noch eine TP6-Installation am Laufen.
Wenn Interesse besteht, was soll das Programm ausgeben?
Gruß
WIRO
Walter T. schrieb:> auf einem nicht-16-Bit-kompatiblen System die entsprechende> Fehlermeldung, dass die Datei nicht auf einem 64-Bit-System ausführbar> sei
Das IST bescheuert - ein Programm, das auf einem 64-bit-System nicht
startet, kann auch nicht melden, dass es nicht startet. Dazu müsste es
ja ein 64-bit-Programm sein.
Es kommt schon eine Meldung, eine der berühmten von Mikrosoft.
Georg
WIRO schrieb:> würde es Dir nützen, wenn ich Dir mit Turbo Pascal eine EXE erzeuge?
Das würde mir sogar sehr helfen. Bin nämlich gerade dabei, nach den
alten Installationsdateien für Win3.11 zu suchen, um eine virtuelle
Maschine aufzusetzen.
Auf einer 16-Bit-Maschine soll einfach der Text: "Error - could not run
application - Media data not found)" über stdout oder stderr (ist
tatsächlich egal) ausgegeben und der Rückgabewert 1 erzeugt werden.
Hallo Walter T.,
die EXE ist fertig. Sie befindet sich in der Anlage in der Datei
test.zip.
Du kannst die EXE beliebig umbenennen.
Ich würde mich noch für das Testergebnis interessieren.
Gruß,
WIRO
Hallo WIRO,
das Ergebnis auf einem 64-Bit-System ist wie erwartet. Auf dem
32-Bit-System, wo die Meldung ausgegeben wird, kommt auch der korrekte
Rückgabewert.
Auf 16 Bit wird morgen getestet.
Danke, das hilft mir ein ganzes Stück weiter!
Viele Grüße
W.T.
Bert3 schrieb:> Was soll er den mit IDA machen und warum unter Wine?
Er soll ein kleines Windows-16bit-Prg in Linux erzeugen/bearbeiten.
Einfacher wäre debug in Dosbox, aber das ist recht absturzfreudig.
Der lange Weg wäre wohl Windows10 Testcd (o.ä) -> Bochs pcEMU ->
Watcom-compiler -> 16bit-exe
(oder eben Code posten und erstellen lassen.)
Er braucht kein windows programm - nur dos exe reicht ihm
Warum unter linux mit wine wenn er schon eine vm hat?
Warum debuggen in dosbox (soll er da die exe debuggen oder debug.com
feur die erstellung nutzen...oder? Und was meinst du mit absturzfreudig
- bei mir läuft der stabil über stunden in analysen)
Und mir ist immer noch unklar klar was er ueberhaupt in dem Szenario mit
dem IDA machen soll (die exe erzeugen dann im IDA analysieren und
dann...?)
Der aktuelle Watcom läuft problemlos unter win64 und kann dort auch
16bit dos exen erzeugen, auch der dmc läuft noch unter win64
ich vermute zwar nicht, dass das die Diskussion stoppt, aber: Ich habe
mit der mit Borland-Pascal erzeugten EXE tatsächlich exakt das, was ich
brauche.
Also danke nochmal an WIRO!
Jörg W. schrieb:> Nein, GCC ist 32bit aufwärts.>> Es gab aber auch Opensource-Compiler für 16-bit-Code, außer den> genannten kommerziellen (die nun teilweise kostenlos zu haben sind).
Das stimmt nicht so ganz.
gcc-ia16 ist solangsam betriebsbereit. Aber für Windows 3.1 ist das
glaube ich wiederum nix, nur DOS/bare-metal.
Ich kann dir auch nur den Watcom empfehlen. Oder Borland C++ ab Version
3.1. Gibt's "kostenlos" auf winworld und anderen Abandonware-Seiten.
Ich sage dazu aber nur, dass man sich da in einer Grauzone bewegt, wo
kein Hahn nach kräht, aber im Prinzip macht man sich damit angreifbar.
Entscheide selbst.
Die Watcom IDE ist Murks, Borland ist da deutlich besser. Auch die
online Hilfe und die Examples die mitkommen. Bei watcom suchst du dir
einen Wolf in der Doku.
Die von Watcom ist echt gut, da kann man nichts gegen sagen, aber sehr
schwer sich darin zurechtzufinden.
Viele Tausend Seiten in 10 PDFs ohne Bookmarks/Links/Seitennummern nicht
konsistent...
Ausserdem ist das Aufsetzen des Watcom Compilers, wenn man die IDE nicht
will, ein Graus. Liegt aber wiederum an dem Dokuformat...
Die compiler-switches sind mindestens ungewohnt für heutige
Verhältnisse...
rbx schrieb:> Er soll ein kleines Windows-16bit-Prg in Linux erzeugen/bearbeiten.
Mit IDA? Ich zerlege damit ROMs erfolgreich seit mehr als 10 Jahren.
Dass man damit Programme schreiben kann, ist mir neu.
Ausser du meinst das Debug-Beispiel aus dem DOS-6.22 Handbuch auf totem
Baum, in dem gezeigt wird, wie man mit debug eine Hello-World .com Datei
erstellt.
Dafür braucht man aber kein IDA, da reicht ein hexeditor.
Wenn's um Debugger geht: Borland C++ 3.1. Hat source-level debugger für
DOS und Windows.
Hat sehr gute Beispielprojekte, Doku und Bedienung wirklich einfach.
IDA läuft in neueren Versionen leider nicht mehr mit Wine. Dafür aber in
einer Windows VM mit VirtualBox im seamless/nahtlos Modus perfekt.
> Einfacher wäre debug in Dosbox, aber das ist recht absturzfreudig.
Das kann ich nicht bestätigen, vielleicht liegts an falschen Eingaben
auf deiner Seite? Ein jump ins Nirvana lässt jeden Rechner abstürzen, ob
emuliert oder echt.
und wegen der VM und verschiedener alter Software: winworldpc.com
PPB schrieb:> dass man sich da in einer Grauzone bewegt, wo> kein Hahn nach kräht, aber im Prinzip macht man sich damit angreifbar.
Es gibt oder gab zumindest bei Borland eine Site zum legalen
Herunterladen uralter Turbo-Pascal-Versionen. Von da habe ich z.B. Turbo
Pascal 3.02 und Turbo C 2.01 und noch einiges andere, aber nicht aktiv
im Einsatz, bloss für Notfälle (wie beim TO).
Georg
Jörg W. schrieb:> Ausgabe einer Zeichenkette unter MS-DOS geht doch mit einem INT 21h, die> paar Register, die man dafür braucht, kann man wirklich im Assembler> zusammenhacken.
Ja, wikibooks und nasm sind toll für sowas :)
Walter hat ja schon eine Lösung, aber auch schön, die vielen
Möglichkeiten hier so zu lesen. Er vermutete ja auch, dass die
Diskussion noch nicht aufhört :D
georg schrieb:> Es gibt oder gab zumindest bei Borland eine Site zum legalen> Herunterladen uralter Turbo-Pascal-Versionen. Von da habe ich z.B. Turbo> Pascal 3.02 und Turbo C 2.01 und noch einiges andere, aber nicht aktiv> im Einsatz, bloss für Notfälle (wie beim TO).
Ja da dämmert was... War damit nicht irgendwas? Also mit dem TC201,
sowas wie kein Assembler, kein Debugger und keine Hilfe dabei, oder so?
Hier mein Versuch. Eine 16bit DOS-Executable welche die gewünschte
Meldung und Return-Code 1 ausgibt. Der Assembler-Code ist aus dem
Internet zusammengestoppelt:
1
code segment public
2
assume cs:code,ds:code
3
start: org 100h
4
5
mov dx,20Ch
6
mov ah,9
7
int 21h
8
9
mov ax,4c01h
10
int 21h
11
12
hello: db 'Error - could not run application - Media data not found)', 13, 10, '$'
13
14
code ends
15
end start
Assembliert und gelinkt mit dem "Arrow Assembler". Funktioniert in der
Dos-Box :-)
Walter T. schrieb:> Error - could not run application (Code 01)" und auf einem> nicht-16-Bit-kompatiblen System die entsprechende Fehlermeldung, dass> die Datei nicht auf einem 64-Bit-System ausführbar sei, zurückgibt
Und was soll das Programm auf einem 32 bit system machen?
Dumdi D. schrieb:> Und was soll das Programm auf einem 32 bit system machen?
Dazu stand deshalb nichts im "Lastenheft" im Eröffnungspost, weil es
schlichtweg egal ist. Es darf gerne den Säbeltanz von Katschaturian als
MIDI über den PC-Lautsprecher in voller Länge abspielen, bevor es sich
mit einem beliebigen Fehlercode beendet.
Walter T. schrieb:> Es darf gerne den Säbeltanz von Katschaturian als MIDI über den> PC-Lautsprecher in voller Länge abspielen, bevor es sich mit einem> beliebigen Fehlercode beendet.
ROTFL :-)
Niklas G. schrieb:> mov dx,20Ch
Sollte das nicht besser
mov dx, hello
oder so ähnlich heißen? Sonst hat dein String zwar schön einen Label,
aber am Ende benutzt du die absolute Adresse …
Auf so eine ähnliche Lösung war ich auch gekommen, konnte sie nur nicht
ausprobieren. Nach einem späteren Post war mir allerdings klar geworden,
dass das wohl eine .com und keine .exe wird (das Wissen darüber
verblasst aber schon langsam :).
Habe es doch nochmal anders gemacht, mit NASM und wine+ALINK. Der Code
ist nahezu unverändert aus dem Wikibook:
1
segment code
2
3
start:
4
mov ax, data
5
mov ds, ax
6
7
mov dx, hello
8
mov ah, 09h
9
int 21h
10
11
mov ax,4c01h
12
int 21h
13
14
segment data
15
hello: db 'Error - could not run application - Media data not found)', 13, 10, '$'
Und das Ergebnis im Anhang. Ist schöner und kleiner.
Jörg W. schrieb:> Sollte das nicht besser
Ja definitiv. Habe aber nicht herausfinden können wie das mit dem Arrow
Assembler geht. Daher hier dieser neue Versuch.
Jörg W. schrieb:> Nach einem späteren Post war mir allerdings klar geworden,> dass das wohl eine .com und keine .exe wird (das Wissen darüber> verblasst aber schon langsam :).
Ja die meisten Tutorials beziehen sich auf .com Dateien... Man braucht
noch einen Linker für .exe-Dateien. Hab mit sowas vor einer Ewigkeit ein
bisschen rumgespielt, und weil ich gerade mit ARM Assembler tüddeln
durfte wollte ich doch nochmal sehen wie man das damals™ so gemacht hat
;-)
Daher aus purem Unfug einfach das gleiche Spiel nochmal für ARM-Linux:
1
#include <sys/syscall.h>
2
3
.section .text
4
.code 32
5
6
.global _start
7
8
.align 2
9
.type _start, %function
10
_start:
11
mov r0, #1
12
adr r1, message
13
mov r2, #(message_end-message)
14
mov r7, #__NR_write
15
svc #0
16
17
mov r0, #1
18
mov r7, #__NR_exit
19
svc #0
20
21
.size _start, .-_start
22
23
.type message, %object
24
message:
25
.ascii "Error - could not run application - Media data not found)!\r\n"
Der aktuelle optlink kann 16bit dos linken, auch der watcom v2 wlink
oder der unilink, da brauch man keinen uralten linker nutzen
Optlink.exe aus dem d language package https://dlang.org/download.html
Aktueller travis build von watcom v2
https://github.com/open-watcom/open-watcom-v2
Aktuelle beta von unilink
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0921.zip
Alle kann man einfach ohne installation entpacken und die entsprechenden
linker exen aufrufen
Bert3 schrieb:> da brauch man keinen uralten linker nutzen
Hat aber gut funktioniert, sogar unter Wine ;-) Diese wunderschöne
Segment-basierte Adressierung zeigt einem direkt wie gut man es auf
32bit-Systemen hat.
Ich hab mal als spassproject ein integer primzahlen berechnungsprogramm
durch einen haufen alter c kompiler gejagt, nebst alter und aktueller
linker, es war erstaunlich zu sehen wie gut das alles noch funktioniert
Muss es unbedingt C sein?
QBasic passt doch zu DOS wie Arsch auf Eimer und ist auf jeder
Win95-Installations-CD dabei (\OLDMSDOS).
QuickBasic 4.5 erzeugt auch eine *.exe oder *.com und ist als
Abandonware im Netz allgegenwärtig.
...und wie schlecht der generierte code zu der zeit teilweise war, ich
bin auf den gcc IA 16 gespannt: https://github.com/tkchia/gcc-ia16 da
siehtman selbst bei kleinen projekten was heutige kompilertechnik auf so
alten platformen noch bringen kann
PPB schrieb:> rbx schrieb:>> Er soll ein kleines Windows-16bit-Prg in Linux erzeugen/bearbeiten.> Mit IDA? Ich zerlege damit ROMs erfolgreich seit mehr als 10 Jahren.> Dass man damit Programme schreiben kann, ist mir neu.>> Ausser du meinst das Debug-Beispiel aus dem DOS-6.22 Handbuch auf totem> Baum, in dem gezeigt wird, wie man mit debug eine Hello-World .com Datei> erstellt.> Dafür braucht man aber kein IDA, da reicht ein hexeditor.
Ich stelle mir auch so Fragen wie - wie erstellt man einen Compiler ohne
Compiler? ;)
(nur mit cat)
Ida (die freie Version) dokumentiert die alten Doscodes bzw. die
klassischen Unterprogramme sehr schön, das ist hilfreich, wenn man sonst
nicht viel Info zu diesem Thema parat hat.
>wie erstellt man einen Compiler ohne Compiler? ;)
So wie echte Männer auch heute noch Programme schreiben sollten
Binärcode, n Stufen bis zu einem guten assembler dann noch n
featurestufen bis zu einem guten kompiler, fertig! Ein kleines
betriebssystem sollte man dabei natuerlich auch noch machen
WIRO schrieb:> die EXE ist fertig. Sie befindet sich in der Anlage in der Datei> test.zip.Walter T. schrieb:> das Ergebnis auf einem 64-Bit-System ist wie erwartet. Auf dem> 32-Bit-System, wo die Meldung ausgegeben wird, kommt auch der korrekte> Rückgabewert.
Aktuell hört man von allen Seiten, die nur einen Hauch Ahnung von IT
haben, wie dumm doch die Politiker waren, deren Daten aufgrund der
aktuellen "Cyberkrise" nun online sind. Weil deren Passwörter wohl zu
billig waren.
Dann scrollt man durch Beiträge in einem Forum, in dem 99% der User mehr
Ahnung von IT haben als der Otto-Normalbürger, und muß sehen, daß jemand
einfach so eine .exe die von einem unbekanntem Gast hochgeladen wurde,
auf mindestens zwei Systemen ausführt.
Da fragt man sich dann im Stillen ob das betreffende System vielleicht
so systemkritisch in einem Unternehmen ist, daß man es nicht einfach
über die letzten Jahrzehnte (!) aktualisieren konnte. Wer weiß,
vielleicht steuert es ja die Zentrifugen einer Urananreicherungsanlage.
Was soll man den nun über die dummen Politikern sagen, wenn schon Leute
mit mehr Ahnung solche katastrophalen Fehler begehen? In einer kleinen
finsteren Ecke meiner Seele gibt es ein bisschen Hoffung darauf, daß
Leute wie Walter zum Schutz der Rest der Welt ihren Job verlieren.
Haettest wohl doch den asm code von Niklas G. nutzen sollen, da waere
die sicherheitsanalyse noch weniger aufwendig ausgefallen, abzueglich
des headers wohl nur ein paar bytes ;)
ganz nebenbei ließe sich der freie Plattenplatz auf dem LW C: ermitteln
und eine Textdatei mit ebensolcher Größe anlegen lassen: schwubbs ->
Platte voll. Zwar nix aufregendes passiert (Datei lässt sich ja leicht
wieder löschen) aber aufgezeigt, was alles ginge... Und das passt auch
locker auf eine A4 Seite im HEX-Editor.
Ich fands "spannend" wie schnell hier angeblich ein "Hacker" ausfindig
gemacht wurde.Auf der einen Seite häggt der Junge Mann etlcihe Seites
und zieht unbemerkt(!) Daten ab und ist dann so blöd, sich innerhalb
eines Tages ausfindig machen zu lassen. Woanders werden zwei tage später
Personalausweise gefunden. Klingt alles sehr inszeniert, damit schnell
ein neues CyberCenter"PLUS" für zig Millionen ins Leben gerufen werden
konnte.
Was genau diese neue Stelle macht, wird und soll sicher niemand
erfahren.
Er hat ja scheinbar nicht gehaeggt sondern nur schon verhandene daten
aus dem inter/darknet gesammelt und strukturiert - eher zeit aufwendig
als "echtes" hacking
Bert3 schrieb:> es war erstaunlich zu sehen wie gut das alles noch funktioniert
Natürlich, an den Primzahlen hat sich nach meiner Information in den
letzten Jahrzehnten ja auch nichts geändert.
Es gibt viele Programme, die noch perfekt funktionieren, weil sie auf
der Gültigkeit von Gesetzen wie Ohm, Kirchhoff, Maxwell usw. beruhen -
die Impedanzberechnung eines Kupferdrahts unter DOS liefert immer noch
das richtige Ergebnis, auch wenn das manche wundert.
Georg
Bert3 schrieb:> Haettest wohl doch den asm code von Niklas G. nutzen sollen, da waere> die sicherheitsanalyse noch weniger aufwendig ausgefallen,
Jein. Zum ersten war die Pascal-EXE zuerst da. Zweitens hatte ich noch
eine EXE-Datei aus TurboPascal (ein von einem Mitschüler zu Schulzeiten
beschriebenes Mini-Berechnungsprogramm) zum Vergleich.
Bei den Assembler-Varianten hätte ich genauer gucken müssen.
georg schrieb:> Es gibt viele Programme, die noch perfekt funktionieren
Das Problem sind auch meist eher die APIs und Sprachstandards und
weniger die tatsächlichen fachlichen Grundlagen. Viele Programme haben
z.B. fröhlich Pointer nach "int" und zurück gecastet; das geht
spätestens bei der Portierung von i386 auf AMD64 schief. Jeder kennt
sicher die Programme, welche ihre Daten/Einstellungen nach C:\Program
Files\ speichern; das klappt ab Vista auch nicht mehr. Alte Linux
Programme welche Gtk+2 und OSS voraussetzen dürften auch ihre Probleme
bekommen, usw usf. Bei DOS hat man immerhin den Vorteil dass das "API"
relativ klein ist und leicht in DOSbox o.ä. nachzuempfinden; mit einem
kompletten Win32-API ist das nicht mehr so einfach.
@meine güte:
Ich bin zu doof, gefährliche Programme zu schreiben und versuche mich
erst noch an nützlichen Aufgaben. Vielleicht hätte dem Walter auch eine
Batch geholfen, da liegt alles offen, das war mir aber zu spät
eingefallen.
Manchmal kann man auch positiv denken und den letzten Satz einfach
weglassen.
Gruß
WIRO
Walter T. schrieb:> Die kleine .EXE-Datei passt im HEX-Editor auf eine Bildschirmseite.
Mir war nicht bekannt daß Schadsoftware eine Mindestgröße haben muß.
...
Oh, muß sie wohl nicht: http://virus.wikidot.com/miniWIRO schrieb:> Manchmal kann man auch positiv denken und den letzten Satz einfach> weglassen.
Mein Kommentar war nicht gegen Dich persönlich gerichtet. Ich mische in
der EDV schon zu lange mit um da überhaupt noch positiv denken zu
können. User die mit nigerianischen Prinzen Geschäfte machen wollen oder
irgendwelche Attachments aus Spammails starten sind da noch am
harmlosesten.
Bei Leuten die Programme unbekannten Ursprungs starten (wo heutzutage
bei jeder Gelegenheit eindringlich davor gewarnt wird) hört mein Mitleid
und Verständnis auf.
meine güte schrieb:> Bei Leuten die Programme unbekannten Ursprungs starten (wo heutzutage> bei jeder Gelegenheit eindringlich davor gewarnt wird) hört mein Mitleid> und Verständnis auf.
Du weißt doch absolut nicht, wo er das gestartet hat.
Wenn ich das machen würde, dann wäre es in einer VM, bei der ich zuvor
einen Snapshot ziehe und hinterher wieder auf diesen zurückdrehe … OK,
im Falle von MS-DOS und einem entsprechenden Emulator ist das noch
einfacher, denn da liegt das sowieso alles in einem disk image, das man
sich nur kopieren muss. DOS hat ja nichtmal Netzwerk, das man zuvor
deaktivieren müsste, aber auch das wäre bei einer VM einfach zu
bewerkstelligen (meine Windows-VMs laufen normalerweise ohnehin ohne
Netzwerkzugang, denn das brauchen die nicht).
Niklas G. schrieb:> Jeder kennt sicher die Programme, welche ihre> Daten/Einstellungen nach C:\Program Files\ speichern;> das klappt ab Vista auch nicht mehr.
Windows virtualisiert diese Ordner aus Kompatiblitätsgründen. Die
Dateien landen also nicht in "C:\Program Files (x86)\", sondern irgendwo
unter "C:\Users\".
> Alte Linux Programme welche Gtk+2 und OSS voraussetzen dürften> auch ihre Probleme bekommen, usw usf.
Für OSS gibt (gab) es Wrapper wie z.B. aoss, welche die ioctl()-Aufrufe
abfangen und auf ALSA umbauen. Bei größeren Bibliotheken wird es aber
tatsächlich schwierig - Qt 1.0 ist nicht mehr.
> Bei DOS hat man immerhin den Vorteil dass das "API"> relativ klein ist und leicht in DOSbox o.ä. nachzuempfinden; mit einem> kompletten Win32-API ist das nicht mehr so einfach.
Muss man ja auch nicht selber machen, Wine hat die meisten Probleme
schon gelöst. :-)
Jörg W. schrieb:> Du weißt doch absolut nicht, wo er das gestartet hat.
Mag sein, aber mein angeborener Pessimismus, gepaart mit Erfahrung, läßt
mich zu der Meinung tendieren, daß keine 3 VMs hierfür benutzt wurden.
Auch hört sich das eher nach einem XY Problem an.
meine güte schrieb:> aber mein angeborener Pessimismus, gepaart mit Erfahrung, läßt> mich zu der Meinung tendieren, daß keine 3 VMs hierfür benutzt wurden.
Stimmt. Es waren nur zwei.
Klar - der Test in einer VM schützt nicht vor echten Schadfunktionen,
sondern nur davor, einem bösen Scherz zum Opfer zu fallen.
Aber bitte sehr:
Wenn Du die Meinung vertreten magst, dass es unverantwortlich sei, eine
EXE-Datei aus dem Internet zu starten, die
- unter 2 kB ist,
- die im HEX-Editor keine verdächtigen Abweichungen gegenüber
"normalen" EXE-Dateien, die mit Turbo Pascal for Windows 1.0 erzeugt
wurden, zeigt,
- auf einer 64-Bit und auf einer 32-Bit-VM keine Auffälligkeiten zeigt
und auch
- von Virustotal durchgehend als unverdächtig bezeichnet wird,
kannst Du sicherlich ein Beispiel für eine Schadsoftware bringen, die in
allen Bereichen unverdächtig bleibt.
meine güte schrieb:> Bei Leuten die Programme unbekannten Ursprungs starten (wo heutzutage> bei jeder Gelegenheit eindringlich davor gewarnt wird) hört mein Mitleid> und Verständnis auf.
Dann darfst du nur noch Programme starten, die du selbst geschrieben
hast, und das möglichst in Assembler. Du weisst ja nicht mal bei
Microsoft, von wem die Software ist - es könnte z.B. auch Sysinternals
sein. Und auch ein noch so seriöser Entwickler könnte unwissentlich
einen Compiler verwenden, der ein Backdoor für einen Geheimdienst
einbaut. Und dein Browser sollte nur HTML als Text darstellen, sonst
nichts.
Georg
Ein Disassembler für 16bit-EXE scheint noch schwieriger aufzutreiben zu
sein als ein Linker - IDA ist dann doch vermutlich etwas zu teuer...
"ndisasm" kann mit den Headern nicht umgehen. Sonst könnte man leicht
sehen was da passiert... Alternativ installiert man sich den Assembler
und Linker einfach selbst und übersetzt den gezeigten Code. DA könnte
natürlich noch eine Backdoor in Assembler/Linker sein... :-)
auch wenn ich diese ganze Security-Sache hier nicht so wichtig finde
Walter T. schrieb:> - unter 2 kB ist,
rekursive alle Verzeichnisse loeschen braucht viel weniger Platz als das
> - die im HEX-Editor keine verdächtigen Abweichungen gegenüber> "normalen" EXE-Dateien, die mit Turbo Pascal for Windows 1.0 erzeugt
wie erkennst du denn bitte an einem Hex-Dump die "normalität" gegenüber
einer andere EXE? ohne disassembler usw. kann man da reichtlich wenig
draus schliessen
> wurden, zeigt,> - auf einer 64-Bit und auf einer 32-Bit-VM keine Auffälligkeiten zeigt
...weil der böse Code erst am 13.1.2019 tatsächlich ausgeführt wird
> und auch> - von Virustotal durchgehend als unverdächtig bezeichnet wird,
...die so gut wie nichts mehr in alten DOS-EXEn finden
Niklas G. schrieb:> Ein Disassembler für 16bit-EXE scheint noch schwieriger aufzutreiben zu> sein als ein Linker - IDA ist dann doch vermutlich etwas zu teuer...
sind doch "nur" knapp 500EUR fuer die Standard-Version :)
leider ist die IDA 7 Demo nicht mehr DOS/16Bit Fähig, aber die IDA
Freeware Version 5 ist in Absprache mit der Hersteller von IDA
(Hex-Rays) bei den ScummVM Leuten verfügbar:
https://scummvm.org/news/20180331/ besser als alles andere was so
rummkreucht, vielleicht noch radare (aber kann der DOS MZs?)
Bert3 schrieb:> aber die IDA> Freeware Version 5 ist in Absprache mit der Hersteller von IDA> (Hex-Rays) bei den ScummVM Leuten verfügbar:
Ach, gut zu wissen, danke für den Tip ;-)
Bert3 schrieb:> rekursive alle Verzeichnisse loeschen
Viel lustiger ist doch sich selbst in alle Verzeichnisse zu kopieren -
irgendwann erwischt es den Autostart...
Walter T. schrieb:> - unter 2 kB ist,> - die im HEX-Editor keine verdächtigen Abweichungen gegenüber> "normalen" EXE-Dateien, die mit Turbo Pascal for Windows 1.0 erzeugt> wurden, zeigt,> - auf einer 64-Bit und auf einer 32-Bit-VM keine Auffälligkeiten zeigt> und auch> - von Virustotal durchgehend als unverdächtig bezeichnet wird,>> kannst Du sicherlich ein Beispiel für eine Schadsoftware bringen, die in> allen Bereichen unverdächtig bleibt.
Anscheinend hast Du meinen Link nicht gelesen. Mini/Trivial war in einer
Variante nur 13 Bytes. Passt zeitlich auch schön zu 16-Bit Windows.
Wenn Du auf einen Blick in den Hexdump ein paar Bytes Schadcode erkennen
kannst, dann nimmt Dich jeder Antivirus-Hersteller mit Kusshand.
Virustotal kann nur erkennen was entweder bekannt ist, oder via
Heuristik passt. Wenn jemand extra für Dich eine exe macht, dann geht
sowas einfach durch. Oder der Compiler schiebt es noch durch einen
Packer, dann hast Du auch bei legitimer Software False Positives.
Hier ein bisschen Assembler, was man auch direkt mit in eine Binary
packen könnte, statt es via debug zu machen:
https://www.itprotoday.com/windows-78/how-can-i-wipe-master-boot-record
Aber das würdest Du natürlich sofort im Hexdump erkennen...
georg schrieb:> Dann darfst du nur noch Programme starten, die du selbst geschrieben> hast, und das möglichst in Assembler. Du weisst ja nicht mal bei> Microsoft, von wem die Software ist - es könnte z.B. auch Sysinternals> sein.
Ähm, Sysinternals gehört Microsoft. Davon abgesehen nutze ich Windows eh
nur da wo es garnicht anders geht. Systeme die ich betreue laufen unter
Linux, und da wird nur von den offiziellen Repos des Herstellers
installiert.
meine güte schrieb:> Systeme die ich betreue laufen unter Linux, und da wird> nur von den offiziellen Repos des Herstellers installiert.
Was juckt dich das dann?
Dich betreffen die Binaries sowieso nicht.
Retro ist halt oft genug damit verbunden, dass man irgendwo eine ZIP
oder EXE runterlädt und sich daran erfreut. In der Hoffnung, dass die
wenigstens nicht korrupt (weil von kaputter Diskette gelesen) sind.
Alte Software hat oft schwerwiegende Bugs schon ab Werk, dagegen ist
heutige Malware doch handzahm. Und wenn es den DOS-Rechner zerfleischt -
who cares? Erstens habe ich da keine relevanten Daten drauf, zweitens
habe ich wegen der unzuverlässigen Hardware mehrere Backups, drittens
haben die Systeme meist erstaunlich wenig Ahnung von "Netzwerk" oder
"IP" und sind daher für andere Systeme vollkommen ungefährlich.
Und wenn du mir den MBR wegschießen willst... unter Windows scheitert
das schon daran, dass da keiner mehr ist (der GPT sei Dank, die
Partitionstabelle ist woanders). Und dass Windows der EXE keinen
direkten Plattenzugriff erlaubt. Und daran, dass Windows nicht mehr so
einfach exploitbar ist. Und mein Linux auch nicht. Und und und.
S. R. schrieb:> Was juckt dich das dann?> Dich betreffen die Binaries sowieso nicht.
Doch. Und zwar dann wenn ein infizierter Rechner online ist. Ein Teil
des Traffics sind Angriffe/Scans von Zombies; der betrifft gerade die,
die eben nichts mit dem System zu tun haben. Wenn infizierte Rechner
sofort vom Internet getrennt würden, dann würden mich die nicht jucken.
S. R. schrieb:> Und daran, dass Windows nicht mehr so> einfach exploitbar ist.
Nicht mehr so einfach mag ja stimmen, aber dennoch gibt es immer noch
zigtausende Malwares die sich einnisten können; und das teilweise auch
gleich mal ohne daß der Benutzer was machen muß.
Wer weiß denn schon, wieviele 0-days aktiv sind?
Die ganze Security Debatte hier ist doch eigentlich sehr witzlos wenn
man mal drüber nachdenkt das der Browser an sich eigentlich eine eigene
VM ist (in der dennoch alle wichtigen Daten wie Login cookies,
Passwörter, Creditkarten daten, etc. gespeichert werden) dessen
Kernfunktionalität das ungeprüfte Downloaden und Ausführen von
Programmcode ist.
Ich hab weniger Angst davor das ich mir durch eine .exe aus dem Internet
einen Virus ziehe (dagegen hab ich wenigstens Windows Defender), als das
eine Website durch einen Sicherheitsbug im Browser (die von der
Komplexität problemlos an die eines Betriebsystems rankommen, da
schleichen sich viele Bugs ein) Zugang auf meine Login cookies von
seiten mit wichtigen Infos hat. Das schlimmste was ein Virus auf meinem
PC machen kann ist das auslesen meiner Browser Daten (ansonsten
speichere ich keine Wertvollen Infos auf meinem Rechner)
meine güte schrieb:> Wer weiß denn schon, wieviele 0-days aktiv sind?
A: "Guck mal! Ich habe eine neue Sicherheitslücke für 16-Bit-Windows
entdeckt!"
B: "Wofür brauchst Du für eine 16-Bit-Windows Sicherheitslücken? Da darf
doch sowieso jedes Programm überall im Speicher lesen und seitenweise
sogar schreiben. Und beliebige andere Prozesse starten. Also kann
faktisch überall schreiben."
A: "Egal. Ich habe eine. Ätsch!"
B: "Und was machst Du damit?"
A: "Ich warte einfach, bis jemand in einem Internetforum nach einer
16-Bit-EXE fragt und BAM! - laden sich das bestimmt zehn Leute
herunter!"
B: "Und was hast Du davon?"
A: "Schnauze!"
Freude der höheren µC.net-Literatur dürfen gerne die folgende Ersetzung
ausführen: "A" -> "Ich", "B" -> "Jusuf, der Kommilitone von der TH"
Edit:
Ich sehe gerade: "Ben" ist der aktuelle Name. Man muss ja auf dem
laufenden bleiben.
Bert3 schrieb:> vielleicht noch radare (aber kann der DOS MZs?
fasm (die Linuxversion) kanns ;)
Eine andere Möglichkeit für ein kleines Programm ist bei DOS tatsächlich
der Hexeditor.
Wenn man die Hexwerte B402 B22A CD21 CD20 in einen Hexeditor (o.ä.)
einträgt und die Datei myprg.com nennt, dann hat man schon ein kleines
Programm (natürlich "nur" ".com") (welches ein Zeichen auf dem
Bildschirm ausgibt).
Die Stringvariante ist nicht größer, nur mit B409 und BA0000 wobei bei
den Nullen die Adresse steht, wo die Zeichenkette anfängt - vorzugsweise
nicht bei Standard-Adresse 0200h sondern hinter dem Programmende
(abzählen ;) ) - dem Interrupt 20 (cd20h)
Das eigentliche Programm ist so nur 4 bzw. 5 Bytes lang.
Bei dieser Ausgabevariante muss man ein Dollarzeichen an das Ende
anfügen.
Bonus:
http://www.linuxandubuntu.com/home/how-to-setup-open-watcom-on-wine-for-windows-programmers
:)
rbx schrieb:> Bert3 schrieb:>> vielleicht noch radare (aber kann der DOS MZs?>> fasm (die Linuxversion) kanns ;)
Radare ist ein reverse engineering tool wie IDA, fasm ist doch ein
assembler (der unter windos und linux dos exen erzeugen kann) oder was
meinst du
Klar kann man so ein programm schreiben - auch wenn es ein steiniger weg
ist :)
Christian M. schrieb im Beitrag #
>> Wieso muss es denn immer dieses völlig veraltete C sein?!>> Gruss Chregu
Es dürfte schwierig sein einen 16 bittigen Rust Compiler zu finden.
SCNR
Niklas G. schrieb:> Ein Disassembler für 16bit-EXE scheint noch schwieriger aufzutreiben zu> sein als ein Linker - IDA ist dann doch vermutlich etwas zu teuer...> "ndisasm" kann mit den Headern nicht umgehen. Sonst könnte man leicht> sehen was da passiert... Alternativ installiert man sich den Assembler> und Linker einfach selbst und übersetzt den gezeigten Code. DA könnte> natürlich noch eine Backdoor in Assembler/Linker sein... :-)
Für ein 16 bittiges Binary das nur 2 kB groß ist braucht man keinen
disassembler, das geht auch von Hand mit einem Hexeditor durch lesen der
Opcodes.
Der Befehlssatz des 8086 ist durchaus überschaubar.
Bert3 schrieb:> auch wenn es ein steiniger weg> ist
Das ist ja das tolle an DOS, weil es diesen Zugang einfach macht. Der
"steinige" Teil ist hier eigentlich nur die Relokation bzw. die
Segmentkontrolle im Real Mode.
Deswegen heißt es ja, das .com Programme nicht größer als 64kbyte sein
dürfen. Aber..
1. Kann man damit schon eine ganze Menge machen.
2. Wenn man die die "Relokation" selber macht, gewissermaßen eine
Light-Version eines eigenen Linkers, dann kann man auch größere
Programme schreiben.
3. Dieser gut gemachte pragmatische Teil findet sich noch Ansatzweise im
MC wieder.
4. Diese Art von Pragmatismus macht ja auch Debian so sympathisch.
5. Könnte man genau da fragen: könnte man ein kleines hexcode prg
brauchen? hexdump und od lesen ja nur formatfreundlich.
6. Ist Lunuxassembly irgendwie doof, weil der Kernel ja in C geschrieben
ist.
https://stackoverflow.com/questions/22122887/linux-kernel-assembly-and-logic
7. Scheint mir das ein Hinweis zu sein, warum die Spielwelt ziemlich
außen vor bleibt in Linux.
Nano schrieb:> Für ein 16 bittiges Binary das nur 2 kB groß ist braucht man keinen> disassembler, das geht auch von Hand mit einem Hexeditor durch lesen der> Opcodes.
Das Lästige ist das Parsen der MZ-Header und das Finden der Segmente.
rbx schrieb:> 6. Ist Lunuxassembly irgendwie doof, weil der Kernel ja in C geschrieben> ist.
Wieso das? Sowohl der Windows- als auch der Linuxkernel sind
größtenteils in C. In Assembler wäre das wenig sinnvoll; nur einige echt
plattformspezifischen Low-Level-Dinge wie Interrupt-Behandlung oder
Speicherverwaltung müssen Assembler sein. Tatsächlich ist
Linux-Assembler-Programmierung sogar einfacher als unter Windows, weil
man die Syscalls hier direkt aufrufen kann; unter Windows muss man das
über die entsprechenden DLLs machen (geht zwar auch direkt, aber das ist
unsauber und kann schief gehen wenn die ABIs der Syscalls geändert
werden). Ein Linux-ARM-Beispiel hab ich ja schon gezeigt:
Beitrag "Re: 16-Bit-EXE erzeugen"
Nur warum wurde das runtergevotet... Unter amd64 geht das ganz ähnlich:
1
#include <sys/syscall.h>
2
3
.section .text._start
4
.global _start
5
.type _start, %function
6
7
_start:
8
mov $__NR_write, %rax
9
xor %rdi, %rdi # fd
10
mov $message, %rsi
11
mov $14, %rdx
12
13
syscall
14
15
mov $__NR_exit, %rax
16
xor %rdi, %rdi
17
syscall
18
19
.section .text.message
20
.type message, %object
21
message:
22
.ascii "Hello, World!\n"
rbx schrieb:> 7. Scheint mir das ein Hinweis zu sein, warum die Spielwelt ziemlich> außen vor bleibt in Linux.
Das liegt einfach nur am Marktanteil. Keiner schreibt (mehr) Spiele in
Assembler. Es ist einfach unrentabel, für die paar Linux-Gamer zu
entwickeln, weshalb es auch dafür nicht die entsprechenden Frameworks
und hochoptimierten Grafik-Treiber gibt.
Niklas G. schrieb:> Nur warum wurde das runtergevotet...
???
ich fand den Teil gut, und kann es mir nur so erklären, dass diese
Geschichte wenig zur eigentlichen Frage oben beiträgt. Aber ich sehe
auch die Bewertungen nicht. Muss ich nicht. Der Nebeneffekt wäre ja
Prostitutives Antworten.
Ich weiß, das soll die Sachlichkeit und den helfenden Teil fördern.
Die Frage ist, ob es nicht andere, bessere Möglichkeiten gibt, die nicht
diesen Nebeneffekt haben. Ein Haken auf eine treffende Antwort ist
ähnlich gut, wie wenn beim Snooker die Kamera in eine Perspektive fährt,
in der man sofort sieht, in welche Richtung die professionelle Sicht
geht.
Der Lowlevel-Teil ist schon klar aber:
1. Wenn nur die Interruptebene offen liegt bzw. läge, dann wäre das
tatsächlich steinig.
(kann man in Dos auch machen, die CD21h und CD20h gerne auch zu Fuß
eintippen)
2. Man kann ja in Linuxasm auch printf benutzen bzw. kann man gleich C
schreiben.. ;)
3. "MZ" braucht man bei .com Dateien nicht, und wenn man die Relokation,
d.h. Segmentmanagement (+ Far Jumps! möglich) selber macht, eigentlich
auch nicht.
4. Die Hardware, bzw. der 64 Bit Mode ist sehr gut (der Rip-Mode). Das
passende DOS dazu fehlt aber.
5. Und: geht der letzte Punkt weit über das hinaus, was eigentlich
gefragt wurde + was ich im Bewertungssinne in positive Richtung
schreiben könnte (unabhängig von der Ausgangsfrage).
rbx schrieb:> Aber ich sehe> auch die Bewertungen nicht
Es wurde aber fast alles runtergevotet. Ominös.
rbx schrieb:> 2. Man kann ja in Linuxasm auch printf benutzen bzw. kann man gleich C> schreiben.. ;)
Dazu muss man aber die C-Library einbinden - o.g. Programm benutzt
überhaupt keinen externen Code auf Userspace-Ebene.
rbx schrieb:> 3. "MZ" braucht man bei .com Dateien nicht
Klar, aber die Frage war nach einer EXE. Das war ja sowieso das
Hauptproblem; das Erzeugen von COM-Files ist z.B. mit NASM simpel.
rbx schrieb:> Das> passende DOS dazu fehlt aber.
Oh graus :-) Wenn ich das richtig verstehe gibt es gar keinen Real Mode
unter AMD64. Man müsste wenn schon den Protected Mode nehmen und alles
im Kernelmodus laufen lassen (Ring 0), so eine Art Unikernel.
rbx schrieb:> 5. Und: geht der letzte Punkt weit über das hinaus
Na, wenn man gar nichts links und rechts anmerken darf wirds ja auch
langweilig hier.
Niklas G. schrieb:> Na, wenn man gar nichts links und rechts anmerken darf wirds ja auch> langweilig hier.
+1 :)
https://xkcd.com/937/ (Tendenz zum Durchschnitt..)
Einer der Zwischenschritte ist ja Freedos. (hätte TO auch nutzen können)
Auf 32bit-Systemen kann man noch vom VM86-Mode profitieren d.h. alle
möglichen neuen Register (MMX, SSE usw.) mit .com Programmen
ausprobieren.
Außerdem ist auch klar, dass in so einen Nerd-Forum
gewisse "Kloppe" normal ist
und dass viele (??) Assemblercode wohl nur "lesen" können
+ die Notwendigkeit, bei Mikrocontrollern, vor allem, wenn man mit
vielen wechselnden Plattformen zu tun hat, automatisch auf C zeigt
und dass diese Punkte zu einem ziemlichen Bias im Bewertungssystem
führen müssen.
war da noch was?
ach ja,..
Niklas G. schrieb:> Dazu muss man aber die C-Library einbinden - o.g. Programm benutzt> überhaupt keinen externen Code auf Userspace-Ebene.
Na und? Für printf kann man das ruhig mal machen und Userspace-Ebene
gibt es bei Dos gar nicht bzw. ist der Vergleich schwierig.
Oder noch einen drauf: bei Dos (asm) kann man wenigstens noch was mit
dem Bios anfangen.
Niklas G. schrieb:> Ein Disassembler für 16bit-EXE scheint noch schwieriger aufzutreiben zu> sein als ein Linker
Ich hab früher für sowas immer Hiew genommen: http://www.hiew.ru/
Wird immer noch entwickelt, ist aber seit einigen Versionen nicht mehr
kostenlos. Günstiger als IDA ist es allemal.
Aber warum nicht Radare? Das kann mit NE EXEn umgehen:
https://rada.re/r/
Warum überhaupt der Umweg über eine 16-bit-EXE? Eine 32-bit/64-bit
PE-Datei verfügt doch ohnehin über den berühmten DOS-Stub, der nichts
weiter als "This program cannot be run in DOS mode" ausgibt. Wenn es dir
darum geht nur diesen Text zu ändern, könntest du auch einfach die
PE-Datei "hacken" und per Hex-Editor diesen String ändern (sofern die 38
Zeichen ausreichen). Oder bist du zwingend auf den Rückgabewert 1
angewiesen? Den könnte man evtl. durch hacken des DOS-Stubs aber auch
erzeugen. Die 32-bit/64-bit-Variante gibt dann eben etwas anderes aus,
bzw. macht gleich das, was bei einem Nicht-16-bit-System stattfinden
soll. So spart man sich zumindest den Umweg über eine separate Datei,
die im Zweifelsfall neu zu erzeugen ja problematisch ist.
Ich kann mich erinnern, dass Microsofts eigener Linker die Möglichkeit
bot, einen eigenen DOS-Stub zu verlinken. Ob das heute noch geht, keine
Ahnung.
Ernsthafte Frage: Wer setzt denn heute noch ein 16-bit-System ein, dass
so ein Test seitens deiner Software relevant ist? Du selbst solltest ja
wissen, was du wo ausführen kannst. Nur so als Neugier, was das Szenario
ist...
Daniel schrieb:> Aber warum nicht Radare? Das kann mit NE EXEn umgehen:> https://rada.re/r/
Kann man machen, aber kann radare auch mit einem unerfahrenen User
umgehen?
1
; fasm example of writing simple EXE program
2
3
format MZ
4
5
push cs
6
pop ds
7
8
mov ah,9
9
mov dx,hello
10
int 21h
11
12
mov ax,4C01h
13
int 21h
14
15
hello db 'Error (1) - could not run application',0A,0D,24h
Das wäre das Flatassemblerbeispiel. Braucht auch kein Wine. Das
"Template ist aus der Dosversion "doku" wenn man das so nennen könnte
und die leichte Codeanpassung an dem Beispiel von Niklas und Stefanus
ausgerichtet.
( https://flatassembler.net )
Thread beobachten
Seitenaufteilung abschalten