Ich arbeite an einer Anwendung, die mehr als ein paar DLLs in VB6 geschrieben hat. VB6-Code enthält COM-DLLs und OCX-Steuerelemente. Der Rest des Codes ist in C++ und C#. Mir wurde die Aufgabe zugewiesen, die Anwendungscode-Basis mit 64-Bit-Architekturen kompatibel zu machen. Jede Menge Hilfsmaterial ist für C/C++ - Code verfügbar, so dass es kein Problem gibt. Aber es ist nicht einfach, all diesen vb6-Code in .net oder eine andere Sprache umzuschreiben, um es mit 64bit kompatibel zu machen. Ich verstehe auch nicht die gesamte zugrunde liegende Logik, sondern gehe einfach davon aus, dass ein Neuschreiben nicht in Frage kommt.Laden/Interagieren mit einer vb6 COM DLL von einer 64bit Anwendung
Auf der anderen wissen wir alle, dass VB6 dlls nicht in 64-Bit-Umgebung arbeiten wird. Was sind meine Möglichkeiten?
1) Covert jede der DLL in eine EXE, die in 32bit geladen wird und es kann mit meinem Rest der 64-Bit-Anwendung über COM-Schnittstellen interagieren. Sehen Sie Probleme mit diesem Ansatz?
2) Ich bearbeiten Sie die Registrierung und laden Sie alle VB6-DLLs aus dem Prozess, laden Sie sie in Dllhost.
3) Machen Sie eine einzige 32bit exe, beziehen Sie alle diese VB6 dlls in dieser exe und laden Sie diese exe in 32bit Adressraum und der 64bit Teil meiner Anwendung kommuniziert mit der 32bit exe.
Das Hauptproblem, das mir bei allen oben genannten Ansätzen in den Sinn kommt, ist, was mit OCX-Steuerelementen zu tun ist ????
Irgendwelche Ideen? Wenn keine neuen Ideen als die oben genannten von Ihnen bevorzugt werden und warum?
Haben Sie herausgefunden, wie die Kommunikation zu tun COM zwischen 64-32 mit? Es sieht immer noch so aus, als würde es eine Art Missverhältnis geben. –
Nopes, ich habe noch kein Experiment gestartet, werde es aber aktualisieren, sobald Erfolg oder Misserfolg eintritt. – Paragon
Eine solche Kommunikation sollte normalerweise reibungslos funktionieren - besonders wenn alle Schnittstellen kompatibel sind, wie in Ihrem Fall. –