you can use any length folder names you want with devpath there is no limit...

As YOU stated in the first post: TITLE: Update DevicePath <-- your original topic remember...

"This way you can keep your long descriptive names for your folders"

that means DevPath and makePNF - Not JUST makepnf - BOTH

my patience on the other hand does have limits and your welcome has now expired...

not listening and being argumentative at the same time is not tolerated...
You have shown zero effort on using the search feature or reading the documentation
or even taking the time to read and understand the responses to your post.
or sticking to your original topic for that matter

you have posted info that is not only inaccurate but it is wrong...
even after I have corrected you multiple times.

go find somewhere else to not pay attention, create problems, post bugged tools, ask for support of non supported platforms, and give out inaccurate info and be disrespectful and ignorant in general...

this site is for the support of DriverPacks BASE and the DriverPacks neither of which you use...
therefore you have nothing to offer or share with us, and you don't listen at all.

a 3 day ban is now in effect and this topic is now closed  - admin

if a mod would like to trash this thread I pre-approve and encourage the second opinion...

If someone says "use this app for this task" I will, but I also will check how the app works and try to find if there are any other alternative.  If there is something I don't understand, I ask about it. This is what I did, asking how these apps works.

Now, after several tests, I feel I know them much better.

As I stated in the first post:

"This way you can keep your long descriptive names for your folders"

This was the original point of this thread:

using LONG DESCRIPTIVE foldernames

I like them, I include the version and the date in the foldernames, so I wrote my app.

I don't use the DriverPacks in this site as I have a x64 system. I only wanted to install my collection of x64 drivers, keeping their long foldernames.

Anyway this is not important for me any more, I realized I don't need to use my app.

The good point is that makePNF will install the INF files, so

             YOU DON'T HAVE TO USE DevPath.exe AT ALL

I read in some post in this forum that, in order to install a driverpack, you have succesively to run:

makePNF.exe
DevPath.exe

but I completely disagree.

PNF files contains the location of the source files, there is no need to create this long registry key, asking Windows to search in a see of folders.

Windows don't need to do so, it will find the info it needs in the PNF files.

As a consequence, if you want to use the DriverPacks for updating current Windows installations, you don't have to use short foldernames in them. You could have a version of the DriverPacks with descriptive foldernames and then apply makePNF to install the drivers. No worries about the DevicePath key.

It seems you know schalti. If you don't trust me, ask him about it.

devpath has no limit! <--- Read this again...
Did you read it this time?... or do i need to beat you some more?

64bit OS's are not supported.

if you open DriverPacks BASE and look at the About page...
schalti is the author of makePNF.exe
Pyron is the author of DevPath.exe
both are members here and at MSFN where DriverPacks got started.

if you look at the DriverPacks you will notice all of our folders have single letter names
and the root folder is D\

this is a leftover from when we used the OemPnPDriversPath entry in winnt.sif/unattended.txt
OemPnPDriversPath has the limit... not the registry location that OemPnPDriversPath is copied to.
therefore bypassing OemPnPDriversPath and populating the registry directly avoids this limit..
--- Re-Read the last paragraph again --- get it into your head correctly...

It seems to me that you are trying to reinvent the wheel...

if you wish to update an existing machine try useing the SAD Feature of base 8.12.1

In case you missed it - X64 is not supported

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

I see that DevPath.exe changes this key, but now I have two concerns.

1. It uses the full path of the driver package, with very long filenames in my case, so very easlily you will achieve the 4096 limit. This is way I wrote my app that changes relative paths to:

\1   \2 ...   \9    \A   \B   ...    \Z        \10   \11     ... \ZZ \

so you save a lot of space.

2. It is really necessay to change DevicePath? Is not enough the path provided by the PNF files?

I have to test it.

I only wanted to say that the bundle of tools in the DriverPacks site is mainly foccussed in new Windows installations, if you don't look at the site in depth you may miss the fact that the site provides tools for updating current installations as well.

This is only my opinion based on my personal experience: I had downloaded DriverPacks BASE before, played a bit with the tools, but didn't realized it could be usssefull for me. In fact I wrote a simpe app and opened this tharead for if it could be ussefull for others and then Echo_Platoon put me in the track of these tools. But anyway, is just an opinion maybe I'm wrong.

