DLLs Vorteil/Nachtei/Tutorial?
-
darthdespotism schrieb:
Dynamische Biblioteken wie die Dlls haben den Vorteil, dass sie eben dynamisch geladen werde. => man kann sieselbst während das Programm läuft austauschen,...
Wenn eine DLL benutz wird, kann ich sie nicht mal löschen. Wie dann austauschen, wenn das Programm läuft?
-
Auch eine "Bibliothek" in Linux kann man Linken und sie wird beim Programmstart geladen. Genauso wie eine DLL.
Genauso kann man eine DLL dynamisch laden genauso wie eine *.so.
Ich kenne sehr wohl beide.
DLL`s unter Windows werden geshared wenn man die gleiche DLL im selben Ordner aufruft.
-
Unix-Tom schrieb:
Auch eine "Bibliothek" in Linux kann man Linken und sie wird beim Programmstart geladen. Genauso wie eine DLL.
Genauso kann man eine DLL dynamisch laden genauso wie eine *.so.Das ist ja wohl bekannt.
Unix-Tom schrieb:
Ich kenne sehr wohl beide.
Aber offensichtlich nicht gut genug.
Unix-Tom schrieb:
DLL`s unter Windows werden geshared wenn man die gleiche DLL im selben Ordner aufruft.
Darum gehts doch nicht. Es geht doch vor allem darum, dass man nicht Pointerownership zwischen DLLs transferieren kann. Und die Sache mit den Threads / anderen DLLs.
Diese Einschränkungen haben mich so angekotzt, dass ich nichtmal versucht habe, mein Plugin-System auf Windows zu portieren.
-
wie du meinst!
Wenn du das nicht kannst dann verwendest du eben keine Windows-DLL.
-
-
Mr. N schrieb:
Diese Einschränkungen haben mich so angekotzt, dass ich nichtmal versucht habe, mein Plugin-System auf Windows zu portieren.
Könnte auch daran liegen, dass dein "Plugin-System" ein grottenschlechtes Design hat. DLLs können dafür nichts. Adobe hat keine Probleme mit Plugin-Systemen und DLLs
-
Kenner der Scene schrieb:
Mr. N schrieb:
Diese Einschränkungen haben mich so angekotzt, dass ich nichtmal versucht habe, mein Plugin-System auf Windows zu portieren.
Könnte auch daran liegen, dass dein "Plugin-System" ein grottenschlechtes Design hat.
Blödsinn.
Kenner der Scene schrieb:
DLLs können dafür nichts.
Doch.
Kenner der Scene schrieb:
Adobe hat keine Probleme mit Plugin-Systemen und DLLs
Die verwenden mit Sicherheit kein volles C++ dafür.
Bei einem Unreg mach ich mir mal nicht die Mühe, alles zu belegen.
-
Mr. N schrieb:
Die verwenden mit Sicherheit kein volles C++ dafür.
Hier gehts doch um DLLs und nicht um C++. DLL Einschränkungen gelten doch auch für andere Sprachen...
-
Pointer Ownership ist kein Problem solange alle DLLs die selbe Heap Implementierung verwenden, die dann entweder selbst in einer DLL steht oder andere Mittel & Wege verwendet eben das zu ermöglichen.
(Die einfachste variante unter Windows ist den Process Heap zu verwenden, dann ist vollkommen egal wo new/delete/malloc/free implementiert sind und ob mehrere Kopien davon verwendet werden)Die Sache mit den globalen Konstruktoren ist etwas blöd, da muss ich Mr. N. Recht geben. Lässt sich aber normalerweise drum rum arbeiten.
-
hustbaer schrieb:
(Die einfachste variante unter Windows ist den Process Heap zu verwenden, dann ist vollkommen egal wo new/delete/malloc/free implementiert sind und ob mehrere Kopien davon verwendet werden)
Wie geht das? Warum sagt mir das keiner?
-
z.B. so:
HANDLE processHeap = GetProcessHeap(); // immer der selbe für einen Prozess, egal in welcher DLL size_t size = 1234; void* p = HeapAlloc(processHeap, 0, size); // 0: flags - siehe MSDN // ... BOOL rc = HeapFree(processHeap, 0, p); assert(rc);Die MSVC Runtimes können z.B. auch mit dem Process Heap arbeiten (dann kann man das eingebaute malloc/free/new/delete verwenden), bloss weiss ich im Moment nicht wie man die dazu überreden kann, bzw. ob das nicht sogar default ist bei MSVC 7.1 und 8. Müsste man mal gucken ob das dokumentiert ist bzw. einfach ausprobieren.
p.S.: natürlich müssen alle new/delete/malloc/free Implementierungen *gleich* sein (nur dass der Code mehrfach dupliziert sein darf, da man den Process Heap als golbales Singleton verwendet), ich hoffe das war klar. DLLs die einfach irgendeine new/delete Implementierung verwenden (z.B. die vom VC6) kann man damit natürlich nicht "erschlagen".
-
hustbaer schrieb:
z.B. so:
HANDLE processHeap = GetProcessHeap(); // immer der selbe für einen Prozess, egal in welcher DLL size_t size = 1234; void* p = HeapAlloc(processHeap, 0, size); // 0: flags - siehe MSDN // ... BOOL rc = HeapFree(processHeap, 0, p); assert(rc);OK.
hustbaer schrieb:
Die MSVC Runtimes können z.B. auch mit dem Process Heap arbeiten (dann kann man das eingebaute malloc/free/new/delete verwenden), bloss weiss ich im Moment nicht wie man die dazu überreden kann, bzw. ob das nicht sogar default ist bei MSVC 7.1 und 8. Müsste man mal gucken ob das dokumentiert ist bzw. einfach ausprobieren.
Es wäre absolute Bedingung. Viele Bibliotheken verwenden unüberschreibbar malloc/free bzw. new/delete.
-
Mr. N schrieb:
Kenner der Scene schrieb:
Mr. N schrieb:
Diese Einschränkungen haben mich so angekotzt, dass ich nichtmal versucht habe, mein Plugin-System auf Windows zu portieren.
Könnte auch daran liegen, dass dein "Plugin-System" ein grottenschlechtes Design hat.
Blödsinn.
Hochmut kommt kurz vor dem Fall. Wenn du noch nicht mal weißt wie man den Prozess-Heap anzapft und welche Auswirkungen das auf DLLs hat, solltest du nicht mit "Blödsinn" angeheult kommen, sondern dir ernsthafte Gedanken machen.
-
Mr. N schrieb:
hustbaer schrieb:
Die MSVC Runtimes können z.B. auch mit dem Process Heap arbeiten (dann kann man das eingebaute malloc/free/new/delete verwenden), bloss weiss ich im Moment nicht wie man die dazu überreden kann, bzw. ob das nicht sogar default ist bei MSVC 7.1 und 8. Müsste man mal gucken ob das dokumentiert ist bzw. einfach ausprobieren.
Es wäre absolute Bedingung. Viele Bibliotheken verwenden unüberschreibbar malloc/free bzw. new/delete.
Solange man diese Bibliotheken mit der DLL Runtime vom MSVC compiliert sollte das doch egal sein, oder?
Ich meine zig verschiedene DLLs die aber alle mit der selben DLL Runtime compiliert wurden kann man was new/malloc angeht *immer* mischen, egal wie das implementiert ist, da durch die Verwendung der DLL Runtime ja trotzdem immer der selbe Heap verwendet wird...
-
In NadrW sind Unregs ja schon verboten, wie wärs damit, sie auch hier zu verbieten?
-
hustbaer schrieb:
Solange man diese Bibliotheken mit der DLL Runtime vom MSVC compiliert sollte das doch egal sein, oder?
Ich meine zig verschiedene DLLs die aber alle mit der selben DLL Runtime compiliert wurden kann man was new/malloc angeht *immer* mischen, egal wie das implementiert ist, da durch die Verwendung der DLL Runtime ja trotzdem immer der selbe Heap verwendet wird...Nun ja, ich habe darauf vertraut, dass derjenige, der von diesen Problemen erzählt hat, die Wahrheit spricht, dass eine MSVC-Runtime-DLL das Problem löst, wusste ich nicht.
Vielleicht habe ich ja nur einen Vorwand gesucht, nicht unter Windows programmieren zu müssen.
-
Mr. N schrieb:
In NadrW sind Unregs ja schon verboten, wie wärs damit, sie auch hier zu verbieten?
Und wieso sollte man das. Du hast z.b. auch mich angegriffen das ich mich nicht auskenne. Man kann nicht austeilen und sich dann aufregen das man auch einsteckten muss.
-
Mr. N schrieb:
Vielleicht habe ich ja nur einen Vorwand gesucht, nicht unter Windows programmieren zu müssen.
Wäre schon möglich, du musst das natürlich am besten wissen
-
Unix-Tom schrieb:
Mr. N schrieb:
In NadrW sind Unregs ja schon verboten, wie wärs damit, sie auch hier zu verbieten?
Und wieso sollte man das. Du hast z.b. auch mich angegriffen das ich mich nicht auskenne. Man kann nicht austeilen und sich dann aufregen das man auch einsteckten muss.
Weil du behauptet hast, dass DLLs und Shared Libraries das selbe wären. Ich sah das (EDIT: meine Reaktion) eigentlich eher als Abwehrreaktion, weil du ohne echten Grund (außer deiner impliziten Vermutung, dass ich glaubte, das sei etwas grundlegend Unterschiedliches) behauptet hast, meine Unterscheidung sei falsch. (Wie sich herausgestellt hat, ist einer der beiden Punkte zwar umgehbar, aber die Unterschiede bleiben bestehen.)
Von einem Unreg hingegen, der nichts auch nur ansatzweise begründet, will ich mich nicht beleidigen lassen. Wäre dieser registriert gewesen, hätte ich anders reagiert.
-
OK, da scheine ich wohl auch noch was lernen zu müssen (bin aber nur Windows-User): was ist denn die Definition von Sharedlibs, so das sie sich von DLLs unterscheidet?
