13 replies to this topic

[fxscrpt]

Hi Peter,


this code

Set,%Current%,NIL

If,EXISTREGKEY,HKLM,WB-Setup\ControlSet001\Control\ServiceGroupOrder,List,RegRead,HKLM,WB-Setup\ControlSet001\Control\ServiceGroupOrder,list,%current%

If,EXISTVAR,%Current%,Set,%Write%,%Current%#$cUIGroup

Else,Set,%Write%,UIGroup

RegWrite,HKLM,0x7,WB-Setup\ControlSet001\Control\ServiceGroupOrder,list,%Write%

writes this REG_MULTI_SZ value :

"drivers","Boot Bus Extender","System Bus Extender","Input Device Support",UIGroup

i'm sorry for bad news.


and a feature request, if possible:
ShellExecute causes delays:
for me
e.g

unmountig imdisk drives (imdisk -d ....) drives: delay ~20 sec.

while runnig iso in emulator, staring explorer search wizard: delay up to 30 sec.


Thanks.

Peter

[pscEx]

You mean the quotes around the old values?
Hard job ...
Maybe it has to wait for the next big change of "quote, comma, space" in argument handling.
Can you try to bypass the issue by using StrFormat,Replace?

ShellExecute does not cause any delay directly. In a loop with half a second wait time, it waits until there is an exitcode from the started process.
I do not know how to accelerate that.

Peter

[fxscrpt]

You mean the quotes around the old values?
Hard job ...
Maybe it has to wait for the next big change of "quote, comma, space" in argument handling.
Can you try to bypass the issue by using StrFormat,Replace?

i mean it writes a single value, not a list of values, with all quotes and commas.
this

StrFormat,REPLACE,%Write%,"#$q","",%Write%

and this

StrFormat,REPLACE,%Write%,"#$q","",%Write%

StrFormat,REPLACE,%Write%,"#$c","##$c",%Write%

writes a single value without quotes, but with commas:

drivers,Boot Bus Extender,System Bus Extender,Input Device Support,UIGroup

ShellExecute does not cause any delay directly. In a loop with half a second wait time, it waits until there is an exitcode from the started process.
I do not know how to accelerate that.

Peter

Peter, not directly.
Please trust me, i can reproduce delay in my code.
You can safely reduce wait time to 20 or 10 ms.
CPU will be at 0%, if there is only processing of messages.

if there is something 'extra' to do in the loop and you dont want to run this 'extra' every 20ms , just run it in every 25th or 50th loop.

For my code , even 100ms wait time causes a noticeable delay.
However, thats only a wish with low priority.





Peter

[pscEx]

Sorry, Peter!

I did not realize the 'single value' in your post.
Now for me it looks like a really nice bug!

To the delay: I can try to reduce the 500 msec to maybe 20 msec.

But IMO that can reduce your waiting time only by half a second.
The reason for the 20 seconds is not explainable for me.

Can you try to execute that apps

• In CodeBox
• In a cmd window

and compare?

Peter

[fxscrpt]

Sorry, Peter!

I did not realize the 'single value' in your post.
Now for me it looks like a really nice bug!

To the delay: I can try to reduce the 500 msec to maybe 20 msec.

But IMO that can reduce your waiting time only by half a second.
The reason for the 20 seconds is not explainable for me.

Can you try to execute that apps

• In CodeBox
• In a cmd window

and compare?

Peter

Hi Peter,

cmd window: (imdisk -d -m Y:) : duration 1-2 sec.
codebox: (ShellExecute,open,"imdisk","-d -m Y:") : duration 48 sec.
(imdisk hangs at message 'sending device removal notifications')

But IMO that can reduce your waiting time only by half a second.
The reason for the 20 seconds is not explainable for me.

Let's say an application will send 50 messages using SendMessage function.
The sender will not return until the window procedure of receiver has processed the first message. Then the sender can send the second message an so on.
In this situation the sender will be blocked for 50 x 500ms.

Peter

[pscEx]

Hi Peter,

cmd window: (imdisk -d -m Y:) : duration 1-2 sec.
codebox: (ShellExecute,open,"imdisk","-d -m Y:") : duration 48 sec.
(imdisk hangs at message 'sending device removal notifications')


Let's say an application will send 50 messages using SendMessage function.
The sender will not return until the window procedure of receiver has processed the first message. Then the sender can send the second message an so on.
In this situation the sender will be blocked for 50 x 500ms.

Peter

@fxscrpt:
Thanks, Peter, for your explanations.

Please try the attached WB with 'the other extreme' 1 msec wait time.
For all users: This is the current stage of my development. Please, do not try to use in a 'productive' enviromment, even if the name is known.

Peter

[pscEx]

Let's say an application will send 50 messages using SendMessage function.
The sender will not return until the window procedure of receiver has processed the first message. Then the sender can send the second message an so on.
In this situation the sender will be blocked for 50 x 500ms.

