Bear with me as this may get a bit long.

I am working on integrating a Windows XP based application into an aircraft 
training simulation.  The XP computer will only need to run the specific 
applications needed as part of the training scenario.  The plan is that the 
system will boot, wait for the trainer to signal that the training scenario 
is ready to run, then execute the application.  When the scenario is 
complete, the application will terminate, and the system will go back to 
waiting for the next scenario.  We want this to be as transparent to the 
users as possible, all they should see is there GUI interface, when the 
trainer is running.  I also need to be able to shutdown the system on command 
from the trainer.

I have a pretty good idea about the various options for logging in, starting 
an application automatically, etc.  Back in the WindowsNT days, I could set 
up the system so that if the user terminated the running application, he was 
automatically logged off, so he never saw the WindowsNT GUI, just the 
application.  My first question is, "Is there a way to make Windows XP behave 
this way?"

My second, more general question is, "Is there some guidance regarding best 
practice for where you do various things with respect to startup and 
shutdown?"  For instance, you can use the group policy editor to build 
computer startup and shutdown scripts.  You can also define user login and 
logout scripts.  Is there some recommended way of deciding where to do 
various operations?

I am looking for any suggestions regarding making things operate in the 
simplest and most reliable fashion.

thanks,

-- 
jfh

I'm not sure what you mean exactly. Try disabling the "Welcome Screen"
from the "User Accounts" control panel.


John Hughes wrote:
> Bear with me as this may get a bit long.
>
> I am working on integrating a Windows XP based application into an aircraft
> training simulation.  The XP computer will only need to run the specific
> applications needed as part of the training scenario.  The plan is that the
> system will boot, wait for the trainer to signal that the training scenario
> is ready to run, then execute the application.  When the scenario is
> complete, the application will terminate, and the system will go back to
> waiting for the next scenario.  We want this to be as transparent to the
> users as possible, all they should see is there GUI interface, when the
> trainer is running.  I also need to be able to shutdown the system on command
> from the trainer.
>
> I have a pretty good idea about the various options for logging in, starting
> an application automatically, etc.  Back in the WindowsNT days, I could set
> up the system so that if the user terminated the running application, he was
> automatically logged off, so he never saw the WindowsNT GUI, just the
> application.  My first question is, "Is there a way to make Windows XP behave
> this way?"
>
> My second, more general question is, "Is there some guidance regarding best
> practice for where you do various things with respect to startup and
> shutdown?"  For instance, you can use the group policy editor to build
> computer startup and shutdown scripts.  You can also define user login and
> logout scripts.  Is there some recommended way of deciding where to do
> various operations?
>
> I am looking for any suggestions regarding making things operate in the
> simplest and most reliable fashion.
>
> thanks,
>
> --
> jfh

I was looking for a lot deeper answer.  Turning of the welcome screen is just 
the tip of the iceberg.  For instance, there is a posting that describes 13 
different ways that a program can be started (see Startup in this discussion 
group).  I am trying to figure out what the advantages and disadvantages of 
those 13 places to start a program might be.  I am looking for guidance 
beyond the obvious (some places start programs on boot, some places start 
programs on login, etc.).  I am also looking for guidance on ways to minimize 
what the user can do, besides play with the specific program we want him too. 
 I know how to do many of these things, but I am looking for expert help to 
make sure I don't unintentionally break something, or leave a gapping 
security hole.

Am I on my own?

thanks,

jfh
-- 
jfh


"Jaelani" wrote:

