DOS,16Bit:Ich suche DOS sys Treiber Beispiel Source

[cppbert3 (Gast)]

Ich suche Beispielcode für einen DOS Sys Treiber - wenn möglich für 
Turbo/Borland C/C++ oder Watcom, ist für ein Reverse Engineering Projekt

Ich hab eine paar Links, Dr Dobbs,... und ein paar PDFs gefunden aber 
fast alles ist Asemblercode - da weiss ich wie ich eine Sys Treiber 
baue, nur finde ich nichts für pure C - falls das überhaupt ganz ohne 
Assembler möglich ist

[Marc (Gast)]

Ich vermute, das damals viel mit Inline Assembler gearbeitet wurde, DOS 
war ja ziemlich nah an der Hardware im Vergleich zu modernen 
Betriebssystemen.

[Peter M. (r2d3)]

Hallo cppbert3,

cppbert3 schrieb:
> Ich suche Beispielcode für einen DOS Sys Treiber - wenn möglich
> für
> Turbo/Borland C/C++ oder Watcom, ist für ein Reverse Engineering Projekt

eventuell findest Du etwas im Sourcecode von Truecrypt.

[cppbert3 (Gast)]

Marc schrieb:
> Ich vermute, das damals viel mit Inline Assembler gearbeitet
> wurde, DOS war ja ziemlich nah an der Hardware im Vergleich zu modernen
> Betriebssystemen.

Wie schon geschrieben, habe ich schon Dos sys Treiber in Assembler 
programmiert, mein Problem ist die Sprungtabelle usw. am Anfang der Sys 
Datei, mir ist nicht klar wie ich das in C hin bekomme oder was ich für 
Linkersettings brauche

[cppbert3 (Gast)]

Peter M. schrieb:
> Hallo cppbert3,
> eventuell findest Du etwas im Sourcecode von Truecrypt.

Truecrypt ist Erstrelease 2004, das ist lange lange nach der 16 Bit DOS 
Zeit, ich denke das ist technologisch was völlig anderes

[Rolf M. (rmagnus)]

Bei FreeDOS sind Treiber dabei, die man sich anschauen kann. Findet man 
hier:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/group-drivers.html

Allerdings wird das wahrscheinlich auch größtenteils alles Assembler 
sein.

[Oliver S. (oliverso)]

cppbert3 schrieb:
> Ich hab eine paar Links, Dr Dobbs,...

https://www.drdobbs.com/writing-ms-dos-device-drivers/184402277

Das alles klingt nicht sehr vielversprechend, um es mit den damals 
verfügbaren tools in C hinzukriegen.

Da das aber damals in Assembler alles machbar war, sollte das heute auch 
noch so sein.

Oliver

[cppbert3 (Gast)]

Oliver S. schrieb:
> Da das aber damals in Assembler alles machbar war, sollte das heute auch
> noch so sein.

Es ist so

[G. O. (aminox86)]

cppbert3 schrieb:
> Ich suche Beispielcode für einen DOS Sys Treiber - wenn möglich
> für
> Turbo/Borland C/C++ oder Watcom,
Das dürfte passen:
Adams/Tondo - Treiberprogramme in C unter Dos
ISBN 3-446-16391-3

[cppbert3 (Gast)]

vielleicht muss es auch nicht unbedingt ein DOS Geräte-Treiber sein

im Grunde will ich mit C ein Binary erzeugen welches bei Offset 0 eine 
far-Jump Tabelle enthält - dieser "drv" wird dann von einer alten 
DOS-Applikation geladen welche dann direkt far calls auf die 
Tabellen-Punkte macht um die entsprechenden Treiber-Funktionen 
aufzurufen

hier ein assemblierbares Beispiel (nur mit weniger/trivial Funktionenals 
in echt)

Wichtig:
-der Jump/Call-Table muss exakt an der Stelle liegen
-es müssen Far-Funktionen als Ziele sein
-alle Variablen werden per cs-Register adressiert
sonst laeuft das nicht mit der Original-Applikation

den Original-Treiber habe ich vollständig reverse engineering und möchte 
den jetzt nach C portieren

