Jump to content











Photo
- - - - -

regwrite 0x7 issue


  • Please log in to reply
13 replies to this topic

#1 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 30 September 2009 - 12:16 PM

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

#2 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 30 September 2009 - 02:18 PM

You mean the quotes around the old values?
Hard job ... :whistling:
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

#3 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 30 September 2009 - 03:16 PM

You mean the quotes around the old values?
Hard job ... :whistling:
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.

:D



Peter

#4 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 30 September 2009 - 04:17 PM

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

#5 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 30 September 2009 - 06:13 PM

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.
:whistling:
Peter

#6 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 30 September 2009 - 06:31 PM

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.
:whistling:
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

#7 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 30 September 2009 - 07:20 PM

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

#8 paraglider

paraglider

    Gold Member

  • .script developer
  • 1739 posts
  • Location:NC,USA
  •  
    United States

Posted 30 September 2009 - 07:21 PM

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;

	   }

}


#9 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 30 September 2009 - 07:28 PM

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

#10 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 30 September 2009 - 07:41 PM

@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

#11 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 30 September 2009 - 07:48 PM

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 :whistling:

#12 paraglider

paraglider

    Gold Member

  • .script developer
  • 1739 posts
  • Location:NC,USA
  •  
    United States

Posted 30 September 2009 - 07:56 PM

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.

#13 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 30 September 2009 - 08:01 PM

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

#14 paraglider

paraglider

    Gold Member

  • .script developer
  • 1739 posts
  • Location:NC,USA
  •  
    United States

Posted 30 September 2009 - 08:13 PM

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users