> I'm not sure what you mean exactly. Try disabling the "Welcome Screen"
> from the "User Accounts" control panel.
> 
> 
> John Hughes wrote:
> > Bear with me as this may get a bit long.
> >
> > I am working on integrating a Windows XP based application into an aircraft
> > training simulation.  The XP computer will only need to run the specific
> > applications needed as part of the training scenario.  The plan is that the
> > system will boot, wait for the trainer to signal that the training scenario
> > is ready to run, then execute the application.  When the scenario is
> > complete, the application will terminate, and the system will go back to
> > waiting for the next scenario.  We want this to be as transparent to the
> > users as possible, all they should see is there GUI interface, when the
> > trainer is running.  I also need to be able to shutdown the system on command
> > from the trainer.
> >
> > I have a pretty good idea about the various options for logging in, starting
> > an application automatically, etc.  Back in the WindowsNT days, I could set
> > up the system so that if the user terminated the running application, he was
> > automatically logged off, so he never saw the WindowsNT GUI, just the
> > application.  My first question is, "Is there a way to make Windows XP behave
> > this way?"
> >
> > My second, more general question is, "Is there some guidance regarding best
> > practice for where you do various things with respect to startup and
> > shutdown?"  For instance, you can use the group policy editor to build
> > computer startup and shutdown scripts.  You can also define user login and
> > logout scripts.  Is there some recommended way of deciding where to do
> > various operations?
> >
> > I am looking for any suggestions regarding making things operate in the
> > simplest and most reliable fashion.
> >
> > thanks,
> >
> > --
> > jfh
>

> I was looking for a lot deeper answer.  Turning of the welcome screen
> is just the tip of the iceberg.  For instance, there is a posting
> that describes 13 different ways that a program can be started (see
> Startup in this discussion group).  I am trying to figure out what
> the advantages and disadvantages of those 13 places to start a
> program might be.  I am looking for guidance beyond the obvious (some
> places start programs on boot, some places start programs on login,
> etc.).  I am also looking for guidance on ways to minimize what the
> user can do, besides play with the specific program we want him too.
> I know how to do many of these things, but I am looking for expert
> help to make sure I don't unintentionally break something, or leave a
> gapping security hole.
>
> Am I on my own?
>
> thanks,

You might be unless you can make your questions a lot more specific. 
That's a complex area and with lots of IFs, caveats and dependencies. 
And besides that, the "simplest and most reliable fashion" is something 
that is wide open to interpretation and personal opinions depending on 
what a person's computer is set up to do (or not do).

There just is no one size fits all answer.  Your best bet is to pick an 
area and start studying it.  Most any area you pick will lead you to the 
others and research will be rather easy to broaden as you go along.  The 
Registry is probably one of the more complex but also most all 
encompassing of the areas for you to start with.  Then begin applying it 
to whatever case you want it to fit.  You'll begin to come to some 
accurate answers for your own situation.  You'll also then be able to 
ask much more specific questions and probably receive much better 
responses too.
   One thing you're not apt to get here is anyone who will take you by 
the hand and instruct you on all the details and nuances of your case. 
Posters are expected to have done their own prior research before coming 
to a newsgroup; being able to demonstrate that you've done that will get 
you some much better answers.  You'll find you just can not be spoon fed 
the answer to such a wide open question.  What you've done so far is 
akin to going to an automotive engineering  newsgroup and asking how to 
build the perfect car without so much as providing the manufacturer, 
brand or any other details about it.

HTH


>
> jfh
>
>> I'm not sure what you mean exactly. Try disabling the "Welcome
>> Screen" from the "User Accounts" control panel.
>>
>>
>> John Hughes wrote:
>>> Bear with me as this may get a bit long.
>>>
>>> I am working on integrating a Windows XP based application into an
>>> aircraft training simulation.  The XP computer will only need to
>>> run the specific applications needed as part of the training
>>> scenario.  The plan is that the system will boot, wait for the
>>> trainer to signal that the training scenario is ready to run, then
>>> execute the application.  When the scenario is complete, the
>>> application will terminate, and the system will go back to waiting
>>> for the next scenario.  We want this to be as transparent to the
>>> users as possible, all they should see is there GUI interface, when
>>> the trainer is running.  I also need to be able to shutdown the
>>> system on command from the trainer.
>>>
>>> I have a pretty good idea about the various options for logging in,
>>> starting an application automatically, etc.  Back in the WindowsNT
>>> days, I could set up the system so that if the user terminated the
>>> running application, he was automatically logged off, so he never
>>> saw the WindowsNT GUI, just the application.  My first question is,
>>> "Is there a way to make Windows XP behave this way?"
>>>
>>> My second, more general question is, "Is there some guidance
>>> regarding best practice for where you do various things with
>>> respect to startup and shutdown?"  For instance, you can use the
>>> group policy editor to build computer startup and shutdown scripts.
>>> You can also define user login and logout scripts.  Is there some
>>> recommended way of deciding where to do various operations?
>>>
>>> I am looking for any suggestions regarding making things operate in
>>> the simplest and most reliable fashion.
>>>
>>> thanks,
>>>
>>> --
>>> jfh

