.lib und .dll?

[Gast]

Moin zusammen!

Diese Frage ist mir fast etwas peinlich aber ich kenne mich nunmal nur etwas mit C/C++-Programmierung auf Konsolenebene aber nicht dem ganzen Drumherum (Linken, Bibliotheken und wiederverwendbare Teile erstellen usw.) aus.

Nun zur Frage:

Ich habe mit Visual Studio (2008) ein kleines Framework geschrieben, dass ich nun gerne mit einer GUI verwenden würde, die ich nebenher entwickelt habe. Ich hatte mir das so vorgestellt, dass das kompilierte Framework in Form einer DLL ausgespuckt wird, was sich ja in Visual Studio leicht bewerkstelligen lässt. Diese DLL wird dann in Windows registriert und nach Einbinden der zugehörigen Header im GUI-Projekt sollte ich ja auf die Funktionen der DLL zugreifen können.
Beim Kompilieren des Frameworks wird immer noch ne .lib-Datei erstellt. Wozu is die genau da ? Ich hab jetzt bisher nur was von statischer Bibliothek gelesen, in der die Funktionsprototypen stehen.

Und noch was: Was haltet ihr eigentlich von Microsoft's COM ? COM hat ja auch irgendwas Interfaces zu tun, die dann irgendwie durch ne DLL genutzt werden können.
Ihr seht schon, ich blick da null durch und hab da etwas Erklärungsbedarf :D

Danke!

[Ectoplasma]

Eine DLL wird nicht perse in Windows "registriert". Wozu auch? Eine Registrierung findet nur dann statt, wenn in dieser irgendwelche OCX/COM etc. was auch immer, Objekte vorhanden sind. Dein Framework ist wohl aber eine ganz normale Sammlung von C++ Objekten. Da brauchst du erstmal nichts zu registrieren.

Die .lib Datei gibt es auch bei einer DLL. In dieser stehen Informationen, wie der Linker Methoden und Attribute in der DLL findet. Sie enthält aber keinen Code und ist daher auch wesentlich kleiner als eine Lib, mit der Code statisch gebunden wird.

[Gast]

Ok, danke schonmal!

Versteh ich das richtig:

Bei COM müsste ich Klassen bzw. Interfaces erstellen, in denen dann die Funktionen (Memberfunktionen?) meine Frameworks drin stehen ? Der Vorteil wäre dann, dass ich das Ganze sprachunabhängig in anderen Programmen wieder benutzen könnte ?

[Gast]

Kann mir hier keiner mit ein paar Worten erklären, wie man den "COM-Mantel" um ein Stück Software hüllt ? :)
Mich würde auch nur die grobe Umschreibung interessieren, also was da ungefähr zu tun ist und was da passiert...nix detailliertes.

[Monger]

Da du ja offenbar Visual Studio nutzst, sollte es das schon von Haus können. Schau mal irgendwo im "Build" Menü nach, da sollte es etwas zur Erzeugun von COM Komponenten geben...

COM wurde entwickelt, um die Kommunikation zwischen unterschiedlichen Applikationen auf dem selben Rechner zu ermöglichen. Denn woher soll Applikation A denn wissen, dass Applikation B auch installiert ist? Deshalb werden COM Applikationen in der Registry registriert.
Wenn du in Visual Studio Referenzen hinzufügst, hast du auch eine Lasche wo die ganzen registrierten COM Applikationen stehen. Das sind verdammt viele. Du kannst ja mal spaßeshalber irgendwas als Referenz reinziehen (z.B. Excel, oder den Windows Media Player ), und dir im Objektbrowser die Klassen in dieser Assembly genauer ansehen.

COM ist auch sprachübergreifend. Es gibt verschiedene COM Builder für verschiedene Sprachen. Es ist allerdings auch eine reine Windows Technologie. Und: es ist Old-school! ;) .NET Assemblies sind der geistige Nachfolger von COM.

[Gast]

COM wird deshalb verwendet, dass Programmierer auf eine installierte Software zugreifen können, die in einer anderen Programmiersprache geschrieben wurde. Die Registrierung dient dazu, um fest zu legen, wo die Software gesucht werden soll.
Das Ganze hat jedoch auch massive Nachteile:
a) Es werden zur Registrierung Administratorrechte benötigt
b) Du wirst um einen Installer nicht herum kommen
c) Es ist nicht möglich mehrere Instanzen der Bibliothek zu installieren (z.B. verschiedene Versionen oder mit verschiedener Config in verschiedenen Ordnern)
d) Das Übergeben von Objekten ist immer mit viel Bauchweh verbunden. Am Besten man übergibt alles als Byte Array, sonst kann man sich nicht sicher sein, ob alles auf der anderen Seite richtig ankommt, wenn irgendeine Sprache mit ganz anderen Datentypen versucht die Daten zu interpretieren. Mit Unicode Kompatibilität sieht es in den meisten Fällen eher düster aus.
e) Debuggen kann man das Ganze auch nicht vernünftig.

Wenn du C++ einsetzt, so würde ich dir empfehlen, dass du gar keine .dll machst, sondern nur die Header einbindest und eine .exe erzeugst. Dann kannst du schön debuggen. dlls werden hier nur eingesetzt, wenn man einem anderen C++ Entwickler die Funktionalität zur Verfügung stellen will, ohne dass man den Source veröffentlichen will.

Bei .NET Sprachen sind die .dlls komfortabler. Man braucht nur die Source Files auf dem Rechner haben und schon kann man die .dlls debuggen, als wäre alles in Einem kompiliert.
Nur Änderungen kann man nicht direkt übernehmen. Da muss man das Projekt der .dll nebenbei offen haben, was aber auch nicht so wirklich stört.
Bei der Auslieferung schmeißt du alles zusammen in einen Ordner und schon kann es los gehen.