pipeline
-
'normale Schnittstelle': eine Funktion die expotiert wird (dllexport).
Kennst du dich mit Pipelines aus?FLO
-
Pipes erzeugst Du mit CreatePipe (CreateNamedPipe scheidet aus - keine Unterstützung unter 9x). Das 'Lese-Handle' gibst Du nun an die andere Dll. Jetzt kannst Du auf der einen Seite mit WriteFile in die Pipe schreiben unf auf der anderen Seite mit ReadFile lesen. Da es sich bei diesen Pipes um Kernel-Objekte handelt und für jeden Schreib/Lese-Vorgang ein Kontext-Wechsel nötig ist, sind Pipes langsamer als direkte Funktions-Aufruf und Wert-Übergabe über Pointer. Es gibt nichts schnelleres als einen direkten Funktionsaufruf.
-
Danke!
Werde aber vor Sonntag leider nicht mehr dazu kommen es auszuprobieren.FLO
-
-
Nein, hab ich nicht. Woran scheitert es denn, schon am Aufruf von CreatePipe?
-
CMatt ist der Pipe experte
-
@ King
Bin mir nicht sicher, ob ich den Parameter (LPSECURITY_ATTRIBUTES lpPipeAttributes) auf 0 setzen kann, bzw wo bekomme ich den Parameter her?
CMatt?
DANKE
FLO
-
Bin mir nicht sicher, ob ich den Parameter (LPSECURITY_ATTRIBUTES lpPipeAttributes) auf 0 setzen kann, bzw wo bekomme ich den Parameter her?
NULL darfst Du verwenden. Damit bekommst Du Standard-Sicherheit zugesprochen. Das ist das Gleiche wie bei allen Kernel-Objecten (File, Event, Mutex, ...).
-
ich versuche Daten von einer DLL in eine andere zu übergeben
Das wird doch im ganzen Windows-System ständig gemacht, user32.dll übergibt Daten an gdi32.dll, gdi32.dll an kernel32.dll u.s.w. ...
Ich hab da noch NIIEEE Pipes gesehn!
-
Hmm, solange man keine Zeiger übergibt braucht man auch keine solche Pipes. Bei Zeigern fängt es an. Man kann da auch Memory Mapping verwenden.
-
Bei Zeigern fängt es an.
Blödsinn. Da die Dlls alle im gleichen Adressraum liegen, fängt da gar nichts an. Man kann die Zeiger problemlos direkt übergeben. Ich habe auch weiter oben schon versucht zu sagen, daß solche Mechanismen nicht benötigt werden.
-
Huups. Tschuldigung. Ich kenne mich nur ein wenig aus bei der Kommunikation zwischen EXE und DLL. Dachte, das wäre bei DLL - DLL ebenso. Gibt es denn einen System-DLL-Prozess oder sowas, so dass die alle den selben Adressraum haben?
-
@RenéG
ich hab das ganze schon mit direktem Funktionsaufruf programmiert, das war kein Problem (auch für einen Anfänger wie mich ). Mein Problem ist viel mehr, dass die ursprüngliche DLL so groß ist, dass ich nun versuche sie übersichtlicher zu machen, indem ich sie in 2 DLLs aufspalte. Da ich aber immer structs (als Zeiger) als Übergabeparameter der Funktionen habe, müßte ich immer die ganze Header Datei in die neue DLL einbinden, und das wollte ich mit Pipes vermeiden.Danke für die Hilfe
FLO
-
Was ist denn da bitte das Problem? Das ist eine einzige zusätzliche Zeile, in der Du den Header inkludierst. Mit Pipes wird das wesentlich mehr Aufwand, und langsamer ist es auch noch.
@WebFritzi
Die Dlls werden in den gemeinsamen Adressraum des Prozesses geladen.
-
Und was, wenn sie nun in mehrere Prozesse geladen werden sollen (z.B. 2 sich untereinander austauschende Hooks)?
-
Mein Problem ist, das es ungefähr 30 Header Dateien sind, die auch wieder Includes haben...
Wenn ich das so mache, bekomme ich auch wieder ne grosse DLL.
FLO
-
Das mit dem CreatePipe hab ich hinbekommen, aber das mit dem ein und auslesen...
Hast du da ne Idee (ReadFile,WriteFile)?FLO
-
Mein Problem ist, das es ungefähr 30 Header Dateien sind, die auch wieder Includes haben...
Wenn ich das so mache, bekomme ich auch wieder ne grosse DLL.Seit wann machen Headerdateien ne Bibliothek gross?
-
Seit wann machen Headerdateien ne Bibliothek gross?
Im Sinne von unübersichtlich.
FLO
-
Aha, 30 Zeilen #include machen also eine DLL mit einigen 10tausend Zeilen Quellcode unübersichtlich
*michkaputtlach*