Kommunikation Skripte untereinander

Die DLL an sich wird imho total einfach, es wird nur ein Speicherbereich von 1MB reserviert.
Der Aufruf der Funktion gibt einfach nur einen Pointer auf eben diesen Speicherbereich zurück.
In diesen Speicher kann nun jedes Programm beliebig Daten einschreiben bzw. auslesen. So die Theorie^^
Naja, vielleicht mache ich sogar 2 Funktionen, eine zum Schreiben, die andere zum Lesen. Usability ftw! Ich setz mich mal dran....

//EDIT
naja, fast hätte ich es mir gedacht, klappt so nicht.
Man kann nicht von "außerhalb" auf innerhalb der DLL reservierten Speicher zugreifen.
Hab eine dll erstellt

welche auch einwandfrei funktioniert, sie gibt den Pointer auf die Variable _mem zurück.
Allerdings kann man per dllstructcreate(byte[1000],$pointer) nicht auf diesen Speicher zugreifen.

Umgekehrt funktionierts aber, man könnte der DLL einen Wert übergeben welcher im Speicher der DLL abgelegt wird, die Frage ist, ob von einem 2. Script dieser Speicher gelesen werden kann!

DLL dazu

; DLL creation example
;
;1) Funktion erstellen in der section .text
; proc Funktionsname
;     AssemblerCode....wie er in AutoIt lauffähig ist... hierhinkopieren
; endp
;
;2) In die section .edata den Funktionsnamen eintragen:
;export 'DLLNAME.DLL',\            ;Name der DLL-Datei
;Funktionsname1,'Funktionsname1',\   ;Funktionsnamen
;Funktionsname2,'Funktionsname2'
;
;3) *.asm-datei mit wfasm.exe oder fasm.exe compilieren (in FASMW.EXE laden und CTRL+F9 drücken)
;
;Aufruf aus AutoIt mit
;$ret=dllcall("dllname.dll","RückgabeTYP","Funktionsname","TYP",$parameter1)


format PE GUI 4.0 DLL
entry DllEntryPoint


include 'win32ax.inc'       ;includes




;************Hier die in der DLL verwendeten Funktionen für den Export eintragen
section '.edata' export data readable
         export 'GETPOINTER.DLL',\         ;Dateiname, Zeilentrenner ist ,\
         VarIn,'VarIn',\          ;Funktion
         VarOut,'VarOut'        ;Funktion




;weitere Sektionen je nach Anforderung der Funktionen
section '.data' data readable writable


_mem dd 10000 dup 0    ;10 Kb Speicher




;section für die Funktionen
section '.code' code readable executable


;DllEntryPoint wird beim Laden der DLL aufgerufen
;um "bombensicheres" Errorhandling zu haben, Funktion anpassen!
proc DllEntryPoint hinstDLL,fdwReason,lpvReserved
        mov     eax,TRUE         ;hart aber herzlich^^
        ret
endp




;******************Ab hier fangen die Benutzer-Funktionen an **********


proc VarIn
;ab hier folgt der Code, wie er z.B. von AssembleIt verarbeitet wird
use32
mov esi,[esp+4]       ;Startadresse variable
mov ecx,[esp+8]       ;länge
mov eax,ecx
mov edi,_mem          ;DLL Speicher
rep movsb             ;alle bytes von quelle nach ziel kopieren
ret 8
endp






proc VarOut
mov edi,[esp+4]       ;Startadresse variable
mov ecx,[esp+8]       ;länge
mov esi,_mem          ;DLL Speicher
mov eax,edi
rep movsb             ;alle bytes von quelle nach ziel kopieren
ret 8
endp




section '.reloc' fixups data discardable

In einem Script( compiliert) gestartet, funktioniert das einwandfrei. Man kann dieses Script laufen lassen und ein weiteres starten, in dem die Zeile mit dem VarIN-Call auskommentiert ist.
Leider wird, wenn man die DLL aus einem weiteren Script anspricht, der Speicher nicht Global angesprochen...werde da wohl nochmal etwas nachhaken müssen!
Funzt nicht...Speicher innerhalb der DLL wird geschützt. Um da ranzukommen, verwendet man die Methode per _WinAPI_ReadProcessMemory(), das geht aber einfacher, s.o.

