Alte Exe mit neuer DLL verbinden ohne Quellcode der Exe

[Haarmann]

Also das Problem ist einfach.

Die DLL dient als Middleware und vermittelt zwischen Geräten/anderer Middleware. Es wurden nur jeweils neue Geräte/Middleware hinzugefügt - der Funktionsumfang an sich ist gleich geblieben.

Vorhanden sind eine Exe, eine DLL der neuen Version, die passende .lib und die passende .h Datei zur DLL.

Gibt es Werkzeuge, die einem das Problem lösen könnten?

Es handelt sich nebenher um Code aus der "Steinzeit" - Windows 3.1 Codebasis und wohl saubere 16 Bit..

[TheRaven666]

Wenn die DLL binärkompatibel erstellt wurde sollte sich das eigentlich sogar ohne Tools durch C&P Deployment und erneutes registrieren lösen lassen. Ich geh davon aus, dass es sich um COM handelt?

[Ectoplasma]

Die .lib und die .h Dateien sind nicht relevant. Das Einzige was zählt ist, dass die exportierten Funktionen der DLL vollständig sind, die Signaturen der Funktionen gleich geblieben sind und falls Strukturen als Parameter übergeben werden, sich diese nicht geändert haben. Falls alle o.g. Dinge zutreffen, brauchst du gar nichts machen. Die Exe läuft dann einfach so mit der neuen DLL. Vorausgesetzt der Name der DLL ist gleich geblieben.

Ein Tool brauchst du dafür nicht.

[Haarmann]

Also mit der neuen DLL geht es eben nicht. Das habe ich schon getestet.

Es handelt sich halt um uralte Win16 Krücken.

[Ectoplasma]

Ähm, kannst du mal ein wenig präziser werden. Meine Glaskugel funktioniert grad nicht ...

Für welche Zielplattform soll das Ganze sein?
Für welche Plattform ist die EXE?
Für welche Plattform ist die DLL?

Man kann schon mal sagen, dass eine 16 Bit EXE keine 32 Bit DLL verwenden kann. Die Zielarchitektur muss für beide identisch sein. Ich wüßte auch nicht, wie ein Werkzeug das beheben sollte.

[Haarmann]

Ectoplasma

Alles ist 16 Bit - Win16 also.

Es steht in der DLL Visual C++ 1.5 - passt zeitlich ganz gut.

Es ist Steinzeitcode - deswegen ist vom ursprünglichen Verfasser des Codes wohl kaum mehr wirkliche Hilfe zu erwarten.

[Ectoplasma]

Und es gibt keine Fehlermeldung? Das Programm startet und hört dann gleich wieder auf, oder wie muss man "geht nicht" verstehen? Leicht machst du es einem nicht gerade, dir zu helfen.

[Haarmann]

Ectoplasma

Es ist eine Exe, aber es läuft nicht eigenständig. Es wird von einem "Ungetüm" aus DOS Zeiten mit Komponenten in Win16 und Win32 aufgerufen und gibt die Daten per DDE und Textfiles herum.

Wenn ich die DLL tausche und das "Ungetüm" starte startet sich auch die Exe, wenn das eingeschaltet ist, es ist ja quasi ein Gerätetreiber, und schmiert sofort ab. Beim Schliessen das Gleiche.

Würde es gehen, würde die Exe mit DLL ein Gerät öffnen resp. schliessen.

[ShadowXX]

Vergiss es. Wenn die Exe und DLL nicht zusammenpassen bekommst du das nie zum Laufen.

Wahrscheinlich wurde in der neuen DLL so viel geändert gegenüber der alten das die Exe die die DDL aufruft umgeschrieben werden müsste.
Deshalb waren bei der DDL auch der Header und die Lib mit dabei, damit eine neues Executable (nach Anpassungen im Quellcode) erzeugt werden kann das dann zur DLL passt.

Mit irgendwelchen Tools kommst du da nicht weiter. Wenn du zu viel Zeit und lust hast könntest du natürlich versuchen irgendwie einen Wrapper zu programmieren...viel Spass:freak:

[Coda]

16 bit DLLs kann man ja allein schon gar nicht in einem 32-Bit-Programm laden.

Man bräuchte als eine 16-Bit-Host-Executable (brrrrrr), die per IPC mit einem 32-Bit-Programm kommuniziert. Hört sich abenteuerlich an.

[Haarmann]

ShadowXX

Funktionen der DLL sind identisch - ich hab die Dateien von beiden Versionen. Es braucht für diese Anwendung auch keine neuen Funktionen. Ist seit Jahren das exakt Gleiche - und wirds bleiben.

Lib und Header Datei sind jeweils identisch gross. DLL wuchs um einige kBytes. Passt im Prinzip, denn eigentlich wurde nur ein einziges Gerät hinzugefügt - zuvor 7 Geräte und nun 8 Geräte.
Ich denke es ist klar, welches Gerät ich benutzen möchte ;).

Coda

Es tummeln sich dort MDBs von Access 2000 und Access 2.0 - die laufen quasi synchron.

Die Exe wird kaum grundlos nur per DDE benutzt (Ich glaube das hiess mal Dynamic Data Exchange). Und schreibt wirklich Textfiles als "Dialog" mit det Anwendung.
Der Fehler mit der neuen DLL wird irgenwie bei 0001:aedf oder so erzeugt - klingt auch schwer nach Segment Offset.
Im EXE steht Vorne das übliche - Program kann nicht in DOS Modus ausgeführt werden.

Ist ne richtige Baustelle und Bastelstube - historisch gewachsene Software.

