Search options (Page 2 of 3)

In my opinion Mass Storage is the only driverpack worth slipstreaming because Windows XP originally doesn't support SATA natively. Also Windows XP might not boot after replacing motherboard, forcing reinstalling Windows XP if there is no way to boot the PC with the old motherboard to install drivers for the new motherboard.

Actually slipstreaming is more tricky and error prone than installing drivers on working OS because some drivers won't install properly during Windows setup and and this problem has to be solved with such workaround as the finisher. On the other hand, it isn't needed when drivers are installed on a working OS. I believe the DriverPack team does its best to make sure that everything is working and I appreciate that but it makes testing driverpacks more difficult.

You might think that installing on working Windows is less reliable because drivers are installed via DPInst which is notorious for its bugs. But it is no longer applies to DriverPack Solution as it switched to devcon(see comments for R146). SAD and Drivers Installer Assistant are still using DPInst though.

It's not that slipstreaming is all bad and it surely has its place. But I myself prefer to have more control over installing drivers and be able to roll back if something goes wrong. Also slipstreaming  makes Windows more bloated and it takes more time detect new device when I plug something in.

DriverPack Solution is still the best program(which is based on driverpacks) for installing drivers on working Windows even though its development slowed down. Drivers Installer Assistant has made some significant progress recently but still hasn't caught up with DriverPack Solution. Romeo91 is aware of all weak points of his program so he might eventually caught up.

Both programs can work with any driverpacks but you should not slipstream the driverpacks which are bundled with the programs because DriverPacks BASE might not be able to extract them(old 7-zip) and these driverpacks might not support the finisher.

Just letting you know: 7-Zip 9.20 is out of beta.

Regrading the speed. I don't download driverpacks that often so I don't know how the speed was changing over time. I remember downloading at my full speed of 6 Mbs about half a year ago. I tried downloading yesterday and the speed was about 3 Mbs. I'm going to measure it again when I get home.

Update:
The average download speed is 4 Mbs out of my max 6 Mbs.

I like mr_smartepants' idea.

I'm aware of download accelerators. My point was that the "100,000 users a week" estimate is not correct. So I suggested calculating this number the other way.

DriverPack Solution and Drivers Installer Assistant are capable of extracting several folders in a single pass. That means that in the worst case scenario they will have to process whole driverpack one time.