Achso, ich ging davon aus das es möglich sein sollte den speicherplatz dynamisch anzufordern. Das wäre natûrlich eine herausforderung. Aber wenn du sagst "so viel speicher wird bereitgestellt und nicht mehr" dann sollte das einfacher sein. Naja, in den meisten fällen ist 1 MB schon mehr als genug. Bin mal gespannt was dabei herum kommt. Stellst du dann auch den sourcecode der dll zur verfügung?

s. EDIT...so ist das, wenn man Threads schreibt/editiert, und erst nach Stunden auf den "abschicken" Button drückt^^

Andy, du musst die Datensektion noch mit shareable global verfügbar machen:

section '.data' data readable writable shareable

So funktioniert das dann auch.

Basierend auf Andy's Assemblercode habe ich selber nun eine kleine einfache DLL geschrieben. In ihr werden 10 Byte an Speicher reserviert (Für eine einfache 10 Zeichen lange Nachricht). Mit der Funktion „GetPtr“ kann der Pointer für den Speicher gelesen werden. Mithilfe einer Struktur lässt sich dies in AutoIt nun ganz simple ansprechen. Der Pointer des Speicherbereiches wird einfach an die Strukur übergeben.

Im Anhang befindet sich ein Beispielskript sowie die nötige DLL + Quelltext. Das Beispielskript ruft sich selber nochmals über den Interpreter auf. Beim ersten Aufruf wird die Nachricht in den Speicherbereich geschrieben, beim zweiten Aufruf in einer MessageBox ausgegeben. Danach geschieht das Selbe nur in anderer Richtung. Das soll verdeutlichen das wirklich nur ein Speicherbereich genutzt wird. Man kann also von mehreren Prozessen problemlos darauf zugreifen.

Andy:
Gute Arbeit von dir, ich habe lediglich ein wenig (oder fast alles :x) bei dir abgeguckt und die kleine Sache mit „shareable“ eingepflanzt. Ziemlich interessant was so alles möglich ist. Die Lorbeeren gehören dir xD

Sodele, habe mal ein Beispielscript erstellt.

Die EXE mehrfach starten, es wird je gestarteter GUI ein Zähler hochgezählt.
Diesen Zähler kann man beliebig lange "anhalten", indem man den Rahmen der GUI anfasst.
Jede dieser GUI´s lädt die DLL. Diese wird im Speicher natürlich nur einmal erstellt ! Das ist der Sinn einer Dynamic Link Library
Die GUI´s erhalten von dieser DLL nur den Pointer auf den innerhalb der DLL verwendeten Speicherbereich.
Dieser Speicherbereich kann nun von JEDER GUI beliebig gelesen/beschrieben werden.
Dazu wird an der Position dieses Pointers eine beliebige Struct erstellt. Ich habe einen String erstellt, und auch einen INT, welcher als Reset-Flag dient, um die GUI´s zu synchronisieren.

Klickt man nun in einer BELIEBIGEN GUI auf den "Reset/Sync"-Button, wird aus dieser GUI im Speicher der DLL das Reset-Flag gesetzt.
Da alle GUI´s permanent den Status des Reset-Flags im Speicher der DLL abfragen, wird im Falle eines Resets IN JEDER DER GUI´s darauf reagiert und der Zähler auf Null gesetzt.

Interprozesskommunikation!

Eins ist noch interessant, wenn man den Speicherbereich innerhalb der DLL vergößert, findet irgendwann Avira Antivir in der DLL den Packer.GEN Wie gesagt, ab einer betimmten Anzahl Nullen in der Datei werden von den Scannern Viren gefunden, weiß jemand den Grund?

autoit.de/wcf/attachment/24801/

//EDIT
Man sollte noch erwähnen, dass die DLL nichts weiter macht, als einen Speicherbereich zu reservieren. Sämtliche Aufteilungen bzw. Strukturen finden alleine im AutoIt-Script statt. So kann man nun Texte, oder Variablen oder Bilder oder wasauchimmer an andere Programme übergeben.

//EDIT2
Script um das "Reset" deutlicher zu machen, compilieren, mehrfach starten...

Zitat von Andy

Die EXE mehrfach starten, es wird je gestarteter GUI ein Zähler hochgezählt.
Jede dieser GUI´s lädt die DLL. Diese wird im Speicher natürlich nur einmal erstellt ! Das ist der Sinn einer Dynamic Link Library

