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.
Freepascal Turbo Pascal gibt es ja auch kostenlos als Vollversion, Borland Turbo C vermutlich auch? https://sourceforge.net/projects/turbopascal-wdb/ https://www.freepascal.org Turbo C https://winworldpc.com/product/turbo-c/3x
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Am einfachsten den aktuellen dmc von digitalmars , der kompiliert und link auch noch unter 64bit problemlos 16bit dos exen https://www.digitalmars.com/download/freecompiler.html 8.57 und die dos libs
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.
Ich hatte damals sehr gerne mit GFA-Basic gearbeitet. Gibt es sogar hier noch als Download : http://michel.goux.pagesperso-orange.fr/gfa_basic_en.htm
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.
Heinz (Gast) schrieb: > GFA-Basic Oder: http://xprofan.de/download.htm Wieso muss es denn immer dieses völlig veraltete C sein?! Gruss Chregu
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
Spannende Frage wäre noch, wie kompatibel die aktuelle tiny-c Variante ist: https://bellard.org/tcc/ Bei Pascal könnte man https://www.freepascal.org auf kompatibel testen.
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.
rbx schrieb: > Eine andere Möglichkeit ist noch was mit IDA zu machen mit/unter > Wine. Was soll er den mit IDA machen und warum unter Wine?
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" |
26 | message_end = . |
27 | .size message, message_end-message |
Im Anhang das Kompilat als ELF.
:
Bearbeitet durch User
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
Ich hab mit den allen schon lattice c 2.5 objekt datei von 1987(oder 84?) Unter win64 gelinkt ;-)
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.
:
Bearbeitet durch User
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
Base schrieb: > Muss es unbedingt C sein? Es ist schon längst fertig … (und zwar in Turbo-Pascal): Beitrag "Re: 16-Bit-EXE erzeugen" Beitrag "Re: 16-Bit-EXE erzeugen"
Jörg W. schrieb: > Es ist schon längst fertig … (und zwar in Turbo-Pascal): Aber genau 1828 Bytes zu groß!11 ;-)
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.
Dann hoff Du mal. Die kleine .EXE-Datei passt im HEX-Editor auf eine Bildschirmseite.
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
Der war gut ;) Ich meinte aber eher 1984 16bit kompiler mit 2018er x64 bit linker
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/mini WIRO 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?
meine güte schrieb: > Wer weiß denn schon, wieviele 0-days aktiv sind? Auf Basis von 16 Bit-EXEn? Äußerst wenige.
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)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Wie wäre es mit
1 | command.com /C echo "Error - could not run application (Code 01)" |
rbx schrieb: > Spannende Frage wäre noch, wie kompatibel die aktuelle tiny-c Variante > ist TinyCC kann nur 32 und 64 Bit.
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...
:
Bearbeitet durch User
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 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.