I was not asking to be spoon fed.  I spent several days bouncing around 
various documents, web sites, forums, news groups, etc. trying to find 
something that would point me in the right direction.  Mostly what I found 
was a huge pool of unconnected information.  It is often difficult to discern 
if the informaton you are reading pertains to Vista, to XP, or even to 
Windows 3.1.

I did ask some specific questions.

1.  Is there a way to make Windows XP automatically log the user off when he 
terminates an application that was automatically loaded on logging in?  I 
have found many references to setting up the automatic log in, with more 
options than I could have ever imagined.  So, I can pick one and go with it, 
but there doesn't appear to be any information about which of the options 
might be more or less secure, which options are likely to be around in the 
future, which might go away, etc.

2.  My second question was asking for a road map regarding recommended 
practices for starting up and shutting down applications.  I can spend weeks 
reading through numerous posts about what does and doesn't work, often with 
no way to tell what expertise the poster has.  There are numerous instances 
where Microsoft has provided guidance regarding recommended ways of doing 
things.  I was looking for a place to start my research.  It sounds to me 
like there are no documented suggestions, so I am forced to pick a direction 
and hope it doesn't lead to a dead end.  I had hoped that someone could help 
me avoid some known pit falls.

Thanks for your input.

jfh
-- 
jfh


"Twayne" wrote:

> > I was looking for a lot deeper answer.  Turning of the welcome screen
> > is just the tip of the iceberg.  For instance, there is a posting
> > that describes 13 different ways that a program can be started (see
> > Startup in this discussion group).  I am trying to figure out what
> > the advantages and disadvantages of those 13 places to start a
> > program might be.  I am looking for guidance beyond the obvious (some
> > places start programs on boot, some places start programs on login,
> > etc.).  I am also looking for guidance on ways to minimize what the
> > user can do, besides play with the specific program we want him too.
> > I know how to do many of these things, but I am looking for expert
> > help to make sure I don't unintentionally break something, or leave a
> > gapping security hole.
> >
> > Am I on my own?
> >
> > thanks,
> 
> You might be unless you can make your questions a lot more specific. 
> That's a complex area and with lots of IFs, caveats and dependencies. 
> And besides that, the "simplest and most reliable fashion" is something 
> that is wide open to interpretation and personal opinions depending on 
> what a person's computer is set up to do (or not do).
> 
> There just is no one size fits all answer.  Your best bet is to pick an 
> area and start studying it.  Most any area you pick will lead you to the 
> others and research will be rather easy to broaden as you go along.  The 
> Registry is probably one of the more complex but also most all 
> encompassing of the areas for you to start with.  Then begin applying it 
> to whatever case you want it to fit.  You'll begin to come to some 
> accurate answers for your own situation.  You'll also then be able to 
> ask much more specific questions and probably receive much better 
> responses too.
>    One thing you're not apt to get here is anyone who will take you by 
> the hand and instruct you on all the details and nuances of your case. 
> Posters are expected to have done their own prior research before coming 
> to a newsgroup; being able to demonstrate that you've done that will get 
> you some much better answers.  You'll find you just can not be spoon fed 
> the answer to such a wide open question.  What you've done so far is 
> akin to going to an automotive engineering  newsgroup and asking how to 
> build the perfect car without so much as providing the manufacturer, 
> brand or any other details about it.
> 
> HTH
> 
> 
> >
> > jfh
> >
> >> I'm not sure what you mean exactly. Try disabling the "Welcome
> >> Screen" from the "User Accounts" control panel.
> >>
> >>
> >> John Hughes wrote:
> >>> Bear with me as this may get a bit long.
> >>>
> >>> I am working on integrating a Windows XP based application into an
> >>> aircraft training simulation.  The XP computer will only need to
> >>> run the specific applications needed as part of the training
> >>> scenario.  The plan is that the system will boot, wait for the
> >>> trainer to signal that the training scenario is ready to run, then
> >>> execute the application.  When the scenario is complete, the
> >>> application will terminate, and the system will go back to waiting
> >>> for the next scenario.  We want this to be as transparent to the
> >>> users as possible, all they should see is there GUI interface, when
> >>> the trainer is running.  I also need to be able to shutdown the
> >>> system on command from the trainer.
> >>>
> >>> I have a pretty good idea about the various options for logging in,
> >>> starting an application automatically, etc.  Back in the WindowsNT
> >>> days, I could set up the system so that if the user terminated the
> >>> running application, he was automatically logged off, so he never
> >>> saw the WindowsNT GUI, just the application.  My first question is,
> >>> "Is there a way to make Windows XP behave this way?"
> >>>
> >>> My second, more general question is, "Is there some guidance
> >>> regarding best practice for where you do various things with
> >>> respect to startup and shutdown?"  For instance, you can use the
> >>> group policy editor to build computer startup and shutdown scripts.
> >>> You can also define user login and logout scripts.  Is there some
> >>> recommended way of deciding where to do various operations?
> >>>
> >>> I am looking for any suggestions regarding making things operate in
> >>> the simplest and most reliable fashion.
> >>>
> >>> thanks,
> >>>
> >>> --
> >>> jfh
> 
> 
> 
>

