Zwischenspeichern im RAM

Ramdisk?

Sicher, dass es die Platte und nicht das COM-Geraffel ist?

Klar, eine Ramdisk wäre das Mittel der Wahl.
Geht aber anscheinend nur mit externen Tools.
Schade dass Windows von Haus aus keine Möglichkeit bietet.

Shared Memory nutzt mir nichts, weil ich ja die Export Funktion von dem 
einen Programm, und die Import Funktion des anderen Programms 
fernbediene. Und das geht nun mal nur über das Dateisystem.

TCP und 127.0.0.1 wäre dann eine Möglichkeit, wenn ich ein 
Netzwerklaufwerk im RAM einrichten könnte.

Thomas_jhfd schrieb:
> Shared Memory nutzt mir nichts, weil ich ja die Export Funktion von dem
> einen Programm, und die Import Funktion des anderen Programms
> fernbediene.

hä?

> Aus dem einen Programm exportiere ich 100te Dateien, die in dem anderen
> Programm wieder eingelesen werden.

Das heißt, du hast irgendwas mit Windows-Bordmitteln zusammengebastelt. 
Jetzt wäre eine gute Zeit mal über eine anständige Architektur 
nachzudenken.

Thomas_jhfd schrieb:
> Ist es möglich die Dateien im RAM anstatt auf der Festplatte
> zwischenzuspeichern?

Wenn du unter Linux Dateien speicherst und kurz danach wieder lädst, 
werden sie automatisch im RAM gepuffert. Ist das bei Windows etwa 
anders?

Rolf M. schrieb:
> Und wie kommt überhaupt ein Dateisystem in den Shared Memory?

Wozu das denn? Du hast nichts verstanden, daher auch das "hä". 
Selbstverständlich musst du halbwegs wissen was du tust wenn du eine 
Interprozesskommunikation programmieren willst. Übrigens heisst Shared 
memory, Überraschung, deshalb so weil Memory von beiden Prozessen 
benutzt werden kann. Was da drinsteht ist Sache des Programmierers.

Georg

Rolf M. schrieb:
> Wie würdest du einem Programm sagen, dass es
> die Dateien statt auf die Festplatte in einen Shared Memory schreiben
> soll?

Indem ich das Programm entsprechend schreibe?

Georg schrieb:
> Shared memory

Ramdisk und shared memory würde ich vermeiden weil man nie weiß ob 
überhaupt genügend RAM in der Maschine ist. Wahrscheinlich braucht der 
To Thomas mal ein paar neue SSDs statt seiner müden Festplatten. Das 
würde einen wesentlichen Geschwindigkeitsgewinn bringen, da die 
magnetischen Festplatten das langsamste Teil im PC sind.

oszi40 schrieb:
> Ramdisk und shared memory würde ich vermeiden weil man nie weiß ob
> überhaupt genügend RAM in der Maschine ist.

Kommt halt auf die benötigte Menge an.

Und sonst? schrieb:
>> Aus dem einen Programm exportiere ich 100te Dateien, die in dem
> anderen
>> Programm wieder eingelesen werden.
>
> Das heißt, du hast irgendwas mit Windows-Bordmitteln zusammengebastelt.
> Jetzt wäre eine gute Zeit mal über eine anständige Architektur
> nachzudenken.

Hier checken es wieder einige nicht, oder?
Er hat eine Fremd Applikation die er über COM automatisieren kann, das 
automatisierte Programm bietet nur diese Schnittstelle mit Dateiausgabe, 
er kann daran nichts ändern, hat nichts mit seinem Code zu tun

cppbert3 schrieb:
> Hier checken es wieder einige nicht, oder?

Tja. Dann hätte Thomas_jhfd das halt mal so beschreiben sollen.
Hellsehen kann ich leider nicht.

cppbert3 schrieb:
> hat nichts mit seinem Code zu tun

Wahrscheinlich gibt es so etwas wie "sein Code" einfach nicht.

Georg

Thomas_jhfd schrieb:
> chade dass Windows von Haus aus keine Möglichkeit bietet.

Also, wenn man ein ISO-Image öffnet, legt Windows automatisch eine 
virtuelle Partition an. Also existiert sowas doch in Windows. Man muß es 
nur programmtechnisch ansprechen und verwalten können.

Kater schrieb:
> Thomas_jhfd schrieb:
>
>> chade dass Windows von Haus aus keine Möglichkeit bietet.
>
> Also, wenn man ein ISO-Image öffnet, legt Windows automatisch eine
> virtuelle Partition an. Also existiert sowas doch in Windows. Man muß es
> nur programmtechnisch ansprechen und verwalten können.

