mikrocontroller.net

Forum: PC-Programmierung 16-Bit-EXE erzeugen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: rbx (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Heinz (Gast) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Heinz (Gast) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier auch noch Profan 5.0b
http://xprofan.de/start.htm
unter Download

Autor: Baumeister (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Heinz (Gast) schrieb:
> GFA-Basic

Oder:

http://xprofan.de/download.htm

Wieso muss es denn immer dieses völlig veraltete C sein?!

Gruss Chregu

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja eben!

Gruss Chregu

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: WIRO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: WIRO (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine andere Möglichkeit ist noch was mit IDA zu machen mit/unter Wine.

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Walter T. (nicolas)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: PPB (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: PPB (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: georg (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: PPB (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: PPB (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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:
code    segment public
        assume  cs:code,ds:code
start:  org     100h

mov dx,20Ch
mov ah,9
int 21h

mov ax,4c01h
int 21h

hello: db 'Error - could not run application - Media data not found)', 13, 10, '$'

code    ends
        end     start

Assembliert und gelinkt mit dem "Arrow Assembler". Funktioniert in der 
Dos-Box :-)

Autor: Dumdi D. (dumdidum)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Walter T. (nicolas)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 :).

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe es doch nochmal anders gemacht, mit NASM und wine+ALINK. Der Code 
ist nahezu unverändert aus dem Wikibook:
segment code

 start:
 mov ax, data
 mov ds, ax

 mov dx, hello
 mov ah, 09h
 int 21h

 mov ax,4c01h
 int 21h

 segment data
 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:
#include <sys/syscall.h>

.section .text
.code 32

.global _start

.align 2
.type  _start, %function
_start:
  mov r0, #1
  adr r1, message
  mov r2, #(message_end-message)
  mov r7, #__NR_write
  svc #0
  
  mov r0, #1
  mov r7, #__NR_exit
  svc #0
  
  .size _start, .-_start
  
.type message, %object
message:
  .ascii "Error - could not run application - Media data not found)!\r\n"
  message_end = .
  .size message, message_end-message

Im Anhang das Kompilat als ELF.

: Bearbeitet durch User
Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich hab mit den allen schon lattice c 2.5 objekt datei von 1987(oder 
84?) Unter win64 gelinkt ;-)

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Base (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
...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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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"

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Es ist schon längst fertig … (und zwar in Turbo-Pascal):

Aber genau 1828 Bytes zu groß!11 ;-)

Autor: rbx (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>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

Autor: meine güte (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Walter T. (nicolas)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Dann hoff Du mal.

Die kleine .EXE-Datei passt im HEX-Editor auf eine Bildschirmseite.

Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 ;)

Autor: äxl (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Er hat ja scheinbar nicht gehaeggt sondern nur schon verhandene daten 
aus dem inter/darknet gesammelt und strukturiert - eher zeit aufwendig 
als "echtes" hacking

Autor: georg (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Bert3 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Der war gut ;)

Ich meinte aber eher 1984 16bit kompiler mit 2018er x64 bit linker

Autor: Walter T. (nicolas)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: WIRO (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@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

Autor: meine güte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: meine güte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: georg (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... :-)

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?)

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: meine güte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: meine güte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine güte schrieb:
> Wer weiß denn schon, wieviele 0-days aktiv sind?

Auf Basis von 16 Bit-EXEn? Äußerst wenige.

Autor: Frederic K. (warfley)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Walter T. (nicolas)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!"

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
:)

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#include <sys/syscall.h>

.section .text._start
.global _start
.type  _start, %function

_start:
  mov $__NR_write, %rax
  xor %rdi, %rdi  # fd
  mov $message, %rsi
  mov $14, %rdx
  
  syscall
  
  mov $__NR_exit, %rax
  xor %rdi, %rdi
  syscall

.section .text.message
.type message, %object
message:
  .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.

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: rbx (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit
command.com /C echo "Error - could not run application (Code 01)"

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rbx schrieb:
> Spannende Frage wäre noch, wie kompatibel die aktuelle tiny-c Variante
> ist

TinyCC kann nur 32 und 64 Bit.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Florian S. (sevenacids)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

; fasm example of writing simple EXE program

format MZ

  push  cs
  pop  ds

  mov  ah,9
  mov  dx,hello
  int  21h

  mov  ax,4C01h
  int  21h

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 )

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..und bei 0a und 0d oben hätte ich lieber noch ein "h" drangehängt..

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.