Hotfix Installer?

[submix8c]

1- Offline After OS Installed - the BAT/CMD method (above)

2 - OEM Integrated Install - the $OEM$ folder (note that the WINNT.SIF needs that Section to copy the OEM folder)

3 - Non-OEM/OEM Integrated Install - QCHAIN method

4 - Full Integration Method - nLite (or manually)

Been using #2 to preserve Original Install (for OEM Refurbishing) - "quick" install from HDD using the Section, remove the Section for the CD (must install Fixes/Drivers manually double-click BAT/CMD). $OEM$ inside I386 for HDD, next to it for CD (so a "Repair Re-Install" will work).

Edited August 1, 2012 by submix8c

[Ascii2]

Yes, I used "Preserve Download Modification Timestamp" addon.

While in the big picture the order was clearly ascendent it wasn't in a strictly manner:

KB931261 08/02/2007 18:28:20
KB925902 02/03/2007 13:12:08
KB932168 21/03/2007 16:51:12
KB929123 04/05/2007 08:06:26

I added the qchain.exe line just before the pause. But placed it in another folder to don't interfere with the "call all .exe in current folder" loop.

What I don't understand from reading the bulletin you offered me is that an example for installing the hotfixes is given using the update.exe program and a command line script. Maybe that is another option (better?) for installing hotfixes?

Typically, When an update package is run, use of select arguments notwithstanding, it is extracted and an update program (typically "update.exe") from the extracted files is run. Extracting the update packages first, then running the update program seems only better in the following circumstances:

1. It is preferred to explicitly specify the extraction location (determination of such explicit location may still be variable)
   
2. Update package does not (or cannot) invoke update program
   
3. It is desirable to perform another or other operations between the extraction of an update package and the running of the update program.
   
4. It is not desired to use an argument that update package supports that the the update program does not support ("/integrate" switch is an example )
   
5. Alternate method or software of or for package extraction is proffered.
   

EDIT: Anyway it looks qchain to be a bit rendundant: link

The use of QCHAIN.EXE often is redundant. However, considering that QCHAIN runs quickly and is a small program, it is often preferable to run QCHAIN.EXE after installing multiple updates with only a single reboot, than it is to check the versions of the individual update programs to determine whether they should contain the QCHAIN program logic. Trying to script also much more complex.

Newer (within about the last 9 years) updates often should contain the QCHAIN logic; sometimes or oftentimes what should happen or exist does not always happen or exist (this is often due to error or defect). It is safer to use QCHAIN.EXE than to not.

[Ascii2]

Also, I noticed that Dogway has stated the he is using Window XP Professional x64 Edition. QCHAIN.EXE was developed originally for use on 32-bit Windows 2000 family operating systems; it may or may or work well on that operating system. I am not sufficiently familiar with 64-bit versions of Windows Server 2003 to be able give good council on this.

Also, the FOR loops above are only applicable when it is desired that updates packages with branching start evaluating from the default branch.

[Dogway]

@submix8c : sorry I don't understand #2. Indeed my XP x64 is OEM, it came installed with the system. I used method #1 so I did it wrong?

@Ascii2: Maybe QCHAIN.exe runs in x86 compatibility mode, haven't tested but is a possibility.

[submix8c]

#2 - ref. this. Using appropriate BAT/CMD and a CMDLINES.TXT you can do it in an "unattended" install. Properly set up, you can both install from HDD (via a WinPE) and have a CD ready in case of "failures" and use the BAT/CMD to reapply the Fixes (what I do).

Also see this topic.

No, you didn't err using #1 - my #2 method "incorporates" #1 (see above). The fact that it's an OEM version is not (necessarily) relevant - it may already have Drivers and some Hotfixes "integrated".

Was just inserting variations of the same "theme".

Edited August 1, 2012 by submix8c

[Dogway]

ex. the date listed next to the "BUILDTIMESTAMP" entry in the "update\update.inf" of each update.

I've been wondering whether it matters that the build timestamp is not the same as the release timestamp, for example the next hotfix:

WindowsXP-KB978338-x86-ESN.exe

Release Date 12/04/2010

Timestamp 12.02.2010

And inside the update_SP2GDR.inf file (the other 3 .inf as well):

BUILDTIMESTAMP = 1

EXPIRETIMESTAMP = 20100413.094910

[tomasz86]

In older updates there was only one "BUILDTIMESTAMP" entry but now they seem to use BUILDTIMESTAMP + EXPIRETIMESTAMP. I'm not really sure what's the purpose of it.

[Dogway]

The thing is that the release dates are very different from build dates (sometimes months), I don't know if that the order then is altered.

Anyways unless someone indicates otherwise, I'll be using the order I got from downloading them with the "Preserve Timestamp" addon... But I wanted to have it noted, just in case it would matter.