[Ascii2]

This thread is intended to facilitate the development of a program or script that can run during the early parts of Windows XP or Windows Server 2003 GUI setup described by the thread (“main thread”):

http://www.msfn.org/...howtopic=131354

Windows XP and Windows Server 2003 setups during the GUI part of the installations have progress and options dialogue box windows. Each dialogue box is hidden unless [Shift] + [F11] is typed or input is required.

A program to unhide the dialogue boxes is desired.

There are four dialogue boxes to be unhidden. I describe them and when they become available:

T-37: Fist Dialogue Available
	Installing Devices

T-32:  Second Dialogue Available
	Networking Settings

T-29:  Third Dialogue Available
	Installing Components

T-22:  Fourth Dialogue Available
	Performing Final Tasks
		(Install Start menu items, Register components,
		 Saves settings, Removes any temporary files used)

A methods I have thought may work:

A program may be developed that automatically sends [Shift] + [F11] when a hidden dialogue box becomes available. The program would be started at T-39 during the GUI portion of setup, occuring before the dialogue boxes become available and remain running until just after T-22.

I request the creation of a program to unhide the hidden dialogue boxes of Windows XP and Windows Server 2003 GUI portion of setup (which should be quite useful for many MSFN.org members).

I suspect the best programming language to use for this task is C, C++, or Delphi.

To reduce confusion, I have attached to this post images of what the doialogue boxes, once unhidden, should loook like:

Attached File(s)

•  Installing_Devices.gif (36.4K)
  Number of downloads: 11
•  Networking_Settings.gif (34.05K)
  Number of downloads: 9
•  Installing_Components.gif (28.2K)
  Number of downloads: 4
•  Performing_Final_Tasks.gif (28.41K)
  Number of downloads: 5

This post has been edited by Ascii2: 28 March 2009 - 11:51 PM

[gunsmokingman]

Why dont you pick up some books or the many tutorials on what ever language you think will work and do it your self.
Myself I see no real need for some thing like this.

[Ascii2]

gunsmokingman, on Mar 21 2009, 12:07 PM, said:

Why dont you pick up some books or the many tutorials on what ever language you think will work and do it your self.

If the quoted statement was meant as an inquiry, I would code it myself if it were efficient.

I have not written programs other than simple batch scripts for many years and doing it myself would require much more expensive than it may would be worth.

For others, this type of task may be significantly less expensive and would therefore be more qualified to perform the task; the utility gained by from the task's output (the program that results in unhiding of windows during Windows XP/Server 2003 GUI setup) may (greatly) exceed the expense (input).

The utility gain may benefit many more than myself, possibly including the programmer.

This post has been edited by Ascii2: 26 March 2009 - 12:33 AM

[gunsmokingman]

Explain

Quote

The utility gain may benefit many more than myself, possibly including the programmer.

When all you want to do is slow down a install. What posssible benifit is going to gained by showing those dialogs, remember Microsoft had a reason to
keep them hidden. There is nothing to be gain by showing them.

I know I would not even try to program something like this because the information you are trying to see is useless information. Explain the porpose of
showing uselesss information that is going to benifit the programmer.

[Ascii2]

gunsmokingman, on Mar 26 2009, 09:37 AM, said:

Explain

Quote

The utility gain may benefit many more than myself, possibly including the programmer.

Other entities than myself may derive a benefit.

gunsmokingman, on Mar 26 2009, 09:37 AM, said:

When all you want to do is slow down a install.

This is incorrect. I do not want to slow down the installation.
I recognize that a slow down would occur (a cost) be believe it to be negligible (the slowdown would be the time to run a small program at from DetachedProgram and performing four unhiding operations). The benefit derived (answered below) is believed to greatly exceed the cost.

gunsmokingman, on Mar 26 2009, 09:37 AM, said:

What posssible benifit is going to gained by showing those dialogs...

The dialogue convey useful information. The dialogue boxes show progress of portions of the installation process and explain what the setup should be doing. The dialogue boxes also cover up the GUI setup advertisements that are not as useful.

gunsmokingman, on Mar 26 2009, 09:37 AM, said:

remember Microsoft had a reason to
keep them hidden. There is nothing to be gain by showing them.

Microsoft Corporation would seek its own interest when deciding how it should act. Its interest is not necessarily what is good for the user (good example include Windows Product Activation, Windows Genuine Advantage, and requiring the input of a Product Key).

I would speculate that the reason Microsoft Corporation set the dialogue boxes to run hidden is because it was less expensive and also would retained compatibility with processes of earlier NT-based Windows (like Windows 2000). To add a new Windows XP look to the GUI and advertise the product during setup, Microsoft simply set a background to cycle a new image (with advertisement) periodically and set the dialogue boxes to hidden because they would reduce the effectiveness of the advertisements. A mechanism was left to make visible the dialogue boxes (by sending [Shift] + [F11]), but it is not so easily done unattended.

[gunsmokingman]

Quote

good example include Windows Product Activation, Windows Genuine Advantage, and requiring the input of a Product Key

So what you are saying then is that you are against Microsoft from having any recource to check to see if you are using
there legitimate software.

Your arguments make no sence all you want to see is nothing more then debugging information, to slow down the install.

Example If you alllow 30 seconds per dialog you have added Two minutes more to your install.

It would of cost Microsoft nothing to unhide these boxes since it there source code no more then One line of code.
They choose to make them hidden to make the install go faster.

If you think it would be a easy task just to whip some thing for something of no importance then grab some C++ tutorials
and see how much work would be involved to do this.

[Kelsenellenelvian]

