By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,671 Members | 1,350 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,671 IT Pros & Developers. It's quick & easy.

Spawning dialog boxes from dlls

P: n/a
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
Nov 13 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Sorry, the host application (windows service) will be implemented in C#.
"Chris" <c w a n @ n o s p a m - v i g i l . c o m> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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

Nov 13 '05 #2

P: n/a
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]
- ni**************@exisconsulting.com

"Chris" <c w a n @ n o s p a m - v i g i l . c o m> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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

Nov 13 '05 #3

P: n/a
"Chris" <c w a n @ n o s p a m - v i g i l . c o m> wrote in message
news:#w**************@tk2msftngp13.phx.gbl...
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.
Nov 13 '05 #4

P: n/a
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!
--
- Nicholas Paldino [.NET/C# MVP]
- ni**************@exisconsulting.com

"William DePalo [MVP VC++ ]" <wi***********@mvps.org> wrote in message
news:eJ**************@tk2msftngp13.phx.gbl...
"Chris" <c w a n @ n o s p a m - v i g i l . c o m> wrote in message
news:#w**************@tk2msftngp13.phx.gbl...
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.

Nov 13 '05 #5

P: n/a
> 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

"Nicholas Paldino [.NET/C# MVP]" <ni**************@exisconsulting.com> wrote
in message news:ur****************@TK2MSFTNGP10.phx.gbl... 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]
- ni**************@exisconsulting.com

"Chris" <c w a n @ n o s p a m - v i g i l . c o m> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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


Nov 13 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.