Traditionally, file systems and file system filter drivers have been installed using custom installation programs. Typically, this is done by interacting with the Service Control Manager via the SCM API. Quite some time ago, the installation of device drivers changed to use INF scripts to drive the installation process.
When using an INF file, the installation program interacts with the Service Control Manager, Plug and Play Manager, and other OS components. Of course, those of us who work with file systems tend to resist making changes (except when absolutely necessary, of course!) taking the standard philosophy of "if it works, don't break it."
The IFS Kit sample filters have been shipping with INF scripts for installation for a while but most developers (those of us at OSR included) tend to ignore such things until absolutely necessary. In developing our first filter with the new (still beta) Filter Manager in the Windows Server 2003 SP1 Beta IFS Kit we decided to eschew building an INF script right away and instead focus on gettting our filter working - after all, how hard could it be? We've been building INF files for a while and the INF files used by a file system filter driver are truly minimal - there's no Plug and Play interaction going on, because file systems don't exist as far as the PnP Manager is concerned (notice those file system filter drivers that are marked as DISABLED in their service entries).
So we created the standard entries for a service. Unfortunately, the Filter Manager wouldn't even load the filter. After a bit of analysis, we found that it insists on some additional entries: an Instances subkey in the service key. The Instances subkey must then in turn contain a DefaultInstance value (a REG_SZ value) that in turn contains the name of another subkey located within the Instances subkey. That instance subkey then must contain two values: one is the Altitude and the other is the Flags field.
We found out the hard way that although both appear as numeric values in the INF script, the Altitude value must be a string (REG_SZ) value, while the Flags field is a REG_DWORD. When we first entered the Altitude we did so as a REG_DWORD value as well. Our mini-filter loaded, but we never received any calls other than to our DriverEntry and Unload routines. It took quite a lot of debugging to finally figure out that the problem was the Altitude value in the registry was not set up properly. (FYI: Altitude is used to control the relative ordering of mini filters with respect to one another and how they process I/O operations).
Understanding this better now, we have the flexibility of using either the newer INF file mechanism or the older SCM mechanism. Now we just need to update osrloader (our driver loading utility) to create those extra registry keys!