;----------------------------------------
; Realmode, 16Bit
; some sort of loadable library binary image with no entry point 
; but a 2 functions jump-table starting at offset 0
;
; this drv file gets dynamically loaded into its own segment
;
; all data is addressed by the CS-Register
;
; how to build:
;
; assembler: current ML (for example from VS2019) or UASM (http://www.terraspace.co.uk/uasm.html)
; linker: UniLinker (ftp://ftp.styx.cabel.net/pub/UniLink/ulnb1155.zip) (or later)
;
; assemble:
;   ml.exe /c /omf drv.asm
;   or
;   uasm64.exe drv.asm
; link:
;   ulink.exe -T16 -Tbi drv.obj, drv.drv
;----------------------------------------

seg000    segment byte public 'CODE' USE16
    org 0
    assume cs:seg000
    assume es:nothing, ss:nothing, ds:nothing

;----------------------------------------
; no entry point:
; there is no fixed first code to run and no (exe or whatever) header to put in the entry point address

; needed for UniLinker
; i can't find an option that allows to create an no-entry-point binary image (-e- does not work with DOS applications)
dummy_entry_point:
;----------------------------------------

;----------------------------------------
; jump table with 2 functions (far called by the drv loading program)
; "interface" of the driver
;----------------------------------------
    jmp near ptr tsub0
; ---------------------------------------------------------------------------
    jmp near ptr tsub1
; ---------------------------------------------------------------------------

; data

value1    db 0
value2    dw 0

; some internal functions

isub0   proc near
    mov cs:value1, 123
    retn
isub0   endp

isub1   proc near
    mov cs:value2, 321
    retn
isub1   endp

; interface implementer

tsub0   proc far
    call isub0
    retf
tsub0   endp

tsub1   proc far
    call isub1
    retf
tsub1   endp

seg000    ends
end dummy_entry_point

[cppbert3 (Gast)]

vielleich auch nur ein kleiner Stub in Assembler für den Table und dann 
ein C Objekt mit dem Code dazu linken, ohne C-Runtime? aber wie bekomme 
ich dann die Variablen CS-Register adressiert?

[Georg (Gast)]

Oliver S. schrieb:
> Da das aber damals in Assembler alles machbar war, sollte das heute auch
> noch so sein.

Möglich ist es schon, aber nicht für jeden. Und von "modernen" 
Programmierern wird das grundsätzlich abgelehnt. Ist wie beim Fuchs mit 
den sauren Trauben oder so ähnlich.

Wichtig ist dabei die Schnittstelle von C zu Assembler- (oder sonstwas) 
Unterprogrammen, die muss in der Compiler-Linker-Dokumentation 
beschrieben sein. Wenn nicht hat man gleich ganz schlechte Karten. Wie 
das bei Turbo-C war kann ich mich nicht mehr erinnern.

Georg

[Peter M. (r2d3)]

Hallo IgNorbert3,

cppbert3 schrieb:
> Peter M. schrieb:
>> Hallo cppbert3,
>> eventuell findest Du etwas im Sourcecode von Truecrypt.
>
> Truecrypt ist Erstrelease 2004, das ist lange lange nach der 16 Bit DOS
> Zeit, ich denke das ist technologisch was völlig anderes

warum bist Du so ignorant?
Ich denke, also irre ich!

Was ich Dir schrieb, betrifft nicht nur Truecrypt, sondern auch das ach 
so moderne Veracrypt.

Lies' hier und krieche zu Kreuze!

[...
Last point : the code of VeraCrypt BIOS boot loader runs in a restricted 
environment with limited resources and legacy mode (16-bit), which make 
all cryptographic computation slower. Once Windows is started, we go 
back to normal more with no performance degradation.
We can do nothing about this. In the future, we plan to support UEFI 
boot which enables the use of more resources for booting.
...]

https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/

[cppbert3 (Gast)]

Peter M. schrieb:
> warum bist Du so ignorant?
> Ich denke, also irre ich!

Warum bist du so empfindlich? Ich war nicht ignorant obwohl ich denke 
das du keine Ahnung von dem hast was ich weiter oben so gepostet habe

Peter M. schrieb:
> Lies' hier und krieche zu Kreuze!
> [...
> Last point : the code of VeraCrypt BIOS boot loader runs in a restricted
> environment with limited resources and legacy mode (16-bit), which make
> all cryptographic computation slower. Once Windows is started, we go
> back to normal more with no performance degradation.
> We can do nothing about this. In the future, we plan to support UEFI
> boot which enables the use of more resources for booting.
> ...]
> https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/

Es geht mir um ein sehr konkretes Problem zu dem ich sogar 
funktionierenden Assemblercode gezeigt habe, das hat mit einem 16 bit 
bootloader eines krypters nicht mehr gemeinsam als das ähnliche 
Schlagworte vorkommen

[Peter M. (r2d3)]

Werter cppbert3,

cppbert3 schrieb:
> Es geht mir um ein sehr konkretes Problem zu dem ich sogar
> funktionierenden Assemblercode gezeigt habe, das hat mit einem 16 bit
> bootloader eines krypters nicht mehr gemeinsam als das ähnliche
> Schlagworte vorkommen

Assemblercode taucht in Deinem Eingangsbeitrag nicht auf.
Ich musste mich daher mit Deinen wenigen Sätzen bescheiden.

Mein Seher ist in Urlaub, und die Kristallkugel in Reparatur.

Eine lustige Antwort von Dir, die mir unterstellt, dass ich 
Informationen von Dir ignoriert hätte, die zu dem Zeitpunkt gar nicht 
vorhanden waren.

Timing kann bei Assemblerproblemen durchaus eine Bedeutung haben.

Unter einem laufenden Windows-Betriebssystem zählt der entsprechende 
Code wohl als "Filtertreiber".

Dir zuliebe nenne ich den Code, der die gleiche Aufgabe beim Systemstart 
wahrnimmt nun "Bert-Minus-Minus-Code". Wir wollen das Kind doch nicht 
bei seinem eigentlichen Namen nennen! :)

[cppbert3 (Gast)]

Peter M. schrieb:
> Assemblercode taucht in Deinem Eingangsbeitrag nicht auf.
> Ich musste mich daher mit Deinen wenigen Sätzen bescheiden.

Bei deinem Folgenpost stand der Assemblercode schon lange da

Wenn du mir helfen kannst dann mach es bitte konkret mit Fragen oder 
Ideen, aber beschwer dich nicht wenn dein dann doch etwas zu allgemeiner 
Tips bei mir nicht den Anklang finden den du erwartet hast und falls du 
keine Ahnung von Assembler und C Linkage hast ist ist es höchst 
wahrscheinlich schwer mir zu helfen, ich entschuldige mich im Vorfeld 
falls du doch tiefe Assembler/C Kenntnisse hast

[cppbert3 (Gast)]

Peter M. schrieb:

> Timing kann bei Assemblerproblemen durchaus eine Bedeutung haben.

> Unter einem laufenden Windows-Betriebssystem zählt der entsprechende
> Code wohl als "Filtertreiber".

Was auch immer die beiden Statements mit meinem Problem zu tun haben
- sollte dir unklar sein was der obige Assemblercode macht ist das 
einfach nicht der Platz um grobes PC wissen zur Schau zu stellen

[linker Linker (Gast)]

cppbert3 schrieb:
> im Grunde will ich mit C ein Binary erzeugen welches bei Offset 0 eine
> far-Jump Tabelle enthält

Du kannst die Ablage im Speicher per Linker koordinieren. Schau mal in 
die Beschreibung von TLink.

[rbx (Gast)]

Ich fühle mich hier erinnert an den Artikel "Assembler to C" von Walter 
Bright.
https://www.digitalmars.com/articles/b43.html

Da gab es glaube ich, auch noch etwas mehr dazu, finde ich aber nicht 
mehr.

Ein anderes Projekt ist der Midnight Commander von Miguel de Icaza - der 
den Dos - Norton Commander (asm) in C geclont hatte.

Microsoft wollte ja auch von Dos wegkommen und hatte dafür u.a. directx 
entwickelt.

Dann gibt es Dos-Programme/Rechner, die DPMI nicht abkönnen - aber so 
manches Dos-Programm braucht die Erweiterung auf z.B. Unreal-Mode z.B. 
oder eben ein Protected Mode Interface.

Bei einfachen 16-Bit Sachen muss der Linker das schwierige Real 
Mode-Handling betreiben - ohne dem wird das nix mit far-jumps.

Die Watcom-Programme laufen auf 16 Bit - und auf 32 Bit d.h. auch auf 
Windows 8. obwohl bei mir 64 Bit.
Auch dieses ist zu berücksichtigen: die Portabilität nach wohin genau?

Es gibt z.B. auch neuere Bibliotheken, so dass ältere Compiler gar nicht 
mehr auf älteren Kisten laufen bzw. gar nicht mehr aufwärts-compatibel 
sind.

[cppbert3 (Gast)]

rbx schrieb:
> Ich fühle mich hier erinnert an den Artikel "Assembler to C" von
> Walter
> Bright.
> https://www.digitalmars.com/articles/b43.html

den Artikel kenne ich

keine Ahnung was deinen anderen Sätze nur im entferntesten mit meinem 
Topic zu tun haben - ausser das es irgendwie mit DOS und 16Bit zu tun 
hat

ich mach nichts mit Windows oder DirectX, DPMI oder DOS/Windows 
Portierung sondern will eine DOS-Code den ich disassembliert habe von 
Assembler nach C portieren - das Ergebnis läuft aber weiterhin unter DOS

und der Linker hat mit der far/near/Real-Mode Segmentierungs-Sache bis 
auf das zuordnen der passenden Symbole keine Bedeutung - das muss alles 
der Kompiler machen

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

> von Assembler nach C portieren
Aber sonst bist Du gesund?

[Julius (Gast)]

Soweit ich verstanden habe geht es ja nur darum wie man eine 
Sprungtabelle in C programmiert. Dafür könntest Du dir auch den 
C-Startup-Code von heutigen ARM Cortex-M3 Mikrocontroller ansehen. Bei 
dem Keil uVision MDK for ARM ist entsprechender Code mit enthalten, oder 
es könnte auch Beipsiele im Netz irgendwo geben.

[cppbert3 (Gast)]

Julius schrieb:
> Soweit ich verstanden habe geht es ja nur darum wie man eine
> Sprungtabelle in C programmiert.

nur die Sprung-Tabelle ist nicht soo schwer, das ich aber meine Daten in 
C/C++ per CS oder Umwege DS adressiert bekomme scheint schwierig

Julius schrieb:
> Dafür könntest Du dir auch den
> C-Startup-Code von heutigen ARM Cortex-M3 Mikrocontroller ansehen. Bei
> dem Keil uVision MDK for ARM ist entsprechender Code mit enthalten, oder
> es könnte auch Beipsiele im Netz irgendwo geben.

ist das in dem Umfeld nicht alles super spezialisiert und lässt sich 
kaum auf mein MS-DOS 16 Bit Umfeld mappen?

[cppbert3 (Gast)]

Ben B. schrieb:
>> von Assembler nach C portieren
> Aber sonst bist Du gesund?

alle paar Jahre packt mich die Assembler-Lust und da ich beruflich u.a. 
auch im Reverse-Engineering tätig bin - dort aber selten mit alten 
Systemen zu tuen haben ist es schon eine Form von krankhaftem 
Masochismus der mich treibt :)