1. AFAIK, a user can only be automatically logged off by Windows
itself if the shell process is terminated. You will have to use a
third party software or a script if you want that to happen for any
application you have specified. For me, I would rather use a script
which is launched at user login. In turn, that script will launch the
needed application and wait until it is terminated. When that happen,
the script can logoff the current user.

2. There are many ways to make an application automatically launched
at system startup or at user login. Many are stored in the registry
and some in configuration files. Almost all available methods can be
used with all kind of applications. But there are restrictions such as
type of application, dependency with other application, security/
privilege, and timing issues. It would be a bit too long to describe
each methods.


John Hughes wrote:
> I was not asking to be spoon fed.  I spent several days bouncing around
> various documents, web sites, forums, news groups, etc. trying to find
> something that would point me in the right direction.  Mostly what I found
> was a huge pool of unconnected information.  It is often difficult to discern
> if the informaton you are reading pertains to Vista, to XP, or even to
> Windows 3.1.
>
> I did ask some specific questions.
>
> 1.  Is there a way to make Windows XP automatically log the user off when he
> terminates an application that was automatically loaded on logging in?  I
> have found many references to setting up the automatic log in, with more
> options than I could have ever imagined.  So, I can pick one and go with it,
> but there doesn't appear to be any information about which of the options
> might be more or less secure, which options are likely to be around in the
> future, which might go away, etc.
>
> 2.  My second question was asking for a road map regarding recommended
> practices for starting up and shutting down applications.  I can spend weeks
> reading through numerous posts about what does and doesn't work, often with
> no way to tell what expertise the poster has.  There are numerous instances
> where Microsoft has provided guidance regarding recommended ways of doing
> things.  I was looking for a place to start my research.  It sounds to me
> like there are no documented suggestions, so I am forced to pick a direction
> and hope it doesn't lead to a dead end.  I had hoped that someone could help
> me avoid some known pit falls.
>
> Thanks for your input.
>
> jfh
> --
> jfh

1.  You suggest a script launced at login, that starts the application(s), 
waits for them to terminate, then logs off.  I can easily write a .bat file 
and place it in the users startup folder.  If it simply starts the 
application in line, it will sit there until the application exits.  I can 
then put a logoff comand in the .bat file.  Is this what you had in mind?

2.  I am aware of at least 13 different places to specify an application or 
program to be run at system startup or login.  You said, "But there are 
restrictions such as type of application, dependency with other application, 
security/privilege, and timing issues. It would be a bit too long to describe 
each methods."  Where are these restrictions documented?  Where can I go to 
get details about each of the methods?  This is the fundamental problem I am 
having right how.  There are too many choices and I have no information on 
which to base a decision about which choice to use.  I was hoping that I 
didn't have to try each choice independently and run countless tests on each 
configuration to determine what was best.  I hoped, I could learn from 
others.  Is there no one who knows, or is willing to share this info?

