Fun with nLite and driver integration

For those of you who use nLite to integrate drivers, especially textmode drivers, you may have noticed that the the source folder grows every time you do this. Well, there is in fact a reason for that.

nLite creates a NLDRV folder under your I386/AMD64 directory, with incrementing sub-directories containing the actual drivers. I say incrementing, because every time you run nLite, even with exactly the same drivers, it adds them to those that were already there in NLDRV. While not particularly installation-breaking, it still causes a nice mess over multiple passes. "Ew", I thought. "Driver file mess? In MY WINDOWS SOURCES? It's more likely than you think." The brief thought of creating a new source every single time was dismissed immediately as too time consuming. So, it was time to hack away at it.

Looking at the overall changed files in the I386/AMD64 directory after the nLite run, a certain pattern emerged. The main things that changed was obviously the NLDRV folder, but also a number of INF files that serve as indexes for that folder, amongst other things. If I were to back those up in their original state, and then replace them, along with deleting the NLDRV folder, nLite would be none the wiser, and create a fresh driver structure.

After checking that the main inf files in question were not present on the service pack installation files, I reached for the original disks, and extracted the original inf files, overwriting the ones bloated by nLite, and deleting the NLDRV folder. After making a pass with nLite, I started an installation using the renewed sources, which promptly bombed with numerous missing file errors. Questions raced in my head "What did I do wrong? Why does the universe hate me? How many kittens does it take to compile a light bulb?"

I started over on a fresh install, unto which I slipstreamed the service pack. Checking for files changed by the service pack, the inf files were among them. ASDF. Apparently service packs update them using some method other than just overwriting. Right then. Time for another go. This time I was careful to overdo it, and backed up all inf files changed by the service pack, which made up my "backup". Of those, 8 files for I386, and 10 files for AMD64 made the cut as those that would be overwriting nLite's changes when driver updates would be needed.

Finally, after testing this method, it worked. A quick batch file for I386 is presented below for your convenience:

@echo off
echo Warning: About to remove integrated drivers from this nLite source!
pause

RD /S /Q .\I386\NLDRV
COPY /Y .\Clean\* .\I386\

echo Running nlite
"C:\Program Files\nLite\nlite.exe"

I keep this file in the root of the Windows source. You can also add some nlite.exe switches to, say, load the last preset automatically. The Clean folder contains the following files (remember, from an unmodified slipstreamed source):

DOSNET.INF
HIVECLS.INF
HIVEDEF.INF
HIVESFT.INF
HIVESYS.INF
INTL.INF
SETUPREG.HIV
TXTSETUP.SIF

For 64 bit, there's also HIVCLS32.INF and HIVSFT32.INF. Ultimately, I believe that only two files really need to be in the list, TXTSETUP.SIF and DOSNET.INF. But I'm feeling too lazy to triple check that far, especially since it would only shave exactly 0.0000288 seconds (calculated in my head, I'm THAT GOOD) off of the batch copy. This works to give me fresh and clean driver integration, and that's enough for the time being.

So regarding those spirals into madness...

At the insistence and urging of my coworkers, I will attempt to detail in this space (Collective groaning at yet another useless blog) some of the more interesting (Read: Wrist slashing material) technological exploits and challenges that I run into on professional and personal basis.

It is my hope that the readers will derive at least some modicum of insight from some of the topics that will (eventually) be posted (maybe), as they will typically be of reasonably obscure and bizarre issues with equally obscure solutions. At the very least, I fall back on the second hope that the readers will be amused by some of the absurdity that happens in the wondrous world of technology, and how I attempt to deal with it without incurring sanity loss.

Me? I'm just some guy that has a job that lets him play with latest hardware and software for a living. Somehow this isn't always (some of the time (almost never)) as exciting as it sounds, as you will no doubt find out in due course.

Strap yourself in - crashes are to be expected and welcomed with open arms, flowers, and keys to the server room.