[cppbert3 (Gast)]

ich bin jetzt von der Idee abgekommen alles vollstaendig in C zu machen
d.h. ich schreiben den Jump-Table in Assembler und verweise auf externe 
far Functionen in C/C++

Assembliert, kompiliert und linkt auch - alles ganz toll

ABER

Jetzt werden meine Variablen in C/C++ nicht richtig adressiert:

1. der Zugriff passiert per DS-Register - obwohl durch den Plugin-Caller 
aber nur CS verfuegbar ist (ich koennte ds=cs+? setzen)
2. der Linker geht irgendwie davon aus das meine C/C++ Variablen in 
einem freien Segment vorliegen deswegen sind
die Variablen-Offsets beim Zugriff falsch

die alte DOS-Applikation macht diese komischen Vorgaben (Daten nur per 
CS erreichbar, und eben dieser Jump-Table) daran kann ich nichts
aendern

ich würde es sehr gerne vermeiden die Variablen in den Assembler-Code zu 
stellen - vielleicht hat ja jemand noch eine Idee

Was ich bisher haben:

Assembler-Code (Stellt sicher das der Jump-Table den DOS Plugin-Vorgaben 
entspricht)

drv_asm.asm

seg000 segment byte public 'CODE' USE16
  org 0 ; das Plugin hat bei Offset 0 den Jump-Table
  assume cs:seg000, es:nothing, ss:nothing, ds:nothing

