Which api functions to install a file system driver in Windows?

Question

I want to install a driver for Ext2 partitions under Windows XP, the installation will be done with a self written Inno Setup script. Which API functions do I need to call for this? From what I googled so far I don't seem to be needing an inf file, and therefore no call to SetupCopyOEMInf. But I don't know what to do instead...

Please enlighten me!

Answer 1

All right, I found some more information:

The MSDN states that 'you should install your file system drivers by using an INF file' (by calling SetupCopyOEMInf etc), but also notes that on Win2k and older systems, 'file system drivers were commonly installed by the Service Control Manager'

And I found another Ext2 driver at sourceforge that comes with an Inno Setup installation script. There they just add a few registry entries under HKLM\SYSTEM\CurrentControlSet\Services\.

I believe that adding these entries is equal to creating a service with the sc.exe tool, which internally calls the OpenSCManager and CreateService api. I prefer the registry way, because it is easier and I see no advantage in using the api calls, since a reboot is always required.

So I ended up with this solution:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourService]
"ErrorControl"=dword:00000001
"Start"=dword:00000003
"Type"=dword:00000001
"DisplayName"="YourServiceDisplayName"
"ImagePath"="System32\Drivers\YourService.sys"

Of course depending on the specifics of the driver in question, some more entries in a Parameters subkey may be required.

I am still hoping that someone will be able to shed some more light on this question, specifically some details on how to use an inf file for the installation, since this is the way recommended by MS.

Come on, folks! There's a nice bounty to catch here!

Answer 2

As you asked which API functions are required to install a driver here is some code I use to load a driver in C:

bool LoadDriver( const char * cpDriverPath, const char * cpDriverName )
{
    SC_HANDLE hSCService;
    SC_HANDLE hSCManager;

    hSCManager = OpenSCManager( NULL, NULL, SC_MANAGER_ALL_ACCESS );
    if( hSCManager == NULL )
     return false;

    hSCService = CreateService( hSCManager, cpDriverName, cpDriverName,
           SERVICE_ALL_ACCESS, SERVICE_KERNEL_DRIVER,
           SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL,
           cpDriverPath, NULL, NULL, NULL, NULL, NULL );

    if( hSCService == NULL && GetLastError() == ERROR_SERVICE_EXISTS )
     hSCService = OpenService( hSCManager, cpDriverName, SERVICE_ALL_ACCESS );

    if( hSCService == NULL )
     return false;

    if( !StartService( hSCService, 0, NULL ) )
    {
     if( GetLastError() != ERROR_SERVICE_ALREADY_RUNNING )
      return false;
    }

    CloseServiceHandle( hSCManager );
    CloseServiceHandle( hSCService );

    return true;
}

You probably want to use SERVICE_ BOOT_ START for a file system driver instead of SERVICE_ DEMAND_ START. If you cant write an Inno script to do the above you could always make a small EXE from the above and have Inno run that as a post installation.

If you want to go down the INF route, check out this Microsoft article.

Answer 3

There are a number of ways you could approach this.

1/ See if the product has a silent install mode (e.g., using a configuration file to install). Then you just incorporate that into your own install.

2/ There are programs that can emulate a user, such as Rational Robot (I wouldn't suggest that one since it's commercial, but there's likely to be free ones around). We mostly use these for automated testing of graphical applications but they can just as easily use it to run an installer.

3/ Contact the developer to see what the actual install process entails, then copy that.

4/ Microsoft has a number of system tools (here) that can track changes to the filesystem, registry and so on. You could use these to reverse-engineer the install process and do those same things in your own install.

Personally, I'd go with number 3 first. The developer would be happy to know their product is being used and may provide the information readily. They may even write a silent installer for you as this would be an extra selling point for their product in a corporate environment (suggest this to them).

Answer 4

I wrote a TDI filter driver.

When I came to write the .inf file, it took two weeks of sheer pain to get something working and I still didn't really understand it, because it didn't really make sense; what you had to do seemed very arbitrary. INF files were, when I was trying to use them, almost wholly undocumented and bizzarely complex.