Alte C-DLL mit neuer Funktion in C++ ergänzen



  • Hallo zusammen,

    ich habe wieder ein Problem mit meinen alten Quellen.

    Momentan in Visual C++ 2005 bearbeitet!

    In einem Programm liegt eine DLL vor.
    Sie wurde in C geschrieben und enthält auch includes auf <Windows.h>.
    Der Compiler-Switch steht zwar auf "/TP" (als C++ compilieren), aber alleine
    das Einbinden eines Headers eines C++-Files oder das Umbenennen in "*.cpp"
    bringt schon die Fehlermeldung, dass "Windows.h" nicht eingebunden werden darf.
    Aber ohne "Windows.h" funktionieren die alten "PASCAL" oder "FAHR PASCAL"
    und etliche Datentypen nicht mehr. Auch die DLL-Schnittstelle müsste wohl
    umgeschrieben werden.

    Gibt es überhaupt eine Möglichkeit, hier etwas aus beiden Welten zu kombinieren?

    Grüsse H.



  • C und C++ in einer DLL mischen ist überhaupt kein Problem. Auch nicht mit Visual Studio 2005. Windows.h einbinden ist in C++ files auch kein Thema -- funktioniert einfach.
    => Keine Ahnung was das jetzt das Problem ist, bei mir funktioniert das alles Problemlos.


  • Mod

    Bei welchen C++ includes bekommst Du den Fehler das Windows.h nicht included werden darf?

    Wenn Du natürlich afxwin.h einbaust dann stimmt das. Die MFC funktioniert aber auch hier anders als eine Plain-Standard-DLL.

    Und ja entweder gilz afx.h/afxwin.h includen oder Windows.h. Aber das ist kein Problem, weil die afx.h die Windows.h included.



  • Bei allen ".c" Files ist das include auf windows.h drin.

    Das würde dann bedeuten, die includes austauschen gegen afxwin.h
    und dann noch die ".c" Files in ".cpp" umbenennen (sonst kommt der
    nächste Fehler, der das verlangt).

    Aber wie Du angedeutet hast, muss ich wohl die DLL-Schnittstelle dann
    auch anders beschreiben, oder?


  • Mod

    MFC != C++

    Wenn Du nur C++ Features benutzen willst ist das was anderes. Dazu brauchst die die MFC nicht.



  • Danke Martin,

    Eine kleine Frage hätte ich noch:
    Um die C++ Features zu nutzen, müsste ich dann nur die Endung ".cpp"
    und den entsprechenden Preprozessor-Switch angeben und die windows.h
    weiterhin includieren?
    Und bei den neuen Dateien nur die afxwin.h durch die windows.h ersetzen?
    Natürlich müssen MFC-Aufrufe raus! Nur hier kann mein Kopf leider nicht
    genau sagen, was zur MFC gehört.


  • Mod

    Vergiss die afxwin.h oder afx.h wenn Du die MFC nicht benutzen willst.

    In einem normalen Projket musst Du nichts umstellen, sondern einfach nur einen cpp Datei ins Projekt aufnehemn.



  • @elmut19
    was ist eigentlich genau dein Problem ?
    die dll liegt doch als c-dll vor, also binärcompatibles Interface ?

    Was willst du jetzt machen ?

    A: die dll anpassen/neu bauen/erweitern ?

    B: oder die dll verwenden/benutzen ?

    Ich vermute eher A (deswegen das gerödel mit den .c dateien).
    Du hasst beim project umwandeln, aufziehen schon nen Problem ...
    die MFC hat da drinne nix zu suchen.

    und ich wuerde das ding weiterhin als C-Dll lassen, sonst müsstest du zu viel anpassen ...
    wenn du die nach .cpp umbenennst, und dein Project als c++ Projekt compilierst, muesstest du üeberall extern c reinschreiben, sonst passt das Symbol matching nimmer ....
    Der vc compiler kann aber auch c code anstandslos uebersetzen, warum dann nach c++ ändern ???

    Generell würd ich bei c bleiben, hasst dich ja damals nicht umsonst für c entschieden (binärkompatiblitaet).

    Warum unbedingt die dll erweitern ?
    Warum dann unbedingt mit C++ ?

    wenn doch würde ich eine neue c++ basierte dll mit c-binärinterface bauen.
    DIe gleichen funktionen mit sysntax aus der alten dll nehmen (die .def uebernehmen).
    in der neuen die alte dll anziehen, und alle exportierten funktionen durchreichen.
    Neue funktionen einfach in der neuen dll hinzubauen.

    Alternativ kannst auch die .c dateien einfach übernehmen ... nen cpp compiler sollte das erkennen und die dateien in c style compilieren, und die symbole korrekt im cpp teil uebernehmen.
    Also c/cpp mixen ist schon möglich, wenn man den compiler nicht zusehr mit irgendwelchen unsinnigen Abhängigkeiten verwirrt 😃

    Ciao ...



  • Hallo RHBaum,

    vielen Dank für die Zusammenfassung.
    Du sagst genau das, wofür ich mich entschieden habe.
    Das bestärkt mich darin, dass ich nun doch auf dem richtigen weg bin.

    Und naja... Ich habe diese Softwarequellen von meinem Vorgänger geerbt!
    Wie meist, ist da keine Doku dabei und der Code für mich auch nicht selbsterklärend.
    Es handelt sich um zwei Softwarepakete, die annähernd das Gleiche machen, die
    Controlerkarte einer Maschine steuern (SCADA-System). Eine alte Software und
    eine neue.
    Beide müssen aber noch gepflegt werden.

    Nun soll die alte Software um eine Funktion der neueren Variante ergänzt werden.
    In der alten sind diese Funktions-Teile eben in einer DLL drin. Da war eben
    meine Hoffnung, dass ich weite Teile der Logik weitgehend unverändert übernehmen kann.

    Aber hier greift auch schon Deine Anmerkung:
    In den Klassen der neuen Software sind auch die Datenstrukturen gekapselt.
    Ich bräuchte hier eine recht aufwendige Fassade, die die Daten mappt.
    Das hat sich auch als fast unmöglich herausgestellt.

    Also habe ich mich nun für Deinen Vorschlag entschieden, zusätzlich aus den
    Gründen, die Du nanntest.

    Grüsse und schönes Wochenende


Anmelden zum Antworten