dummy_entry_point: ; for the linker

; ---------------------------------------------------------------------------
; jump table aka "interface", far called by the "plugin" loading program
  jmp near ptr _tsub0
  jmp near ptr _tsub1
  ; jmp near ptr _tsub2
  ; ... around 20 function jumps
; ---------------------------------------------------------------------------

extrn _tsub0:far
extrn _tsub1:far
; extrn _tsub2:far
; ...

seg000 ends

end dummy_entry_point

drv_cpp.cpp

static int value1 = 10;
static int value2 = 11;

extern "C" {
  void far tsub0()
  {
    value1 = 20;
  }
  
  void far tsub1()
  {
    value2 = 22;
  }
}

Build-Script (Tools laufen alle unter Windows x64):

build.cmd

rem UASM: http://www.terraspace.co.uk/uasm.html
set uasm_exe=D:\rev_eng\uasm249_x64\uasm64.exe
%uasm_exe% drv_asm.asm

rem Microsoft Masm VS2010,VS2017,VS2019,...
rem call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat"
rem ml.exe /c /omf drv_asm.asm

rem DigitalMars dmc: https://www.digitalmars.com/download/freecompiler.html
rem   Digital Mars C/C++ Compiler Version 8.57: http://ftp.digitalmars.com/Digital_Mars_C++/Patch/dm857c.zip
rem   DOS 16 libraries: http://ftp.digitalmars.com/Digital_Mars_C++/Patch/dm850dos.zip
set DMC=D:\rev_eng\dmc\dm\bin\dmc.exe
rem Parameter: https://www.digitalmars.com/ctg/sc.html
%DMC% -mtd -NL -2 -c drv_cpp.cpp
rem -mtd = Memory model tiny dos -NL = no standard lib, -2 = only <=286 code, -c = only compile

