You are not logged in. Please login or register.
Is it possible to do this:
compare the vendor ID`s /device ID`s /version ID`s etc from those extracted from the hardware by the install routine of windows to those that could be compiled from a list from the driverpacks then just extract the driver for the hardware instead of decompressing and or copying the packs to the hd and searching from there?
I would be quite prepared to help to achieve this if people want
You would need some sort of "index" to make this possible. But it's definitely possible - I've thought about this already myself, but haven't had the time to work on this.
So if I put the time in to compile the index from the DP`s then setup can just extract the driver it needs from the compressed .7z files yes?
OH pleeeaase say yes!!!! 
les: you'd have to write a program that automatically indexes the DriverPacks (not humanly possible to do this manually), and if you write that, then yes, it would be possible
I Am Aware that I would have to write a program to do this but i think such a task is within my capabilities as I am experienced at programing and consider that there is no point burning leptons (and one would have to burn many when it comes to the logic of programing) only to end up with someting that is already availabe on the net, has a confined market or is useless.
I may not have done much programing latlely but logic is logic and never changes - Hey, it`s logical!
This is idea is just up my street! I will start working on it yesterday! (he he) 
Only thing that remains to decide is which PL do I use? any suggestions anyone?
Only thing that remains to decide is which PL do I use? any suggestions anyone?
Well that depends on what lang you're comfortable with.
an easier way would be to have the drivers setup method 1 style on a cd/dvd - if desiredyou may use oempnp path pointing to the cd/dvd but probably not needed since the cd/dvd will be searched anyway by new hardware wizard.
then drivers would only be copied to disk if "new hardware found" installatin wizard found them on the cd/dvd.
in the post below SKIP the batch files and just Copy the OEM\$1\D folder from the slipstreamed source to a CDRW
IE run the install "method one" to a temp windows install folder then copy only the "\d\" driver folders to your cd/dvd. Probably will have to be a dvd as in this format the driverpacks are around 600 meg.
full directions here for making a disk that DOES copy drivers from this cd to windows
(you dont have to run [or even create] the Batch files)
http://forum.driverpacks.net/viewtopic.php?id=960
Last edited by OverFlow (2007-04-20 00:55:27)
an easier way would be to have the drivers setup method 1 style on a cd/dvd - if desiredyou may use oempnp path pointing to the cd/dvd but probably not needed since the cd/dvd will be searched anyway by new hardware wizard.
then drivers would only be copied to disk if "new hardware found" installatin wizard found them on the cd/dvd.
in the post below SKIP the batch files and just Copy the OEM\$1\D folder from the slipstreamed source to a CDRW
IE run the install "method one" to a temp windows install folder then copy only the "\d\" driver folders to your cd/dvd. Probably will have to be a dvd as in this format the driverpacks are around 600 meg.
full directions here for making a disk that DOES copy drivers from this cd to windows
(you dont have to run [or even create] the Batch files)
http://forum.driverpacks.net/viewtopic.php?id=960
The method suggested by les (and of which I have thought myself too already, of course, but "just" haven't implemented yet) would be faster in 2 ways:
1) By using an index, it will find the correct driver faster than Windows itself. (Note that windows caches parsed driver .inf's! See the INFCACHE.1 files. But we're creating an index, which can be used right away, which is obviously faster.)
2) By using that index, we can selectively extract files. This is the main benefit: now we have to decompress less drivers (decompressing = CPU intensive) and hence we only have to write a fraction of the normal amount of files to the HDD (writing the files = HDD intensive).
@les: the DriverPacks BASE and the Finisher were written in AutoIt. But of course, since you'd be writing it, you're free to use the language you'd like to use. No Java or C# though please, since they have too specific requirements for the program to be useful at all stages.
And by the way, I already have the code that transforms HWIDs into their "different levels of precision" (I think you know what I mean), it's in use by the Finisher, and thus it's written in AutoIt.
"I see" said the blind man!
also my guess was a little off 1.7 Gig uncompressed about 500 cabbed and 310 7-Zip format (method 2).
so it also is a disk space pickup!
Last edited by OverFlow (2007-04-20 19:20:14)
Here is a perl script to parse your driver inf files :
#/usr/bin/perl
use Data::Dumper;
use File::Find;
use CGI qw(:standard);
my $q = new CGI();
$| = 1;
my $ROOT = 'C:/dev/infs';
my $DEBUG = $q->param('debug');
#
# Find all .INF within $ROOT subdir
#
my @FILES = ();
sub wanted { push @FILES ,$File::Find::name if $File::Find::name =~ /\.inf$/i; }
if ($q->param('subdir') eq 'no') { @FILES = glob("$ROOT/*.inf"); }
else { find(\&wanted, $ROOT);}
my %INI = ();
my $regex = qr/^\[([^\]]+)]+\s*?\n # [Section Header]
(.*?)\n # Section body
(?=^\[|\Z) # [Next Section Header or EOF]
/xsm; # multiline support
my $regex2 = qr/^([^=]+)=([^\n]+)\n/xsm; # key=value
foreach my $i (@FILES) {
printf "\nParsing $i...\n" ; #if $DEBUG;
local $/ = undef; # \n treated as normal char
open (FOO, "<$i") || die $!;
$_ = <FOO>;
close(FOO);
%INI=();
$INI{"\U$1\E"}{tmp} = $2 while /$regex/g;
foreach my $key (sort keys %INI) {
print "KEY = [$key] :\n" if $DEBUG;
#1 while $INI{$key}{tmp} =~ s/\"//g; # wipe out quotes
1 while $INI{$key}{tmp} =~ s/\;.*//g; # wipe out comments
1 while $INI{$key}{tmp} =~ s/^\n$//gxsm; # wipe out empty lines
%temp = ();
$temp{$key}{$1} = $2 while $INI{$key}{tmp} =~ /$regex2/g;
while(my($k, $v) = each %{$temp{$key}}) {
$k =~ s/^\s+//; $k =~ s/\s+$//;
$v =~ s/^\s+//; $v =~ s/\s+$//;
$INI{$key}{$k} = $v;
print " $k => $v\n" if $DEBUG == 2;
}
delete $INI{$key}{tmp};
}
#[Version]
#Provider=%CANON% --+
#[Strings] |--> Provider = "Canon" (=Manufacturer)
#CANON="Canon" <--+
#[Manufacturer]
# "Canon" = Canon,NTx86.5.1 => change to Canon.NTx86.5.1 for [Canon.NTx86.5.1]
#[Canon.NTx86.5.1]
#"Canon S9000" = CNMS9000XP, LPTENUM\CanonS9000EEDB, Canon_S9000
map { $INI{MANUFACTURER}{$_} =~ s/,/\./ } keys %{$INI{MANUFACTURER}};
$provider="";
if ($INI{VERSION}{Provider} =~ /%(\S+)%/) { # $1 = CANON
if (exists $INI{STRINGS}{$1} ) { # => "Canon"
$provider = $INI{STRINGS}{$1};
print "Strings [$1] = $provider\n" if $DEBUG;
}
elsif (exists $INI{MANUFACTURER}{$1}) {
$provider = $INI{MANUFACTURER}{$1};
}
}
else { $provider = $INI{VERSION}{Provider}; }
print "PROVIDER : $INI{VERSION}{Provider} => $provider\n" if $DEBUG;
($manufacturer) = values %{$INI{MANUFACTURER}}; # Canon.NTx86.5.1 => CANON.NTX86.5.1
print "MANUFACTURER : $manufacturer\n" if $DEBUG;
print "CLASS : $INI{VERSION}{Class}\n" if $DEBUG;
if (exists $INI{ uc $manufacturer }) {
print "DEVICES : ", Dumper \%{$INI{ uc $manufacturer }} if $DEBUG;
map { $dev = (( /^%(.*)%$/ ) ? $INI{STRINGS}{$1} : $_) ; # %MN130.DeviceDesc% => "Microsoft(R) PCI Adapter MN-130"
printf "%10s\t%10s\t%15s\t%20s\t%20s\n",
$provider,
$INI{VERSION}{Class},
$INI{VERSION}{CatalogFile},
$INI{VERSION}{DriverVer},
$dev;
} sort keys %{$INI{ uc $manufacturer }};
}
}1/ Install ActivePerl : http://www.activestate.com/Products/ActivePerl/
2/ Run it (ouputs html) :
perl parse_ini.pl infroot=c:\my_inf_files > index.html
3/ it's "out of the box", so not perfect.
Thanks for the feedback guys, Ive looked at the perl script and it may be useful to us but as Bashrat is using Autoit I may use that instead for integration, compatability and continuity issues.
My brain is in super persuit mode now! in the time it took me to write this sentence I burnt 6m leptons!! (he he)
Will keep you posted with progress reports ok
Thanks for the feedback guys, Ive looked at the perl script and it may be useful to us but as Bashrat is using Autoit I may use that instead for integration, compatability and continuity issues.
My brain is in super persuit mode now! in the time it took me to write this sentence I burnt 6m leptons!! (he he)
Will keep you posted with progress reports ok
Remember to e-mail me when you need that "HWID transform" function of mine, so you don't have to write it again (Only PCI/ is supported by it, but that's at least SOME code you don't have to write then. You'd still have to extend it to support USB/, ACPI/, etcetera. But they're all similar so that'd be drop dead easy.
I have read the manual for Autoit and the UDF file and have started building the GUI.
A DP update/comparision function will be builtin along with a download function
apart form the obvious is there any function anyone would like to see on this GUI?
for example output options for various file formats (.xls?)
I am thinking about providing a tabbed area in the GUI for output results for the different packs to provide info such as Vendor, model, version, release date, OS etc along with a save function for each/all etc. Would this be worth providing?
Les
Are you sure you aren't pushing things too far immediately? Unless you're a genious programmer (and even then), you should start with getting the foundations right first, then add extra things
Since you haven't mailed me, I suppose you don't need/want my "HWID transform" function?
The first release will just create the index file then I will continue the development to spruce it up ok
And yes I would like the HW transforms code if you would be so kind, you can send it to les95@hotmail.com
cheers
Last edited by les (2007-04-30 18:56:24)
@les
Most of the pack's ini files are not populated yet since we just started doing them. It strikes me you might be able to use your code to verify or create the individual pack ini files (which also would be a huge help to me for the bartpe module). It may even be that the ini's are the "key" to some mutual obsticals. If the ini's were used by your GUI would additional ini sections be required?
Last edited by OverFlow (2007-04-30 09:45:54)
Update!
I have so far:
1) created the GUI.
2) Provided an output window which lists all the found DP`s automatically, along with filesizes and versions.
To Do:
A)Hook up the compressor and get it to scan for *.inf`s for output to another column in the output window with totals for each pack
(This seems like a good idea to me at the moment so we can verify the output file totals to the originals for errors, but if you think it is superfluous tell me and I`ll drop it ok)
B) Extract the VID`s etc from the packs and complie into index
C) Get the transforms code from bashrat and hook that in
D) Redirect the paths in the index to the CD ready for burning
At this stage I plan to test it for conformity and then release it for beta testing (after testing it myself of course)
While that is going on I am planning further sprucing it up by working on the following (among other things):
E) Integrate the update feature into the GUI
F) Tightening up the code
G) Maybe providing an output window as mentioned earlier (vendor, model, version etc) If people want such a thing
BTW The AI help file I printed out was nearly 800 pages! YAY - good job I`m a bookworm
There goes another 6m leptons! (he he)
Overflow. If you would care to be a bit more specific with your ini pack query, I may be able to work on it ok
Bashrat, I cannot find an your email address, can you please email the transforms code to me at les95@hotmail.com (you may have done this already but I can`t see it amongst my mail)
Thank you
Last edited by les (2007-05-03 18:02:44)
Bashrat, I am using string manipulation to isolate specific parts of the filenames of your DP naming convention for presentation reasons. and have a few questions:
1) will the naming convention remain the same, with underscores etc.
2) I noticed on you naming convention thread that versions were using the "." convention (IE 6.08.2 etc), but some of the "704" releases have an extra digit, eg 7041, I will summize the extra digit is something like an update or bugfix after the main release etc. Am I correct?
Regards
Les
les, I will create an extra directory on the subversion repository for your work, so your work won't get lost. Simultaneously, you'll have access to all our code and thus to our functions, including the one that parses version numbers
EDIT: just made you a member of the Code Team already
I didnt see the directory ???
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.020 seconds, 10 queries executed ]