The "most elegant" method of instance communication. RRS feed

  • Question

  • I've written a variety of "behind the scenes" applications (and none of them viral), most of which work in most legacy and most current versions of Windows.  The problem child is 7, the applications run (as they're installed correctly using Admin priveldges in the installer), they run just fine, with one minor issue, which I'm trying to decide how to resolve, since I've been using this method for many many years.

    The application is hidden from the user (usually "acts" like a server, but does something nice in the background), it's usually doing drudge work (like removing resource fork leftovers from NTSC partitions shared by Mac users when the data fork is removed).  Most of these programs either have a "status" or some small gui's built into them.

    What I've normally been doing was finding the previous instance, then finding it's "service" window and "bumping" it with a SendMessageTimeout, which as of Windows 7, is a security issue unless the Admin does it.  I'm alright with this, but without having to resort to bumping the priviledge up to Admin level to just to talk to the already running application, I thought I'd ask here if anyone has Legacy to beyond "safe" way to tell another instance of the application "I've been run again, please respond, I'm leaving, you deal with it."

    All of the ideas I've had, are either overly complex or can be blocked again by even more system security, like a TCP port, firewall can stop it and then there are others I was thinking of, all of which at one point were either too "far out there" that I guess I've over analyzed the situation.  So I'm asking for an elegant and safe OS version method of telling the active application to tell the current previous instance to deal with the user running it again.  I'm not sure I want to monitor the amount of times the application is running unless it can be monitored safely without "false alarms".


    Sunday, January 2, 2011 1:44 AM

All replies

  • Please do look WCF technology.
    Sunday, January 2, 2011 1:23 PM
  • Please do diagonse the problem very thoroughly, please do analyse the problem in depth. It helps every one understanding the technical issues in details.


    Sunday, January 2, 2011 1:28 PM
  • I am looking for a Legacy to Current (and beyond) method that will work across various Windows platforms from old to new.  Some may say that developing for old is unwarranted these days, but older versions of Windows are like masses of audiences, it's never wise to discriminate.


    WFC is .Net 3 and isn't available on Legacy Windows.

    Sunday, January 2, 2011 1:49 PM
  • I'm not sure what you have control over, can your app launch these other apps, i.e. act like shell?

    Saturday, January 22, 2011 9:12 PM
  • The apps usually run as a "service" (doing something in the background), but what I want to do is to actually require some kind of admin to connect to them, but in an attempt to not require two apps (since those can be hijacked), the application when it first runs (as the background "service") runs without admin permissions (and I want to keep it that way), but under Windows .. to 7 I want to make sure the app cannot be run again unless it has admin permissions (which I can safely test up and to 2003, but under Vista and 7 the UAC won't allow the application to ask for admin rights without re-running or a stub to connect to it, which is hijackable).  At least I've not found any resources to re-run the exact same application asking for the UAC to grant admin permissions to the same application.  All the ones I've seen so far ask for the user/password of the account you want to run (which I cannot actually give, since that too is a security risk).

    The reason I need the UAC to step in is the communication to the actual background app is blocked by the UAC unless you allow admin permissions (a security feature I don't mind having in place actually).  If there is a way to possibly run a shortcut to an app with a separate manifest that requests admin elevation, that would seriously work in my favor.


    Sunday, January 23, 2011 4:24 AM
  • Sounds like you can change the applications so the solutions I would consider are;

    TCP port/wcf - firewall problems or host in web server, probably not able to do that

    Process explorer - look up how sysinternals wrote process explorer and at worst each application could spin up a well known thread/sub process you could kill off - feels a bit over the top

    Command file - a solution I used on win3.1 clients was to a well known file location. The controller changes commands for each application. Each application polls the file for an instruction. Ok it's not hitech and not great if need to avoid polling but it should work


    Sunday, January 23, 2011 7:54 AM
  • I was tempted to use the file last modified to determine if the file had changed and react on the file, the downside with that is, the file could get hijacked by another process meaning to cause grief or mischief. As for the process explorer, you can't terminate a process in the UAC without admin permissions, which I can understand as being a security issue.


    Sunday, January 23, 2011 2:03 PM
  • Just restrict permissions to the file for you app?
    Sunday, January 23, 2011 9:52 PM
  • The idea is this:

    Admin permissions to change settings, but, with Vista and Windows 7, the UAC denies sending the response information to the program directly unless the actual program has been run with permissions prior (right click, Run as Administrator).  This is the situation I'm trying to get past, how to keep the program as 1 program, no stub, no file, nothing that can be hijacked, but still offer the same operation and functionality under all the versions of Windows (including Vista and beyond).


    Monday, January 24, 2011 2:41 AM
  • I think you'll need to compromise somewhere. You can't have an application directly poke another app, you can't have any firewall restrictions, you can't use files, you can't ask for elevated permissions...I don't think it can be done. Something needs to give. I would guess the best thing to do would be to only run your program with Admin Permission. Be that by simply failing to start w/o perms (i.e. shortcut with runAsAdmin) or assiging a dedicated admin user to running it on start-up. Vista may still prompt though, Win7 is a little more sensibly placed with prompting for UAC.
    Wednesday, January 26, 2011 9:24 AM