Re: Shell, executes but no GUI is displayed .NET 2.0?
- From: William Sullivan <WilliamSullivan@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 7 Jul 2006 12:44:01 -0700
Maybe you should port your program to Linux? Good luck rtfm'ing.
"Rob R. Ainscough" wrote:
So your suggesting I read up and learn remoting for the next several days.
for what amounts to be a very basic GUI that basically permits the user to
Enable/Disable and Turn notifications on/off and view the progress of the
downloads/installs? I would find it unlikely that Vista will not permit
existing services that interact with the desktop to not work come the final
build -- a quick check for Services that interact with my desktop comes up
with a count of 12 (Symatec, hardware support services, and a few others) --
so M$ will have to come up with some solution.
I would disagree that "I'm opening a security hole" -- the hole exists due
to the poor implementation of the OS -- security isn't something that should
get in the way of a valid process installed by a user. MS can try to pass
the buck, but it ultimately stops on their door step in terms of public
perception -- when you hear about the next virus on the news, you don't hear
about the developer or IT person that "opened hole", no, you hear
"Microsoft". So Microsoft can continue to blindly point fingers, but it
doesn't change the public perception and fear of M$ operating systems and
viruses. The folks at Redmond either need to come up with a better plan or
seal their static fate with flat revenue and declining stock value.
Remoting -- yet another "new and improved approach to be obsolete within the
next 6 months as it's deemed unsecure, slow, buggy, etc. etc."
Rob.
"Greg Young" <druckdruckREMOVEgoose@xxxxxxxxxxx> wrote in message
news:OhYdxuaoGHA.4816@xxxxxxxxxxxxxxxxxxxxxxx
And you may open a security hole
...http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true
I believe this functionality has also been removed in vista so your
service would not work there.Your service will only be able to interact
with a different desktop (not the one the user is on). MS has said for a
long time that this was a bad way of doing things.
The general way of doing this is to have a back end service and a front
end client app that talks to the back end service through a mechanism such
as remoting. The service then tells the client app to show something to
the user this way the client app runs in the same security context as the
user (as opposed to a service running under a higher priv level).
Cheers,
Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung
"Rob R. Ainscough" <robains@xxxxxxxxxxx> wrote in message
news:uYFAfcZoGHA.4816@xxxxxxxxxxxxxxxxxxxxxxx
Brendan,
It is an Automatic Update Service that I've created to update several of
my applications of client PCs. The service does some checking, downloads
updates, and if the user has enabled the interface it will shell the
application (GUI) that will interface with the user. To be clear, this
is a shelled process that shouldn't care what the source of the shell
was, but apparently a Windows Service seems to prevent any shell process
from have any interface/window.
This needs to be a service because making the app part of the Startup is
too easy for my clients/users to remove it. "What this, I don't know,
lets delete it" is all too common with my user base, services are a tad
more hidden and most of my users don't even know what they are nor how to
even identify them.
I believe Microsoft use the same approach? If not, I'd certainly
appreciate some insight on what the best approach is for this situation?
Regardless, thank you!! Your solution resolved it! I've spent all day
working on this and it didn't occur to me that a shelled process would be
restricted by the same rules that govern a service (IMHO they process
should be separate entity unto itself) -- I have coded services before
and know how to set the interact with desktop via the ServiceController
in the project installer -- I will do that
Thanks, Rob.
"Brendan Green" <bgreen@xxxxxxxxxxxxx> wrote in message
news:%236MwbdYoGHA.220@xxxxxxxxxxxxxxxxxxxxxxx
It's not a flaw, and it has nothing to do with .NET.
Why are you trying to run a GUI application from a service? You can
probably get this to work by allowing the service to "interact with the
desktop" (check the properties of the service).
"Rob R. Ainscough" <robains@xxxxxxxxxxx> wrote in message
news:OrFdRDYoGHA.4104@xxxxxxxxxxxxxxxxxxxxxxx
Situation:
.NET 2.0 based Windows Service
Have a timer event in the service
Private WithEvents ServiceTimer As New System.Timers.Timer(30000)
Private Sub Check_Updates(ByVal sender As Object, _
ByVal e As System.Timers.ElapsedEventArgs)
Handles ServiceTimer.Elapsed
Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE",
AppWinStyle.MaximizedFocus, True, -1)
End Sub
Start the service, no errors are triggered and in 30 seconds
NOTEPAD.EXE appears in Task Manager Processes tab but not in
Applications tab and there is NOTHING displayed on my screen anywhere.
I've tried using Diagnostic.Process approach also, same results. Also
tried waitonexit, timeout values, and nothing will permit my shelled
process (NOTEPAD) to show it's interface yet it appears as a running
process in Task Manager?
Any suggestion as to this pretty serious flaw in .NET 2.0? Someone
care to duplicate this and confirm my results?
Rob
- References:
- Shell, executes but no GUI is displayed .NET 2.0?
- From: Rob R. Ainscough
- Re: Shell, executes but no GUI is displayed .NET 2.0?
- From: Brendan Green
- Re: Shell, executes but no GUI is displayed .NET 2.0?
- From: Rob R. Ainscough
- Re: Shell, executes but no GUI is displayed .NET 2.0?
- From: Greg Young
- Re: Shell, executes but no GUI is displayed .NET 2.0?
- From: Rob R. Ainscough
- Shell, executes but no GUI is displayed .NET 2.0?
- Prev by Date: Finding disk space on UNC drive
- Next by Date: Re: Windows authentication over remoting... possible?
- Previous by thread: Re: Shell, executes but no GUI is displayed .NET 2.0?
- Next by thread: Re: Shell, executes but no GUI is displayed .NET 2.0?
- Index(es):
Relevant Pages
|