Search options (Page 6 of 159)

OK, I've finished testing and here's v130501
http://www.mediafire.com/?97bu3hoemk9abcw
I'm also uploading 3 HID test packs as proof-of-concept for the removals...but the uploads are going slow.

I made some changes to the code, but I didn't see what you guys were seeing in testing.  So maybe I fixed it and didn't know it?

No reason.  It's safe to rename.
I renamed it .bat in testing and forgot to name it back.

Well that is very strange since I didn't touch anything from Synaptics.  Your system must have been installing the driver from one folder but using a synaptics app.
Can you go back to a previous install where the touchpad was working fine and go to the device manager "driver" tab, click the "driver details" button and take a screenshot of the .sys info?

I thought about it some more and instead of deleting the directory, I may just rename the offending .inf files to .inf.bak and then include a "undo" script that a user can run after the fact that would rename any .inf.bak file to .inf and re-run SAD.
In the meantime, I'll post the code that I have right now until I can get some testing done on the new method.

Please post your DP_Install_Tool log so I can see which ones are being tagged.

Which OS are you installing on?  Are you using SAD during setup prior to first login?  Is the message generated by Windows or part of the SAD script?
Can you post your log file?

Well, the only way I know to fix that is by removing the "touchpad" or "HID" folders from the driver pool and leave them for manual installation.  That kinda defeats the purpose of the automatic install.
I went back through versions 2.5 & 2.7 and I didn't see any code that would differentiate any HID drivers at all.
I'll keep looking into it.

I'll look into both reports and upload a newer version tonight if needed.

Some new Intel drivers for you.
12.5.0.1066
https://downloadcenter.intel.com/Detail … p;lang=eng

3.6.0.1093
https://downloadcenter.intel.com/Detail … p;lang=eng

Cool, grabbing now.
You know, one of the great tools I use to do line-by-line code comparison is WinMerge.  http://winmerge.org/
It'll spot the difference between a space and a tab, as well as between a short-dash and long-dash which depending on the font used look the same.
Speaking of fonts, I prefer the free Adobe SourceCodePro.  http://sourceforge.net/projects/sourcecodepro.adobe/

I have two text editors of choice.  NotePad2 (with code folding) and SublimeText2.
http://xhmikosr.github.io/notepad2-mod/
http://www.sublimetext.com/2

I'm currently chasing a bug in the :Elevate section (and elsewhere).  The bug is in how the variable %0 is used.
When the SAD script is called from a command line, then %0 populates as a fully qualified path with name.ext (C:\SAD\DP_Install_Tool.cmd).  But when the SAD script is double-clicked, the :Elevate .vbs script fails because %0 only populates with the name.ext, not the path (DP_Install_Tool.cmd).
This can be solved by substituting %0 with %~dpnx0 (DrivePathName.eXtension) which has a more consistent behavior.
To illustrate this behavior, create a test.cmd file with the following code:

@ECHO off

ECHO Path with '0'    : %0
ECHO Path with 'dp0'  : %~dp0
ECHO Path with 'dpnx0': %~dpnx0
PAUSE

Run from command line:

When double-clicked:

I'm still busy testing M1 and M2 in both XP and Win7...but I'm close!

Jeff is right about the DriverPacks archive streams.  When I build the final DriverPacks, I use the tool here: http://forum.driverpacks.net/viewtopic.php?id=4789
I don't think the testing packs are built the same way (solid packs).

@DanInWV, please post your sample code so we can see what's going on.

Well that would be fine if the "touchpad-HID" Third Party DriverPack included only drivers for laptops.  However that Third Party DriverPack includes drivers for mice and keyboards also.

I like the idea (it's been brought up before).
It would require that the DriverPacks contain "index" files (like a database) for each contents.
Then we'd have to poll the system for a HWID list and compare it to the index and build an array of matching paths to drivers.
Then extract only the matched drivers.

This would require that we also repackage all the DriverPacks without using the "solid archive" option.  This would create DriverPacks packages that are much larger in size.

In theory, that should be much quicker but would require a LOT of scanning/comparison to build the array which may take even longer than just extracting all the drivers at once.

I'm not saying that we won't do it, only it would require a lot of coding just to make a 'proof-of-concept'.
We'll keep that in our "to-do" list.