Was bringt ihm das in Windows fest eingebautes virtuelles Dateisystem 
für ISO Images bei seiner Anforderung? Eine Ramdisk implementiert die 
selbe API aber die bekommt er ohne Admin Rechte nicht geladen, was hier 
sein Problem ist

Unter Windows gibt es keine eingebaute Ramdisk die per Default aktiv ist 
die er für so was nutzen könnte

Rolf M. schrieb:
> und nirgends hat er behauptet, dass er diese zwei Programme selbst
> geschrieben hätte.

Wir befinden uns in:
Forum: PC-Programmierung

Rolf M. schrieb:
> Er hat also ein fertiges Programm, dem er per IPC sagen
> kann, dass es eine Datei erstellen und auf der Platte speichern soll.

nur das es keine Missverständnisse gibt "IPC" bedeutet hier nicht 
Industrie-PC sondern Interprozess-Kommunikation :)

und COM ist das "Component Object Model" von Microsoft

Rolf M. schrieb:
> Kann es sein, dass du es darauf anlegst, die Frage falsch zu verstehen?

Was soll der Blödsinn?
Ich habe die Frage anscheinend falsch verstanden.
Das haben wir ja jetzt geklärt.

Die Ursachen dafür, dass jemand eine Frage falsch versteht, liegen in 
der Regel beim Fragesteller. Sie war offensichtlich nicht eindeutig 
gestellt.

Thomas_jhfd schrieb:
> per COM (VBA oder .NET) automatisiere ich zwei Programme.
> Aus dem einen Programm exportiere ich 100te Dateien, die in dem anderen
> Programm wieder eingelesen werden.

ER wollte nur den UMweg über die Festplatte sparen. Also wäre Ramdisk 
schon schön WENN der RAM reicht. Gleichzeitig sind aber alle Daten 
verloren wenn mal der Strom fehlt. Also doch copy irgendwas nach 
x:\irgendwo

Wir kennen jetzt keine Details zu deinem Code, aber vielleicht schlucken 
die über Com+ aufgerufenen Funktionen ja named pipes als file handle. 
Die wurden ursprünglich mal genau dazu erfunden.

Stickworte "named pipe" und NPFS (named pipe file system)

Musst du dich eventuell etwas einlesen. Oder jemand anders hier hat 
Erfahrung damit.

https://versprite.com/blog/security-research/microsoft-windows-pipes-intro/

Grüße,
M

cppbert3 schrieb:
> Hier checken es wieder einige nicht, oder?
> Er hat eine Fremd Applikation die er über COM automatisieren kann, das
> automatisierte Programm bietet nur diese Schnittstelle mit Dateiausgabe,
> er kann daran nichts ändern, hat nichts mit seinem Code zu tun

Genau so ist es. Zwei Programme, die ich nehmen muss wie sie sind. 
Dachte das wäre klar. Scheinbar nicht. Danke.

Thomas_jhfd schrieb:
> Zwei Programme, die ich nehmen muss wie sie sind.

Ja dann ist doch alles klar. Nimm sie, wie sie sind, und gib dich 
geschlagen.

Da ist das Problem:
Thomas_jhfd schrieb:
> Da meine SW auf Fremdrechnern installiert wird sollte das möglichst mit
> Bordmitteln gehen.

Wenn ich das wie eine Library in meine Solution packen kann wäre das ok. 
Ich möchte aber nicht, dass der User weitere SW installieren und 
einrichten muss.

Per Copy & Paste über die Zwischenablage ist noch naheliegend. Geht auch 
prinzipiell. Hat aber Nachteile wegen fehlender Einstellmöglichkeiten, 
die der Export als Datei bietet.

Wenn es keine Möglichkeit gibt das innerhalb meiner Solution selbst 
umzusetzen bleibt es halt wie es ist. Der Poweruser hat ja immer noch 
die Möglichkeit seinen temporären  Ordner selbst in eine Ramdisk zu 
legen.

Thomas_jhfd schrieb: schrieb:
> Wenn ich das wie eine Library in meine Solution packen kann wäre das ok

Du schreibst doch, dass du an der Software nicht das geringste ändern 
kannst - was soll da eine Library helfen? Die Funktionen muss man aus 
der Software heraus aufrufen.

Georg

Oliver S. schrieb:
> Eigentlich gibt es da kein allzugroßes Problem. Für reine
> C&P-"Programmierer" wirds aber vermutlich schwierig.