Umm I see no real need for this either, but an auto-it script that has been compiled should do the trick.

Simply have it "push" the needed buttons and then watch the window title and when it is gone have it wait for like 10000 and "push" the buttons again.

Personally I like, as most members here probably do, to have much less then more. 2-5 minutes is a lot of time when you are doing 100 installs.

This post has been edited by Kelsenellenelvian: 28 March 2009 - 09:22 PM

[MHz]

The dialogs already exist during setup so I fail to see the relevance stated about "slowing" down the install. The dialogs are behind the billboard that covers them up. Info here shows you how to remove the billboard so the dialogs are seen without any other action needed nor any resources wasted.

Here is an AutoIt script that may help if you want to keep the billboard. Changes maybe needed depending on the state and reaction of the windows. Resources wasted would be very little to notice.

$title = 'Windows XP Professional Setup'
_WinWaitSetState($title, 'Installing Devices')
_WinWaitSetState($title, 'Network Settings')
_WinWaitSetState($title, 'Installing Components')
_WinWaitSetState($title, 'Performing Final Tasks')

Exit

Func _WinWaitSetState($title, $text = '', $flag = @SW_SHOW)
	WinWait($title, $text)
	WinSetState($title, $text, $flag)
	WinActivate($title, $text)
EndFunc

[Ascii2]

MHz, on Mar 28 2009, 10:33 PM, said:

The dialogs already exist during setup so I fail to see the relevance stated about "slowing" down the install.
...
Resources wasted would be very little to notice.

This was also my conclusion. It would take a grossly inefficient program to casue a noticable slow down of setup.

MHz, on Mar 28 2009, 10:33 PM, said:

Info here shows you how to remove the billboard so the dialogs are seen without any other action needed nor any resources wasted.

The page linked to is of interest. It shows what seems to be the only method of not showing the billboards for the entire GUI setup.

The method of removing the use of the billboards during GUI setup shows the dialogue boxes centered both horizontally and vertically. Making the dialogue boxes hidden by the billboard visible by sending [Shift] + [F11] results in the dialogue box visible aligned centered verticall, but not horizontally. Perhaps [Shift] + [F11] invokes a repositioning of a dialogue box.

MHz, on Mar 28 2009, 10:33 PM, said:

Here is an AutoIt script that may help if you want to keep the billboard. Changes maybe needed depending on the state and reaction of the windows.

$title = 'Windows XP Professional Setup'
_WinWaitSetState($title, 'Installing Devices')
_WinWaitSetState($title, 'Network Settings')
_WinWaitSetState($title, 'Installing Components')
_WinWaitSetState($title, 'Performing Final Tasks')

Exit

Func _WinWaitSetState($title, $text = '', $flag = @SW_SHOW)
	WinWait($title, $text)
	WinSetState($title, $text, $flag)
	WinActivate($title, $text)
EndFunc

Thanks,

Given this information, I now intend to use versions of the setup with and without the billboards, but always displaying existing the dialogue boxes.

Of interest is GrofLuigi's post here. GrofLuigi claims a "speeding up [of] the process" when billboards are removed. The process GrofLuigi was referring to, I believe to be the GUI part of setup. If my interpretation of his statement is correct and its significance valid, removing the billboards should reduce the time Windows setup takes to install Windows XP/Server 2003, all else equal. The modification to remove the billboards is, however, inconvenient for a frequently updated installation source when patch integration is performed.

I shall schedule some time to try the script compiled to an application in a few days.

Disabling of the billboard would have been a useful option for the WINNT.SIF answer file.

EDIT: This post has been edited to fix a mispost. Not all words copied and pasted when copying and pasting text between a few applications (oddly).

This post has been edited by Ascii2: 02 April 2009 - 12:41 AM

[GrofLuigi]

Ascii2, on Apr 2 2009, 06:45 AM, said:

Of interest is GrofLuigi's post here. GrofLuigi claims a "speeding up [of] the process" when billboards are removed. The process GrofLuigi was referring to I believe to be the GUI part of setup. If my interpretation of his statement is correct its significance valid, it may be incovienient editing

I shall schedule some to to try the script in a few days.

Disabling of the billboard would have been a useful option for WINNT.SIF answer.

I have not taken exact measurements, and the only way to know would be to apply exact same "tweaks" and "removing components" in other parts of nLite and make two builds with only this part different. I didn't do that, but *seems* faster... Might be totally subjective.

But that wasn't my point, my point was that it had never shown me any more useful info than the billboards (and I have done many nLite builds, some being broken, but even then - a dialog box appears in both cases, or the whole setup just hangs).

GL

[Ascii2]

I tried an application converted from the AutoIT script posted by MHz above, and it failed to unhide the dialogue boxes.

Perhaps the setup with the billboards is not the same setup without the billboard (this seems true of setup or mini-setup invoked by sysprep.exe); the dialogue boxes may not exist as dialogue boxes until [Shift] + [F11] is sent.

[vsu]

Ascii2, on Apr 2 2009, 08:45 AM, said:

Disabling of the billboard would have been a useful option for the WINNT.SIF answer file.

If you have WINNT.SIF with OemPreinstall=Yes, you can disable billboards by creating an empty file $OEM$\$$\SYSTEM32\WINNTBBU.DLL (when starting setup from CD, use the $OEM$ directory at the root of CD, not \I386\$OEM$). At the end of the text-based setup this file will be copied to the installed system, overwriting the default WINNTBBU.DLL. When the GUI setup loads, it will fail to load WINNTBBU.DLL and fall back to the old setup style. Later during setup the original WINNTBBU.DLL will be restored by SFC, but look of the running setup will not change.