ctacke/>
Sun Oct 22 16:18:14 CDT 2006
Sleep() will pump up CPU usage to 100%? Not possible. It doesn't guaratee
the behavior you're after, but the way Sleep is implemented in the kernel,
it's not possible for it to rob all thread quantum from the scheduler
(unless the OEM screwed something up, but then you'd see a *lot* of other
problems anyway).
--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--
"JamesFielding" <JamesFielding@discussions.microsoft.com> wrote in message
news:226B7B3E-052B-4CF7-B4A3-AD31AEA06166@microsoft.com...
>
>> in a loop to check whether the window is open. But first I wait 2
>> seconds, using Sleep( 2000 ), to give it a chance
>
> Nooooooooo !!!!
>
> Okay, fellow eVC++ users... never, ever, eeeever use the Sleep()
> function to just "do nothing" for a short period of time.
>
> In theory, it's fine. In reality, Sleep() will often pump up the CPU
> useage to 100%, and leave it there until your time period has
> expired. That .cab file that you're trying to install has just
> ground to a halt for 2 seconds. You'll then check if it's finished
> (it won't have), then you'll grind it to a half for another 2 seconds..
> and so on.
>
> Below is the short function we use, as a replacement for
> Sleep(), and this doesn't fall into the same trap.
>
> void SafeSleep(long period)
> {
> // The Sleep() function tends to hog 100% of the CPU.
> // Use this function instead.
> //
> // Entry: period contains the pause period in 1/1000th's of a second.
> //
> MSG msg;
> BOOL bMessageWaiting;
> long timeRemaining = period;
> long startTime = GetTickCount();
>
> do
> {
> // Sleep until timeout or event occurs
> MsgWaitForMultipleObjects(0, 0, 0, timeRemaining, QS_ALLINPUT);
> timeRemaining = period - (GetTickCount() - startTime);
> if (timeRemaining <= 0)
> return;
>
> do
> {
> bMessageWaiting = PeekMessage(&msg, (HWND) NULL, 0, 0, PM_REMOVE);
> if (bMessageWaiting)
> {
> TranslateMessage(&msg);
> DispatchMessage(&msg);
> }
> }
> while (bMessageWaiting);
> }
> while(1);
> }
>
>
>
> James
> www.PocketPCinstaller.com
>
>
>
>
> "r_z_aret@pen_fact.com" wrote:
>
>> On Fri, 15 Sep 2006 07:44:20 -0400, vino
>> <vino.2e6con@no-spam-here.com> wrote:
>>
>> >
>> >Peter,
>> >
>> >Thanks again for the update.
>> >
>> >So, if the wceload kicks off a new process, then the workaround of
>> >custom cesetup.dll will not work. Right ? Because I dont have the
>> >required handle to wait upon.
>> >
>> >Is there any way I can get the new wceload process that was launched ?
>> >If so, I think I can pick up its handle and then wait upon it.
>>
>>
>> Ugly hacks, but:
>>
>> 1) I believe the "WCELOAD" is the class name for the window that is
>> visible while WCELOAD runs (found by using GetForegroundWindow and
>> GetClassName). So I use
>> FindWindow( _T( "WCELOAD" ), NULL )
>> in a loop to check whether the window is open. But first I wait 2
>> seconds, using Sleep( 2000 ), to give it a chance
>>
>> 2) After the popping out of the previous loop, I pop up a messagebox
>> and ask the user to dismiss it when the CAB file is done. This was
>> necessary on older hardware, but seems no longer needed.
>>
>>
>> >
>> >Vino.
>> >
>> >'Peter Foot [MVP Wrote:
>> >> ']I think the difference is that wceload kicks off a new process to
>> >> perform
>> >> the install and hence the handle used for the initially launched
>> >> process
>> >> closes almost immediately.
>> >>
>> >> Peter
>> >>
>> >> --
>> >> Peter Foot
>> >> Device Application Development MVP
>> >> www.peterfoot.net | www.inthehand.com
>> >>
>> >> "vino" <vino.2e5u5z@-BLCKSPM-no-spam-here.com> wrote in message
>> >> news:vino.2e5u5z@-BLCKSPM-no-spam-here.com...
>> >> >
>> >> > Peter,
>> >> > Many thanks for the info /silent flag.
>> >> >
>> >> > You also mentioned *However I don't think these changes explain the
>> >> > behaviour with waitforsingleobject, which is due to another change
>> >> in
>> >> > WM5.*
>> >> >
>> >> > This is what I understood. The behaviour of WaitForSingleObject has
>> >> > changed in WM5. Can you let me know what/how exactly has changed ?
>> >> The
>> >> > reason I am asking is because, we still need to support PPC2003 as
>> >> > well. I just want to make sure that our application is backward
>> >> > compatible.
>> >> >
>> >> > Thanks again,
>> >> > Vino
>> >> >
>> >> > 'Peter Foot [MVP Wrote:
>> >> >> ']wceload in WM5 no longer uses the/noaskdest /noui switches but
>> >> >> you
>> >> can
>> >> >> use
>> >> >> /silent instead for the same behaviour. If the cab isn't signed and
>> >> >> your
>> >> >> device is set to prompt the user will still need to accept the
>> >> >> security
>> >> >> prompt. However I don't think these changes explain the behaviour
>> >> with
>> >> >> waitforsingleobject, which is due to another change in WM5. You
>> >> could
>> >> >> work
>> >> >> around this by using a custom cesetup.dll in your cab so that you
>> >> can
>> >> >> signal
>> >> >> when installation is complete e.g. trigger a named event.
>> >> >>
>> >> >> Peter
>> >> >>
>> >> >> --
>> >> >> Peter Foot
>> >> >> Device Application Development MVP
>> >> >> www.peterfoot.net | www.inthehand.com
>> >> >>
>> >> >> "vino" <vino.2e2ttz@-BLCKSPM--BLCKSPM-no-spam-here.com> wrote in
>> >> message
>> >> >> news:vino.2e2ttz@-BLCKSPM--BLCKSPM-no-spam-here.com...
>> >> >> >
>> >> >> > We ran into a problem when we shifted our device to Dell Axim x51
>> >> >> [spec:
>> >> >> > OS Name: Microsoft Windows CE; OS Version: 5.1 Build 70;
>> >> Processor:
>> >> >> > StrongARM] from the iPAQ PocketPC 2003 [spec: OS Name: Microsoft
>> >> >> > Windows CE; OS Version: 4.20 Build 1081; Processor StrongARM].
>> >> >> >
>> >> >> > The problem is with wceload. Nothing has changed in the code when
>> >> we
>> >> >> > shifted from PPC2003 to PPC51. The parameters to wceload remains
>> >> *
>> >> >> > /noaskdest /noui "my.cab"*
>> >> >> >
>> >> >> > After searching through the net, I realized that the behaviour of
>> >> >> > wceload has changed from PPC2003 to PPC51.
>> >> >> >
>> >> >> > From this link -
>> >> >> >
http://blog.opennetcf.org/afeinman/default,date,2005-04-20.aspx
>> >> the
>> >> >> OP
>> >> >> > talks about the switch /noaskdest and its peculiar behaviour.
>> >> >> Keeping
>> >> >> > in tune with this fact, the parameters to wceload now became *
>> >> /noui
>> >> >> > "my.cab"*. Now WaitForSingleObject does not return anything. The
>> >> >> > applications justs exits at this point. Though after some amount
>> >> of
>> >> >> > time, the cab gets extracted.
>> >> >> >
>> >> >> > From yet another link -
>> >> >> >
http://support.microsoft.com/default.aspx?scid=kb;en-us;297962 I
>> >> >> used
>> >> >> > the boilerplate code provided there. Even for this approach, the
>> >> >> setup
>> >> >> > application exits just before *if (WAIT_OBJECT_0 ==
>> >> >> > WaitForSingleObject(hEvent, INFINITE))*.
>> >> >> >
>> >> >> > I am out of options now.
>> >> >> >
>> >> >> > I want to know whether the analysis of wceload (on Axim 51) not
>> >> able
>> >> >> to
>> >> >> > perform well with WaitForSingleObject is right ? Am I doing
>> >> >> something
>> >> >> > wrong ?
>> >> >> >
>> >> >> > Can anyone tell me
>> >> >> > 1. What has changed in wceload
>> >> >> > 2. How to overcome the above problem.
>> >> >> >
>> >> >> > Any other approach is welcome as well.
>> >> >> >
>> >> >> > BTW, I have to say these cab files are not signed. Does that make
>> >> >> any
>> >> >> > difference ?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Vino.
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>>
>> -----------------------------------------
>> To reply to me, remove the underscores (_) from my email address (and
>> please indicate which newsgroup and message).
>>
>> Robert E. Zaret, eMVP
>> PenFact, Inc.
>> 20 Park Plaza, Suite 478
>> Boston, MA 02116
>> www.penfact.com
>>