Sicher? Ich hatte mich schon die ganze Zeit gefragt, wie eure Idee überhaupt funktionieren kann, aber wahrscheinlich liegt es einfach nur an dem "shareable," das MG in #24 erwähnt hat.
Microsoft sagt dazu nämlich folgendes:

Zitat von About Dynamic-Link Libraries

Every process that loads the DLL maps it into its virtual address space.
After the process loads the DLL into its virtual address, it can call the exported DLL functions.

Und damit mein Post nicht völlig umsonst war hier noch eine Möglichkeit, die noch nicht (direkt) erwähnt wurde: Pipeline DLL - die einfachste Art der Prozess-Kommunikation

James,
genau aufgrund der von dir geposteten Microsoft-Statements zum Thema bin ich überzeugt, dass diese "sharable"-Geschichte überhaupt nicht im Sinne des Erfinders (bzw. der "neueren" BS) ist!
In sämtlichen von mir gelesenen Forenbeiträgen taucht irgendwann ein Microsoft-MVP auf und bestreitet vehement die von uns gezeigten Möglichkeiten.
Die innerhalb der DLL untergebrachten Funktionen werden natürlich nur einmal in den Speicher geladen, genau dafür ist das System DLL/LIB ja gemacht! Es gibt Konstruktionen, sogar mit mehreren Threads innerhalb eines Prozesses "eine" Funktion im Speicher zu benutzen. Alles andere wäre auch unsinnig. Sämtliche Betriebssystem-eigenen DLL´s stellen ihre Funktionen ja auch sämtlichen Programmen zur Verfügung.

Hat ggf. ein C/C++-Spezi eine Möglichkeit, diese "shareability" von Speicher innerhalb mit einem Compiler erstellten DLL nachzuvollziehen?

//EDIT
Mit dieser Methode kann man übrigens ECHTES Multitasking (eher Multiprocessing) realisieren!
Statt in einem Prozess mehrere Threads zu erstellen, erstellt man einfach mehrere Prozesse!
Windows sorgt selbstständig dafür, dass verfügbare Prozessorkerne ausgelastet werden.

In C/C++ kann man solch einen Datenbereich mit #pragma data_seg(".shared") realisieren. Gleiches prinzip den du bei dem Assemblercode angewendet hast.

Hallo zusammen,

jetzt hätte ich noch eine Frage an Andy.

wie kann man aus dem asm Code eine dll erstellen
und wie könnte man den Speicherbereich der reserviert werden soll durch den DLLCall direkt angeben.
Im Moment ist der Speicherbereich ja begrenzt auf 10KB.

Grüße
Schnuffel

