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

[Bernhard Geyer]

Zitat von paule32.jk:

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.

Ich würde darauf Tippen das eine globale Konstante/TypeDef in beiden Units vorhanden ist, aber unterschiedlichen Wert/Definition.
Sowas hatte ich auch ein paar Mal. Glücklicherweise waren aber die definitionen zueinander inkompatible, so das der Compiler gemeckert hat.
Aber wenn in der einen Unit z.B. TRUE als 1 definiert ist und in der anderen als -1, kann es das schon Probleme geben, die einem Compiler nicht auffällt.

[paule32.jk]

naja, kommisch ist auch, dass ich die C++ STL nicht verwenden kann, wenn C Code mittels
BC++B6 compiliert wird.
Ein workaround wäre dann kommischerweise, das man:
#ifdef __cplusplus
# include <iostream>
...
extern std::string StringToUpperCase(const std::string& input);
#endif
verwendet - also dieses #ifdef __cplusplus ...

Ist das in der Neuen Version auch so komisch ?
Ich habe hier ein Angebot bekommen, das sich über: 1.234 TEuro bewegt, und in guten
Fällen auch noch 20 Prozent Rabatt gegeben wird...

Da würde ich eher die Alte Version nehmen, die zwar bissl mekkert, aber stabil läuft.
Nungut, man hat dann 1 Jahr Wartung und andere Special's - aber mir macht das echt
Gedanken, zumal ein C++ Compiler erkennen müsste, ob es sich um # include <cheader>
oder um # include <c++header> handelt.

Das: extern "C" void ... iss klar, aber ohne __cplusplus Definition ... naja...
Der MinGW oder auch einfach GCC/G++ kann an Hand der Extension erkennen, welcher
Compiler verwendet werden soll.

Da gebe ich einfach:
g++ -o foo.o -c foo.c // oder:
g++ -o foo.o -c foo.cc

ein, und es werden beide kompiliert, weil ja C das Subset von C++ ist ...

Manchmal macht mir Prograschmmiererei echt Spaß ...

Gruß
paule32

[paule32.jk]

Hallo,

das Problem der Fehler wurde von mir behoben.
In den Projekt-Einstellungen vom BCB gibt es die Option: "Force C++ Compile".
Diese Option ist aber ein wenig klein (auf großen Bildchirn) versteckelt.

Wenn man diese Option nicht anchecked, dann hagelt es Fehlermeldungen.
Erst wenn diese Option angecheckt wurde, wird der Quellcode wie ein C++ Code
behandelt, um man kann die:
extern "C"
Möglichkeiten nutzen.

Okay.
Man sollte also nicht gleich die Flinte ins Korn werfen.

Das lustige hier ist nun, dass ich C Code mit C++ (Code) Funktionen mischen kann
aber die EXPORT'ed Symbole "de-mangelt" sind (also keine Postfix-Letter besitzen).

[Bernhard Geyer]

Die antiken C++-Builder waren eher auf kompatiblität mit Delphi/Pascal-Code ausgelegt und hatten viele Mängel richtung der diversen C/C++-Standards.
Hier lieber (wen man nicht die Delphi-Compatiblität brauch) einen anderen Compiler nutzen.