1 Reply by pepin

(11 replies, posted in Software)

No my friend, I'm not trying to reinvent the wheel, I'm only trying to know how this wheel works.

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.

Go to forum: Software

2 Reply by pepin

(11 replies, posted in Software)

I see what is happening. I'm using Windows x64 and the relevant key is:


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.

Go to forum: Software

3 Reply by pepin

(11 replies, posted in Software)

Overflow, 

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?

Go to forum: Software

4 Reply by pepin

(11 replies, posted in Software)

Thanks for the info

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?

Go to forum: Software

5 Reply by pepin

(11 replies, posted in Software)

Definetly, the USBoot aproach seems to me the best way to integrate a folder tree of new PnP drives in a existing Windows installation:

- 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.

Go to forum: Software

6 Reply by pepin

(11 replies, posted in Software)

Thanks for the info, I will check it.

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).

Go to forum: Software

7 Topic by pepin

(11 replies, posted in Software)

A very simple app, don't know if there exists something like this. I needed it, I didn't find it, so I wrote it.

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

Go to forum: Software