Die Vermutung mit dem lseek war natürlich Blödsinn, hat ja einen long-Parameter und keinen int. Sonst könnte ja kein DOS-Programm mit Dateien >32MB umgehen.
Falls es wen interessiert:
Die Problembehebung wird sich vermutlich als sehr schwierig bis unmöglich gestalten. OpenAccess ist in UCSD Pascal geschrieben. Nähere infos dazu gibt es z.B. hier:
http://pascal.hansotten.com/index.ph...=ucsd-p-system
Das ist quasi eine Art virtuelle Maschine, die Bytecode ausführt, um Systemunabhängig zu sein. Das bedeutet, dass in der OA4.SPI kein echter Assemblercode steckt sondern sogenannter Pcode, welcher von einer virtuellen Maschine interpretiert wird. Genauer gesagt handelt es sich um ein Diskimage, welches der Interpreter dann mountet und verwendet. Jetzt ist es mir zwar gelungen, das Diskimage zu zerlegen und Dateien daraus zu dumpen. Jedoch kann ich die library-Dateien nicht in ihre einzelnen Module zerlegen. Selbst wenn mir das gelingen sollte (erachte ich noch durchaus als machbar), so könnte ich dann eventuell die einzelnen Routinen in PCODE disassemblieren. Nachdem man dann aber nur den reinen Code für die Stackmaschine ohne jegliche Referenzen hat, und auch ein debuggen ja nicht möglich ist, da man mit einem normalen Debugger ja nur den Assembler-Code durchsteppen kann, wird eine Analyse des Problems nahezu unmöglich. Denn wenn man im Debugger breakt, landet man prinzipiell einfach nur in der Interpreterschleife für den PCODE.
Insofern haben wir bei dem Pause-Enter Problem noch Glück gehabt, denn das scheint ein Problem der UCSD-Pascal Runtime gewesen zu sein und diese muss logischerweise in Assemblercode vorliegen.
Schlechte Karten also...
Hat sonst noch wer das Problem mit der Netzwerkversion?