getting a VB service's dependencies on the interactive desktop

[Michael Shutt]

I have the following components in development:

- A service application written in VB using the NTSVC.ocx from MSDN
- A multi-threaded ActiveX exe that contains a CProcessingThread class
(marked as thread per object)

When the service starts up, it creates one or more instances in the
CProcessingThread class, each one running in its own thread in the ActiveX
EXE's process space.

The ActiveX EXE server uses some third party components that occasionally
popup message boxes (I can't seem to reliably suppress them). So, in order
to know when a message box has popped up and blocked one of the processing
threads, I configured the service application to run as the system account
and allow it to interact with the desktop. The service applicaton does show
up on the desktop (windows station = WinSta0, desktop = Default). The
problem is that this still doesn't get the ActiveX Exe onto the interactive
desktop. Instead, the ActiveX EXE's process gets placed in the service
windows station (Service-0x0-3e7$), which means its threads can't be
switched to the interactive desktop.

So, I figured that on startup of each thread, I would just change the
ActiveX Exe's threads to the interactive desktop through calls to
SetThreadDesktop. This means (I assumed) that in the first thread, I would
have to change the process' window station with a call to
SetProcessWindowStation. I quickly found out that I get access denied when
calling OpenWorkstation to open the WinSta0 window station from the ActiveX
EXE.

I am guessing that this is because of the way VB implements an ActiveX EXE.
According to the documentation for the windows stations and desktop API, I
can't switch a thread's desktop *after* any windows or hooks have been
created in the thread. I know tbat VB creates some additional threads and
I'm pretty sure that VB creates some "extra" windows in the ActiveX EXE's
process (not forms in my project), which means I am SOL with this approach.

The only other avenue I could think of is to somehow start the ActiveX EXE's
process in the interactive desktop before I create any objects from it. I
found out that I can specify the process windowstation and desktop in the
STARTUPINFO structure for CreateProcess. It appears that I can successfully
create launch the ActiveX EXE in a process which uses the interactive
desktop. However, when I create objects against the ActiveX EXE, a new
process is started (rather than the objects being created in the existing
process). That new process can't access the interactive desktop.

Anyone have other ideas outside of building this in C++?

[Karl Blacquiere]

Hi, did you find any solution ?
I have the same problem here.
If you have a hint, please email me back

Tank you


"Michael Shutt" <mshutt@mediaone.net> wrote:
>I have the following components in development:
>
>- A service application written in VB using the NTSVC.ocx from MSDN
>- A multi-threaded ActiveX exe that contains a CProcessingThread class
>(marked as thread per object)
>
>When the service starts up, it creates one or more instances in the
>CProcessingThread class, each one running in its own thread in the ActiveX
>EXE's process space.
>
>The ActiveX EXE server uses some third party components that occasionally
>popup message boxes (I can't seem to reliably suppress them). So, in order
>to know when a message box has popped up and blocked one of the processing
>threads, I configured the service application to run as the system account
>and allow it to interact with the desktop. The service applicaton does
show
>up on the desktop (windows station = WinSta0, desktop = Default). The
>problem is that this still doesn't get the ActiveX Exe onto the interactive
>desktop. Instead, the ActiveX EXE's process gets placed in the service
>windows station (Service-0x0-3e7$), which means its threads can't be
>switched to the interactive desktop.
>
>So, I figured that on startup of each thread, I would just change the
>ActiveX Exe's threads to the interactive desktop through calls to
>SetThreadDesktop. This means (I assumed) that in the first thread, I would
>have to change the process' window station with a call to
>SetProcessWindowStation. I quickly found out that I get access denied when
>calling OpenWorkstation to open the WinSta0 window station from the ActiveX
>EXE.
>
>I am guessing that this is because of the way VB implements an ActiveX EXE.
>According to the documentation for the windows stations and desktop API,
I
>can't switch a thread's desktop *after* any windows or hooks have been
>created in the thread. I know tbat VB creates some additional threads and
>I'm pretty sure that VB creates some "extra" windows in the ActiveX EXE's
>process (not forms in my project), which means I am SOL with this approach.
>
>The only other avenue I could think of is to somehow start the ActiveX EXE's
>process in the interactive desktop before I create any objects from it.
I
>found out that I can specify the process windowstation and desktop in the
>STARTUPINFO structure for CreateProcess. It appears that I can successfully
>create launch the ActiveX EXE in a process which uses the interactive
>desktop. However, when I create objects against the ActiveX EXE, a new
>process is started (rather than the objects being created in the existing
>process). That new process can't access the interactive desktop.
>
>Anyone have other ideas outside of building this in C++?
>
>
>
>
>

[Karl Blacquiere]

Hi, did you find any solution ?
I have the same problem here.
If you have a hint, please email me back

Tank you


"Michael Shutt" <mshutt@mediaone.net> wrote:
>I have the following components in development:
>
>- A service application written in VB using the NTSVC.ocx from MSDN
>- A multi-threaded ActiveX exe that contains a CProcessingThread class
>(marked as thread per object)
>
>When the service starts up, it creates one or more instances in the
>CProcessingThread class, each one running in its own thread in the ActiveX
>EXE's process space.
>
>The ActiveX EXE server uses some third party components that occasionally
>popup message boxes (I can't seem to reliably suppress them). So, in order
>to know when a message box has popped up and blocked one of the processing
>threads, I configured the service application to run as the system account
>and allow it to interact with the desktop. The service applicaton does
show
>up on the desktop (windows station = WinSta0, desktop = Default). The
>problem is that this still doesn't get the ActiveX Exe onto the interactive
>desktop. Instead, the ActiveX EXE's process gets placed in the service
>windows station (Service-0x0-3e7$), which means its threads can't be
>switched to the interactive desktop.
>
>So, I figured that on startup of each thread, I would just change the
>ActiveX Exe's threads to the interactive desktop through calls to
>SetThreadDesktop. This means (I assumed) that in the first thread, I would
>have to change the process' window station with a call to
>SetProcessWindowStation. I quickly found out that I get access denied when
>calling OpenWorkstation to open the WinSta0 window station from the ActiveX
>EXE.
>
>I am guessing that this is because of the way VB implements an ActiveX EXE.
>According to the documentation for the windows stations and desktop API,
I
>can't switch a thread's desktop *after* any windows or hooks have been
>created in the thread. I know tbat VB creates some additional threads and
>I'm pretty sure that VB creates some "extra" windows in the ActiveX EXE's
>process (not forms in my project), which means I am SOL with this approach.
>
>The only other avenue I could think of is to somehow start the ActiveX EXE's
>process in the interactive desktop before I create any objects from it.
I
>found out that I can specify the process windowstation and desktop in the
>STARTUPINFO structure for CreateProcess. It appears that I can successfully
>create launch the ActiveX EXE in a process which uses the interactive
>desktop. However, when I create objects against the ActiveX EXE, a new
>process is started (rather than the objects being created in the existing
>process). That new process can't access the interactive desktop.
>
>Anyone have other ideas outside of building this in C++?
>
>
>
>
>

[Michael Shutt]

Nope. I had to rewrite the service in C++.

--
Michael Shutt

Please respond to newsgroup as I will not return direct emails.

"Karl Blacquiere" <blacquiere.karl@hydro.qc.ca> wrote in message
news:3ba11ff8$1@news.devx.com...
>
> Hi, did you find any solution ?
> I have the same problem here.
> If you have a hint, please email me back
>
> Tank you
>
>
> "Michael Shutt" <mshutt@mediaone.net> wrote:
> >I have the following components in development:
> >
> >- A service application written in VB using the NTSVC.ocx from MSDN
> >- A multi-threaded ActiveX exe that contains a CProcessingThread class
> >(marked as thread per object)
> >
> >When the service starts up, it creates one or more instances in the
> >CProcessingThread class, each one running in its own thread in the
ActiveX
> >EXE's process space.
> >
> >The ActiveX EXE server uses some third party components that occasionally
> >popup message boxes (I can't seem to reliably suppress them). So, in
order
> >to know when a message box has popped up and blocked one of the
processing
> >threads, I configured the service application to run as the system
account
> >and allow it to interact with the desktop. The service applicaton does
> show
> >up on the desktop (windows station = WinSta0, desktop = Default). The
> >problem is that this still doesn't get the ActiveX Exe onto the
interactive
> >desktop. Instead, the ActiveX EXE's process gets placed in the service
> >windows station (Service-0x0-3e7$), which means its threads can't be
> >switched to the interactive desktop.
> >
> >So, I figured that on startup of each thread, I would just change the
> >ActiveX Exe's threads to the interactive desktop through calls to
> >SetThreadDesktop. This means (I assumed) that in the first thread, I
would
> >have to change the process' window station with a call to
> >SetProcessWindowStation. I quickly found out that I get access denied
when
> >calling OpenWorkstation to open the WinSta0 window station from the
ActiveX
> >EXE.
> >
> >I am guessing that this is because of the way VB implements an ActiveX
EXE.
> >According to the documentation for the windows stations and desktop API,
> I
> >can't switch a thread's desktop *after* any windows or hooks have been
> >created in the thread. I know tbat VB creates some additional threads
and
> >I'm pretty sure that VB creates some "extra" windows in the ActiveX EXE's
> >process (not forms in my project), which means I am SOL with this
approach.
> >
> >The only other avenue I could think of is to somehow start the ActiveX
EXE's
> >process in the interactive desktop before I create any objects from it.
> I
> >found out that I can specify the process windowstation and desktop in the
> >STARTUPINFO structure for CreateProcess. It appears that I can
successfully
> >create launch the ActiveX EXE in a process which uses the interactive
> >desktop. However, when I create objects against the ActiveX EXE, a new
> >process is started (rather than the objects being created in the existing
> >process). That new process can't access the interactive desktop.
> >
> >Anyone have other ideas outside of building this in C++?
> >
> >
> >
> >
> >
>

[Michael Shutt]

Nope. I had to rewrite the service in C++.

--
Michael Shutt

Please respond to newsgroup as I will not return direct emails.

"Karl Blacquiere" <blacquiere.karl@hydro.qc.ca> wrote in message
news:3ba11ff8$1@news.devx.com...
>
> Hi, did you find any solution ?
> I have the same problem here.
> If you have a hint, please email me back
>
> Tank you
>
>
> "Michael Shutt" <mshutt@mediaone.net> wrote:
> >I have the following components in development:
> >
> >- A service application written in VB using the NTSVC.ocx from MSDN
> >- A multi-threaded ActiveX exe that contains a CProcessingThread class
> >(marked as thread per object)
> >
> >When the service starts up, it creates one or more instances in the
> >CProcessingThread class, each one running in its own thread in the
ActiveX
> >EXE's process space.
> >
> >The ActiveX EXE server uses some third party components that occasionally
> >popup message boxes (I can't seem to reliably suppress them). So, in
order
> >to know when a message box has popped up and blocked one of the
processing
> >threads, I configured the service application to run as the system
account
> >and allow it to interact with the desktop. The service applicaton does
> show
> >up on the desktop (windows station = WinSta0, desktop = Default). The
> >problem is that this still doesn't get the ActiveX Exe onto the
interactive
> >desktop. Instead, the ActiveX EXE's process gets placed in the service
> >windows station (Service-0x0-3e7$), which means its threads can't be
> >switched to the interactive desktop.
> >
> >So, I figured that on startup of each thread, I would just change the
> >ActiveX Exe's threads to the interactive desktop through calls to
> >SetThreadDesktop. This means (I assumed) that in the first thread, I
would
> >have to change the process' window station with a call to
> >SetProcessWindowStation. I quickly found out that I get access denied
when
> >calling OpenWorkstation to open the WinSta0 window station from the
ActiveX
> >EXE.
> >
> >I am guessing that this is because of the way VB implements an ActiveX
EXE.
> >According to the documentation for the windows stations and desktop API,
> I
> >can't switch a thread's desktop *after* any windows or hooks have been
> >created in the thread. I know tbat VB creates some additional threads
and
> >I'm pretty sure that VB creates some "extra" windows in the ActiveX EXE's
> >process (not forms in my project), which means I am SOL with this
approach.
> >
> >The only other avenue I could think of is to somehow start the ActiveX
EXE's
> >process in the interactive desktop before I create any objects from it.
> I
> >found out that I can specify the process windowstation and desktop in the
> >STARTUPINFO structure for CreateProcess. It appears that I can
successfully
> >create launch the ActiveX EXE in a process which uses the interactive
> >desktop. However, when I create objects against the ActiveX EXE, a new
> >process is started (rather than the objects being created in the existing
> >process). That new process can't access the interactive desktop.
> >
> >Anyone have other ideas outside of building this in C++?
> >
> >
> >
> >
> >
>