Preparing your device installs for 64-bit Windows and Windows Longhorn

Posted December 29, 2004

Chat Date: December 9, 2004

Please note: Portions of this transcript have been edited for clarity

Introduction

Website: https://www.microsoft.com/whdc, https://www.microsoft.com/whdc/driver/install/default.mspx

EricSa_MSFT (Moderator):
Welcome to today’s chat. Our topic today is: Preparing your device installs for 64-bit Windows and Windows Longhorn.

EricSa_MSFT (Moderator):
We are pleased to welcome our Experts for today’s chat. I will have them introduce themselves now.

Patty_msft (Expert):
My name is Patty and I am a PM for the DIFXTools. You can get the DIFXTools at: https://www.microsoft.com/whdc/driver/install/default.mspx

Joe_MSFT (Expert):
Joe_MSFT= my name is Joe Marusak and I am the Partner Development Program Manager for the Device Management and Installation Team.

Jason_MSFT (Expert):
Hello, I'm Jason, the Dev lead of the Device Installation and Management team.

Ferdous_MSFT (Expert):
Hello, I am Ferdous. I am responsible for testing DIFx tools, and device installation feature of Windows Longhorn.

Neil_MSFT (Expert):
Hi, I'm Neil and I'm a developer in the device management and installation team. I work on INF syntax and other setupapi issues.

Jim_MSFT (Expert):
Hi, I’m Jim, a developer with the windows device management and installation team.

Erik_MSFT (Expert):
Hi, my name is Erik and I'm a developer on the DFX Tools.

Eugene_MSFT (Expert):
Eugene_MSFT = I'm Eugene Lin and I'm a Program Manager with the Windows Device Management and Installation team.

Joe_MSFT (Expert):
The Device Management and Installation team was formerly called the Plug and Play team. The focus of this chat is preparing driver installations for Windows Longhorn and our soon to be released 64-bit operating systems.

Start of Chat

Joe_MSFT (Expert):
The Device Management and Installation team was formerly called the Plug and Play team. The focus of this chat is preparing driver installations for Windows Longhorn and our soon to be released 64-bit operating systems.