I expect splitting archive into multiple solid blocks will have similar effect on the compression rates as packing with multitreading support. This would improve extracting times when the files to be extracted are in the middle-ending of the archive. Personally I could care less about these times(it isn't as bad when PC lacks RAM) but if doing so isn't affecting compression too much, I would go for it.

BTW SamLab repacked his custom driverpacks.
He originally packed them with the 100MB dictionary.
After repacking with the 32MB dictionary most driverpacks decreased in size but some big driverpacks almost doubled in size. After repacking with the 64MB dictionary, they got smaller then they were originally packed.

The point is you don't have to use the 32MB dictionary if it greatly affects compression. Anyway it looks like the 256MB dictionary is overkill and 64MB should suffice for the big driverpacks. Also it is safe to assume that a PC with Windows Vista/7 will have more RAM available than a PC with XP.

Other settings can turned for max compression and the worst thing that can happen is longer packing or unpacking times(unpacking from the middle of the archive).
The dictionary size is the only one option that may prevent unpacking altogether. This is why I made this script so that the user could pick the dictionary size and none of the other options.

You can try packing 2-3 driverpacks concurrently. This shouldn't affect compression and you still can make use of your cores.

Let's break this script into 3 parts and discuss them separately.
1. Tunning for max compression. Disabling hyperthreading support(-mmt=off) improves compression while sacrificing compression speed because using single stream allows better compression when using two independent streams.
2. Improved speed of indexing driverpacks(DriverPack Solution, Drivers Installer Assistant).
3. Suggests using a smaller dictionary.

You hope you aren't opposing the first two changes and we can discuss the third one.
The suggestion to use 32MB dictionary was based on measurement of compression ratios. Each doubling the dictionary size improves compression rate by only 1%. Changing the dictionary size doesn't affect performance providing a PC has enough memory but has a huge performance hit when there is not enough memory. Sometimes Windows fails to allocate enough memory and the operation fails completely.

At workplace we still have such old PCs which are alive and kicking. Obsolete DDR and SDRAM are difficult to find and they are too expensive. Downgrading to Win98 isn't an option because it doesn't support Microsoft Office 2003, many thumb drives and printers.

Smaller dictionary definitely improves speed because Windows doesn't have to swap data into pagafile so often.

P.S. Suggestion to use 32MB dictionary is only a recommendation. The main reason I made this script is improving indexing times.

I didn't know that. I heard there were some disagreements regarding how things should be done but your explanation is believable and makes sense. Though DriverPack Solution didn't use php as far as I know.

I have been following your project closely so I noticed this improvement and the new format of indexes is almost compatible with DriverPack Solution so I concluded that this code influenced in some way. I'm not accusing of stealing, and even if it is influenced, it's all right. Besides there is only one way to do it right anyway. I also think both project could benefit from sharing experience and research which would reduce duplicate research and provide users with a better experience.

Note: Users are advised to read the first 4 chapters and may skip the rest. These chapters can be copied into the first post so new users can understand this thread.

Index.
1.  Description
2.  Getting DriverPack Solution 10.
3.  Comparison to Drivers Installer Assistant by Romeo91.
4.  Search in the web service

5.  DriverPack Autorun to DriverPack Solution 9(R2).
6.  DriverPack Solution 9 Dev Build(R36).
7.  DriverPack Solution 10 Dev Build(R144)
8.  DriverPack Solution 10 distributed DVD edition(various revisions).
9.  DriverPack Solution (the plans)
10. Cooperation on driverpacks.net

1. DriverPack Solution is a program that uses driverpacks to check if some drivers can be installed and updated. It tries to find drivers the latest drivers which are known to be compatible with the current system. When it finds such drivers it suggest installing them. The program doesn't install drivers itself, it extracts them from driverpacks and feeds the drivers to DPInst which does the job.

2. There is no official release as of now, so I suggest using the recommended revision(!not the latest!) from SVN.
Follow this instruction.
1. Download and install TortoiseSVN (SVN client) http://tortoisesvn.net/
2. Create a new folder for the program.
3. Right click on the folder and select "SVN Checkout".
4. Enter "http://driverpacksolution.googlecode.com/svn/trunk" in the URL field.
5. Type in "145"(the recommended revision) into the revision field.
6. Click OK. The SVN client should download the program.
7. Create a folder "DRP" and put driverpacks inside. If there is such folder, the program will create it for you. You can create sub-folders in the DRP folder like "Vista/7_x86", "Vista/7_x64", "XP".
8.The first time you start the program, it should find driverpacks and suggest to index them, say OK.

Should a problem arise, you can provide logs from the "logs" folder.
The best place to report problems is the Issues on SVN.
http://code.google.com/p/driverpacksolution/issues/list

3. Romeo used to work with ArtX on DriverPack Autorun but due a conflict he quit the project and made his own program: Drivers Installer Assistant. I don't know what the conflict was about(I wasn't around then) and it appears people don't want to talk about it. By the time I joined DriverPack Solution 9, Drivers Installer Assistant was(and still is) a pretty mature application. I outlined the features which are supported by Drivers Installer Assistant but aren't yet implemented in DriverPack Solution.
1. Finisher isn't fished(no pun intended). It's commented out in the source code.
2. PhysX driverpack isn't supported. I haven't got around how to use it.
3. DP_Runtimes driverpack isn't supported. I haven't got around how to use it.
I think 2 and 3 are the easy ones I just don't know on which condition I should use them. As for the finisher, it's more complex and I still don't know how to handle it and how it's essential. I think it is important but it was put off till a next version. QuarQ's driverpacks don't have any ini files and he says he doesn't need it.