rem UniLinker: ftp://ftp.styx.cabel.net/pub/UniLink/ulnb1187.zip (or later)
set ulink_exe=D:\rev_eng\unilink\ulnb1185\ulink.exe
%ulink_exe% -T16 -Tbi drv_asm.obj drv_cpp.obj, drv.drv, drv.map

nach dem kompilieren kommt diese drv_cpp.obj Datei raus - Auszug aus IDA

DGROUP:0000
DGROUP:0000 ; Segment type: Group
DGROUP:0000 DGROUP group _DATA,CONST,_BSS
DGROUP:0000
_TEXT:0000 ; ===========================================================================
_TEXT:0000
_TEXT:0000 ; Segment type: Pure code
_TEXT:0000 _TEXT  segment word public 'CODE' use16
_TEXT:0000        assume cs:_TEXT
_TEXT:0000        assume es:nothing, ss:nothing, ds:DGROUP, fs:nothing, gs:nothing
_TEXT:0000
_TEXT:0000        public _tsub0
_TEXT:0000 _tsub0 proc far
_TEXT:0000        mov     ds:word_10020, 20
_TEXT:0006        retf
_TEXT:0006 _tsub0 endp
_TEXT:0006
_TEXT:0007        public _tsub1
_TEXT:0007 _tsub1 proc far
_TEXT:0007        mov     ds:word_10022, 22
_TEXT:000D        retf
_TEXT:000D _tsub1 endp
_TEXT:000D
_TEXT:000D ; ------------------------------------------------------------------
_TEXT:000E        align 4
_TEXT:000E _TEXT  ends
_TEXT:000E
_DATA:0000 ; ===========================================================================
_DATA:0000
_DATA:0000 ; Segment type: Pure data
_DATA:0000 _DATA           segment word public 'DATA' use16
_DATA:0000                 assume cs:_DATA
_DATA:0000 word_10020      dw 10                  ; DATA XREF: _tsub0+w
_DATA:0002 word_10022      dw 11                  ; DATA XREF: _tsub1+w
_DATA:0004                 align 10h
_DATA:0004 _DATA           ends
_DATA:0004
CONST:0010 ; ===========================================================================
CONST:0010
CONST:0010 ; Segment type: Zero-length
CONST:0010 CONST           segment word public 'CONST' use16
CONST:0011 CONST           ends
CONST:0011
_BSS:0020 ; ===========================================================================
_BSS:0020
_BSS:0020 ; Segment type: Zero-length
_BSS:0020 _BSS            segment word public 'BSS' use16
_BSS:0020 _BSS            ends

und das fertig Plugin "drv.drv" sieht dann nach dem Linken so aus