Am Anfang wars meiner Information nach ein DOS Produkt - diese Version hab ich nie gesehen.
Das Teil läuft aber, den Spass habe ich mir gegönnt, in der ersten Version, bestens auf Windows 3.1.

Es läuft nicht auf Vista oder Windows 7 - keine Chance - weder x86 noch x64.

P.S. Falls es wirklich wen interessiert um welche glorreiche DLL es sich handelt... per PM möglich, aber ich will präventiv Aerger ausm Weg gehen. Das "Produkt" wird nach wie vor feil geboten. Ausdrücklich auch für DOS....

[Coda]

Was passiert denn überhaupt wenn du die DLL einfach darüberkopierst?

[Exxtreme]

Also das Problem ist einfach.

Die DLL dient als Middleware und vermittelt zwischen Geräten/anderer Middleware. Es wurden nur jeweils neue Geräte/Middleware hinzugefügt - der Funktionsumfang an sich ist gleich geblieben.

Vorhanden sind eine Exe, eine DLL der neuen Version, die passende .lib und die passende .h Datei zur DLL.

Gibt es Werkzeuge, die einem das Problem lösen könnten?

Es handelt sich nebenher um Code aus der "Steinzeit" - Windows 3.1 Codebasis und wohl saubere 16 Bit..
Wird schwer. ;)

Bei so einer alten Software wird wohl call by ordinal verwendet. DLL-Funktionen kann man entweder über den Namen der Funktion oder über die Ordinalzahl aufrufen. Wenn es über den Namen geschieht dann reicht ein Drüberkopieren der neuen DLL über die alte. Wenn es nicht funktioniert dann ... wird's eklig bis nicht machbar mit einem vertretbaren Zeitaufwand. Du müsstest nämlich die alten und die neuen Ordinalzahlen kennen und dann die Exe patchen.

[Haarmann]

Coda

Der Assistent mit dem Fehlermeldung an MS senden erscheint beim Start und beim Stop. Hiesse Gerät lässt sich nicht öffnen und Gerät lässt sich nicht schliessen.

Nicht nur das neue Gerät, sondern auch die Bestehenden. Die Fehlermeldungen kenne ich sonst quasi auswendig.

Exxtreme

Sieht so aus - es ist Offset 0001dace laut Problemmelder und beim schliessen auch wieder 0001dace.

Mal nen Hexeditor befragen, was dort bei der alten zu sehen wäre

Das müsste ich das wohl auf 000216FE biegen... also den Spass gönne ich mir wohl noch ;)

[Ectoplasma]

Also wenn alles schon mal lief, kann es ja auch einfach sein, dass im Initialisierungs-Code der DLL für das neue Device, irgendetwas nicht stimmt. Lief denn die DLL überhaupt schon mal irgendwo?

Es kann auch sein, dass einer der Letzten beiden Problempunkte, die ich oben schon mal genannt hatte, das Problem ist. Es sind zwar alle Funktionen der DLL vorhanden, aber die Signatur von einigen Funktionen könnte sich geändert haben.

[Haarmann]

Ectoplasma

Die DLL läuft bestens mit entsprechenden Testwerkzeugen - die hab ich auch dazu bekommen. Im Prinzip springt diese neue DLL dann auch wieder nur eine andere DLL an in meinem Gerätefall - Middleware zu Middleware. Das Ganze Paket habe ich vom Hersteller der DLL und vom Hersteller des Gerätes - und das Gerät ist auch bereits im Einsatz. Es läuft... nur nicht vom "Ungetüm" aus. Vielleicht sollte ichs besser Fossil nennen ;).

Ich versuchte auch schon eben ein Gerät der alten Version zu steuern mit der neuen Version per "Ungetüm" - geht nicht.

Wenn ich es richtig verstehe müsste die lib Datei mal eingebunden worden sein, weswegen das Teil nun versagt.

Header Files sind identisch der 2 Versionen - lib Dateien gleiche Länge, aber anderer Inhalt. Gibts da nicht zB einen "Unlinker" und "Relinker" oder sowas?

Solche netten Werkzeuge wird es doch sicher noch geben. Disassembler sind ja auch noch nicht ausgestorben.

[Ectoplasma]

Gibts da nicht zB einen "Unlinker" und "Relinker" oder sowas?

Solche netten Werkzeuge wird es doch sicher noch geben. Disassembler sind ja auch noch nicht ausgestorben.

Wird es wahrscheinlich geben. Habe ich selbst noch nicht verwendet. Aber das Ganze willst du dir nicht wirklich antun oder? Ich meine ich habe sehr lange Zeit in Assembler programmiert, hat auch spass gemacht, aber ein Problem dieser Art zu lösen ist ungefähr so wie das Tauchen in eine Jauchegrube und dabei kräftig zu schlucken. Jetzt versuch mal dabei noch zu grinsen.

[Haarmann]

Ectoplasma

Ergo Plan B...

Ich brauche einen Dummy DDE Server, der mir die Daten, der das Fossil an diese Exe schicken will ausgibt, loggt oder was auch immer. Mit DDE kenne ich mich ehrlicherweise nicht wirklich aus.

Was ich weiss:

Fossil schickt nur Daten - es empfängt keine Daten direkt. Wenn der Befehl erfolgreich war, dann gibts als Ergebnis schlicht ein Textfile als Antwort, das dann bearbeitet werden kann vom Fossil.

Die Textdatei wird von der DLL erstellt - von daher bin ich auf die EXE nicht wirklich angewiesen.

Kennt sich jemand mit so einem DDE Server Tool aus?