[update] // Initially I though Drivers Installer Assistant had the same features.
I think DriverPack Solution has a superior algorithm for picking drivers because it looks for exact HWID matches, checks compatible IDs and checks if the driver in question is compatible with the current OS.
[/update]
I'm still not sure if it's completely correct. However I do know that over time it becomes more accurate and I'm going in the right direction. Maybe there is documentation somewhere which would save me a long way of trial and errors and investigation of every failure.
I made a switch from driverpack based interface to driver based interface.
There were some complains regarding the interface which I handled by introducing the expert mode and adding descriptions to the lists.
I would like to know if these complains are still valid for regular users and driverpack maintainers:
1. It's difficult to understand the purpose of some list.
2. The lists are are too long because the program shows several drivers for chipset. Some drivers should be hidden.
3. The lists are are too long because the program shows the name driverpack. It should list drivers without showing the name of driverpack where the driver was found.
4. Some lists are useless.

To sum up, DriverPack Solution right now might have a better driver matching algorithm but miss the features mentioned above and maybe some more which aren't apparent. The programs use different approach in presenting information and DriverPack Solution is leaning rather to advanced users, driverpack maintainers than to users. This is why ArtX added the infobox which advice user what to do. Anyway I want to see progress in both projects, it's good for users. I wanted to implement installation from unpacked driverpacks(like it was done by WsnoW) but I didn't because the code would be hard to maintain without making major changes. This feature is planned in to be implemented in a new version(that means it is unlikely to be soon).

4. There is a feature in DriverPack Solution which allows to search driver with specified HWID on the Internet.
http://devid.drp.su/
DevID service provide search for drivers uploaded by users. Search on Microsoft is made by ArtX. He said he tried to minimize amount of requests to this service because Microsoft wouldn't be happy about it. I don't remember why though. The publisher said he want to provide this basic service for free and provide some paid service like collecting all drivers for particular computer and
giving them as a single download. The publisher plans to assign the task to freelancers. This service is intended to be automated and won't involve a human deciding which drivers to use. I don't know much about these web services. I think ArtX know about it more.

5. History. I can't really explain how it started so I tell what I know and I'll try not bore you with details. The program was created in May 2008 and was initially named DriverPack Autorun and was renamed to DriverPack Solution when it became version 9. As far I can tell by the changelog most releases had rather small changes while 6 and 9 versions were major updates. I joined the project when DriverPack Solution 9 was released. You can see that R2 at SVN corresponds to DriverPack Solution 9 so there is detailed changelog on SVN.

6. At some point I released DriverPack Solution 9 Dev Build as an experimental branch which added support for X64, improved speed of parsing INF files, improved HWID matching algorithm. Eventually I switched to algorithm which matches exact HWIDs and checks compatible HWIDs.
This version corresponds to R36.
Also I take time to collect driverpacks from different maintainers and uploaded it to my hosting(free mediafire account) which I later switched to ArtX's hosting. But I haven't updated driverpacks since October so users are advised to use the links to get the latest driverpacks from maintainers. Though according to statistics a lot of people still download outdated driverpacks.
I remember the days I updated driverpacks, the hosting could barely handle the traffic and the provider tried to limit it. The majority of people were from the former USSR, I think it it's because of the common language. This is why I was planning to introduce the project in
the English speaking community.

7. I was going to release DriverPack Solution 10 Dev Build but I was being hold back by the publisher(read about it below). This release was supposed to be based on R144 and I had uploaded updated driverpacks to mediafire. I couldn't use ArtX's hosting because he didn't have enough space(5.4 GB) and the provider of hosting might not handle such amount of users because the attention was building up since I announce I would release my own branch: DriverPack Solution 10 Dev Build soon.
At the same time I was preparing a DVD edition of DriverPack Solution 10 Dev Build. This edition would had stable driverpacks for XP removed in favor for the driverpacks from nightlies. Driverpacks for printers were also removed. I was working on it with a guy who was supposed to make this release on torrents.ru. At some point I had to said that could no longer be involved,he is his own and he can't release it labeled as “Dev Build”. He prepared it himself and released it on several major tracker labeled as "DriverPack Solution 10 Professional DVD(????????????? ?????)". Since this unofficial version was superior to other custom versions, it replaced them. In my deleted post, I was worried that the Internet(save for RUnet) was full of broken custom releases of DriverPack Solution 10. However I see that this release has reached the English speaking folks but it dropped the "(Unofficial release)" from its title and is named "DriverPack Solution 10 Professional DVD". It doesn't mention “Dev Build” as it was intended either. The English description could have been handled better(it was translated by Google Translate).