Would you mind tell me who are the creators of these tools (makepnf)? where they developed for driverPacks? would you point me to a documentation of them? I only found disscussion in forums, but no author notes at all.

I have to insist that devpath does nothing in my case:

devpath.exe c:\drivers

don't changes the key

HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath

did you check it?.

In fact installing the INF files makes not necessary to touch the DevicePath key at all. Each PNF files contains the path of the driver's source, just edit one of them with an hex editor and look at the end of the file.

This is why I decided the procedure used by USBoot and makePNF is better that the one I have been using with my app, as you don't have to touch the DevicePath key, no more worries about the 4096 bytes limit.

So I wonder, what does DevPath.exe?

IE devpath c:\D
assuming there is a folder on C: named 'D' that contains drivers in folders

this is necessary because of the MS Limit of 4096 and the sysprep limit of 2047 for the OemPnPDriversPath.
DEVPATH has no limit (your post above is not clear on this point, in fact it states the opposite)

HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath

pnf are just cached lists of the available drivers, it speeds up detection and location of drivers.

We Don't consider these second class tools    their creators are honoured by us...
And we are Lucky to have these guys allow us to use their tools...
We credit them and respect their copyrights.
(I assume you would get permission from them for useing these for a non personal use?)

and they are quite well documented everywhere here and in the included files
and on many of our friends sites like MSFN for example.

Thanks for your interest. Take a look around, and play with it, let us know.

Have a great day...

Well, I have been reading the forum searching for some hint of DEVPATH and found some intersting threads about installing INF files in a working windows installation.

It seems to me that this type of tools are seen here as second class tools, as they are fairly hiden in the full setup. Considering the capabilities of the current imaging apps, I feel they are as important as first installation tools, and deserves be addresed independently.

Anyway, I have been playing with makepnf and it seems to me it does just the same work than

USBoot>phase II>extra Drivers installation

The only difference I could appreciate is that makepnf lets you choose the source folder, whereas usboot has it hardcoded:

\Windows\extra Drivers

So I will start using makepnf with advantage (of course custom PnP driver installation is a secondary feature of USBoot).

However I didn't be able to guess what DEVPATH.EXE does. I runned several times and saw no changes at all. No changes in the INF folder, no changes in the  DevicePath reg key. The app closes almost inmediatly after invoked.

So, what's the point with DEVPATH.EXE?

- No need to modify DevicePath key
- You can keep your long descriptive names for your folders
- There's no risk of multi-installing the same driver when you run the program several times

However there is still a little issue, the author, Gerd, promised to have a look on this soon.

http://forum.driverpacks.net/viewtopic. … 326#p27326

However you can easily overcome the issue by deleting the \Windows\extra Drivers\ folder prior to run USBoot phase II.

However maybe there is a better aproach, using USBoot, just only first step of phase II. It copies the custom driver pack to

windows\extra Drivers

and install the INFs, so there is no need to change DevicePath.

I didn't try it yet, I have to be sure there is no risk in running it several times (I mean, no several copies of the same INFs wil be installed).

http://rapidshare.com/files/177835269/U … cePath.zip

It just updates DevicePath reg key to include your source PnP driver package folder tree.

Becuase the 4096 bytes limit of DevicePath value, the source driver package tree is copied to

c:\Drivers\

in a modified form to save space. This way you can keep your long descriptive names for your folders, as:

D:\Sources\Operating Systems\Drivers\Drivers\Media\Intel Audio HDMI, v5.10.00.1042, 20080429

The DevicePath reg key is updated to include the created target tree along with folder %systemRoot%\Inf

To use it:

-Copy the provided files to the uppermost level of your source driver package tree. In my case:

                      D:\Sources\Operating Systems\Drivers\Drivers\

-Run UpdateDevicePath.exe

Limitations:
- This app will look for INF files. If not present, the folder will be ignored
- Folders with inf files can't contain subfolders. If some do contains one, the app will complain and exit

Enjoy

pepin