Loading drivers and the shell

On Mon, 22 Dec 2003 14:14:32 -0600, Damon Gautama wrote:

> Hello,
> It has fallen in my lap to research a potential problem in our XPE
> configuration. This is my first time exploring this realm, so please excuse
> any untoward display of ignorance.
>
> The requirement is to boot up into our custom application without giving the
> user a chance to monkey with anything in the mean time. An attempt, before
> my time, to launch without Explorer caused application failure due to
> drivers not being loaded. From what I have read so far, I don't think there
> is an particular relationship between the shell and drivers, so my guess is
> that launching Explorer just happens to give the drivers time to load before
> our app is called.
>
> Does this sound right? Could I just write a shell that was essentially
>::Sleep(5000); ::CreateProcess(<our exe>)? Could I then launch Explorer
> later if needed?
>
> Am I on the right track, or am I barking up the wrong tree (what's a
> sentence without multiple metaphors?).
>
> Thanks for any and all help,
> damon

I had the same problem with my application (DirectX): if it is started too
soon, DirectX display initialization fails.

It takes about 15 seconds (in my case) after the shell is started before
the display becomes available.

When another (non-directX) app runs as shell it also only appears on screen
some time after it's been started, but it looks like XPE intercepts the
problem in this case.


To minimize the amount of changes to my application, I modified it so it
just stops with a certain exit code if DirectX init fails; then I wrote a
launcher app that's started as shell instead.
The launcher starts the main app, goes into a WaitForSingleObject until it
exits, and depending on the exit code it stops itself too or it retries
starting the main app. I included a five second Sleep() before each retry.

A retry loop around the initialization in my original app would have been a
more elegant solution, but it didn't work on the first attempt and I didn't
feel like debugging DirectX code on the target platform ;-)

Thanks for the pointer. I'll suggest that as the first try.

damon

"Slobodan Brcin" <sbrcin@ptt.yu> wrote in message
news:O8$hGxMyDHA.2156@TK2MSFTNGP09.phx.gbl...

> I don't know what drivers your application is using, but Sleep(5000) is

not

> a good solution. Why not 4000 or 6000?
>
> Instead find and read info on function CMP_WaitNoPendingInstallEvents
>
>
>
> Regards,
>
> Slobodan
>
>
>
> "Damon Gautama" <damon.gautama@medtronic.com> wrote in message
> news:Ov5L3gMyDHA.2360@TK2MSFTNGP10.phx.gbl...

> > Hello,
> > It has fallen in my lap to research a potential problem in our XPE
> > configuration. This is my first time exploring this realm, so please

> excuse

> > any untoward display of ignorance.
> >
> > The requirement is to boot up into our custom application without giving

> the

> > user a chance to monkey with anything in the mean time. An attempt,

before

> > my time, to launch without Explorer caused application failure due to
> > drivers not being loaded. From what I have read so far, I don't think

> there

> > is an particular relationship between the shell and drivers, so my guess

> is

> > that launching Explorer just happens to give the drivers time to load

> before

> > our app is called.
> >
> > Does this sound right? Could I just write a shell that was essentially
> > ::Sleep(5000); ::CreateProcess(<our exe>)? Could I then launch Explorer
> > later if needed?
> >
> > Am I on the right track, or am I barking up the wrong tree (what's a
> > sentence without multiple metaphors?).
> >
> > Thanks for any and all help,
> > damon
> >
> >

>
>

Thanks for the idea. I think we are going to try the
CMP_WaitNoPendingInstallEvents route. If that doesn't work, we'll try to
mimic your workaround.

damon

"Lucvdv" <name@null.net> wrote in message
news:4e8ti4tolni5.19tk25msmkjnt.dlg@40tude.net...

> On Mon, 22 Dec 2003 14:14:32 -0600, Damon Gautama wrote:
>

> > Hello,
> > It has fallen in my lap to research a potential problem in our XPE
> > configuration. This is my first time exploring this realm, so please

excuse

> > any untoward display of ignorance.
> >
> > The requirement is to boot up into our custom application without giving

the

> > user a chance to monkey with anything in the mean time. An attempt,

before

> > my time, to launch without Explorer caused application failure due to
> > drivers not being loaded. From what I have read so far, I don't think

there

> > is an particular relationship between the shell and drivers, so my guess

is

> > that launching Explorer just happens to give the drivers time to load

before

> > our app is called.
> >
> > Does this sound right? Could I just write a shell that was essentially
> >::Sleep(5000); ::CreateProcess(<our exe>)? Could I then launch Explorer
> > later if needed?
> >
> > Am I on the right track, or am I barking up the wrong tree (what's a
> > sentence without multiple metaphors?).
> >
> > Thanks for any and all help,
> > damon

>
> I had the same problem with my application (DirectX): if it is started too
> soon, DirectX display initialization fails.
>
> It takes about 15 seconds (in my case) after the shell is started before
> the display becomes available.
>
> When another (non-directX) app runs as shell it also only appears on

screen

> some time after it's been started, but it looks like XPE intercepts the
> problem in this case.
>
>
> To minimize the amount of changes to my application, I modified it so it
> just stops with a certain exit code if DirectX init fails; then I wrote a
> launcher app that's started as shell instead.
> The launcher starts the main app, goes into a WaitForSingleObject until it
> exits, and depending on the exit code it stops itself too or it retries
> starting the main app. I included a five second Sleep() before each

retry.

>
> A retry loop around the initialization in my original app would have been

a

> more elegant solution, but it didn't work on the first attempt and I

didn't

> feel like debugging DirectX code on the target platform ;-)