8. DriverPack Solution 10 distributed DVD edition. It was announced that users could order delivery of DVD with the latest program and driverpacks. The size was stated as 3200MB, I don't know where ArtX got this figure and wasn't given information about the driverpacks on DVDs.
Users were given an offer to preorder the DVD for 300 rubles later 500 rubles and since February 1 it is 1000 rubles(US Dollars: 10$, 16$, 33$). It was stated that the official DriverPack Solution will be released on March 1.
I pointed out that this information would mislead users into thinking that they have to pay to get the program yearly. I believed distribution and the official release would start on the same day and the offer would  nly give users discount for yearly preorder.
I was planning to release my branch DriverPack Solution 10 Dev Build(as an experimental release) before on March 1, this way we could test it and fix bugs before releasing the final official version.
I clarified for users that ordering DVD is meant for these who have slow and expensive Internet or don't have it at all. I also announced that I would release my experimental branch soon. Shortly I learned that I wasn't supposed to release it because I'm known as a developer and it would harm sales. I had a conversation with the publisher over Skype for more then 4 hours but we couldn't come to agreement. In the end, I quietly canceled the release without an explanation. The publisher felt that an honest explanation would harm the reputation and I couldn't lie to users. I decide not to quit yet and take a break till March 1. I feel free to discuss this here because it's unlikely that there would be many people who would order the DVD so I'm not harming sales.
For I a few days I received orders in my mails but it stopped soon so I don't know how many people ordered the DVD. The announcement about the new version was sent via e-mail to the people who was interested in DriverPack Solution at some point. It's about 50 000 e-mails the last time I checked, I can't login into e-mail campaign anymore to see how many respondents are on the list.
I wasn't informed when the distribution begun and didn't know about the content of DVD. However some customers contacted me for support so I learned about it. Publisher says they send some a limited amount of DVD yearly but the major distribution hasn't started. I didn't know for sure but my observations didn't fully support their claims. So I announced that users don't have to buy DVD and this is only a delivery service for these who don't have Internet or it's too expensive. The same way anyone can buy a Linux distribution.
Also I think it's the publisher presses us to make special functionality for distributed DVDs. You can look at the last 3 options in tools\config.js and decide for yourself whether it's a good idea or not.
At the moment there are a lot of custom made distributions of DriverPack Solution made by users. I recommend to stay away from them because they are based on revisions which aren't meant for release and some of them are so broken that some driverpacks aren't indexed. However some decent  distributions are out there already.

9. I decide that I'm going to port the project from JavaScript to C++. That means I will have to write everything from scratch and only few important parts of original source code could be salvaged. It might take a long time to get all the features which are available right now. In the long run, users will benefit from lower memory footprint, full support for non-ASCII characters, mulithreading and multicore optimizations. This version will have a solid design which will make it easier for developers to maintain and add new features. I'm going to come up with a codename for this branch of development so we could provide support and make bugfixes for the JavaScript-based program while it's in the development. I'm going to start working on this branch after DriverPack Solution 10 release.

