Coffeehouse Thread

15 posts

Event Based OS Notifications - A good idea?

Back to Forum: Coffeehouse
  • User profile image
    Stebet

    Here's an idea i 've been thinking about for awhile. What if we could be able to monitor almost every aspect of our OS's operation easily? What i'm thinking about is, what if Windows would have a very rich, easily subscribable event model. Think if we could easily subscribe to many miscellaneous OS level (and User level) events, such as, New Email arrived, a new network socket is opened, a file is opened or created, CPU temperature has changed (by a specified margin), a user logged on to the computer, IIS got a new HTTP request etc. etc.

    I'm thinking Windows could have a directory of events and properties which programs and services could expose their events and status to (similar to Web Service method discoveries). For example when you'd install a junk filtering software on your email server, that software could expose an event to the OS, allowing developers to listen for that event and let the administrator know each time an email is classified as spam etc. This could perhaps be tied in with WMI in some way too, allowing other programs to closely monitor almost any OS and program activity. This would open up a lot of possibilities for all sorts of notifications to the end user, allowing him to more closely monitor his system and it's activities.

    Anyways, this is just an idea i had, and i don't think anything similar already exists, so don't hesitate to bring up any pro's and con's you find thinking about it. All you system System Admins might be more interested in this thatn others?

  • User profile image
    jamie

    so under taskman processes - it would say what everything is and what everything does - not just
    MSPROGRAMWEHOPE.exe

    and if you clicked a "New Tab" that said "Events"
    it would list every system thing thats happening /happened recently ..that would be nice

  • User profile image
    Stebet

    Yes. That's pretty much what i was thinking, but also you'd have access to these events programmatically.

    I actually realized as i thought harder about this that we do already have a part of this to a certain extent, we just have to go through a bit of hassle. For example, you can subscribe to most MSN Messenger events (user signed in, user changed name etc.). It does have to go through COM interop though but it works. I'd like to see it on a much larger scale though.

    This "new tab" in taskman would then show all events that happened recently as you said, as well as what program or service they are associated with.

    And when i think further, shouldn't Indigo be able to provide most of these features through its "two-way" communications, since it allows pretty easy inter-process communications?

  • User profile image
    AndyC

    It'd be a fantastically brilliant idea. System administrators the world over could make amazing use of it. Servers could email you when a service fails, or disk space gets low or some other pending disaster is on the horizon.

    Presuambly that's why it's already there as part of Windows Management Instrumentation - see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/monitoring_events.asp

  • User profile image
    Manip

    Sounds like a lag-fest to me... I mean if for each 'event' the system has to call this event handler you are going to be calling this thing every millisecond with a new event and the system will just grind to a halt.

     

     With the current model only events requested have to be sent to a callback, with this new one all events would have to be sent to all applications so the lag time between the event getting fired an the last application receiving it would be immense and if that application wanted a blocking event hook, well you simply couldn't do that...

     

     

     

  • User profile image
    Stebet

    No.. i'm actually talking about an event system like it exists now in .NET, but which is open to inter-process communications. Of course if an even't isn't monitored, no callbacks are called. I'm not talking about a new event system, i'm rather talking about making lot's and lot's of events available to developers instead of having to mess with COM interops and WMI, all this of course with a pluggable interface to add new events. We can already see some of this in the Microsoft.Win32 namespace where you can subscrive to events such as monitor resolution changes, shutdown etc. What i'm talking about is making a much richer collection of monitorable events.

    For the taskman example, taskman would register itself as an event subscriber as soon as it's started but not all of the time. Besides, i don't think this would the lag fest you think, since similar things are happening all the time right now in the current Windows Messaging system (a bit different but i hope you catch my drift). This would also make a lot of current windows messages unnecessary (although they couldn't be removed for compatibilitys sake).

  • User profile image
    CPrest

    Well its not a bad idea.. but it needs to be a little more segmented.  you must now ask yourself this question.  does this new subscription to "events" model become a service or built into the kernel?

    I would suggest a service, that can be setup in XML format, stored in a location in the windows folder where a user can programmatically create an object that can subscribe to a list of the events currently connected to that service.

    this way you can make custom events, and any application can use this service to expose events within their respective apps.

    its a fun concept, unfortunatly you need time to develop it Sad

  • User profile image
    AndyC

    But this is exactly how the existing WMI mechanism already works. Any app can supply a WMI provider and any app can recieve a callback when any event occurs.

    If you're just suggesting that more event providers should be included, I'd agree wholeheartedly (the single best change from 2000 to XP/2003 was the increase in WMI providers, IMHO)

    If you're suggesting producing another system then I really don't see an advantage.

  • User profile image
    Blkbam

    This is already possible, without the directory though.  It's called Subclassing and Hooking, at least in VS6 it is.  I'm not sure how to accomplish the samething in .Net but I'm sure there is a framework class for it now.

  • User profile image
    Larry​Osterman

    Stebet wrote:
    No.. i'm actually talking about an event system like it exists now in .NET, but which is open to inter-process communications.


    You do know that by default, .Net's events (really C# events) are synchronous?

    I believe you can make them asynchronous, but they're normally synchronous.

  • User profile image
    Stebet

    AndyC wrote:
    But this is exactly how the existing WMI mechanism already works. Any app can supply a WMI provider and any app can recieve a callback when any event occurs.

    If you're just suggesting that more event providers should be included, I'd agree wholeheartedly (the single best change from 2000 to XP/2003 was the increase in WMI providers, IMHO)

    If you're suggesting producing another system then I really don't see an advantage.


    Seems from what you say that WMI does a lot of what i was thinking (or nearly all of it). Wonder why i've never heard of it that way before? I haven't looked at WMI closely, but now i think i should. I have on the other hand read a lot of complaints about it not being developer friendly enough (although i have no experience with it so i'll leave that sentence at the rumor mill until further examination).

    Since i brought up Microsoft.Win32.SystemEvents a little earlier, i thinkit would be nice to see more work put into similar event exposing classes such as Microsoft.Windows.NetworkEvents (new TCP connection established etc.), Microsoft.Windows.StorageEvents (new Directory Created etc.), Microsoft.Office.OutlookEvents (new mail received) etc.

  • User profile image
    ZippyV

    AndyC is right, this is exactly what WMI does and you can use it in .net.
    And the Taskmanager does connect to the WMI thing to see what the processor is doing.
    You can even monitor every request on IIS with WMI, or see how many connections are open with SqlServer or look at the uptime of you computer.

    The best thing of this all is: you can even view this information from remote computers.

  • User profile image
    Stebet

    Seems to me that that pretty much settles it from my end. I'm off to look at WMI now Smiley

    Thanks a lot for the great responses.

    P.S. I still would like more events exposed in the neat way the Microsoft.Win32.SystemEvents are exposed. Hopefully we'll see more of them when more programs and services are ".NETized".

  • User profile image
    AndyC

    WMI is probably Window's best kept secret. I stumbled upon it by accident and have never looked back. Once you've seen what it can do for you, you'll wish you discovered it years ago.

  • User profile image
    Minh

    LarryOsterman wrote:
    You do know that by default, .Net's events (really C# events) are synchronous?

    All right! we can write drivers w/ .NET. I'm all for it.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.