Dann lass mal hören.

Georg schrieb:
> Thomas_jhfd schrieb: schrieb:
>> Wenn ich das wie eine Library in meine Solution packen kann wäre das ok
>
> Du schreibst doch, dass du an der Software nicht das geringste ändern
> kannst - was soll da eine Library helfen? Die Funktionen muss man aus
> der Software heraus aufrufen.
>
> Georg

Er hat 2 Applikationen die er beide per COM fernsteuert - die eine 
Importiert, die andere Exportiert - da ist noch sein dritte im Bunde

ist das echt alles so schwer?

Oliver S. schrieb:
> Thomas_jhfd schrieb: schrieb:
>> Wenn ich das wie eine Library in meine Solution packen kann wäre das ok.
>
> Eigentlich gibt es da kein allzugroßes Problem. Für reine
> C&P-"Programmierer" wirds aber vermutlich schwierig.
>
> Oliver

Er schrieb doch das er die Software wenn möglich ohne zusätzlichen 
Aufwand auf Fremd-Rechnern installieren will - eine RAMDisk bedürfte 
mindestens Admin-Rechte - vielleicht bekommt er die einfach nicht

Mark B. schrieb:
> Wie soll man ein Programm, an dem man nichts verändern kann, dazu
> bringen auf eine RAM-Disk zu schreiben anstatt auf die Festplatte?

Den Pfad, wohin exportiert wird, kann er vermutlich per COM 
Schnittstelle beeinflussen. Oder er erstellt einen Symlink zu einem 
Verzeichnis auf der RAM-Disk. Nur wie man automatisiert unter Windows 
eine RAM-Disk anlegt, dass weiß ich nicht. Bin kein Windows Spezialist.

Mark B. schrieb:
> Wie soll man ein Programm, an dem man nichts verändern kann, dazu
> bringen auf eine RAM-Disk zu schreiben anstatt auf die Festplatte?
>
> Wie soll man ein Programm, an dem man nichts verändern kann, dazu
> bringen von einer RAM-Disk zu lesen anstatt von der Festplatte?

Konfiguration. In einer Datei, Registry, oder als Parameter beim Aufruf, 
setzen, wo die Daten liegen.

Und wenn das nicht möglich ist, gibt es noch Symlinks.

Mark B. schrieb:
> Um die zu nutzen, müsste man nach meinem Verständnis wiederum die
> bereits bestehenden Tools auch konfigurieren können. Nämlich so, dass
> sie für das Lesen/Speichern von Dateien eben einem Symlink folgen und
> nicht das Verzeichnis nutzen, welches fest einprogrammiert (?) ist.

Sofern das Programm nicht explizit angibt, dass das OS Symlinks nicht 
folgen soll, (z.B. unter Linux mit O_NOFOLLOW Option für open, Win hat 
da sicher etwas ähnliches), tut das OS das automatisch. Das ist ja genau 
der Sinn der Sache.

Ein Symlink ist nicht das selbe wie diese .lnk Dateien, die vom 
Explorrer ausgewertet werden. Wobei, bei MS gibt es eigentlich keine 
echten Symlinks, sondern Reparse Points, und da gibt es viele 
verschiedene.

Wie auch immer, man erstellt die Dinger unter Win mit mklink [1], du 
kannst ja selbst mal etwas damit rum spielen.
Ich nutze die Dinger gerne, damit Programme nicht merken, dass die auf 
einen Netzwerkshare und gar nicht lokal schreiben (was wiederum geht, 
weil ein reparse point eben nicht das selbe wie ein symlink ist, und das 
dort irgendwie merkwürdig vom darunterliegenden Dateisystemtreiber mit 
beeinflusst wird...)

PS: Was ist eigentlich der Unterschied zwischen "directory symbolic 
link" und "Directory Junction"?

1) 
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink

Btw. Das konfigurieren des Programms ist nicht notwendig, weil man 
einfach (die im Programm fix angegebene) Zieldatei oder das 
Zielverzeichnis mit einem Symlink ersetzt.

Mark B. schrieb:
> Um die zu nutzen, müsste man nach meinem Verständnis wiederum die
> bereits bestehenden Tools auch konfigurieren können. Nämlich so, dass
> sie für das Lesen/Speichern von Dateien eben einem Symlink folgen und
> nicht das Verzeichnis nutzen, welches fest einprogrammiert (?) ist.

