Is it possible to create a custom global WMI event?

[JJ]

I want to create a WMI event that can be used for anything and not just the
XXXAsync() methods of the SWbemServices object. For example, for signalling
the completion of non WMI related tasks where other VBScript code in other
W/CSCRIPT.EXE processes can wait for the event. Something like SWbemSink but
works across different process.

Is this possible?

Currently, I'm using the presence of a file as the event but I'm hoping to
use something that doesn't write to disk.

[R.Wieser]

JJ,

Post by JJ
I want to create a WMI event

...

Post by JJ
Is this possible?

Looks to be:

https://technet.microsoft.com/en-us/library/hh849954.aspx

Post by JJ
Currently, I'm using the presence of a file as the event but
I'm hoping to use something that doesn't write to disk.

Well, in that case a WMI event looks to be the proverbial cannon to shoot a
fly. :-)

My suggestion would be use the much simpler Event object

https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms682396(v=vs.85).a
spx ). If you want a "sender side only" solution, you could use a named
pipe -- which can be, IIRC, opened at the receiving side as a simple,
blocking "file".

regards,
Rudy Wieser

Post by JJ
I want to create a WMI event that can be used for anything and not just the
XXXAsync() methods of the SWbemServices object. For example, for signalling
the completion of non WMI related tasks where other VBScript code in other
W/CSCRIPT.EXE processes can wait for the event. Something like SWbemSink but
works across different process.
Is this possible?
Currently, I'm using the presence of a file as the event but I'm hoping to
use something that doesn't write to disk.

[JJ]

Post by R.Wieser
https://technet.microsoft.com/en-us/library/hh849954.aspx

Post by JJ
Currently, I'm using the presence of a file as the event but
I'm hoping to use something that doesn't write to disk.

Well, in that case a WMI event looks to be the proverbial cannon to shoot a
fly. :-)
My suggestion would be use the much simpler Event object
https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms682396(v=vs.85).a
spx ). If you want a "sender side only" solution, you could use a named
pipe -- which can be, IIRC, opened at the receiving side as a simple,
blocking "file".

For me, PowerShell is no different due to .NET.

I'm trying to use only resources that are available in every Windows
installations (with minimum version requirement), so that the script would
be guaranteed to work on those systems.

But you have a good idea, though. A tiny custom program that provides event
capability for both VBScripts and batch files would be very useful indeed.

[R.Wieser]

JJ,

Post by JJ
For me, PowerShell is no different due to .NET.

It wasn't my intention to refer to either.

Post by JJ
I'm trying to use only resources that are available in every
Windows installations (with minimum version requirement)

Same here.

Post by JJ
But you have a good idea, though. A tiny custom program
that provides event capability for both VBScripts and batch
files would be very useful indeed.

As you posted in VBScript my thought was you could create an COM/OCX
component. But yes, making it a stand-alone program would make it broader
in its application.

On the other hand, it could cause a same kind of problem as using a lock
file: if the parent program dies before closing the external program holding
the signal you are left with a (session bound) permanent lock that will
disallow further usage of the parent program -- though a reboot (or logging
out and in again) will solve that, which is better than when using a lock
file.

... though the parent program could, on startup, possibly clean up any
outstanding lock file, mitigating that problem.

In other words, I myself would most likely go for a method more tightly
bound to the script itself, and (thus) terminating when the script ends --
regardless of if that happens by cleanly ending, or by throwing an error.

Regards,
Rudy Wieser

Post by JJ

Post by R.Wieser
https://technet.microsoft.com/en-us/library/hh849954.aspx

Post by JJ
Currently, I'm using the presence of a file as the event but
I'm hoping to use something that doesn't write to disk.

Well, in that case a WMI event looks to be the proverbial cannon to shoot a
fly. :-)
My suggestion would be use the much simpler Event object

https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms682396(v=vs.85).a

Post by JJ

Post by R.Wieser
spx ). If you want a "sender side only" solution, you could use a named
pipe -- which can be, IIRC, opened at the receiving side as a simple,
blocking "file".

For me, PowerShell is no different due to .NET.
I'm trying to use only resources that are available in every Windows
installations (with minimum version requirement), so that the script would
be guaranteed to work on those systems.
But you have a good idea, though. A tiny custom program that provides event
capability for both VBScripts and batch files would be very useful indeed.

[JJ]

Post by R.Wieser
On the other hand, it could cause a same kind of problem as using a lock
file: if the parent program dies before closing the external program holding
the signal you are left with a (session bound) permanent lock that will
disallow further usage of the parent program -- though a reboot (or logging
out and in again) will solve that, which is better than when using a lock
file.

Yes, that's one of the problems when using a file based event. Which is why
I'm wondering if it's possible to use the real event from WMI.

Post by R.Wieser
In other words, I myself would most likely go for a method more tightly
bound to the script itself, and (thus) terminating when the script ends --
regardless of if that happens by cleanly ending, or by throwing an error.

Do you have any idea?

I've also considered using TASKLIST.EXE, but it doesn't provide any field
that can be used as a binder to the script.

[R.Wieser]

JJ,

Post by JJ
Yes, that's one of the problems when using a file based event. Which
is why I'm wondering if it's possible to use the real event from WMI.

...

Post by JJ
Do you have any idea?

Well, that is what I tried to explain in my previous post: when a VB
script -- and the engine that runs it -- terminates *for whatever reason*
(other than hard power-down ofcourse) it will also releases all its loaded
COM/OCX objects. And because of that you can, when your own object is
released, tell it to terminate the signalling it has set up. And thats not
something you can do when using a stand-alone program or a file.