seg000:0000 ; Segment type: Pure code
seg000:0000 seg000 segment byte public 'CODE' use16
seg000:0000        assume cs:seg000
seg000:0000        assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
seg000:0000 ; ------------------------------------------------------------------
seg000:0000        jmp     near ptr _tsub0
seg000:0003 ; ------------------------------------------------------------------
seg000:0003
seg000:0003 loc_3:                         
seg000:0003        jmp     near ptr _tsub1
seg000:0006
seg000:0006 _tsub0 proc far                
seg000:0006                                
seg000:0006        mov     word ptr ds:loc_3+1, 20
seg000:000C        retf
seg000:000C _tsub0 endp
seg000:000C
seg000:000D
seg000:000D _tsub1 proc far                
seg000:000D        mov     word ptr ds:_tsub0, 22
seg000:0013        retf
seg000:0013 _tsub1 endp
seg000:0013
seg000:0013 ; ------------------------------------------------------------------
seg000:0014        dw 10
seg000:0016        dw 11
seg000:0016 seg000 ends

man sieht deutlich das die Variablen-Offsets so aufgeloest worden sind
als wenn es wirklich ein Daten-Segment geben wuerde, d.h. die Offsets 
reichen in Code-Bereiche

ich habe keine Idee wie ich das lösen kann

[cppbert3 (Gast)]

Es kommt der gleiche Code raus wenn ich das mit einem alten Borland C++ 
3.1, TLINK, 16 Bit MS-Linker usw. probiere - damit hat es nichts zu tun, 
der Linker hat eben keine Ahnung was er machen soll

[cppbert3 (Gast)]

die beiden Zuweisungen mit 20 und 22 gehen aus ds:4 und ds:6

seg000:0006        mov     word ptr ds:loc_3+1, 20
--> mov word ptr ds:4, 20

seg000:000D        mov     word ptr ds:_tsub0, 22
--> mov word ptr ds:6, 22

also mitten rein in meinem Jump-Table-Code, nur warum Offset 4 und 6 ist 
mir noch nicht klar

[cppbert3 (Gast)]

cppbert3 schrieb:
> also mitten rein in meinem Jump-Table-Code, nur warum Offset 4 und 6 ist
> mir noch nicht klar

ah, ok das Map-File erklaerts

drv.map

 Base Offset   Length Name               Class
 0000:0000     0006   SEG000             CODE    
 0000:0006     000E   _TEXT              CODE    
 0001:0004     0004   _DATA              DATA   <-- hier sind die Variablen

d.h. die variablen werden um 0001:0004 => 0001*16+0004 => 14h Bytes nach 
unten verschoben

_DATA:0000 ; Segment type: Pure data
_DATA:0000 _DATA           segment word public 'DATA' use16
_DATA:0000                 assume cs:_DATA
_DATA:0000 word_10020      dw 10                  ; DATA XREF: _tsub0+w
_DATA:0002 word_10022      dw 11                  ; DATA XREF: _tsub1+w
_DATA:0004                 align 10h
_DATA:0004 _DATA           ends

word_10020 ist dann bei 14h+0
word_10022 ist dann bei 14h+2

[cppbert3 (Gast)]

cppbert3 schrieb:
> nur warum Offset 4 und 6 ist
> mir noch nicht klar

und durch das align 4

_TEXT:000E        align 4
_TEXT:000E _TEXT  ends

werden die Offset um 4 innerhalb der dev_cpp.obj verschoben

[cppbert3 (Gast)]

im Anhang das jetzige Layout mit den falschen Offsets

kann ich überhaupt zum Linkzeitpunkt die falschen mov-Offsets im TEXT 
Segment noch beeinflussen?

eine andere Idee wäre es das DATA-Segment zwischen den Jump-Table und 
die C-Funktionen zu linken und dann irgendwie den Wert von ds per Hand 
über die größe des Tables zu berechnen + Tramplin-Funktion pro 
Table-Eintrag - und damit indirekt die move-Offsets zu korrigieren?

Fühlt sich alles ein wenig bastelig an - aber so ein Plugin ist eben 
auch absolut keine normale Exe oder Com-Program

Kennt jemand vielleicht noch ein Forum das mehr auf solche Frage 
spezialisiert ist?

[cppbert3 (Gast)]

fast geschafft:

beim UniLink wie auch beim Microsoft Linker gibt es eine Option um 
Sections zu mergen

ich hab jetzt einfach mit "-GM:_TEXT=_DATA" als Linker Parameter 
befohlen die beiden Segmente in eins rein zu machen - und schon passen 
die Offsets

