Ascii2

The guide linked to may not work with Windows 2000 setup (any Service Pack level) and I believe the gold (RTM) version Windows XP Professional or Windows XP Home Edition; the guide uses a file to run ("RunOnceEx.cmd") during GUI setup that violawtes 8.3 filenames (short filenames) which are important to maintain. Instead of "RunOnceEx.cmd", something like "Logon.cmd" may be used.

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.

Windows XP Service Pack 3 comes with a new luna.msstyles file. The file binary is different from the older luna.msstyles file, but has the same file version value. What is different about the newer luna.msstyles visual style file?

Simply creating a file named "RunOnceEx.cmd" does not install applications. Instead, add registry keys and values to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx] to install applications or use a script or batch file at RunOnce to run the installations

To run at T36 I without modification of Windows Setup, a program must launch prior to T36 (like at T39 using DetachedProgram) to launch the application at T36. I am uncertain how to have the program detect T36 (but I am interested in knowing).

I have used XXMLINK in the past and have found that it works well, unlike Shortcut from http://www.optimumx.com/download/ or SHORTCUT.EXE included in the Microsoft Windows NT 4.0 Resource Kit.I have not yet tried MakeLink.

I have run Windows XP Professional with Service Pack 1 GUI setup many times and have taken note of when hidden dialogue boxes become available. (Although, I have not noted when the Windows Server 2003 GUI setup hidden dialogue boxes become available, I suspect the time points to be the same.) I note the time points during the GUI setup below: 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)

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/board/index.php?showtopic=131354Windows 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:

In this thread I shall attempt to address and hopefully acquire a correction to a great annoyance of Windows XP and Server 2003 GUI setup that I believe may also be of interest to anyone who runs unattended Windows XP/Server 2003 setups. 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 (the annoyance). I would prefer the dialogue boxes to always display. For an unattended Windows installation for which setup parameters are fully specified by answer file (WINNT.SIF), the dialogue boxes would never display unless [shift] + [F11] were typed for each dialogue box; that is quite undesirable for an unattended installation. Two possible options appear available: Modify Windows Setup to always display dialogue boxes. Run code (either a script or program) that unhides the dialogue boxes. (The code may be started at T-39 using DetachedProgram from WINNT.SIF answer file) I would prefer the second (2.) solution. I have stated this thread to organize the finding and discussing a solution of this problem by any means available. I believe the MSFN.org forums has members qualified to implement option number 2 and have also started a thread in the Programming (C++, Delphi, VB, etc.) forum discussing implementation of the solution (2.) for this problem. That thread is located at: http://www.msfn.org/board/index.php?showtopic=131355See next post. EDIT: Considering that the default show state of the dialogue boxes is hidden, I suspect that many users may have been unfamiliar with the dialogue boxes during the GUI part of Windows XP/Server 2003 setup. The dialogue boxes are similar to those used in older NT Windows setups like for Windows 2000. I have attached images showing what the dialogue boxes, once set visable look like:

I tried it and it did not work.I have found the correct property: MSIEXEC /i <packagename> /qb ALLUSERS="1" OR MSIEXEC /i <packagename> /qb ALLUSERS="2" If Administrative privileges do not exist ALLUSERS="1" will fail to install; when ALLUSERS="2" an installation to the current user would occur.

Windows Installer packages (MSI) can be installed unattended using: "MSIEXEC /i <packagename> /qb", where "<packagename>" is the name of the MSI package.Some MSIs have a choice to install for all users or only the current user. When using the line above to install the package unattended, the package is installed only for the current user. How can an MSI package be installed unattended for all users?

6.2 MB does seem like a reasonable size. The minimum is one or two. Usually "Current" and "Default" reference the same ControlSet and Last Good refers to an additional ControlSet used for the Last Known Good Configuration. I am uncertain if the operation system would boot if the Last Good Control set were deleted. The long pause during Windows 2000 boot is normal. You possibly may be able to lessen the length of the pause, but it would still remain long relative to the other occurrences during the boot process. Try the following to lessen the boot time: Examine the drivers you have installed, remove unless drivers, change inefficient drivers if possible, or replace or remove hardware (and their drivers). Check the hard disk acoustic management, power management, and transfer mode settings if they exist and adjust them to maximize performance. Adjust BIOS settings to improve boot performance if possible. Ensure that all cables are well connected and of sufficient quality.

"Share" probably should have been "Shares" in the KB article; "Share" may be a typo.You should be able to delete one of your three ControlSets. Check the [HKEY_LOCAL_MACHINE\SYSTEM\Select] key to determine what control sets are being used for "Current", "Default", and "LastKnownGood". You may delete all other ControlSets. If you are able to reduce you SYSTEM hive sufficiently such that the Windows XP boot loader is able to load Windows 2000, Windows 2000 may in the future fail to boot if the SYSTEM hive continues to grow. It may best just to continue using the Windows 2000 boot loot files.