-- 
jfh


"Jaelani" wrote:

> 1. AFAIK, a user can only be automatically logged off by Windows
> itself if the shell process is terminated. You will have to use a
> third party software or a script if you want that to happen for any
> application you have specified. For me, I would rather use a script
> which is launched at user login. In turn, that script will launch the
> needed application and wait until it is terminated. When that happen,
> the script can logoff the current user.
> 
> 2. There are many ways to make an application automatically launched
> at system startup or at user login. Many are stored in the registry
> and some in configuration files. Almost all available methods can be
> used with all kind of applications. But there are restrictions such as
> type of application, dependency with other application, security/
> privilege, and timing issues. It would be a bit too long to describe
> each methods.

1. Yes, that's exactly what I have in mind. Don't know if Windows
Script (WSC, JS or VBS) is capable of performing this task, but if it
does, it can be used to avoid having a console window.

2. None that I know of, sorry. Most websites describes only several
methods. In Microsoft website, this information are scattered. Some
are in the Knowledge Base and some are in the MSDN Online Library. The
least known and hard to find ones are the ones from the Knowledge Base
which are usually provided for administrators and programmers in
technical manner. Some only contain instructions on how to utilize it
without explaining what it actually do, what it requires and what is
affects in details.


As far as I can see, you want your system to run in so-called "kiosk"
mode where your main application starts automatically PRIOR the
windows desktop by replacing the shell. However, some Windows
components may not yet be available during this stage. You application
might need to manually start any required components that are not yet
available.


John Hughes wrote:
> 1.  You suggest a script launced at login, that starts the application(s),
> waits for them to terminate, then logs off.  I can easily write a .bat file
> and place it in the users startup folder.  If it simply starts the
> application in line, it will sit there until the application exits.  I can
> then put a logoff comand in the .bat file.  Is this what you had in mind?
>
> 2.  I am aware of at least 13 different places to specify an application or
> program to be run at system startup or login.  You said, "But there are
> restrictions such as type of application, dependency with other application,
> security/privilege, and timing issues. It would be a bit too long to describe
> each methods."  Where are these restrictions documented?  Where can I go to
> get details about each of the methods?  This is the fundamental problem I am
> having right how.  There are too many choices and I have no information on
> which to base a decision about which choice to use.  I was hoping that I
> didn't have to try each choice independently and run countless tests on each
> configuration to determine what was best.  I hoped, I could learn from
> others.  Is there no one who knows, or is willing to share this info?
>
> --
> jfh

I currently have a .bat file that I am placing in the users startup folder 
which starts the applications correctly.  I am having numerous issues with 
making things work just the way I would like, but the basic concept is 
working.  Thanks for your help with this.

The "kiosk" mode is exactly what I am trying to set up.  Is there more 
documentation about how to do this somewhere?  Or, is this another example of 
things that will have to be mined out of the extensive online resources?

Again, I thank you for your help.

-- 
jfh


"Jaelani" wrote:

> 1. Yes, that's exactly what I have in mind. Don't know if Windows
> Script (WSC, JS or VBS) is capable of performing this task, but if it
> does, it can be used to avoid having a console window.
> 
> 2. None that I know of, sorry. Most websites describes only several
> methods. In Microsoft website, this information are scattered. Some
> are in the Knowledge Base and some are in the MSDN Online Library. The
> least known and hard to find ones are the ones from the Knowledge Base
> which are usually provided for administrators and programmers in
> technical manner. Some only contain instructions on how to utilize it
> without explaining what it actually do, what it requires and what is
> affects in details.
> 
> 
> As far as I can see, you want your system to run in so-called "kiosk"
> mode where your main application starts automatically PRIOR the
> windows desktop by replacing the shell. However, some Windows
> components may not yet be available during this stage. You application
> might need to manually start any required components that are not yet
> available.
> 
> 
> John Hughes wrote:
> > 1.  You suggest a script launced at login, that starts the application(s),
> > waits for them to terminate, then logs off.  I can easily write a .bat file
> > and place it in the users startup folder.  If it simply starts the
> > application in line, it will sit there until the application exits.  I can
> > then put a logoff comand in the .bat file.  Is this what you had in mind?
> >
> > 2.  I am aware of at least 13 different places to specify an application or
> > program to be run at system startup or login.  You said, "But there are
> > restrictions such as type of application, dependency with other application,
> > security/privilege, and timing issues. It would be a bit too long to describe
> > each methods."  Where are these restrictions documented?  Where can I go to
> > get details about each of the methods?  This is the fundamental problem I am
> > having right how.  There are too many choices and I have no information on
> > which to base a decision about which choice to use.  I was hoping that I
> > didn't have to try each choice independently and run countless tests on each
> > configuration to determine what was best.  I hoped, I could learn from
> > others.  Is there no one who knows, or is willing to share this info?
> >
> > --
> > jfh
>

