fremde DLLs statisch laden

wuschu

dan schau in die doku der libs
zlib kann man auf jeden fall statisch linken hab ich selber schon mal gemacht
libjepg kann man sicher auch statisch linken ohne das man was am source ändern muss
omnithread kenn ich nicht muste halt in die docu schaun

Dezipaitor

CMatt schrieb:

Hab grad nur VC++ 7 bei mier.. müsste aber bei VC++ 6 so ca. im selben eck zu finden sein. Rechtsklick auf das Projekt -> Einstellungen -> Allgemein -> Knofigurationstyp : LIB (nicht DLL)

ne da steht in keinem projekt sowas dran:
nur die art, wie die MFC gelinkt werden soll ist dort.

kann mir denn keiner helfen?

Mr. IfThen

Ich verwende auch zlib, und da geht das so:

Die Dateien

zlib.lib
zconf.h
zlib.h

über "Projekt->Dem Projekt hinzufügen->Dateien" hinzufügen.

Dann natürlich:
#include "zlib.h" wo man es braucht.

Wird bei den anderen nicht anders sein.

Dezipaitor

Mr. IfThen schrieb:

Ich verwende auch zlib, und da geht das so:

Die Dateien

zlib.lib
zconf.h
zlib.h

über "Projekt->Dem Projekt hinzufügen->Dateien" hinzufügen.

Dann natürlich:
#include "zlib.h" wo man es braucht.

Wird bei den anderen nicht anders sein.

und wie wird da nun zwischen dynamisch und statisch linken unterschieden?

Mr. IfThen

Wenn du die lib in deine exe einbindest, ist das natürlich statisch, so wie oben beschrieben.
Bedeutet, du brauchst nicht auf eine externe dll zuzugreifen.

PAD

:p Glaub ich nicht?

Wenn man dll´s erstellt wird zu jeder dll ein lib file erzeugt damit der Kompiler für das impliziete laden (d.h.laden beim Programmstart) die zugehörigen stub funktionen hat, die dann beim Programmstart durch die DLL-Funktionen ersetzt werden.

Nur durch die lib bin ich in der lage die Funktionsnnamen der eingebunden dll in meinem Programm zu nutzen.
Man sieht es auch daran das die meistrn libfiles circa nur 20 % der Größe der zugehörigen dll haben.

Wenn libraries explizit durch loadlibrary geladen werden brauche ich entweder den Namen oder die Funktionsnummer und kein lib file.

Mr. IfThen

@PAD

Die lib, die bei der Kompilierung einer dll ensteht, ist doch eine andere lib, als die lib, die bei der Kompilierung einer "normalen" lib entsteht, oder?

Ich hatte mich auch nur auf mein zlib-Beispiel bezogen, denn die zlib.lib ist ein waschechtes Bibliotheksmodul(LIB). Also nicht die Pseudo-lib zur dll.

PAD

Das war der Grund warum ich meinen Text geschreiben hab, weil dritte es mißverstehen könnten.

*.lib files zur staischen Bindung enthalten den Code der ausgeführt werden soll.

*.lib file für dir implizite Bindeung von dll´s in Projekten enthalten "nur" die stub-funkktionen die beim dynamischen Laden durch die funktionen der dll ersetzt werden.

Leider haben beide dieselbe Extension.

Dezipaitor

ich glaube ich habe mich da falsch ausgedrückt!

ich meinte mit statisch binden, nicht die art wie die funktionen einer dll mit einer EXPORT-Definition eingebunden werden,
!sondern, dass die DLL in die EXE-Datei eingebunden wird.!

Delphi macht das ja vor : DLL dateien werden by default, direkt in die EXE mit reingelinkt.
das will ich auch mit den C++ projekten machen.

ich habe alles :
quellcode aller bibilotheken!
die davon erstellen LIB-Dateien.
noch was?

ich weiß, dass man zwei verschiedene Arten von Bibilotheken als neues Projekt erstellen kann :
statische Bibilotheken und dynamische Bibilotheken.

die statischen erzeugen garkeine DLL-Datei, die dynamischen schon.

allerdings wurde zlib und omnithread so erstellt, dass die eine DLL-Datei erzeugen.
muss ich nun denen ein neues projekt als statische Bibilothek erstellen und das anstelle der alten projekte einbinden?
- das ist meiner Meinung nach etwas umständlich
oder kann ich einen Schalter setzen, der dem Linker sagt, er solle den code in die EXE-Datei reinsetzen?

PAD

Jetzt mal ganz langsam.

Was willst du tun:

Möchtest du von einem Projekt aus eine DLL benutzen, d.h du compilierst deinen Code und hast damit eine exe Datei. Wenn du die
Exe datei startest soll beim Start das dll mit in den Speicher geladen und benutzt werden

ODER

Möchstest du dein Projekt so aufbauen, das in deiner Exe Datei der Code der in normalerweise in der DLL wäre in deinem exe File mit dabei ist. Falls ja warum (wenn du 6 Programme schreibst in jedem 4 MB Libraries einbindest verschwendest du 20 MB auf der Platte und 20 MB RAM im Speicher wenn du alle Programme lädst)

Das Beste wäre du beschreibst mal dein Problem, vielleicht können wir dann besser helfen.

Dezipaitor

zweiter Fall ist richtig.

Zweck:
ich will das VNC (www.tigtvnc.com) Viewer- und Serverprogramm in ein Programm bauen.
d.h.
viewer und server verwenden beide dieselben DLL dateien (zlib.dll, omnithread.dll), welche nur auf den wenigsten system vorinstalliert sind (und dann gewiss nicht im windows verzeichnis).

der viewer steckt nun auch in einer DLL datei drin : vncviewer.dll,
und wird von der winvnc.exe geladen. (statisch gebunden)

wenn jetzt all diese (nur diese!) dll-dateien an die exe angehängt werden könnten , müsste man nur noch !eine! Datei zum Download anbieten (Installation
darf es sowieso nicht geben).
- Achtung : Windows-DLLs dürfen da natürlich nicht rein.
All die Dateien da oben, geben zusammen ca 1mb - und mit upx komprimiert sogar die Hälfte.

Vielleicht gibt es ja ein Programm, dass so eine Single-Anwendung aus der Exe und den angegebenen Dateien erzeugen kann.
z.b. kann Winzip das? d.h. alles in eine Self-Extracting Zip packen und beim Start automatisch die Exe-Datei (mit mögl. Kommandozeilenparamtern) starten lassen?

das muss doch gehen oder?

Delphi Anwendungen sind doch auch Stand-Alone (bis auf winAPI).

PAD

Abgesehen davon das dein Wunsch nicht mehr "up to date" ist.

etwas in ein selbstextrahiernds zip Archiv packen und anschliesend entpacken
zu lassen ist doch aeine art Installation oder.

Ich würde empfehlen die dll zusammen mit dem Programm in ein zip-File zu packen
es vom Kunden auspacken zu lassen und dann soll er auf das prog doppelklicken.
das sich exe und dll im selben Verzeichnis befinden sollte es laufen.

woher weist du das?

der viewer steckt nun auch in einer DLL datei drin : vncviewer.dll,
und wird von der winvnc.exe geladen. (statisch gebunden)