IPC UDF via FileMapping (2018.04.04)

[argumentum]

I was in need of an IPC (Interprocess communication) between system, admin and user levels, and ended up writing this UDF to suit my wantings.
Hope you find it useful too.

Works from WinXP/Server2003 to the now current Win10/Server2016.
It communicates between any mix of x32, x64, Admin, User.

In the zip file, there is the UDF and an example: FMIPC(v0.2018.04.04).zip

Special thanks to @RTFC for the help in the support forum   

Edited April 3, 2018 by argumentum
update

[Melba23]

argumentum,

Looks nice, but why do I get 2 copies of the message if I change the content of the input? As I would imagine that is the most likely case, it seems strange.

M23

[argumentum]

in the example, there is a global counter.
The sender notes the message as >>> Counter >>>, then the receiver gets the <<< Counter <<<, that way you can see that the counter is the same in both, sender and receiver.

There is also a "Rounds" counter, so when you send, send X times, one right after the other, to test the semaphore and timeouts, therefore the 1 of 1 or 1 of x.

There is a Turn around: x ms. in one, the sender, to see the time it took to send and return from the function.

In the example you can:
- Change the $g__FMIPC_Size of the message. The message is upto half the size of the memory file created.
- Change the $g__FMIPC_Timeout of the message. ( A $var can be created by the scriptor, to use as a buffer, to retry later, via Adlib or what not, if there was an error sending, but all that would be the in the creativity of the scriptor/user, based in his/her code needs/ability/imagination/circumstances )
- Change how many times it will send in "rapid fire", by the $iRounds of the For Loop, to stress test the environment

Even tho, the script fires up the 2 other instances that do the testing, one can, run each independently with the command line of "one" or "another", to run it as different user levels and test that too. Much of the code will look like the help file's own example, as all this is taken and rearranged from the help file.

And thanks for asking, I was tired and did not include this, hopefully clarifying explanation.

And to anyone reading this, if you find a flaw or improvement, do share.

If there is need for support, please post it on [Solved] IPC between system and user's topic or general support forum    

[argumentum]

1 hour ago, Melba23 said:

Looks nice, but why do I get 2 copies of the message

lol, I was tired, I saw it just now, I'll fix the example today. Thanks  

PS: I'm still tired 

Edited April 1, 2018 by argumentum

[argumentum]

Thanks @Melba23, there was more than the example that needed attention.

In this version (v0.2108.04.02)

1) Added an error if trying  to send more than the declared size.
2) Nicer demo too.   

Edited April 1, 2018 by argumentum

[argumentum]

In this version (v0.2108.04.03)

Added a parameter to _FMIPC_Write(), to not wait until the message is flagged as read. ( I needed that feature. Default is to wait )
Removed the code from the 1st post. ( is easier to download the file and run, than copy paste all that )

[Melba23]

argumentum,

I have been playing with this UDF over the past few days - very nice indeed. I may have to change my "MailSlot" recommendation when asked about IPC in future.

One point - you set the UDF size and timeout variables within the example by direct assignments to the UDF global variables. It would be much better to have a small function within the UDF which could be called from the example to change these values when required - it is very poor coding practice to expose internal UDF variables to the user in this way.

M23

[argumentum]

2 minutes ago, Melba23 said:

 it is very poor coding practice to expose internal UDF variables to the user in this way.

noted. I'll have it tonight    

[Melba23]

argumentum,

And you might want to put the _FMIPC_Write_ErrStr function in the UDF as well - it is better placed there than in the example itself.

Sorry to be picky, but it is worth getting a UDF as useful as this into as good a shape as possible.

M23

[argumentum]

1 minute ago, Melba23 said:

Sorry to be picky, but it is worth getting a UDF as useful as this into as good a shape as possible

I agree, and thank you very much for testing and debugging AND showing me a proper way   

[argumentum]

In this version (v0.2108.04.04)

  FuncName_ErrStr() are more and in the UDF itself.
  added _FMIPC_SetTimeout()
  added _FMIPC_SetSize()**
  changed _FMIPC_Create(). Without a parameter, will now use, StringTrimRight(@ScriptName, 4) & String(@AutoItPID), as the name.
  as such, a unique name is assigned by default, that can be easily discovered via ProcessList().

**_FMIPC_SetSize(), for now, can only be used before _FMIPC_Create(), due to a hiccup in _FMIPC_Close() that crashes the process, when the process stays running.
Hope to get to fix the bug soon, as I really want to have the functionality, but I don't have the time to investigate deeper and fix it right now, due to work   
Any and everyone, is encouraged to look at it and fix it. I'll patch and update ASAP.

So this is an interim release until properly fixed. 

Edited April 3, 2018 by argumentum

[Conitental]

On 4/1/2018 at 5:56 AM, argumentum said:

I was in need of an IPC (Interprocess communication) between system, admin and user levels, and ended up writing this UDF to suit my wantings.

Hi argumentum,

(Sorry to dig out a year old thread)

I too was in need of an IPC to communicate bi-directional from system account to some user applications.

Have you really managed to get the user side to communicate with the system file map? (meaning sending anything from user --> system) This has always been the part I never got to work with your UDF or most of the other ways I found looking for a solution (including mailslots and other IPC UDF's).

I eventually ended up using tcp sockets and it worked on first attempt.

So actually my search has been ended. Just curious if you found a way to do this with your UDF's (Great work by the way 😉 )

 

[argumentum]

4 hours ago, Conitental said:

I eventually ended up using tcp sockets and it worked on first attempt.

That is what I do myself most times. I never continued this code, that is more of a recompilation of code laying around than a personal brainstorm.

4 hours ago, Conitental said:

Just curious if you found a way to do this with your UDF's

The your UDF merits a clarification. The way I see it, everyone is welcome, and I encourage, the testing and bettering of code, any and all code.
I dislike the notion of intellectual property. The history of the code would be important for following the development, so mention of the collaborators in chronological order and their contribution carries this importance. Other than that, is our code  

5 hours ago, Conitental said:

Have you really managed to get the user side to communicate with the system

Back then, when I tested, I thought I did. But to be fair, I don't remember much. I thought the code was good enough to share under the claim. I'd have to go back to it, and look at it again. And I will ( pinky swear ) to look at it at a future time, when I can devote some time to it  

5 hours ago, Conitental said:

Sorry to dig out a year old thread

Actually, thank you for bringing up, this having an issue no one was aware of, and posting about it.

[argumentum]

On 4/25/2019 at 6:10 AM, Conitental said:

Have you really managed to get the user side to communicate with the system file map? (meaning sending anything from user --> system)

Now am the one digging an old thread. Worst of all to someone missing since 2019. But is to say that I've tested with "Elevate Your Script to the SYSTEM Account" code and run as SYSTEM and user without any issue.
Posting for anyone visiting this thread, not leave with the idea that it did not work as advertised ( system, admin, user / x32, x64 )