You can do a search on the Microsoft website using this keywords:
shell AND explorer.exe AND winlogon

Take a look at the one titled "Shell Entry: Core Services". The
default shell is EXPLORER.EXE, which is the desktop. In other word, in
kiosk mode, the EXPLORER.EXE desktop is the kiosk application. You
just need to replace it with your application or your application
manager.

The search result should be relevant to the shell, all the bits and
pieces. You will need to use the registry and NOT the one in the
SYSTEM.INI file. Also, as you already have known, the welcome screen
should be disabled, since it will interfere with the whole screen
display.

The welcome screen AFAIK, will show its "welcome" screen to block user
inputs in order to let the USERINIT.EXE process to finish. The
USERINIT.EXE performs all the necesarry user profile initializations,
so it's best to let it finish prior launching the main application.
Your application manager (the shell) should perform this task.
Frankly, I don't know the details about what would happen if we don't
wait USERINIT.EXE finishes it job and launch the main application
right away. Although in my experience, nothing bad happened since I
myself don't use the welcome screen and all of the startup
applications are launched without waiting USERINIT.EXE to finish its
job.

Since the desktop is gone, don't expect support for tray icons nor
tray notifications including any other things that depend on the
desktop features.

HTH.


John Hughes wrote:
> I currently have a .bat file that I am placing in the users startup folder
> which starts the applications correctly.  I am having numerous issues with
> making things work just the way I would like, but the basic concept is
> working.  Thanks for your help with this.
>
> The "kiosk" mode is exactly what I am trying to set up.  Is there more
> documentation about how to do this somewhere?  Or, is this another example of
> things that will have to be mined out of the extensive online resources?
>
> Again, I thank you for your help.
>
> --
> jfh
>
>
> "Jaelani" wrote:
>
> > 1. Yes, that's exactly what I have in mind. Don't know if Windows
> > Script (WSC, JS or VBS) is capable of performing this task, but if it
> > does, it can be used to avoid having a console window.
> >
> > 2. None that I know of, sorry. Most websites describes only several
> > methods. In Microsoft website, this information are scattered. Some
> > are in the Knowledge Base and some are in the MSDN Online Library. The
> > least known and hard to find ones are the ones from the Knowledge Base
> > which are usually provided for administrators and programmers in
> > technical manner. Some only contain instructions on how to utilize it
> > without explaining what it actually do, what it requires and what is
> > affects in details.
> >
> >
> > As far as I can see, you want your system to run in so-called "kiosk"
> > mode where your main application starts automatically PRIOR the
> > windows desktop by replacing the shell. However, some Windows
> > components may not yet be available during this stage. You application
> > might need to manually start any required components that are not yet
> > available.
> >
> >
> > John Hughes wrote:
> > > 1.  You suggest a script launced at login, that starts the application(s),
> > > waits for them to terminate, then logs off.  I can easily write a .bat file
> > > and place it in the users startup folder.  If it simply starts the
> > > application in line, it will sit there until the application exits.  I can
> > > then put a logoff comand in the .bat file.  Is this what you had in mind?
> > >
> > > 2.  I am aware of at least 13 different places to specify an application or
> > > program to be run at system startup or login.  You said, "But there are
> > > restrictions such as type of application, dependency with other application,
> > > security/privilege, and timing issues. It would be a bit too long to describe
> > > each methods."  Where are these restrictions documented?  Where can I go to
> > > get details about each of the methods?  This is the fundamental problem I am
> > > having right how.  There are too many choices and I have no information on
> > > which to base a decision about which choice to use.  I was hoping that I
> > > didn't have to try each choice independently and run countless tests on each
> > > configuration to determine what was best.  I hoped, I could learn from
> > > others.  Is there no one who knows, or is willing to share this info?
> > >
> > > --
> > > jfh
> >