Let me give a bit OFFTOPIC story to the community.
That remembers me on some issues when I have been working for a US / Boston company.

At that stone-age time, we wrote programs in assembler code.
And the OS had several priority levels:
0: User level
...
6: User editor level
7: System level

Some very clever programmers wanted to make their program faster by giving it level 6 or even level 7.

But as result mostly the COMPLETE system slowed down.

Reason: The OS monitor processes:

• All 7 level tasks
• All 6 level tasks
• ...
• All 0 level tasks

If a 7 level task calls a 0 level task, it has to wait until the 0 level task is activated. And that can need some time ...
In this time the 7 level task gets some 10000 activations, where it only waits for his 0 level child ...

At that time I learned, never to try to fasten the process by changing priorities ...

Just the reminders of an old man, not relevant here ...

Peter

[paraglider]

There should be no need to wait at all. Assuming hHandle contains a handle to the process you are waiting to exit.

for (;;)

{



		   DWORD result&#59; 

	MSG msg&#59; 

	// Read all of the messages in this next loop, removing each message as we read it.		 

	while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) 

	{ 

	   // If it's a quit message, we're out of here. 

	   if (msg.message == WM_QUIT)				   return; 

	   // Otherwise, dispatch the message. 

	   DispatchMessage(&msg); 

	 } // End of PeekMessage while loop.  



	  result = MsgWaitForMultipleObjects(1, &hHandle,				   FALSE, INFINITE, QS_ALLINPUT);

			 // The result tells us the type of event we have.		 

	  if (result == (WAIT_OBJECT_0 + 1))		 

	  {			 

		  // New messages have arrived.			  

		  // Continue to the top of the for loop to dispatch them and resume waiting.			 

		  continue;		 

	   }		  

	   else		  

	   {			  //  Process Exited

		   GetExitCodeProcess(hHandle, &ExitCode)

		   return;

	   }

}

[pscEx]

What is the logical difference to the current WinBuilder code

begin

			  while GetExitCodeProcess(exinfo.hProcess, exitcode) and

				(exitcode = STILL_ACTIVE) and (Scripthalt = False) do

			  begin

				WaitForSingleObject(ExInfo.hProcess, 1);

				ProcessMessages; //application.ProcessMessages;

				if scriptHalt then

				  terminateProcess(exInfo.hProcess, WM_QUIT);

				if actShow then

				begin

				  ProgressBar2.StepIt;

				  if ProgressBar2.Position = ProgressBar2.Min then

					ProgressBar2.Step := -ProgressBar2.Step;

				  if ProgressBar2.Position = ProgressBar2.Max then

					ProgressBar2.Step := -ProgressBar2.Step;

				end;

			  end;

			  scriptVarsOri.Variable['%ExitCode%'] := IntToStr(exitcode);

			  scriptVars.Variable['%ExitCode%'] := IntToStr(exitcode);

			end;

Peter

[fxscrpt]

@fxscrpt:
Thanks, Peter, for your explanations.

Please try the attached WB with 'the other extreme' 1 msec wait time.
For all users: This is the current stage of my development. Please, do not try to use in a 'productive' enviromment, even if the name is known.

Peter

Winbuilder rocks! ShellExecute duration: 1-2 sec.
But 1ms is very extreme, because (depends on workstation or server)
scheduler task switching time is minimum 3ms.

Peter

[pscEx]

Winbuilder rocks! ShellExecute duration: 1-2 sec.
But 1ms is very extreme, because (depends on workstation or server)
scheduler task switching time is minimum 3ms.

Peter

Great! You teached me something (inportant) new!

I'll use 10 msec. I hope that fullfills your ideas!

Peter

[paraglider]

The big difference is the INFINITE i.e. its not polling for process exit / windows messages. This means it waits indefinitely for a windows message or the process to exit.

Waiting for 1ms means you just give up the time slice and then get immediately rescheduled to run. Which means you have more impact on the process that you are waiting to exit and the rest of the system. If you only have 1 CPU then this becomes more of an issue.

[pscEx]

The big difference is the INFINITE i.e. its not polling for process exit / windows messages. This means it waits indefinitely for a windows message or the process to exit.

Sorry, paraglider,
I do not understand your post
(remember my 'German 1 year school English' )
Can you try to explain it to a fool?

Peter

[paraglider]

This is what I was referring to:

MsgWaitForMultipleObjects(1, &hHandle, FALSE, INFINITE, QS_ALLINPUT);


This waits for the process to exit or for a message to appear on the message queue. So you can pump messages as soon as its required to pump messages.

If you need to do other things like update a progress bar then this could be replaced with:

MsgWaitForMultipleObjects(1, &hHandle, FALSE, 500, QS_ALLINPUT);

which still gives you the immediate detection of messages / process exit but has a much smaller impact on the rest of the PC.