Note: this part might be difficult to comprehend unless you are a programmer so you can skip it.
The main part of the program is written in JavaScript and INF parser is written in VBScript. The program uses bat files to link several modules together. ArtX decided to make it this way because he has more experience in web programming. But it's decided that I'll be poring the program to C++ after testing DriverPack Solution 10. While the core of program works well, the current design is known to slow down program(can't read binary files, can't seek trough files, RegExps are slow and don't support advanced syntax, rendering is slow), depends on IE(we have to support IE 6), fails when encounters non-ASCII characters in paths, fails on highly modified pirated Windows(while it's their fault, they expose legit bugs under unusual conditions), dependence on external programs for some features, JavaScript and VBScript are prone to bugs because the code isn't compiled which means it won't give warning/errors due weak typing. When I joined the project, the source code was in a bad shape: indents were absent or inconsistent, lots of lines with more than 100 characters,
comments were in Russian, some variable and function names were in translited Russian, some parts of code were complicated than they should have been. The way code was designed make it very difficult to make changes without breaking something in other places. Over time I cleaned up the code and made changes to make it easier to maintain but there is still some code which I consider poorly designed. Don't get me wrong, I'm not to criticize ArtX for his code, after all he started it all and it still worked. Back then he might not known which design was optimal in the long run. He end up implementing new features via hacks and copy-paste rather then unifying code.
I believe the project benefit from a good design and monolith code(C++ rather than JavaScript+VBScript+bats). These are the problems which I wasn't able to solve for this platform.
I'm going to use GCC as primary compiler(I'm not sure if I'm going support Microsoft Visual Studio Express all the time), using win32 API for GUI(it will keep size of binary to minimum) and use UNICODE through program(it won't be compatible with Win98 but it's OK). I don't know how much time it will take before the program will have the same features as the JavaScript-based version. I'll try not to spend much time optimizing RegExps and implementing multithreading till the core is ready. ArtX doesn't have experience with C++ but he agrees with the decision to switch and is willing to learn (switch from JavaScript to C++ shouldn't be difficult). It will make things more complicated for testers though because they will have to set up compiler and compile the source code.

10. I'm glad I'm here and the way I see we could be useful for each other. Driverpack.net could help with localizing the program to many languages, reviewing the source code providing expertise on drivers. DriverPack Solution could provide DPInst and logs with failed installations, statistics from devid.drp.su implement features which might be helpful for driverpack maintainers. These features shouldn't make major changes which could posses a  risk to users, I'm going to abandon the old codebase anyway when a new branch is ready.

I just committed R145.
http://code.google.com/p/driverpacksolu … tail?r=145
If you checked out a working copy from SVN, use the command "Update" to get the latest revision.

I was looking all over place for the link to driverpacks.net in DriverPack Solution 8 and 9 but found none. There are plenty of links, including comprehensive list of hardware manufacturers. This makes me wonder if ArtX even know where the DriverPacks originated. For all we know, he could have used driverpacks by SamLab giving all credit to SamLab. ArtX doesn't speak English and might not have known about the DriverPack.
SamLab makes his tweaks to the DriverPacks and distributes driverpacks rebranded as SamDrivers with Driver Installer Assistant. The users aren't given any information about the origin of driverpacks apart from the links in Driver Installer Assistant. Considering the overwhelming popularity of SamDrivers in the RUnet, it's no wonder many people don't know anything about the DriverPacks and the fact that SamDrivers are based on the DriverPacks. I never knew that Greg's driverpacks are based on the DriverPacks either. The filenames were so different that I never tried to compare them with the DriverPacks.
EDIT: SamLab and Greg give proper credit to the driverpacks. Sorry for making the false claim. I should have checked it before showing my ignorance. There are many unofficial torrents where  the DriverPacks aren't mentioned though

I think people were mostly unaware about the DriverPacks and were using different branches, until I begun collecting driverpacks from over the Internet and uploading them to my mediafire and providing the links to the maintainers.
I suggest we educate users by asking the other maintainers to provide information about the DriverPacks and stating thier goals.

EDIT2: I can't even come up with a good excuse for not mentioning the DriverPacks at all in old versions of DriverPack Solution.

It appears you're already familiar with everyone except QuarQ. Do you want me to introduce QuarQ to driverpacks.net?

e2162110e469f192fe037a5553ab8847 *./drp/Vista & 7 (SamLab)/x64/MasStorage_x64_9121.7z

ED0D39414B8E933015E0A6206CC9EF8D http://driverpacks.net/driverpacks/wind … age/9.12.1

They are different.

EDIT:
It's late here. I'll be back tomorrow.