| |
| |
|
| - Seite 1 - |
|
Jac
de
Lad | Hallo Community!
Mit der API CreateFile kann man jede Menge verschiedener Dateien erstellen. Ich suche eine Möglichkeit eine Datei quasi im RAM zu erstellen um dann mittels einer DLL-Funktion darauf zuzugreifen, etwas damit zu machen und die Datei anschließend wieder zu löschen. Damit würde ich eine temporäre Datei umgeben, was erstens schneller ist und zweitens einfach schöner. Kennt sich jemand damit aus? Ich komme mit der Hilfe nicht klar, es gibt das etliche Parameter mit hunderten Möglichkeiten...
Jac  |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 18.04.2008 ▲ |
|
| |
|
|
| |
| |
| - Seite 1 - |
|
 | | string a&,0=Blub |
|
| |
| |
| |
|
|
Jac
de
Lad | Ich hab mir im MSDN die APIs angesehen, aber ich komme damit nicht klar. Hast du eventuell ein Minimalbeispiel?
Jac |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 19.04.2008 ▲ |
|
| |
|
|
| | Im Moment nicht - die pipeUnit raspelt vieles hin-und-her sodass diese kaum zeigt wie es einfach geht... |
|
| |
| |
| |
|
|
Jac
de
Lad | | Das ist schlecht. Trotzdem danke, ich schau mich mal weiter um. |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 19.04.2008 ▲ |
|
| |
|
|
Frank
Abbing |
Ich suche eine Möglichkeit eine Datei quasi im RAM zu erstellen um dann mittels einer DLL-Funktion darauf zuzugreifen, etwas damit zu machen und die Datei anschließend wieder zu löschen.
Hört sich für mich an wie ein stinknormaler Speicherbereich. Übergib einfach einen Zeiger auf den Speicher an die Dll-Funktion, z.B. NeueFunktion(bereich#) |
|
| |
| |
| |
|
|
| | Stimmt, er brauchs ja garnicht prozessübergreifend, sei denn die DLL läuft in einem anderen Prozess... |
|
| |
| |
| |
|
|
Andreas
Miethe
 | Frank Abbing
Frank AbbingIch suche eine Möglichkeit eine Datei quasi im RAM zu erstellen um dann mittels einer DLL-Funktion darauf zuzugreifen, etwas damit zu machen und die Datei anschließend wieder zu löschen. Hört sich für mich an wie ein stinknormaler Speicherbereich. Übergib einfach einen Zeiger auf den Speicher an die Dll-Funktion, z.B. NeueFunktion(bereich#)
Wird nicht funktionieren !
So wie ich das verstanden habe, soll eine Datei, die nur im Ram liegt, mit einem Dateinamen angesprochen werden.
Beispiel:
Eine EXE wird mittels Datengenerator in die Exe eingebunden.
Da habe ich meine EXE im Speicherbereich.
Jetzt versuch mal mit der Kernel32.Dll per CreateProcess() das Ding zum Laufen zu kriegen.
Da wird kein Speicherbereich sondern ein Dateiname erwartet.
Immer wenn eine Dll-Funktion einen Zeiger auf einen Dateinamen erwartet, und davon gibt es eine Menge, wird das so nicht funktionieren.
Bitte berichtige mich wenn ich da falsch liege ! |
|
| |
| Gruss Andreas ________ ________ ________ ________ _ Profan 3.3 - XProfanX2 Win 95,98,ME,2000,XP,Vista - Win 7 32 / 64 Bit ASUS X93S - Intel Core I7-NVIDIA GForce 540M 8GB Arbeitsspeicher Homepage : [...]  | 20.04.2008 ▲ |
|
| |
|
|
Frank
Abbing |
Bitte berichtige mich wenn ich da falsch liege !
Du liegst da sicher nicht falsch. Die Sache mit dem Dateinamen habe ich bewußt aussen vor gehalten, weil ich davon ausgegangen war, dass Jac die Dll selber erzeugt. Dafür fand ich die Technik über die Bereiche viel sinnvoller. Das geht aber mit einer fremden Dll nicht.
Aber ich bin sicher, dass auch eine Exedatei aus dem Speicher gestartet werden kann. Immerhin geht das ja auch mit Dlls (Memorymodule) und diese sind ja auch Exedateien.
Wie auch immer, alles in Allem ist iFs Lösung vorzuziehen. Ich bin sicher, er liefert Jac noch einen kurzen Democode dazu. |
|
| |
| |
| |
|
|
Andreas
Miethe
| Hallo Frank,
ist eine ganz andere Geschichte, wenn die Dll selbst geschrieben wird.
Davon gehe ich aber nicht aus.
Jac
Aber wie kann ich die Datei nutzen, wenn die Funktion der DLL einen Zeiger auf einen Dateinamen benötigt? Jac |
|
| |
| Gruss Andreas ________ ________ ________ ________ _ Profan 3.3 - XProfanX2 Win 95,98,ME,2000,XP,Vista - Win 7 32 / 64 Bit ASUS X93S - Intel Core I7-NVIDIA GForce 540M 8GB Arbeitsspeicher Homepage : [...] | 20.04.2008 ▲ |
|
| |
|
| |
| |
| - Seite 2 - |
|
|
Jac
de
Lad | Nein, nein, nein.
Folgendes:
Eine DLL xyz benötigt für eine Operation einen Dateinamen (meinetwegen wird die Datei geladen und unter einem anderen Format wieder gespeichert). Ich erzeuge die Datei aber nur temporär, weil Profan die Datei x nur in einem anderen Format erzeugen kann. Ich will nun diese temporäre Datei umgehen, weil es mir zu langsam ist, dass die auf der Festplatte erstellt wird. Deswegen suche ich nach einer Möglichkeit, dass die Datei trotzdem erstellt wird, aber die Ausgabe in den RAM umgeleitet wird. Die Datei muss natürlich trotzdem unter einem Dateinamen ansprechbar sein, da sonst die DLL xyz nicht mehr geht.
Wisst ihr jetzt was ich meine?
Jac |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 20.04.2008 ▲ |
|
| |
|
|
Sebastian
König | Jac
Nein, nein, nein. Folgendes: Eine DLL xyz benötigt für eine Operation einen Dateinamen (meinetwegen wird die Datei geladen und unter einem anderen Format wieder gespeichert). Ich erzeuge die Datei aber nur temporär, weil Profan die Datei x nur in einem anderen Format erzeugen kann. Ich will nun diese temporäre Datei umgehen, weil es mir zu langsam ist, dass die auf der Festplatte erstellt wird. Deswegen suche ich nach einer Möglichkeit, dass die Datei trotzdem erstellt wird, aber die Ausgabe in den RAM umgeleitet wird. Die Datei muss natürlich trotzdem unter einem Dateinamen ansprechbar sein, da sonst die DLL xyz nicht mehr geht. Wisst ihr jetzt was ich meine? Jac
Eine Möglichkeit, die mir gerade einfällt, wäre vielleicht CreateNamedPipe(). Solche Objekte bekommen einen Namen nach dem Schema \.pipepipename und lassen sich mit CreateFile() öffnen, sodass man sie höchstwahrscheinlich an die Funktion als via ihres Datei-Namens übergeben könnte. Das schwierige an der Sache ist allerdings, dass man sich in dem aufrufenden Prozess um das Beschreiben der Pipe kümmern muss - sehr schwierig, denn das ganze müsste parallel zu dem Funktionaufruf geschehen, also in einem eigenen Thread ablaufen (was mit Profan2Cpp wohl funktionieren würde). Leider habe ich im Moment extrem wenig Zeit, sodass ich kein Beispiel liefern kann, aber ich werde in den nächsten Tagen mal etwas ausprobieren... 
Vielleicht hat aber jemand noch eine bessere, i.e. einfachere Idee...
MfG
Sebastian |
|
| |
| |
| |
|
|
Sebastian
König | So, hier ist jetzt mal ein Beispiel. Im Prinzip funktioniert es - jedenfalls bei mir. Die Prozedur TestProc ist ein Dummy für die DLL-Funktion: Sie öffnet die Datei über ihren Namen und liest den Inhalt, bis nichts mehr zum Lesen verfügbar ist. Leider liegt hier (höchstwahrscheinlich) auch die große Einschränkung des Konzepts: Das ganze funktioniert wohl nur, wenn das Lesen auf diese Art und Weise stattfindet und nicht irgendwie zunächst die Dateigröße ermittelt und dann alles auf einem gelesen wird. Einen Versuch ist aber vielleicht trotzdem Wert...
KompilierenMarkierenSeparieren $H Windows.ph
$IFNDEF P2CPP
Cls
Print Der Code funktioniert leider nur mit Profan2Cpp - Sorry!
Print
Print Taste zum Beenden.
WaitKey
End
$ENDIF
var pipe$ = \\.\pipe\sk-testpipe
var signal& = ~CreateEvent(0,0,0,0)
declare data#
dim data#,1024 * 100 100 KB
clear data#
Bereich füllen...
declare error&
proc WriteThreadProc
parameters lpParams&
P2CPP: <USE_EXTERNAL_ST>
var pipe& = ~CreateNamedPipe(Addr(pipe$),~PIPE_ACCESS_OUTBOUND,~PIPE_TYPE_BYTE | ~PIPE_WAIT,1,1024,1024,500,0)
if pipe& = ~INVALID_HANDLE_VALUE
error& = ~GetLastError()
~SetEvent(signal&)
~ExitThread(1)
endif
~SetEvent(signal&)
~ConnectNamedPipe(pipe&,0)
var dwTotalAvail& = SizeOf(data#)
var dwTotalWritten& = 0
var dwWritten& = 0
while dwTotalWritten& < dwTotalAvail&
dwWritten& = 0
~WriteFile(pipe&,data# + dwTotalWritten&,1024,Addr(dwWritten&),0)
dwTotalWritten& = dwTotalWritten& + dwWritten&
~Sleep(0)
endwhile
~FlushFileBuffers(pipe&)
~DisconnectNamedPipe(pipe&)
~CloseHandle(pipe&)
~ExitThread(0)
P2CPP: </USE_EXTERNAL_ST>
endproc
proc TestProc
parameters filename$
declare file&
var file& = ~CreateFile(Addr(filename$),~GENERIC_READ,0,0,~OPEN_EXISTING,0,0)
Color 12,15
Print Datei-Handle:,file&
if file& = ~INVALID_HANDLE_VALUE
Print WinError$(error&)
WaitKey
End
endif
var dwTotalRead& = 0
var dwRead& = 0
declare buffer#
dim buffer#,1024
while ~ReadFile(file&,buffer#,1024,Addr(dwRead&),0)
dwTotalRead& = dwTotalRead& + dwRead&
dwRead& = 0
endwhile
~CloseHandle(file&)
Print Int(dwTotalRead& 1024),KB gelesen
Print
dispose buffer#
endproc
Cls
declare id&
var thread& = ~CreateThread(0,0,ProcAddr(WriteThreadProc,1),0,0,Addr(id&))
Print Thread-ID:,id&
Print Thread-Handle:,thread&
Print
~WaitForSingleObject(signal&,~INFINITE)
~CloseHandle(signal&)
TestProc pipe$
~CloseHandle(thread&)
dispose data#
Color 0,15
Print Taste zum Beenden.
WaitKey
End
HTH
Sebastian |
|
| |
| |
| |
|
(1.108)
Deutsch
English
Français
Español
Italia