System wide memory-only storage?

[JJ]

Anyone know any system wide memory-only storage? To serve as a media for
communication between scripts.

i.e. can be accessed by any process (shared accross application), and is not
persistent across user login session or system reboot.

Perhaps an unused/inapplicable memory-only setting of a Windows' built-in
process which is always running on every use login session. e.g. the shell
process, service processes, etc.

[R.Wieser]

JJ,

Post by JJ
Anyone know any system wide memory-only storage? To serve as a media
for communication between scripts.

Ha! My chance to return a favour. :-)

You could take a look at

https://docs.microsoft.com/en-us/windows/win32/memory/creating-named-shared-memory

Ofcourse, it would need a small program (an invisible service one ?) to
create and keep it alive. By putting it into the "startup" folder its ready
for use whenever someone logs on.

By the way: have you also thought about using a named pipe ? Might even be
easier to manage (no handshaking).

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
JJ,

Post by JJ
Anyone know any system wide memory-only storage? To serve as a media
for communication between scripts.

Ha! My chance to return a favour. :-)
You could take a look at
https://docs.microsoft.com/en-us/windows/win32/memory/creating-named-shared-memory
Ofcourse, it would need a small program (an invisible service one ?) to
create and keep it alive. By putting it into the "startup" folder its ready
for use whenever someone logs on.
By the way: have you also thought about using a named pipe ? Might even be
easier to manage (no handshaking).
Regards,
Rudy Wieser

Sorry, but I need to use/borrow existing built in Windows applications'
functionality. Not creating a custom application.

[R.Wieser]

JJ,

Post by JJ
Sorry, but I need to use/borrow existing built in Windows
applications' functionality. Not creating a custom application.

Than I think you're out of luck. Although a (vb)script can access a named
pipe or a mailslot* when one exists, it doesn't seem to be able to create
one themselves.

*which nowerdays is normally disabled on ones 'puter.

A question though : why the "memory-only" requirement ? Without it you
could just use one (or two in case of handshaking).

A quick search for IPC returned this one :

https://stackoverflow.com/questions/10943464/inter-process-communication-using-vbscript

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
JJ,

Post by JJ
Sorry, but I need to use/borrow existing built in Windows
applications' functionality. Not creating a custom application.

Than I think you're out of luck. Although a (vb)script can access a named
pipe or a mailslot* when one exists, it doesn't seem to be able to create
one themselves.
*which nowerdays is normally disabled on ones 'puter.
A question though : why the "memory-only" requirement ? Without it you
could just use one (or two in case of handshaking).
https://stackoverflow.com/questions/10943464/inter-process-communication-using-vbscript
Regards,
Rudy Wieser

The main use of the memory-only storage is for a login session bound
setting/data. It's not for realtime communication such as the Named Pipe as
mentioned in that SO.

e.g. a counter for how many times a script has been run, for the current
login session. Kind of like how Windows stores the tick counter, which is
not persistent across system reboot, and always reset at system startup.

Whether it's bound to system or login session, doesn't matter. As long as
it's persistent within a session.

As I've already mentioned, because it's a memory-only storage, it has to
borrow from an already running applications/services. It can't be something
which is created from scratch, or need to manually run another
application/services.

I'm pretty sure there's somewhere in the built in Windows
applications/services which can be used. It's just, it's like finding a
needle in a haystack.

I don't mind using undocumented features, or even some (safe) hacking.

Once, I thought of storing data in a newly created WMI class' property, but
it turns out that it changes the WMI database file. Duh...

[R.Wieser]

JJ,

Post by JJ
e.g. a counter for how many times a script has been run, for the current
login session. Kind of like how Windows stores the tick counter, which is
not persistent across system reboot, and always reset at system startup.

In that regard (making it session bound) I could imagine a small
"erase/create a new statistics file" command/script* in the startup folder
(which you than append to in the scripts). Perhaps not perfect, but
/should/ give you a clean slate every time.

*would even allow you to make some "last X sessions" log-file stack ...

Post by JJ
I'm pretty sure there's somewhere in the built in Windows
applications/services which can be used. It's just, it's like
finding a needle in a haystack.

Isn't that often the case ? All the "fun stuff" only known by a few, who,
more often than not, stumbled over it by those themselves ?


Something just occured to me : If the logfile should really disappear on its
own why not create a ramdisk and put the logfile on it ?

https://www.codeguru.com/windows/ramdisk-version-1-0-for-windows-2000-windows-xp/

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
Something just occured to me : If the logfile should really disappear on its
own why not create a ramdisk and put the logfile on it ?
https://www.codeguru.com/windows/ramdisk-version-1-0-for-windows-2000-windows-xp/

Everything must be applicable on most Windows installations without
requiring additional software or configuration. i.e. use only what's
available.

[R.Wieser]

JJ,

Post by JJ
Everything must be applicable on most Windows installations
without requiring additional software or configuration.

Than I'm going to admit defeat. I do not know of any default enabled
component which would give you what you're after.

Regards,
Rudy Wieser

[JJ]

Post by JJ
Anyone know any system wide memory-only storage? To serve as a media for
communication between scripts.
i.e. can be accessed by any process (shared accross application), and is not
persistent across user login session or system reboot.
Perhaps an unused/inapplicable memory-only setting of a Windows' built-in
process which is always running on every use login session. e.g. the shell
process, service processes, etc.

Again... finally found it.

The trick is to use Windows Explorer's window (via InternetExplorer object).
By opening a new Explorer window not as a separate process (temporarily
changes the Explorer setting as necessary), the window will be created by
the desktop process which is already present.

InternetExplorer interrestingly has a dictionary-like property storage which
is accessible through its `GetProperty()` and `PutProperty()` methods. The
property storage is a memory storage which is bound to or contained in the
InternetExplorer object. So, as long as the window is still open, the
property data stays.

Since the property is COM compatible, it can store values and preseve their
type. Including objects. However, for objects, they can only be valid as
long as the script/process which created the object is not yet terminated.
So, the script/process will act as a COM server, where if the object is a
user defined object, other script/process can access the object and call its
methods. This functionality is an unexpected bonus, since what I want is
just a way to globally share a simple string typed value in a session bound
storage.