R
Rick Brooks
Hello all,
Hopefully someone out there can answer this question. I've been working on
this for a couple of days and can't find the solution.
I am working on a problem where the vendor has written a simple installer
application (or at least....it started out that way) that calls the
SetupCopyOEMInf function to copy the INF files for the drivers into the
default directory (C:\Windows\Inf\OEMx.INF.) This is a multi-function
device. The device has two (2) unique vendor-supplied drivers with
corresponding INF files and three functions that use Windows system drivers.
It is a multi-function keyboard with a hub that uses the inbox drivers for
the hub, keyboard, and hid devices. The vendor wishes to use the inbox
drivers but, rename the devices or "brand" them (example: Acme USB Hub, Acme
USB Keyboard, Acme USB HID-Input.) The devices have unique VID_PID (well,
Keyboard/HID use the same PID and the HUB has its own.)
The problem we have is that the installer works fine for the vendor supplied
drivers but when installing the devices that require the inbox drivers, the
user is prompted for the file path. The path points to the temp directory
where the installer was launched but has the "\i386" subdir appended.
Installing the devices from the device manager using the update driver or
using the add driver from the control panel works fine.
After working with this for a few days and asking around, we understand why
this is happening. The INF files that reference system-supplied drivers and
use the needs and include directives point to the system INF files. For
example:
(AcmeHub.Dev.NT)
Include = USB.INF
Needs = StandardHub.Dev.NT
According to WHQL, this is valid (see Errata ID: 1347) In the case of the
HUB, the USB.INF references LAYOUT.INF and LAYOUT.INF uses decorated
sections that point to the driver source (in this case USBHUB.SYS) as
"usbhub.sys = 1,\i386" That answers the mystery of where the appended subdir
is coming from and we know that the beginning of the path is provided by the
parameters passed to SetupCopyOEMInf. If we just use:
SetupCopyOEMInf ((char*)devPathStr.data(), NULL, SPOST_PATH, 0, NULL, 0,
NULL, NULL)
From the SDK:
Bool WINAPI SetupCopyOEMInf (
PCTSTR SourceInfFileName,
PCTSTR OEMSourceMediaLocation,
DWORD OEMSourceMediaType,
DWORD CopyStyle,
PTSTR DestinationInfFileName,
DWORD DestinationInfFileSize,
PDWORD RequiredSize,
PTSTR DestinationInfFileNameComponent
);
The default source path is the first parameter (this happens to be the temp
directory where the install was launched.) We can override the temp
directory and point to the system32\drivers directory by supplying the
proper info to the OEMSourceMediaLocation parameter. But, no matter what we
try, "\i386" is appended to the source directory, which fails so the user is
prompted to supply the path to the driver.
It seems that even if the drivers/INFs were WHQL-signed (which is planned),
the behavior would be the same since the precompiled INF (OEMx.PNF) should
be storing the bogus directory with a \i386 appended so, I'm not convinced
that calling the UpdateDriversForPlugAndPlayDevices after the files are
copied would update the generic system devices with the vendor-supplied
names after the .INF and .CAT files are copied over. They would like to
submit the drivers and INF files to WHQL but, we're not sure if this can be
fixed in the INF files for the generic device so, we don't want to submit
until this installation issue is addressed.
Anyone have any suggestions or experience with this?
Thanks in advance.
Rick
Hopefully someone out there can answer this question. I've been working on
this for a couple of days and can't find the solution.
I am working on a problem where the vendor has written a simple installer
application (or at least....it started out that way) that calls the
SetupCopyOEMInf function to copy the INF files for the drivers into the
default directory (C:\Windows\Inf\OEMx.INF.) This is a multi-function
device. The device has two (2) unique vendor-supplied drivers with
corresponding INF files and three functions that use Windows system drivers.
It is a multi-function keyboard with a hub that uses the inbox drivers for
the hub, keyboard, and hid devices. The vendor wishes to use the inbox
drivers but, rename the devices or "brand" them (example: Acme USB Hub, Acme
USB Keyboard, Acme USB HID-Input.) The devices have unique VID_PID (well,
Keyboard/HID use the same PID and the HUB has its own.)
The problem we have is that the installer works fine for the vendor supplied
drivers but when installing the devices that require the inbox drivers, the
user is prompted for the file path. The path points to the temp directory
where the installer was launched but has the "\i386" subdir appended.
Installing the devices from the device manager using the update driver or
using the add driver from the control panel works fine.
After working with this for a few days and asking around, we understand why
this is happening. The INF files that reference system-supplied drivers and
use the needs and include directives point to the system INF files. For
example:
(AcmeHub.Dev.NT)
Include = USB.INF
Needs = StandardHub.Dev.NT
According to WHQL, this is valid (see Errata ID: 1347) In the case of the
HUB, the USB.INF references LAYOUT.INF and LAYOUT.INF uses decorated
sections that point to the driver source (in this case USBHUB.SYS) as
"usbhub.sys = 1,\i386" That answers the mystery of where the appended subdir
is coming from and we know that the beginning of the path is provided by the
parameters passed to SetupCopyOEMInf. If we just use:
SetupCopyOEMInf ((char*)devPathStr.data(), NULL, SPOST_PATH, 0, NULL, 0,
NULL, NULL)
From the SDK:
Bool WINAPI SetupCopyOEMInf (
PCTSTR SourceInfFileName,
PCTSTR OEMSourceMediaLocation,
DWORD OEMSourceMediaType,
DWORD CopyStyle,
PTSTR DestinationInfFileName,
DWORD DestinationInfFileSize,
PDWORD RequiredSize,
PTSTR DestinationInfFileNameComponent
);
The default source path is the first parameter (this happens to be the temp
directory where the install was launched.) We can override the temp
directory and point to the system32\drivers directory by supplying the
proper info to the OEMSourceMediaLocation parameter. But, no matter what we
try, "\i386" is appended to the source directory, which fails so the user is
prompted to supply the path to the driver.
It seems that even if the drivers/INFs were WHQL-signed (which is planned),
the behavior would be the same since the precompiled INF (OEMx.PNF) should
be storing the bogus directory with a \i386 appended so, I'm not convinced
that calling the UpdateDriversForPlugAndPlayDevices after the files are
copied would update the generic system devices with the vendor-supplied
names after the .INF and .CAT files are copied over. They would like to
submit the drivers and INF files to WHQL but, we're not sure if this can be
fixed in the INF files for the generic device so, we don't want to submit
until this installation issue is addressed.
Anyone have any suggestions or experience with this?
Thanks in advance.
Rick