qemu gpio direkter HW-Zugriff

>Win16 Software binary (sourcen vorhanden) mit HW-Zugriff

Auf welche Ports greift die Software denn zu - was wird gesteuert?

Wäre es nicht sinnvoller das ganze auf Win32 zu portieren
und die Hardware-Anbindung anders zu lösen?

In was ist die Software geschrieben (Borland, Watcom, Visual C/C++ 1.x, 
VB)?

Die Software darf nicht geändert werden !

>Die Software darf nicht geändert werden !

1. Warum nicht (falls es nicht per qemu oder sonstigem geht)?
2. warum schreibst du dann das du den Source Code vorliegen hast?
3. was wird denn jetzt über welche Ports gesteuert?

Original Laufzeitverhalten, irgendwelche Audits, Abnahmen usw. sind eh 
dahin wenn du das ganze auf eine VM migrierst

Anmerkung: 3 Frage = 3 Antworten :)

@Bert3

1. Warum nicht (falls es nicht per qemu oder sonstigem geht)?
   - Es sind zu viele SW-Varianten - eine Neuentwicklung/Portierung auf 
ein
     neues Betriebssystem ist zu aufwendig.
   - Neue OS mit Windows (10 o.ä) sind nicht mehr optimal für embedded
     -> Migration auf Linux.
   - Die SW soll einfach weiterleben, nur das OS + HW ändert sich.

2. warum schreibst du dann das du den Source Code vorliegen hast?
   - Damit man weiß welche Ports man per qemu durchschleusen muss,
   - Es ist kein reverse engineering auf binär - Ebene nowendig.

3. was wird denn jetzt über welche Ports gesteuert?
   - Es sind einfach digitale IO's + serial mit handshake etc.
   - Die alte HW hat ein anderes GPIO-Interface als die neue,
     alt z.B. Parallelport, neu PCI-Express. Eine SW-Schnittstelle in 
qemu
     fängt die Zugriff ab, und setzt diese funktionell im neuen OS 
(Linux)
     auf neue HW-Schnittstellen um.

Original Laufzeitverhalten, irgendwelche Audits, Abnahmen usw. sind eh
dahin wenn du das ganze auf eine VM migrierst

Na klar gibt es neue Abnahmetests.

Du hast nicht nur den Quelltext deiner Software vorliegen, sondern auch 
den von QEmu.

also: ran an die Tasten, und deine Sonderhardware in QEmu emulieren.
Ob du dass dann außerhalb vom Qemu auf dieselbe echte Hardware, was 
neueres, oder was eigenes umbiegst ist dann nochmal eine andere 
Geschichte.

@Virtualisierer

Wenn deine Vorgaben und Möglichkeiten so klar sind würde ich

1. auf jeden Fall mal eine aktuelle qemu-Version nutzen - so als 
Standardvorgehen (gibt oft genug welche die dann mit 0.1.x rumdaddeln)

2. auf der qemu-Mailinglist
http://wiki.qemu-project.org/Contribute/MailingLists
Users (vielleicht sogar Developers) dein Anliegen (wenigstens so 
vollständig wie deine Antwort auf meine Fragen) vorstellen

da bekommst du am schnellsten Hilfe

d.h.
-welche qemu-Version (oder git-hash deiner Version)
-genaues Host-System setzt du ein (Linux x64, Kernel xyz, Ubuntu...)
-welche GPIO-Interface war es mal, soll es werden (ist es)
-was hast du schon ausprobiert/implementiert

denke dann bekommst du schneller passende Antworten

@Bert3

danke, ich hatte die Hoffnung das jemand sich hier schonmal damit
beschäftigt hat.

kannst du deinen Post dann hier auch reinstellen - wäre interessant

einfach einen Link auf die entsprechenden Mailinglist/Archiv/Seite