16-Bit-EXE erzeugen

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

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

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

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

Ja eben!

Gruss Chregu

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

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

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

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

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?

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

Ich hab mal als spassproject ein integer primzahlen berechnungsprogramm 
durch einen haufen alter c kompiler gejagt, nebst alter und aktueller 
linker, es war erstaunlich zu sehen wie gut das alles noch funktioniert

Muss es unbedingt C sein?
QBasic passt doch zu DOS wie Arsch auf Eimer und ist auf jeder 
Win95-Installations-CD dabei (\OLDMSDOS).
QuickBasic 4.5 erzeugt auch eine *.exe oder *.com und ist als 
Abandonware im Netz allgegenwärtig.

...und wie schlecht der generierte code zu der zeit teilweise war, ich 
bin auf den gcc IA 16 gespannt: https://github.com/tkchia/gcc-ia16 da 
siehtman selbst bei kleinen projekten was heutige kompilertechnik auf so 
alten platformen noch bringen kann

PPB schrieb:
> rbx schrieb:
>> Er soll ein kleines Windows-16bit-Prg in Linux erzeugen/bearbeiten.
> Mit IDA? Ich zerlege damit ROMs erfolgreich seit mehr als 10 Jahren.
> Dass man damit Programme schreiben kann, ist mir neu.
>
> Ausser du meinst das Debug-Beispiel aus dem DOS-6.22 Handbuch auf totem
> Baum, in dem gezeigt wird, wie man mit debug eine Hello-World .com Datei
> erstellt.
> Dafür braucht man aber kein IDA, da reicht ein hexeditor.

Ich stelle mir auch so Fragen wie - wie erstellt man einen Compiler ohne 
Compiler? ;)
(nur mit cat)

Ida (die freie Version) dokumentiert die alten Doscodes bzw. die 
klassischen Unterprogramme sehr schön, das ist hilfreich, wenn man sonst 
nicht viel Info zu diesem Thema parat hat.

>wie erstellt man einen Compiler ohne Compiler? ;)

So wie echte Männer auch heute noch Programme schreiben sollten

Binärcode, n Stufen bis zu einem guten assembler dann noch n 
featurestufen bis zu einem guten kompiler, fertig! Ein kleines 
betriebssystem sollte man dabei natuerlich auch noch machen

WIRO schrieb:
> die EXE ist fertig. Sie befindet sich in der Anlage in der Datei
> test.zip.

Walter T. schrieb:
> das Ergebnis auf einem 64-Bit-System ist wie erwartet. Auf dem
> 32-Bit-System, wo die Meldung ausgegeben wird, kommt auch der korrekte
> Rückgabewert.

Aktuell hört man von allen Seiten, die nur einen Hauch Ahnung von IT 
haben, wie dumm doch die Politiker waren, deren Daten aufgrund der 
aktuellen "Cyberkrise" nun online sind. Weil deren Passwörter wohl zu 
billig waren.

Dann scrollt man durch Beiträge in einem Forum, in dem 99% der User mehr 
Ahnung von IT haben als der Otto-Normalbürger, und muß sehen, daß jemand 
einfach so eine .exe die von einem unbekanntem Gast hochgeladen wurde, 
auf mindestens zwei Systemen ausführt.

Da fragt man sich dann im Stillen ob das betreffende System vielleicht 
so systemkritisch in einem Unternehmen ist, daß man es nicht einfach 
über die letzten Jahrzehnte (!) aktualisieren konnte. Wer weiß, 
vielleicht steuert es ja die Zentrifugen einer Urananreicherungsanlage.

Was soll man den nun über die dummen Politikern sagen, wenn schon Leute 
mit mehr Ahnung solche katastrophalen Fehler begehen? In einer kleinen 
finsteren Ecke meiner Seele gibt es ein bisschen Hoffung darauf, daß 
Leute wie Walter zum Schutz der Rest der Welt ihren Job verlieren.

Haettest wohl doch den asm code von Niklas G. nutzen sollen, da waere 
die sicherheitsanalyse noch weniger aufwendig ausgefallen, abzueglich 
des headers wohl nur ein paar bytes ;)

ganz nebenbei ließe sich der freie Plattenplatz auf dem LW C: ermitteln 
und eine Textdatei mit ebensolcher Größe anlegen lassen: schwubbs -> 
Platte voll. Zwar nix aufregendes passiert (Datei lässt sich ja leicht 
wieder löschen) aber aufgezeigt, was alles ginge... Und das passt auch 
locker auf eine A4 Seite im HEX-Editor.

Ich fands "spannend" wie schnell hier angeblich ein "Hacker" ausfindig 
gemacht wurde.Auf der einen Seite häggt der Junge Mann etlcihe Seites 
und zieht unbemerkt(!) Daten ab und ist dann so blöd, sich innerhalb 
eines Tages ausfindig machen zu lassen. Woanders werden zwei tage später 
Personalausweise gefunden. Klingt alles sehr inszeniert, damit schnell 
ein neues CyberCenter"PLUS" für zig Millionen ins Leben gerufen werden 
konnte.
Was genau diese neue Stelle macht, wird und soll sicher niemand 
erfahren.

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

Bert3 schrieb:
> es war erstaunlich zu sehen wie gut das alles noch funktioniert

Natürlich, an den Primzahlen hat sich nach meiner Information in den 
letzten Jahrzehnten ja auch nichts geändert.

Es gibt viele Programme, die noch perfekt funktionieren, weil sie auf 
der Gültigkeit von Gesetzen wie Ohm, Kirchhoff, Maxwell usw. beruhen - 
die Impedanzberechnung eines Kupferdrahts unter DOS liefert immer noch 
das richtige Ergebnis, auch wenn das manche wundert.

Georg

Der war gut ;)

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

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

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

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

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.

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?

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.

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

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/

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 )

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