Der asm code muss mit der FASM.exe (flat assembler -> http://www.flatassembler.net) kompiliert werden. Der benötigte speicherbereich MUSS vor dem kompilieren angegeben werden, das spãter dynamisch zu machen ist so leider nicht möglich. Reserviere dir also genug speicher.

Ich arbeite aber gerade an einem tool der solch eine dll erstellt. Schließlich hat nicht jeder asm erfahrung oder lust das selber zu kompilieren. Das tool wird dann in autoit geschrieben sein, wird aber noch ein bisschen dauern bis es fertig ist. So hat dann jeder die möglichkeit diese art der kommunikation zu nutzen.

Schnuffel, Einfach den Code in FASMW.exe (der Editor) laden und Ctrl-F9 (Compile) drücken, dann ist die DLL erstellt.
Dynamisch den Speicherbereich zu erstellen geht auch, dazu ruft man einfach ein MemAlloc() auf
Aber das könnte man auch direkt aus dem AutoItcode machen, somit wäre das ganze witzlos.
Ich würde einfach einige DLL´s unterschiedlicher Größe erstellen und mit eigenen Namen versehen.
MemShare_1kb.dll
MemShare_100kb.dll
MemShare_1Mb.dll
MemShare_100Mb.dll
usw.
Da die reservierte Speichergröße heutzutage kein Thema sein sollte, nimmt man die DLL, welche für das Vorhaben reichlich Platz bietet.
Selbst wenn man in der Anwendung nur 10% des Speicherplatzes in der DLL benötigt....who cares

@MG, sollte so schwer nicht sein, der eigentliche DLL-Code bleibt ja konstant, nur die Größe der Variablen im Datasegment ändert sich. Und Nullen reinpacken sollte so schwer ja nicht sein.

Jetzt wo du's sagst, auf das mit MemAlloc bin ich nicht gekommen. Prinzipiell könnte man so 4 byte in der dll reservieren und dort den pointer zu den per MemAlloc reservierten speicher hinein schreiben. So hätte jeder prozess direkt den passenden pointer und man kann locker den speicher dynamisch verändern. Ob das aber dann immernoch so einfach via dllstruct funktioniert, müsste man mal ausprobieren.

€dit: {
Hab's ausprobiert, der reservierte speicher via GlobalAlloc sowie VirtualAlloc wollen zum erbrechen nicht mit dllstruct's angesprochen werden. Auch nicht wenn man den speicher direkt in der dll anforder. Hab sogar aus verzweiflung versucht die prozedur welche den speicher anfordert auch mit shareable zu kennzeichnen. Nützt nichts, aber ich hab's mir sowieso schon gedacht. Naja
}

Und das mit dem tool hätte sich dann so auch erledigt, da ja dann nur eine einzige dll mit 4 byte reservierten speicher erforderlich ist. Aber ansonst: paar nullen mehr hinein schreiben (wie du's so schön gesagt hast). Aber trzd. muss man dann den header noch anpassen (wenn ich mich richtig errinnere), sollte aber so gehen.

Achja, mich würde das schon interessieren wenn man 10 mb an daten reserviert aber nur 1 mb nutzt. Bei meiner download geschwindigkeit bin ich froh wenn entwickler bytesparend programmieren würden. xD

[Kann es sein dass wir solangsam vom eigentlichen thema abschweifen?]

Danke Euch.

Andy das mit der FASM werd ich ausprobieren.

Ich hab die dll dann sowieso als Variable in autoit eingebettet und passend zur Anforderung erstellt und gestartet.

@MG, hast du virtualalloc mit MEM_COMMIT | MEM_RESERVE mal getestet? WENN ich so Speicher reserviere, hau ich als protect-Parameter auch gleich PAGE_EXECUTE_READWRITE rein

Schnuffel bin schon auf Anwendungen gespannt!

@Homer j.S.,

zu 2, das war ein kurzfristiger "Fehler" von mir, da bei mir der Virenscanner gesponnen hat, wenn ich innerhalb der DLL mehr als 6k Speicher reserviert habe.
Ursprünglich stand dort _mem dd 10000 dup 0 ;10 Kb Speicher
Jetzt alles klar?

zu 1, habe mit FASM noch keine 64Bit-DLL assembliert, werde mich mal dransetzen.

jetzt ist mir in FASM aufgefallen, die erstellte dll ist immer knapp 4x so groß wie der allozierte Speicher.
Das ist doch nicht im Sinne des Erfinders???
Ich dachte damit wird "nur" Speicher im RAM angefordert und reserviert.
Aber in der dll???

Mache ich etwas falsch?

Beispiel einer 1MB dll:

64-Bit dll

format PE64 GUI 4.0 DLL
entry DllMain
 
include 'win64a.inc'
 
;--------------------------------------------------------------------
section '.text' code readable executable
 
proc GetPointer64


mov rax,_mem


ret
endp
 
proc DllMain hinstDLL, fdwReason, lpvReserved
mov eax, TRUE
ret
endp
 
;--------------------------------------------------------------------
section '.idata' import data readable writeable
 
library\
kernel, 'KERNEL32.DLL',\
user, 'USER32.DLL'


 
;--------------------------------------------------------------------
section '.data' data readable writeable shareable


_mem db 10000 dup 0   ;10kbyte Speicher reservieren




;--------------------------------------------------------------------
section '.edata' export data readable
 
export 'sharedmem64.dll',\
GetPointer64, 'GetPointer64'


;--------------------------------------------------------------------
data fixups
end data

und Script dazu^^

Schnuffel
schau mal nach, was dd bedeutet
um bytes zu reservieren, _mem db 10000 dup 0 ;10 Kb Speicher
um words zu reservieren, _mem dw 10000 dup 0 ;20 Kb Speicher
um dwords zu reservieren, _mem dd 10000 dup 0 ;40 Kb Speicher
um quadwords zu reservieren, _mem dq 10000 dup 0 ;80 Kb Speicher

http://flatassembler.net/docs.php?article=manual#1.2.2