h, lib und dll



  • Hallo!

    Kann mir bitte jemand den Zusammenhang zwischen den Dateitypen *.h, *.lib und *.dll erklären?

    Mir fehlt da irgendwie der Durchblick. Was ist so gespeichert? Was ist am Ende dann in der EXE und was muss separat am Zielrechner installiert werden?

    Danke im Voraus!

    mfg



  • xxx.h (manchmal auch xxx.hpp) sind sogenannte Header (daher das h), die Deklarationen/Klassendefinitionen enthalten. Für die WinAPI-Programmierung gibt es z.B. den wichtigen header windows.h, für MFC afx.h und für die C++-I/O-Streams cout/cin/cerr/clog z.B. <iostream>. Diese Header werden in Implementierungen (xxx.c / xxx.cpp) eingebunden.

    lib sind statische Bibliotheken und dll dynamische.

    dll: http://www.henkessoft.de/api6.htm
    http://www.mut.de/media/buecher/VCPLUS6/data/kap17.htm

    lib: http://www.mut.de/media/buecher/VCPLUS6/data/kap16.htm



  • *.h

    das sind Headerdateien (gibt auch andere Endungen dafür, zB .hxx .hh .hpp etc). Dort stehen die deklarationen der Klassen, Funktionen etc.

    *.lib

    das sind statische Librarys, sie enthalten die definitionen der Klassen, Funktionen etc. schon in kompilierter Form. Wenn du die Datei nun in deinem Projekt benutzen willst, dann linkt der Linker die Datei einfach zu deinem Projekt.

    *.dll

    sind dynamisch ladbare librarys, wenn du diese Librarys in deinem Projekt verwendest, dann werden diese nicht gelinkt, sondern der Linker fügt nur Informationen in deine ausführbare Datei ein und die Datei wird erst zur Laufzeit geladen. Der Vorteil gegenüber des statischen Linkens ist der, dass man Speicher spart, wenn die Library von mehreren Programmen benutzt wird, weil sie nur einmal geladen wird und das man die Datei einfach ersetzen kann ohne, dass das ganze Projekt neukompiliert werden muss. Der Nachteil ist, dass man die Datei auf dem Rechner brauch.

    Unter Windows sind DLLs sehr verpönt, weil Microsoft es 1. verfehlt hat dafür zu sorgen, dass DLLs vernünftig gespeichert werden und 2. viele Programme DLLs nicht vernünftig deinstallieren und 3. die Implementierung von DLLs in Windows wohl sehr schlecht ist und DLLs wohl trotzdem für jedes Programm einzelnd gestartet werden

    btw. solltest du aufhören in Dateiendungen zu sprechen, weil Dateinamen sind Schall und Rauch. Sag anstelle

    EXE - executable oder programm oder ausführbare Datei
    *.h - Header
    *.lib - statische Library
    *.dll - dynamische Library



  • @kingruedi Deine Wertung von dll´d kann ich nicht nachvollziehen. Sie sind unter Windows nicht verpönt sondern eher lebenswichtig´, 80% des Windows bestehen aus dll´s

    Das Microsoft gewählte Speicherverfahren ist mit sicherheit nicht dass beste, aber es funktioniert.
    Das Deinstallieren von dll´s ist sehr problematisch, das ist aber auch systembedingt.
    Vielleicht hast du ein paar gute Ideen, so daß man es bei eigenen Projekten besser machen kann.

    Was definitiv fehlt ist eine Versionsverwaltung der dll´s.

    Die Implementierung schlecht ? (das verstehe ich nicht, erklär das bitte mal etwas ausführlicher).

    und DLLs wohl trotzdem für jedes Programm einzelnd gestartet werden

    Windows überprüft ob eine dll bereits geladen ist, falls ja nutzt sie diese und reserviert für sie Datenspeicherplatz im Process des Programmes. Dll´s müssen ja wohl für jeden Processkontext Datenmaäßg neu initialisiert werden, sondt kämen sich die Porgramme ja wohl in die Quere. Für Processunabhängige Daten der dll´s gibts global (shared) memory.

    ➡ Nun noch zu den Fragen von C-Anfänger

    Was ist am Ende dann in der EXE und was muss separat am Zielrechner installiert werden?

    Auf dem Zielrechner muss von dn von dir genanten Dateitypen nur das Exe-File und die dll´s auf das Zielsystem gespeichert werden, (bezüglich der Daten und Konfigurationsfiles must du es selber wissen)

    Wofor man sich hüten sollte, ist es dll´s irgedwo im Verzichnis \Windows\sys... abzulegen, denn dann hat kingruedi mit seiner kritik (bezüglich deinstallation) recht. Die Suchreihenfolge für dll´s ist definiert.
    Das Verzeichnis in dem das Image (die EXE-Datei) steht, dann das current directory, danach der Suchpfad.
    d.h. Für die meisten dll´s bietet es sich an die dll´s an der selben Stelle zu speichern dan der sich das Image befindet.

    Hat man viele eigene Programm und nutzt in diesen diegleichen dll´s so sollte man diese in einem eigenen Verzeichnis speichern und den Namen des Verzeichnisses vorne an de Pfad anhängen. Das hat auch den Vorteil, das ein Programm welches eine neuere oder ältere inkompatible Version der DLL braucht (schlechter Stil) diese lokal bei dem Program speichern kann und dies Programm diese spezielle Version nutzt.

    Ich hab irgendwo etwas über eine Versionsfunktion für DLL´s gelesen. Wenn das stimmen sollte , sollte das Hauptprogramm die Version auslesen und mit der Version die es benötigt vergleichen und falls die Version nicht übereinstimmt sich sicher beenden.

    Allerdings haben die meisten Diskussionspunkte nicht speziell etwas mit C++ oder C zu tun. Es wäre tolle wenn ein Moderator die passende Stelle finden und den thread dorthin verschieben sollte.

    😃



  • PAD schrieb:

    @kingruedi Deine Wertung von dll´d kann ich nicht nachvollziehen. Sie sind unter Windows nicht verpönt sondern eher lebenswichtig´, 80% des Windows bestehen aus dll´s

    Das Microsoft gewählte Speicherverfahren ist mit sicherheit nicht dass beste, aber es funktioniert.
    Das Deinstallieren von dll´s ist sehr problematisch, das ist aber auch systembedingt.
    Vielleicht hast du ein paar gute Ideen, so daß man es bei eigenen Projekten besser machen kann.

    Windows ist so ein leidiges Thema, dass entwickelt sich leicht zum Flamewar (spätestens wenn wieder die ersten Leute kommen "Windows läuft bei mir schon 3Tag und 5Minuten ohne abzustürzen und die meisten die Windows scheiße finden, nutzen das selber" 🙄 ). Eine bessere Lösung ist der Weg, den Unix und Unix Derivate beschreiben, irgend wie klappt das da zumindest vernünftiger.

    Die Implementierung schlecht ? (das verstehe ich nicht, erklär das bitte mal etwas ausführlicher).

    Das hab ich irgend wo gelesen, ich such den Link mal raus. Aber das wird hier alles irgendwie zu OT 🙂

    [edit]so, hab den Link gefunden, das hatte ich wohl falsch verstanden, bei Windows funktioniert Code Sharing bei den DLLs wohl korrekt, nur bei Applikationen macht Windows das nicht[/edit]



  • kann es sein das dieser kingruedi ein echter troll ist??

    ➡ gruß ft



  • @ft Eine Antwort darauf lohnt sich nicht

    @kingruedi Mit dem Flame hast du leider recht. Allerdings muß ich einer NT-Umgebung SW entwickeln, die mit dll´s parallel laufenden Prozessen uns ähnlichem arbeitet. Deswegen interessieren mich solche Aussagen. Wenn da irgendwo Porbleme existieren und man frühzeitig davon erfährt kann man sie meistens umschiffen.

    Ich habe oben "muß entwicklen" gechrieben, dazu muss ich ergänzen das ich an der Auswahl vor 2 1/2 Jahren stark beteiligt war. Da zu diesem Zeitpunkt es noch keine kommerziellen Linux/Unix Treiber für die MeßHardware gab und auch heute teilweise nicht gibt (selberschreiben leider zu teuer) war Linux leider keine Option. Deshalb hatte ich damals für NT gestimmt und würde es heute leider (immer) noch tun.

    Den thread nach OT verschieben, würde mich nicht stören.



  • Wofor man sich hüten sollte, ist es dll´s irgedwo im Verzichnis \Windows\sys... abzulegen, denn dann hat kingruedi mit seiner kritik (bezüglich deinstallation) recht. Die Suchreihenfolge für dll´s ist definiert.
    Das Verzeichnis in dem das Image (die EXE-Datei) steht, dann das current directory, danach der Suchpfad.
    d.h. Für die meisten dll´s bietet es sich an die dll´s an der selben Stelle zu speichern dan der sich das Image befindet.

    Die Aussage bzgl. der Suchreihenfolge ist nicht ganz korrekt, manche DLLs werden zuerst im Systemverzeichnis gesucht (Stichwort google, known dlls, microsoft, dll hell).



  • @thomm Danke für deine Info


Anmelden zum Antworten