Das ist nicht richtig. Ein Symlink ist keine *.lnk Datei wie sie der 
Dateimanager erstellt wenn man eine Verknüpfung auf eine Datei anlegt.

Symlinks sehen für gewöhnliche Programme (die diese nicht speziell 
behandeln) wie ein Verzeichnis oder eine Datei aus, je nach dem, worauf 
der Symlink zeigt.

Danke für die konstruktiven Beiträge.
Zum Verständnis, so in etwa sieht es bei mir aus:

1

string svgFile Path.GetTempPath() + "item.svg";

2

3

foreach(var article in stock.articles)

4

{

5

    article.ExportAsImage(svgFile);

6

    page.AddPicture(svgFile);

7

}

Und wie kommst du nun auf den Trichter, dass die Platte das Bottleneck 
ist?  Wenn die Dateien nicht gerade im Gigabytebereich liegen, dürfte 
die Geschwindigkeit der Platte kaum was ausmachen.  Könnte man ja 
einfach mal testen ...

Keine Ahnung, wie Windows es handhabt, aber unter Linux werden 
kurzlebige Dateien in der Regel gar nicht auf die Festplatte 
geschrieben.
Wenn man also eine Datei schreibt, liest und innerhalb weniger Sekunden 
wieder löscht, kommt es in der Regel zu gar keinem Disk-I/O.
Kann Windows das auch?

Thomas_jhfd schrieb:
> Danke für die konstruktiven Beiträge.

Wenn Windows da wirlich exzessiv die Platte verwendet, würde ich 
versuchen, ob sich das Verhalten ändert, wenn man die Datei gleich 
wieder löscht.

1

string svgFile Path.GetTempPath() + "item.svg";

2

3

foreach(var article in stock.articles)

4

{

5

    article.ExportAsImage(svgFile);

6

    page.AddPicture(svgFile);

7

    unlink(svgFile);

8

}

mmm schrieb:
> Wenn Windows da wirlich exzessiv die Platte verwendet, würde ich
> versuchen, ob sich das Verhalten ändert, wenn man die Datei gleich
> wieder löscht.

hört doch bitte mal auf - das ist doch alles nur noch Unfug was hier an 
den Post gehängt wird

Axel R. schrieb:
> 1992-94 [..] Da war so ne 4MByte-RAMDISK Goldwert.

Da musste man aber erst einmal 4 MB RAM frei haben, oder überhaupt 4 MB 
RAM haben :)

Wie ich oben geschrieben habe, versuch mal, ob deren API named pipes 
schlucken.
Die sind die Windows Lösung für solche IPC Aufgaben.
Das ist quasi eine virtuelle Datei, allerdings nicht einem eigenen 
Namensraum, nicht innerhalb der üblichen Laufwerksstruktur.
Darf man Fragen welche zwei Programme du steuerst?
Gibt's eventuell ne Doku zur COM Schnittstelle? Oder wenigstens die 
Deklaration der Funktionen ExportAsImage und AddPicture?

Vielleicht schlucken die ja noch andere Typen als Argument Pfad, z. B. 
sowas wie ein streamIO Objekt oder Ähnliches.

Mark B. schrieb:
> Jetzt wäre noch die Frage, ob man irgendwie geschickt solche Symlinks
> automatisiert erzeugen kann, mit Hilfe eines Installers.

Dazu gibt es den mklink Befehl und die Funktion CreateSymbolicLinkA() in 
der Windows API (winbase.h).

Stefan ⛄ F. schrieb:
> Wenn du unter Linux Dateien speicherst und kurz danach wieder lädst,
> werden sie automatisch im RAM gepuffert. Ist das bei Windows etwa
> anders?

Du hast recht, daran habe ich gar nicht gedacht.
Eine Analyse mit einigen 1000 Dateien bestätigt deine Vermutung.
Das Problem ist der SVG Export, der nur einen Kern nutzt.
Andere Formate gehen schneller, haben aber andere Nachteile.

Danke an alle!

Thomas_jhfd schrieb:
> Du hast recht, daran habe ich gar nicht gedacht.
> Eine Analyse mit einigen 1000 Dateien bestätigt deine Vermutung.
> Das Problem ist der SVG Export, der nur einen Kern nutzt.

Ich weiß ja nichts über die Inhalte Deiner SVGs, aber vielleicht wäre es 
auch möglich, die Rohdaten zu exportieren und die SVG-Wandlung mit etwas 
anderem zu machen? Gerade wenn die Daten auf so viele Dateien verteilt 
werden, schreit das ja geradezu nach einer Parallelisierung...