jetzt ist nur noch blöd das der C-Kompiler DS zur Adressierung der Daten 
nutzt - sonst wäre ich schon fertig mit dem Rumpf :(

seg000:0000 seg000  segment byte public 'CODE' use16
seg000:0000         assume cs:seg000
seg000:0000         assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
seg000:0000         jmp     near ptr sub_6
seg000:0003 ; -------------------------------------------------------------------
seg000:0003         jmp     near ptr sub_D
seg000:0006
seg000:0006 ; ======= S U B R O U T I N E =======================================
seg000:0006
seg000:0006
seg000:0006 sub_6   proc far                ; CODE XREF: seg000:0000j
seg000:0006         mov     ds:word_14, 14h
seg000:000C         retf
seg000:000C sub_6   endp
seg000:000C
seg000:000D
seg000:000D ; ======= S U B R O U T I N E =======================================
seg000:000D
seg000:000D
seg000:000D sub_D   proc far                ; CODE XREF: seg000:0003j
seg000:000D         mov     ds:word_16, 16h
seg000:0013         retf
seg000:0013 sub_D   endp
seg000:0013
seg000:0013 ; -------------------------------------------------------------------
seg000:0014 word_14 dw 0Ah                  ; DATA XREF: sub_6w
seg000:0016 word_16 dw 0Bh                  ; DATA XREF: sub_Dw
seg000:0016 seg000  ends

[cppbert3 (Gast)]

jetzt hatte ich gedacht eine schöne Lösung gefunden zu haben (sogar die 
Adressierung per DS sieht so gut aus) - aber leider sind jetzt meine 
Variablen-Offsets wieder falsch :(

CALL_C macro c_function
  push ds
  push cs
  pop ds
  assume ds:seg000
  call c_function
  pop ds
  retf
endm

extrn _tsub0:near
extrn _tsub1:near
; extrn _tsub2:near
; ...

seg000 segment byte public 'CODE' USE16
  org 0
  assume cs:seg000, es:nothing, ss:nothing, ds:nothing

dummy_entry_point: ; for the linker

; ---------------------------------------------------------------------------
; jump table "interface", far called by the "plugin" loading program
  jmp near ptr tsub0_stub
  jmp near ptr tsub1_stub
  ; jmp near ptr _tsub2
  ; ... around 20 function jumps
; ---------------------------------------------------------------------------

tsub0_stub: CALL_C(_tsub0)
tsub1_stub: CALL_C(_tsub1)
; ...

seg000 ends

end dummy_entry_point

[cppbert3 (Gast)]

Fertig!

so jetzt klappt es - mit dem Open Watcom V2 kann man auch CODE-Segment 
Variablen machen
damit bekomme ich dieses komische Plugin-Konzept unter Kontrolle
und kann jetzt alles schoen in C/C++ nachbauen

drv_asm.asm

extrn tsub0_:far
extrn tsub1_:far
; extrn _tsub2:far
; ...

seg000 segment byte public 'CODE' USE16
  org 0
  assume cs:seg000, es:nothing, ss:nothing, ds:nothing

dummy_entry_point: ; for the linker

; ---------------------------------------------------------------------------
; jump table "interface", far called by the "plugin" loading program
  jmp near ptr tsub0_stub ; a stubbed version
  jmp near ptr tsub1_ ; direct call (if there are no parameters to handle)
  ; jmp near ptr _tsub2_stub
  ; ... around 20 function jumps
; ---------------------------------------------------------------------------

tsub0_stub: 
  ; prepare parameter if needed
  jmp near ptr tsub0_

seg000 ends

end dummy_entry_point

drv_cpp.cpp

#define CODE_SEG_VAR __based( __segname("_CODE") )

static int CODE_SEG_VAR value1 = 10;
static int CODE_SEG_VAR value2 = 11;

extern "C" {
  void far tsub0()
  {
    value1 = 20;
  }
  
  void far tsub1()
  {
    value2 = 22;
  }
}

build

D:\rev_eng\uasm249_x64\uasm64.exe drv_asm.asm
D:\rev_eng\open-watcom-2_0-c-win-x64\binnt64\wpp.exe drv_cpp.cpp -2 -zl -zls -s
D:\rev_eng\ulnb1187\ulink.exe -T16 -Tbi drv_asm.obj drv_cpp.obj, drv.drv, drv.map