Spawning dialog boxes from dlls

[Chris]

Hi,

I'm currently developing an application capable of loading dll's
dynamically. The dll's will primarily be developed in C#, but there are old
legacy dll's that must be migrated from VC++ 6.0 as well.

To configure each dll independently, I'm thinking that a dialog box from
each dll could be spawned directly from it. Do any of you have a better
suggestion? The final product will be a Windows Service application loading
appropriate plugins dynamically. Anyway, I'm wondering if any of you know
of any online resources or have any suggestions on how to implement this in
C# and VC++. Can I make a call directly to the windows api to spawn a
dialog box? Are there other ways to do this?

Thanks in advance,

Chris

 

[Chris]

Sorry, the host application (windows service) will be implemented in C#.

 

[Nicholas Paldino [.NET/C# MVP]]

Chris,

I think that this is a moot point actually, because you are creating a
windows service. Services should not have user interface elements.

If you want to handle the configuration of the properties of the plug
in, then yes, that would be a good idea. Having a method/function that is
called to indicate to the DLL that it should display a property page of some
sort. Of course, you could use COM property pages, as the framework is
already there. All you have to do is possibly pass in the host that is
hosting the plug in. This could be as simple as a handle to a window, or an
interface that exposes more functionality of the host.

Hope this helps.

 

[William DePalo [MVP VC++ ]]

Sorry, the host application (windows service) will be implemented in C#.

I'm going to pass on the main point of your question. I expect you will get
help on that front shortly.

However, having a Windows NT service display a dialog is generally
considered a bad idea no matter what programming language you choose.

The reason for that has to do with the fact that a service can only interact
with the interactive window station if it runs under the LocalSystem
account. The LocalSystem account, as its name implies, has free reign over
the local system, it can do just about anything.

Now when a user logs in to a system his privileges are usually limited by
the groups of which he is a member. As Martha says, that's a good thing. Not
everyone should be an administrator. But if an application running under the
user context sends a window message to the service then that message is
processed by the service under the all powerful account. That's a
(potentially) bad thing (1).

Now the .Net security model is code-based so the risk may be mitigated to
some extent but as far as I know the advice that comes from on-high is that
services should not interact with the desktop. A service that requires an
interactive component can implement its UI in an agent which uses some IPC
mechanism to communicate with the service instead of implementing the UI
itself.

Regards,
Will

(1) If I remember correctly, the vulnerability is referred to as the
"shatter attack" and involves sending an innocuous looking WM_TIMER message
to a window owned by a thread running under the LocalSystem account.

 

[Nicholas Paldino [.NET/C# MVP]]

William,

You forgot the other important reason why a service should not have a
UI. Even if running under the LocalSystem account, a person has to be
logged into the workstation in order to see the UI!

 

[Chris]

Having a method/function that is

called to indicate to the DLL that it should display a property page of some
sort.

I would expect that the host application would call a dll function to pop
the property page. Within that dll function, would it call something like
'DialogBoxParam' which creates a modal dialog box from a dialog box template
resource in the OS or is there some other way this should be done?

Thanks,

Chris

Chris,

I think that this is a moot point actually, because you are creating a
windows service. Services should not have user interface elements.

If you want to handle the configuration of the properties of the plug
in, then yes, that would be a good idea. Having a method/function that is
called to indicate to the DLL that it should display a property page of some
sort. Of course, you could use COM property pages, as the framework is
already there. All you have to do is possibly pass in the host that is
hosting the plug in. This could be as simple as a handle to a window, or an
interface that exposes more functionality of the host.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I'm currently developing an application capable of loading dll's
dynamically. The dll's will primarily be developed in C#, but there are old
legacy dll's that must be migrated from VC++ 6.0 as well.

To configure each dll independently, I'm thinking that a dialog box from
each dll could be spawned directly from it. Do any of you have a better
suggestion? The final product will be a Windows Service application loading
appropriate plugins dynamically. Anyway, I'm wondering if any of you know
of any online resources or have any suggestions on how to implement this in
C# and VC++. Can I make a call directly to the windows api to spawn a
dialog box? Are there other ways to do this?

Thanks in advance,

Chris