You can do a search on the Microsoft website using this keywords:
shell AND explorer.exe AND winlogon

Take a look at the one titled "Shell Entry: Core Services". The
default shell is EXPLORER.EXE, which is the desktop. In other word, in
kiosk mode, the EXPLORER.EXE desktop is the kiosk application. You
just need to replace it with your application or your application
manager.

The search result should be relevant to the shell, all the bits and
pieces. You will need to use the registry and NOT the one in the
SYSTEM.INI file. Also, as you already have known, the welcome screen
should be disabled, since it will interfere with the whole screen
display.

The welcome screen AFAIK, will show its "welcome" screen to block user
inputs in order to let the USERINIT.EXE process to finish. The
USERINIT.EXE performs all the necesarry user profile initializations,
so it's best to let it finish prior launching the main application.
Your application manager (the shell) should perform this task.
Frankly, I don't know the details about what would happen if we don't
wait USERINIT.EXE finishes it job and launch the main application
right away. Although in my experience, nothing bad happened since I
myself don't use the welcome screen and all of the startup
applications are launched without waiting USERINIT.EXE to finish its
job.

Since the desktop is gone, don't expect support for tray icons nor
tray notifications including any other things that depend on the
desktop features.

HTH.


John Hughes wrote:
> I currently have a .bat file that I am placing in the users startup folder
> which starts the applications correctly.  I am having numerous issues with
> making things work just the way I would like, but the basic concept is
> working.  Thanks for your help with this.
>
> The "kiosk" mode is exactly what I am trying to set up.  Is there more
> documentation about how to do this somewhere?  Or, is this another example of
> things that will have to be mined out of the extensive online resources?
>
> Again, I thank you for your help.
>
> --
> jfh
>
>
> "Jaelani" wrote:
>
> > 1. Yes, that's exactly what I have in mind. Don't know if Windows
> > Script (WSC, JS or VBS) is capable of performing this task, but if it
> > does, it can be used to avoid having a console window.
> >
> > 2. None that I know of, sorry. Most websites describes only several
> > methods. In Microsoft website, this information are scattered. Some
> > are in the Knowledge Base and some are in the MSDN Online Library. The
> > least known and hard to find ones are the ones from the Knowledge Base
> > which are usually provided for administrators and programmers in
> > technical manner. Some only contain instructions on how to utilize it
> > without explaining what it actually do, what it requires and what is
> > affects in details.
> >
> >
> > As far as I can see, you want your system to run in so-called "kiosk"
> > mode where your main application starts automatically PRIOR the
> > windows desktop by replacing the shell. However, some Windows
> > components may not yet be available during this stage. You application
> > might need to manually start any required components that are not yet
> > available.
> >
> >
> > John Hughes wrote:
> > > 1.  You suggest a script launced at login, that starts the application(s),
> > > waits for them to terminate, then logs off.  I can easily write a .bat file
> > > and place it in the users startup folder.  If it simply starts the
> > > application in line, it will sit there until the application exits.  I can
> > > then put a logoff comand in the .bat file.  Is this what you had in mind?
> > >
> > > 2.  I am aware of at least 13 different places to specify an application or
> > > program to be run at system startup or login.  You said, "But there are
> > > restrictions such as type of application, dependency with other application,
> > > security/privilege, and timing issues. It would be a bit too long to describe
> > > each methods."  Where are these restrictions documented?  Where can I go to
> > > get details about each of the methods?  This is the fundamental problem I am
> > > having right how.  There are too many choices and I have no information on
> > > which to base a decision about which choice to use.  I was hoping that I
> > > didn't have to try each choice independently and run countless tests on each
> > > configuration to determine what was best.  I hoped, I could learn from
> > > others.  Is there no one who knows, or is willing to share this info?
> > >
> > > --
> > > jfh
> >