PIC vs. APIC, hardware independent images, and Driver Roll Back

[Guest]

Hello, all;

I have been building Windows XP SP 2 images and have been trying to create
one that will work for most hardware in use where I work. I have run into
the situation that others have where using the "ACPI Uniprocessor PC" (ACPI
APIC UP HAL) on my master build machine causes the image to fail on machines
that use the "Advanced Configuration and Power Interface (ACPI) PC" (ACPI PIC
HAL) driver. Like others have, I found that using "Advanced Configuration
and Power Interface (ACPI) PC" on the master build machine causes the image
to work on most hardware. However, now I have the situation where any PC I
put this image on is using the ACPI PIC HAL, and as it says in KB article
309283, "...running a PIC HAL on an APIC computer is not supported" (not to
mention my multiprocessor PCs only show one processor).

I have read where others manually copy the HALAACPI.DLL for APIC PCs. I now
have the image autologon after the minisetup and script the use of the
SMBIOSD.EXE utility and flag for the "On-chip APIC supported" string. If the
string is found, the script copies the HAPAACPI.DLL to %sysdir%\system32,
then reboots. This works well, because if the PC is multiprocessor or
hyperthreaded, XP will automatically update the HAL to HAPMACPI.DLL. The
downside to this is now my builds are not supported: from the same KB article
309283: "Microsoft also does not support swapping out the files that are used
by the HAL to manually change HAL types."

A brief aside: I can take my personal workstation that uses the "ACPI
Multiprocessor PC" (ACPI APIC MP HAL) and "update driver" to "Advanced
Configuration and Power Interface (ACPI) PC." Since this is not supported
(PIC HAL on APIC PC), I can "Roll Back Driver" to "ACPI Multiprocessor PC."
Now I assume my PC is supported again.

So if I can't manually copy the file, can I do this:

Build my master image with "ACPI Uniprocessor PC" and then update the driver
to "Advanced Configuration and Power Interface (ACPI) PC." Sysprep my image,
and then when ghosted onto the target PC, have it autologon and use
SMBIOSD.EXE to flag for APIC. If found, instead of manually copying the
file, do an automated Driver Roll Back. Viola, no manual swap of files,
hence, still supported.

This brings me to my question: is there a way to script the roll back of the
driver?

Thanks;
T. Tyrone

 

[Adam Leinss]

Hello, all;

I have been building Windows XP SP 2 images and have been trying
to create one that will work for most hardware in use where I
work. I have run into the situation that others have where using
the "ACPI Uniprocessor PC" (ACPI APIC UP HAL) on my master build
machine causes the image to fail on machines that use the
"Advanced Configuration and Power Interface (ACPI) PC" (ACPI PIC
HAL) driver. Like others have, I found that using "Advanced
Configuration and Power Interface (ACPI) PC" on the master build
machine causes the image to work on most hardware. However, now I
have the situation where any PC I put this image on is using the
ACPI PIC HAL, and as it says in KB article 309283, "...running a
PIC HAL on an APIC computer is not supported" (not to mention my
multiprocessor PCs only show one processor).

Sorry, no solution, just a comment! I've used the APCI HAL for
all my Windows 2000 and Windows XP images at two different companies
without incident. Dells, Compaqs, HPs, Gateways, even clones, it all
works great.

I understand your want to conform with Microsoft's recommendations,
but using a 3rd party tool to determine the processor type and then
have it pick the right HAL isn't supported either. Microsoft only
supports using different images for different HAL types:

http://technet2.microsoft.com/WindowsServer/en/Library/16a9be2c-156d-
45d7-8329-b9b23097b3b61033.mspx.

Curiously, some Microsoft employees have praised people for making an
"universal image" for all hardware using "unsupported Microsoft
methods", others have condemened it. At the end of the day when I
have 8 different types of hardware and I can use one image or
several, I choose one. "The needs of the many outweigh the needs of
the few or the one", as Dr. Spock would say.

P.S. I have yet, after asking why using an ACPI HAL on a Uniprocessor
is bad, gotten a response as to why it is bad or unsupported (other
then Microsoft simply stating "not supported").

Adam

 

[Guest]

Sorry, no solution, just a comment! I've used the APCI HAL for
all my Windows 2000 and Windows XP images at two different companies
without incident. Dells, Compaqs, HPs, Gateways, even clones, it all
works great.

I understand your want to conform with Microsoft's recommendations,
but using a 3rd party tool to determine the processor type and then
have it pick the right HAL isn't supported either. Microsoft only
supports using different images for different HAL types:

http://technet2.microsoft.com/WindowsServer/en/Library/16a9be2c-156d-
45d7-8329-b9b23097b3b61033.mspx.

Curiously, some Microsoft employees have praised people for making an
"universal image" for all hardware using "unsupported Microsoft
methods", others have condemened it. At the end of the day when I
have 8 different types of hardware and I can use one image or
several, I choose one. "The needs of the many outweigh the needs of
the few or the one", as Dr. Spock would say.

P.S. I have yet, after asking why using an ACPI HAL on a Uniprocessor
is bad, gotten a response as to why it is bad or unsupported (other
then Microsoft simply stating "not supported").

Adam

Hi Adam;

Thanks for the reply. I have seen the "Evaluating Hardware Differences"
article and I suppose you're right, using one image is better than multiple
even if it crosses the MS line of supportability. The image works, and at
the end process, the target PC will be using the right HAL. The reason why I
went with the PIC HAL on my master build machine is because the original
image using the APIC HAL would not boot on an IBM R51 laptop. Now the image
boots on everything, but then I realized that multiprocessor PCs only showed
one processor in Task Manager, and then it dawned on me that the APIC
machines were not playing the happy logon tune, either. Now with the process
of copying over the HALAACPI.DLL, multiprocessor PCs now show both, and the
PC audio is working again. I guess I've just been spinning my wheels trying
to have a facade of "supportability" by doing a driver roll back, when in
essence, that is really what I have the image doing.

Thanks for the comment!

Cheers;
T