If you slipstream the Windows 2000 Service Pack 4 update into a Windows 2000 installation source the . The Windows 2000 Service Pack 4 redistributable does not contain all the files necessary to install the updated Recovery Console, but once slipstreamed into a Windows 2000 installation source, the updated Recovery console may be invoked using the installation source's "Winnt32.exe".A download from Microsoft Corporation exists that has the files necessary to install the Recovery Console, but installing from it is not publicly a Microsoft documented method (I have forgotten what package(s) exactly to download).

It seems that you made a discovery Dave-H. It is possible that Windows XP does not allow its registry hives to grow very much and its loader cannot handle large registry hives as well as Windows 2000. I have looked into this issue, and it seems that problems with large registry files were corrected in a patch during year 2000 and the fix was included in Windows 2000 Service Pack 2. It may be best for you to use a recent version of the Windows Server 2003 boot loaders. Acording to KB302594, Windows 2003 should be able to load much larger registry hives. It may be that the Windows Server 2003 may not load Windows 2000 as quickly as a recent boot loader from Windows 2000. Note that Windows Server 2003 also uses a boot loader "Osloader.ntd". Articles related to registry hive size and boot (none pertaining to Windows XP): http://support.microsoft.com/kb/302594/ http://support.microsoft.com/kb/259930/ http://support.microsoft.com/kb/270028/ http://support.microsoft.com/kb/277222/ http://support.microsoft.com/kb/216369/

The Windows XP disc (assuming you meant disc) is not necessary. Recent version of ntldr and ntdetect.com for Windows XP may be found within the Windows XP Service Pack 3 redistributable (or just use the files from the archive I have attached to this post). The files need not be expanded after extraction from the package. No. You also would need to delete the Recovery Console information from boot.ini. If you are referring to Recovery Console that comes with Windows XP, yes. Versions of Recovery Console from a Windows XP operating system of at least Service Pack level 2 will perform an OS check. If the operating system is not determined to match the operating system in use (including Service Pack level), installation aborts. I would recommend installing the recovery console from a Windows 2000 with Service Pack 4 CD (or bootdisks) instead.

If you suspect the hard disk, first check the S.M.A.R.T. status of the drive (I would recommend using SpeedFan). Then, if S.M.A.R.T. appears fine, use the manufacturer's hard disk diagnostic program to check the disk. Report the version of "newdev.dll" located at "%SystemRoot%\system32".

This is news to me. Care to expand on this? Windows Server 2003 products may use a boot loader file named "Osloader.ntd" (NTLDR and NTDETECT.COM may still exist). I am uncertain between the relationship between the different boot loaders of Windows Server 2003.

I have been able to test the EnableUDMA66 value affect on a computer using a Intel chipset and an IDE hard disk capable of transfering at rates greater than UDMA66. The hard disk was still able to transfer at rates greater than UDMA66 after applying the UDMA66 set to 1 registry modification.I noted a burst spped performance increase for the hard disk of about 6.25% after enabling the UDMA66 setting (only ran a benchamark a single time to test).

The size is large, although possibly not excessive (not something I am able to determine for you). The Recovery Console comes with a boot loader and NTDETECT.COM. Different versions of Recovery Console exist with different versions of their boot loader (CMLDR). I believe your problem is mainly do to design (defects) of the boot loaders.Try removing the Recovery Console, prepare a floppy capable of booting Windows 2000 (in case booting from hard disk partitions fails later), install a recent version of Recovery Console (like from a Windows 2000 Professional with Service Pack 4 CD, not of a lower Service Pack), copy a recent version of Windows XP (not Windows Server 2003, as it seems to use a different file to load the operating system) NTLDR and NTDETECT.COM to the root of the system drive, and restart the computer.

Yes.I have also known about HFSLIP. It has, however, been unclear if HFSLIP can be forced to only use Microsoft supported methods of integration. If the Windows installation source binaries are updated when the /integrate switch is used, that may be acceptable. A method of integration for the update packages that do not support the /integrate switch is described in KB828930 ( http://support.microsoft.com/kb/828930/ ) starting "Earlier versions of Update.exe". The method is not the SVCPACK.INF described on unattended.msfn.org. The method seems too time consuming to manually repeat many times. I was looking for a tool that would support this method of integration without doing something different.

Older versions of NTLDR could not load large fragmented registry hives during Windows boot (this was before Windows XP; Windows 2000 with Service Pack 4 NTLDR). Newer versions of NTLDR should not (not the same as "do not") have the problem.Auslogics Registry Defrag (among many others) is software that may defragment registry hive files. If the registry hives that are maintained loaded in memory stay at about the same size (regardless if the size is great), do not expect much fragmentation. By the way, if you test versions of NTLDR, it may be wise to keep a copy of the versions boot.ini, NTDETECT.COM, NTLDR, Ntbootdd.sys if necessary for SCSI, and possibly arcldr.exe and arcsetup.exe that boot Windows 2000 on a floppy. If you cannot later boot, from the hard disk partition, you may use the floppy to boot Windows 2000. Also Dav-H, do you have a recovery console installed?

Please add support for the Microsoft packages such as the one available: http://www.microsoft.com/downloads/details...;displaylang=en

I had posted a long reply to this thread (took me about 30 minutes), but Internet Explorer stopped responding on click of the "Add Reply" button.

Booting from the Windows XP CD.