Eugene_MSFT (Expert):
Q:
What is changing in Longhorn device installation?
A: For device installation in Longhorn, we're doing a couple of things to provide features that customers and partners have asked for:
- We're moving device install to a client/server architecture, in which device installs happen separately from the user's security context

  • We're protecting internal PnP state to prevent misbehaved apps from corrupting the installation state of device

    A: There's a lot to cover. Are there any specific things you'd like to know?

    Neil_MSFT (Expert):
    Q:
    Okay, since I don't see any questions I'll ask a generic one. If a driver is already x64 WS03 ready, what is the scope of the changes required for Longhorn?
    A: The main change that you need to be aware of is that now an "architecture decoration" is required in an INF on the models line.... I can give you an example if you need it.

    Patty_msft (Expert):
    Q:
    I need to install a driver with one or more usermode services, and/or kernel libs (export drivers). Can DIFX do this?
    A: This is not currently supported in the current version of the tools. Can you supply us with more information on your scenario?

    Patty_msft (Expert):
    Q:
    Patty: I have a driver that must work with an usermode service (it implements part of logic)

    Jason_MSFT (Expert) replies on behalf of Patty

    A: Our tools aren't really designed to install user mode code, but you are in luck :D

    There is really no installation difference between a kernel mode service and a user mode service, so if you just install these as kernel services using our tools they should work fine.

    The one issue we are still investigating is if we will allow a single INF to install multiple services. Our current logic is to only support one service per INF; so if you need multiple services installed you need multiple INFs.

    Jason_MSFT (Expert):
    Q:
    Could any of you tell me what this snippet from the setupapi.log file means: #W154 Class installer failed. Error 1459: This operation requires an interactive window station.
    A: Device installation can happen in two different contexts, the user’s context (which is interactive) and the Plug and Play service context (which is non-interactive). When you get this error it means that the install was happening in the Plug and Play service but something required UI. In this specific case it looks like the class installer itself failed because it needed to show some UI. When this happens, we will push the device installation into the users context where UI can be displayed.

    Erik_MSFT (Expert):
    Q:
    Self signing still not possible in XP? Must I go thru WHQL?
    A: Yes, self signing is not possible in XP, and currently there are no plans to provide it. Depending on your driver class, you can go through WHQL, but users can still install unsigned drivers.

    Neil_MSFT (Expert):
    Q:
    Will the NTamd64 decoration in INF's still be required in Longhorn to distinguish from 32-bit?
    A: Yes, we will introduce this on W2K3 server SP1, and it will always be required.

    Jason_MSFT (Expert):
    Q:
    Will Longhorn support launching external processes from the DevInstall function of a printer driver?
    A: I'm not a printer expert but do you mean VenderInstall?

    In any case, printers will still support VerndorInstalls, which mean running external processes in the user's context after the device drivers are installed.

    The only reason not to do this is it forces an install to be interactive (since UI is required); this means corporate IT admins can't push this package down to non-admin users...but if that isn't interesting to you then you are fine for Longhorn.

    Jason_MSFT (Expert):
    Q:
    Is there any chance that CoInstallers will be "enabled" (meaning executed) during and Add Printer Wizard install in Longhorn? You get 'em now in PnP, but not APW.
    A: We don't have any printer guys here, but I don't think they plan on doing this.

    Eugene_MSFT (Expert):
    Q:
    Is Driver Store a conceptual successor of SFC
    A: The short answer is no. It is not a successor, but it will be protected against tampering by misbehaved apps.

    Eugene_MSFT (Expert):
    Q:
    I mean will SFC functionality be a part of Driver Store?
    A: The Driver Store will be protected against tampering, using technology that is similar to Windows File Protection. The difference is that this protection will now apply to all drivers installed on Longhorn, whether they come from third parties or Microsoft.

    The Driver Store is a local staging area for driver packages. Whenever a driver is installed via the Driver Install Frameworks tools or Longhorn, its files are all copied to the local machine first, and then installed. This allows Windows to roll back to previous versions of drivers.

    Neil_MSFT (Expert):
    Q:
    do you know test tool to troubleshoot why external disks won't mount (ex. USB flash is OK in dev. manager, but not shows up as drive letter)?
    A: I am not aware of a test tool that can help with this. There are actually a few different components (e.g., partmgr, disk class, usbstor) which could all be responsible for the problem... I agree that Windows should do better to help users diagnose this. There is a lot of diagnosability work going on for Longhorn, and I'll relay this suggestion to the appropriate team.

    Jason_MSFT (Expert):
    Q:
    Haven't completely figured out what Code Integrity component is. As far as I understand, it's a component, maintaining a database of legally installed applications. So, the system won't allow non-registered driver to start. Is it correct?
    A: We don't own Code Integrity (CI), but I think the plan is still up in the air as to if this will be on or off by default. The last I heard is that it will simply log to the event log when unsigned drivers are loaded. But it should have a mode that can be turned on that prevents unsigned drivers from loading.

    Jason_MSFT (Expert):
    Q:
    Does Microsoft have a recommendation for install media for 32 bit and 64 bit drivers? I mean to ask, should we put them on separate CDs? Should we maintain 2 different INFs?
    A: All INFs need to be decorated for their appropriate architecture in Longhorn. So you can lay a 32-bit and 64-bit INF down side by side on the CD and Longhorn will pick up the correct architecture INF automatically. This also applies to WS03 SP1.

    Here is the link to decorating INFs: https://www.microsoft.com/whdc/driver/install/64INF_reqs.mspx

    Neil_MSFT (Expert):
    Q:
    Will XP support natively PCI express? SDIO?
    A: I actually am not quite certain about the status of PCI express... the last I heard we were not going to support it on XP, but that might change. SDIO support was released on XPSP2, and is also available for OPK release on W2K and XP RTM.

    Jason_MSFT (Expert):
    Q:
    Will I be able to install an unsigned driver via telnet? On XP, I can't (not without setting up an elaborate hoop to jump through), but for development/debug/testing it is almost essential. I think the administrator should have the option to allow this.
    A: Just to clear this up. Telnet was a hack solution to try to get this to work on XP. We won't support that on Longhorn, but we will allow you to self-sign a driver package (or install an unsigned driver package) on Longhorn.

    Let me know if you need more information.

    Eugene_MSFT (Expert):
    Q:
    Will Longhorn allow/handle the display of a EULA during PNP driver installs? If so, where can I find some details on that?
    A: It is currently in our plan, but we're still working on a design. Actually the EULA prompt would happen when the driver is copied into the Driver Store, not when it's installed. If you're calling any existing APIs (e.g. SetupCopyOemInf) then they will copy the driver into the Driver Store and install them in one shot.

    You can also use the Driver Install Frameworks tools today to display a EULA.

    Eugene_MSFT (Expert):
    Q:
    Thanks very much for all of the help!!
    A: You're very welcome. Please take a look at the current DifX tools, which allow you to require EULA sign off on installs today.

    Jim_MSFT (Expert):
    Q:
    In LH, will user be able to define a device as NOT removable even if OS thinks it is? (so it won't appear in safe removal API) For example my DVD in laptop is in hot-plug bay, but I never want to remove it.
    A: the drivers for a device can report whether the device shows up in the safe-removal tray applet based on the removable and surprise-remove-ok capabilities of a device. we have no plans to let users override these indicators, so if the drivers indicate the device needs safe-removal, the applet will show the device. on windows xp, the shell can be configured to show or hide certain tray applets, so you can configure it that way.

    Jim_MSFT (Expert):
    Q:
    Jim: too bad... I often stop my DVD by mistake instead of USB and cardbus cards :( Can you add a registry parameter to .HW subkey to override what driver returns?
    A: ah, I see, it's too easy to pick the wrong device. Thanks for the suggestion. We’ll look into what we can do here. Thanks.

    Patty-MSFT (Expert):
    Thank you for participating in today's chat. If you have any additional questions or comments send them to: Difxbeta@ microsoft.com. You can download the latest tools at: https://www.microsoft.com/whdc/driver/install/difxtools.mspx

Top of pageTop of page