@5eraph, you are correct when it comes to using Raid/SATA drivers to a point, as you can still use this method, if you're NOT using them to boot the computer with and IF they have an INF to do the install.
As far as all the other drivers goes, as long as they install using an INF you can use this method, if they don't use an INF, then you'll have to use another method to install them.
Also, if you're doing TXTMODE, (RAID/SATA,) drivers, once you have the .sys files integrated into i386, (the only files that are needed during TXTMODE setup,) and have them also called using TXTSETUP.SIF and DOSNET.INF, they will work also during TXTMODE. The rest of the files, that you would normally leave in the $OEM$\TXTMODE folder, don't have to be there because they aren't looked for until Windows reboots and starts installing from the GUI mode, which doesn't start until after the presetup.cmd runs and tells Windows to look for the drivers in your Drivers folder, (wherever you chose to put it.) If you have no need to boot to the RAID/SATA drives, then you don't need them to be in the i386 folder nor do you need to call them from TXTSETUP.SIF nor DOSNET.INF because they will still be installed using this method for drives that are connected when you install the rest of the drivers, as Windows will look for them when it's installing the rest of it's drivers.
I know this to be fact because I've done them this way several times before, you only need to tell Windows that the RAID/SATA drivers are there, using TXTSETUP.SIF and DOSNET.INF, when your booting to them, if your not booting to them you don't need them to start with. So if your booting to an IDE drive then you don't need your RAID/SATA drivers unless your IDE drive is on a RAID controller. All other drivers that use an INF file to install, can be installed this way, assuming it will work at all because Windows isn't being told to look for "OEM" drivers unless you specifically use the command in WinNT.SIF to tell it to. Once that command has been issued, Windows will look in your Drivers folder for the drivers instead of using it's own drivers.
It used to look for them in the $OEM$\$1\Drivers folder when being run from CD automatically, but Microsoft broke something and now it doesn't automatically look for the "OEM" drivers unless you tell it that you're using OEM drivers using WinNT.SIF, the problem was that if you used sub-folders in the $OEM$\$1\Drivers folder you had to specify them in WinNT.SIF and you were limited, (by character spacing,) to how many you could put into that line, using this method you're not limited to how many folders/sub-folders you can point to.
If all your doing is building this for a single computer, you can put all your drivers into the Drivers folder and call them all from there unless you have two components that use similar drivers but are different, such as the case with some RAID/SATA drivers. In those cases if you combine and modify their TXTSETUP.OEM's to show which folder you put them into and they will be found. And since you're using WinNT.SIF, you don't need this method at all, unless your also trying to bypass the Driver Signing Policy, which you can do by just using Ryan's SFC_OS.dll to install unsigned, (beta,) drivers. If your using Signed, (Released,) drivers then you wont need to use the SFC_OS.dll at all. (Yes I know companies, such as nVidia, releases drivers that are unsigned, but those drivers aren't "officially released" drivers, they are beta drivers that just happen to be good working drivers in most cases, hence the reason some people will want to use the hacks to the Driver Signing Policy to install those drivers.)
The problem I have found, using Ryan's SFC_OS.DLL hack is sometimes it will cause Windows to bluescreen during install, saying that it can't continue because setup's catalog file isn't found. Using this method, I've found that it will continue without any errors, (other than setup.log reporting that the catalogs aren't there,) and when you get to the desktop the Driver Signing Policy is already reset so it's not deactivated thus there is no reason to replace the SFC_OS.DLL file afterwards or use the registry file to turn it back on, as Windows does this automatically after the reboot before you start the OOBE or get to the desktop initially if you done the install fully unattended.
In any case, Microsoft only supports installing drivers from WinPE when doing a CD based install now, according to the revised OPK.ref that's in the OPK thats available from oem.microsoft.com.
I have some gmail invites left, if you'd like one IM me and let me know.
[url=mms://wmc1.liquidviewer.net/WNOR]WNOR FM-99[/url] The best station in the world!