Delphi 7 32-Bit / C++ Builder 6 32-Bit / GNU C++ 64-Bit - Load 64-Bit in 32-Bit ?

[paule32.jk]

Hallo,

ich würde gerne .DLL Dateien, die ich mittels MinGW32 / MinGW64 erstellt habe unter Delphi 7 laden.
Aber wer das schonmal versucht hat, der kann auch (wie ich) auf Informationen im Internet stoßen,
die erklären, das in einen Laufenden 32-Bit Prozess, keine 64-Bit .DLL geladen werden kann.
Gleiches gilt natürlich auch in umgekehrter Richtung.

Dies ist ein Umstand, der unter Windows 10/11 (oder allen) besteht, und so dass (programmieren)
erschweren läßt ...

Nun habe ich gelesen, das man durch Verwendung von DCOM (eine Windows-Erfindung, die auf einer
weiterentwickelten *nix RPC (Remote Procedure Call) Basis erfunden wurden.
Das heißt, das man eigentlich nur unter Windows-Systeme dieses "alte" RPC-Protokoll nutzen kann.

Aber man hat doch schon unter Delphi 7 und dem C++ Builder 6 die Möglichkeit RPC in Form von
DCOM Modulen die beiden Welten 32 und 64-Bit unter Windows zu koppeln.

Leider ist es mir noch nicht gelungen, alle Welten durch die Pakete MingW32/64 zu koppelln, und ich
einen Workaround verkrätschung mache: Bison/Flex mittels GNU-C den C Code erstellen lasse, und den
erzeugten C-Code mittels C++ Builder 6 in einen reinen "nicht" mutithreading "C" Projekte übersetze
unf fie so erzeugte .DLL in den entsprechenden .EXE Ordner kopiere.

Ich würde in diesen Zusammenhang gerne die C++ (mit und ohne VCL) Möglichkeiten der C++ Builders
nutzen (weshalb ich vorerst meine Zeit vergeutet habe, das ganze per GNU 64-Bit zu erstellen).
Mir ist bewust, das es das Framework Qt5 gibt - aber das ist mir irgendwie in der Lizenzierung
zu suspect, und ich daher lieber auf "ältere" und "Eigene" Lösungen zugreife.

Naja, zurück:
Leider verweigert der C++ Builder reinen C Code im C++ Modus, und im C++ Modus C Code.
Ich würde das ganze mittels FPC erzeugen, aber das ist irgendwie umständlicher (und fätter) als
das gute (und mittlerweile freie) Delphi 7 - jedenfalls kann man es frei erhalten.

Zudem sind die Tools, die gerne nutzen möchte sehr viel älter (pyacc.exe und plex.exe), und
dadurch auch sehr beschränkt (was die moderne Anwendungsprogrammierung auch nicht gerade föderlich
dahstehen lässt).

Zusammenfassend:
- plex / pyacc sind zu alt, und beschränkt
- zur Zeit kann ich nur 32-Bit .EXE, und .DLL Daten verbinden

- würde mehr über DCOM erfahren, um ggf. die Welten zwischen 32 und 64 Bit sowie Windows und *nix
zu verstöpseln (kann auch erstmal mit lokalem Rechner erfolgen)
- würde dann ggf. auf Indy 9 aufsetzen (falls das besser ist)
Indy 9, weil ich da erstmal kein SSL brauche (das wird da auch so offiziell nicht unterstützt
und steht erst in der Version 10 zur Verfügung)

- für das RPC würde ich eine bestehende (Indy ähnliche) Bibliothek nutzen wollen, um bestehende
Merkmale (Bugs) nicht neu schreiben zu müssen

Vielleicht nen bissl viel Text bis hier hin - aber ich dachte, schreibst einfach mal, in welche
Richtung das gehen soll.

Mit freundlichen Grüßen
Euer paule

[himitsu]

ActiveX, DCOM und Co.

Auch da gilt, in 32 Bit nur 32 Bit und in 64 Bit nur 64 Bit,
aber das ist auf einen InProcess-Server bezogen. (also wenn diese "DLL" im eigenen Prozess geladen wird)

Einem OutOfProcess-Server ist das egal, da dieser in einem "externen" Prozess geladen wird. (also die DLL nicht in deinem Prozess)
-> Die DLLHost-EXEn sind dir im Taskmanager bestimmt schon aufgefallen.


Im CC gab es auch mal einen Code für 32/64-Bit-Bridge, wo man 64-Bit-DLLs in einem 32-Bit-Programm laden konnte ... oder irgendwie sowas.

[Bernhard Geyer]

Was spricht gegen die kostenlose Community-Edition
(https://www.embarcadero.com/de/products/delphi/starter)
und dort in einem 64-Bit Exe die 64-Bit DLL zu laden?

in 2023 zu versuchen für sowas umwege über COM/DCOM und Co. zu machen.
Will man sich wirklich sowas "ans Bein binden"?

[paule32.jk]

Hallo Bernhard,

im Prinzip ginge das eventuell.
Allerdings ist die Community Version von Delphi so eingeschränkt, dass nach Ablauf
der Lizenz(tage) ALLES komplett gelöscht und wieder aufgespielt werden.

Dann müssen wieder ALLE Packages neu installiert werden.

Diese Einschränkung hat man in der Pro Version nicht.
Allerdings kostet die Pro Version als Einzelerwerb 1234 Euro.

Für lanjahrige Community-User ist gerade eine Aktion mit 30 % Rabatt.

Aber wenn man auch dann noch wie ich nur 80 Euro im Monat zur Verfügung hat, dann
sind Alternativen nur die Lösungen.

Aber ob man sich dass dann ALLES ans Bein binden will ... ich weiss es nicht.

[himitsu]

MigrationsTool.

Einfach alle registrieren Packages in eine Neue Version mitnehmen geht aber eh nicht, da die neue IDE der neue Compiler auch zu sich passende Packages haben will.


GetIt: Da ibt es auch FremdTools, oder man sieht sich mal die GetItCmd.exe an, anstatt der ekligen GUI.

[paule32.jk]

Hallo,

nochmals herausgekrammt - für eventuelle nützliche Informationen ...

Das Problem mit Delphi 7 und C++ Builder 6 wurde soeben von mir gelöst.
Man muss irgendwie aufpassen, das man die richtigen Header von BC++B in
der richtigen Reihenfolge angibt.

Ich weiß nicht warum, aber folgende Zeilen führen zu einen Caos im BCB:

Code:

# include "../common.h"  // eine Benutzerspezifische Header Datei 
# include <vcl.h>
# include <windows.h>

Aber folgende Zeilen führen zum Erfolg:

Code:

# include <vcl.h>
# include <windows.h>

# include "../common.h"

Ich habe Stunden damit verbracht, um diesen kleinen Markel zu finden.
Aber wie ist es schön zu schreiben:
- Ente Gut, Alles Gut.

Nun kann ich die VCL (C++) und reinen C Code zusammen verwenden, und die
benötigten Funktionen exportieren, und in Delphi importieren.

Hope this Helps others...

MfG
paule32