In other words: such a COM/OCX object is pretty-much the tightest binding
you have with your script. Combine it with the earlier mentioned Event
object or a named pipe and you're good to go.

Hmmm .... Another method just popped into my mind: you could also take a
peek at broadcasting a system-wide message:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644932(v=vs.85).a
spx This one can be put in a stand-alone program. Downside: The receiving
end needs to have a (hidden) window to be able to receive it.

Shucks, I just realized: if you have the "winsock" object already installed
you could use that to create a port on localhost which the second app than
can listen to.

Hope that helps,

Regards,
Rudy Wieser

Post by JJ

Post by R.Wieser
On the other hand, it could cause a same kind of problem as using a lock
file: if the parent program dies before closing the external program holding
the signal you are left with a (session bound) permanent lock that will
disallow further usage of the parent program -- though a reboot (or logging
out and in again) will solve that, which is better than when using a lock
file.

Yes, that's one of the problems when using a file based event. Which is why
I'm wondering if it's possible to use the real event from WMI.

Post by R.Wieser
In other words, I myself would most likely go for a method more tightly
bound to the script itself, and (thus) terminating when the script ends --
regardless of if that happens by cleanly ending, or by throwing an error.

Do you have any idea?
I've also considered using TASKLIST.EXE, but it doesn't provide any field
that can be used as a binder to the script.

[JJ]

Post by R.Wieser
Well, that is what I tried to explain in my previous post: when a VB
script -- and the engine that runs it -- terminates *for whatever reason*
(other than hard power-down ofcourse) it will also releases all its loaded
COM/OCX objects. And because of that you can, when your own object is
released, tell it to terminate the signalling it has set up. And thats not
something you can do when using a stand-alone program or a file.
In other words: such a COM/OCX object is pretty-much the tightest binding
you have with your script. Combine it with the earlier mentioned Event
object or a named pipe and you're good to go.
Hmmm .... Another method just popped into my mind: you could also take a
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644932(v=vs.85).a
spx This one can be put in a stand-alone program. Downside: The receiving
end needs to have a (hidden) window to be able to receive it.
Shucks, I just realized: if you have the "winsock" object already installed
you could use that to create a port on localhost which the second app than
can listen to.
Hope that helps,

I am so sorry that I've made a mistake. I've misunderstood you earlier and
have made you made time to write long replies.

I also forgot to mention that I need my scripts to work on all Windows
installations (at least Windows XP; i.e. WinXP and newer; with/without
service packs). So, I need to use only the resources that are already
available in the system. Using third party or custom programs is one of my
considerations, but it's currently as a last resort only - since file based
event is still enough to do the job albeit dirty.

[Mayayana]

"JJ" wrote:

| I also forgot to mention that I need my scripts to work on all Windows
| installations (at least Windows XP; i.e. WinXP and newer; with/without
| service packs).

It's an interesting issue. You never explained what you're
trying to do, so it's hard to think about solutions. I've used
IE windows before, tracking changes in things like status text.
But then IE changes with every version, so that can be tricky.

I've also used Ax EXEs, but of course that doesn't fit your
requirement of no extras. Even if it did, VBScript getting events
is awkward. WScript.CreateObject allows for specifying an
object for event subs, but the script still has to loop in paralysis
while it waits for that event. So I've only used that method
where I absolutely have to, such as with an emailing component
where I need to wait for the server's final "goodbye" before
ending. So it's hard to see any advantage to WMI. You'd still
be stuck with a looping script, even if you can get an event
using WScript.CreateObject. And while WMI is well supported,
it's not guaranteed. I would have the service disabled if I
didn't use it myself. It's not of much use to the average person,
except as the basis of hardware reporting utilities.

For something shared across scripts it's hard to imagine
anything better than a file used as flag. But I'd be interested
if you find something better. :)

[R.Wieser]

JJ,

Post by JJ
I am so sorry that I've made a mistake. I've misunderstood
you earlier and have made you made time to write long replies.

No problem, that sometimes happens. And I'm not free from blame either, as
I, even though you already mentioned it should work on every windows
installation, thought you where able to add your own executable to it (the
program that, I thought, would than recieve the by you mentioned WMI event)

In that case I think you're pretty-much out of luck with VBScript though
(other than the basic "using a file" signalling)...

Regards,
Rudy Wieser

Post by JJ

Post by R.Wieser
Well, that is what I tried to explain in my previous post: when a VB
script -- and the engine that runs it -- terminates *for whatever reason*
(other than hard power-down ofcourse) it will also releases all its loaded
COM/OCX objects. And because of that you can, when your own object is
released, tell it to terminate the signalling it has set up. And thats not
something you can do when using a stand-alone program or a file.
In other words: such a COM/OCX object is pretty-much the tightest binding
you have with your script. Combine it with the earlier mentioned Event
object or a named pipe and you're good to go.
Hmmm .... Another method just popped into my mind: you could also take a

https://msdn.microsoft.com/en-us/library/windows/desktop/ms644932(v=vs.85).a

Post by JJ

Post by R.Wieser
spx This one can be put in a stand-alone program. Downside: The receiving
end needs to have a (hidden) window to be able to receive it.
Shucks, I just realized: if you have the "winsock" object already installed
you could use that to create a port on localhost which the second app than
can listen to.
Hope that helps,

I am so sorry that I've made a mistake. I've misunderstood you earlier and
have made you made time to write long replies.
I also forgot to mention that I need my scripts to work on all Windows
installations (at least Windows XP; i.e. WinXP and newer; with/without
service packs). So, I need to use only the resources that are already
available in the system. Using third party or custom programs is one of my
considerations, but it's currently as a last resort only - since file based
event is still enough to do the job albeit dirty.