Snappy Driver Installer

Hi BadPointer. First of all congratulations on the SDI project, it is by far the best driver installer there is.

I would like add the following suggestions:
  1. add cmd option to only install specific driver package. As an example of desired functionality: sdi.exe -p:chipset -autoinstall -autoclose. The reason for this is that some need to automate only specific drivers. Right now I'm using separate SDI folders one with all drivers and a separate for only chipset.
  2. Some support for network printers would be nice. I was thinking if it would be possible to add function that would ask for the printer IP address and install the drivers from your packs. I know it's somewhat impossible but maybe you can find a workaround. This would be a huge time saver.

I do agree that your hard work needs to be rewarded. If you decide to make this project trialware/adware/nagware I don't how many companies would actually buy it. As you probably know, the battle here is for businesses as they configure lots of machines. A typical home user would only use such a program once every reinstall.
The issue with companies is that not all would agree to subscribe/buy this. I work in such a company that feel this type of program will create system instability and would be a security breach. They would usually prefer manufacturer drivers but when you have thounsads of machines, different machines, it impossible to do so.

Probably the best way is to accept donations while trying to keep the project free for everyone. Just my humble opinion.
 
add cmd option to only install specific driver package. As an example of desired functionality: sdi.exe -p:chipset -autoinstall -autoclose. The reason for this is that some need to automate only specific drivers. Right now I'm using separate SDI folders one with all drivers and a separate for only chipset.
Your setup with multiple folders looks good to me and you can easily select folders with the -drp_dir switch. Why do you need another switch?

Also keep in mind that SDI can find driverpacks in sub-directories, so you can move one driverpack into the 'drivers/chipset' folder and run SDI either with -drp_dir:drivers or -drp_dir:drivers/chipset.

Some support for network printers would be nice. I was thinking if it would be possible to add function that would ask for the printer IP address and install the drivers from your packs. I know it's somewhat impossible but maybe you can find a workaround. This would be a huge time saver.
SDI currently can pick up printers only if they show up in Device Manager.

SDI has limited support for printers, anyways. In the past there were 41 driverpacks dedicated for printers alone. Their total size was about 8.5 GB and they were released under name "SamDrivers Printers"(not to be confused with SamDrivers). They were so huge because these drivers were poorly unified and each model needed its own driver. Another problem was the fact some drivers had separate versions for each language instead of having a single multilingual version and it’s a big deal for these drivers because some users would be having hard time setting up pages if dialog boxes were in English, so SamLab picked Russian versions for these drivers.

SamLab had enlist help of volunteers to collect all drivers but it proved to be too difficult to maintain these driverpacks, so SamLab stopped updating them in 2011 and focused on maintaining drivers for other devices. The good news is, other than printers/scanners, current driverpacks cover pretty much any device.
 
The good news is, other than printers/scanners, current driverpacks cover pretty much any device.
I had to console into a switch the other day and I have an old com to USB adapter and windows 7 would not self install and Google searches yielded nothing but frustration. Fired up SDI and installed it in seconds.. Thank you!
 
So far I'm loving SDI, I'll give it a few more weeks of testing but I think I'm actually going to donate.
So far I've only had one Toshiba laptop it didn't like, so after safemode and rolling back drivers I was at least able to get the networking up which was good enough for me at the time.
I'd say so far it's one in 20-ish failure rate for me and that's pretty good
 
SDI is a great drive utility and I'm very happy with it. It won't, however, install associated programs for various devices - but that is OK with me. As long as it finds nearly everything (driver-wise.) :)

<<<<<-- That's my high school graduation picture. I'm a handsome devil, ain't I?
 
So far I'm loving SDI, I'll give it a few more weeks of testing but I think I'm actually going to donate.
So far I've only had one Toshiba laptop it didn't like, so after safemode and rolling back drivers I was at least able to get the networking up which was good enough for me at the time.
I'd say so far it's one in 20-ish failure rate for me and that's pretty good
We have been using SDI for around 2 years and can't think of a single time it hasn't accomplished its goal. We previously used 3DP_net but haven't used it since SDI. +1 for SDI.
 
Just updated SDI and saw the patreon request. So I've put in $5 per month for now. I hope you get more results. I've been a big supporter of SDI and was glad to see it as I had lost trust with DPS. That guy is a crook and no good tech should support him or put their clients PCs at risk using that spyware trap.
 
We really don't want to be like other driver updaters which rely on turning basic functionality into premium features or tricking users into installing adware.

Their owners also spend a lot of resources in advertising on the Internet. They pay major bloggers and websites to write articles about their software and pay websites to place them prominently. A lot of people know about these products, but SDI isn't even on the radar.

Snappy Driver Installer was first released in February 2014. It started out as a fork/rewrite of DriverPack Solutiоn which differentiated from it by having no adware, no premium features, being faster(hence its name), taking great care in picking best matched drivers, not leaving traces in systems and being honest to users.

Previously I worked on DriverPack Solutiоn(DPS) and made significant contributions to it. It's worth mention that it's a commercially successful project and its annual revenue is about $1 000 000. I worked as a volunteer and made no attempt to claim any of that money. DriverPack Solutiоn uses the same old driver matching engine that I wrote a long time ago and no one touched it since I quit the project because no one else understand how it works. While the software hasn't been updated since 2013, a new version comes out each month thanks to SamLab's driverpacks. Users are already used to its defects such as installing touchpad drivers on desktops, installing both Realtek and Creative at the same time, scripting errors, etc. SamLab still tries to make his driverpacks compatible with DPS but it causes bloating of driverpacks because in order to trick DPS into installing the correct driver, he has to duplicate the same driver multiple times. Also he can't include some drivers because DPS would renders PCs unbootable trying installing them. I'm not fixing these issues because I no longer support DPS and users better off using SDI anyway.

Even though SDI outperformed DPS in every way and doesn't include any adware, DPS is vastly more popular and recognized. It has to do with the fact АrtX put a lot resources into advertising and trying to capitalize on adware. His employee went on saying on forums that they target housewives because they're easily tricked into installed adware and don't complain about poorly picked drivers due to not being tech-savvy.


I need to give some backstory explaining how I get involved in the first place. There's not much information about the project on English speaking forums, so hopefully people will be able to piece it together to get a better idea on how things unfolded.

Back in 2009 I started working as a PC technician at a company that had over 1000 PCs and there was no Internet due to a security policy. So I started looking for software that would help me with installing drivers.

The best one that I found was Driver Pack Autorun(it was re-branded as DriverPack Solutiоn some time later). It used driverpacks from driverpack.net(they're meant to be slipstreamed into Windows installation discs) and rely on DPInst.exe to do the actual installation. At the time it didn't support 64-bit systems, couldn't update drivers(only missing drivers were installed), didn't provide information about drivers that are available for installation. Users were supposed to click on red mark and hopefully red marks turns into green marks. You can see how it looked back then on Wikipedia(link).

The software was advertised as being released under GPL. I joined the project in 2009 and put source code at Google Code, so that multiple people could participate in the development at the same time. Over time I made significant contributions such as support for 64-bit systems, changed GUI to displaying list of drivers instead of list of driverpacks, optimizing for speed(indexation of 700MB driverpacks used to take about 6 hours on my PC), added tooltips displaying information about drivers, rewrote driver matching engine(that improved chances of finding the best matched driver and enabled updated old drivers).

However I had some disagreements with its founder(АrtX).
I was arguing for providing as much information about drivers as possible while АrtX wanted to show users only one big button "Install all". I was opposing keeping records in registry about drivers that failed to be installed, so that DriverPack Solutiоn wouldn't be suggesting installing them again because it deceived users(it looked like drivers were successfully installed). I also opposed stuff like forcing adware on users, changing home pages, OEM logos, loading from the Internet JavaScripts and many other things I'm having trouble recalling.

At one point АrtX decided to make new version available only for users who ordered DVDs with the software. New version was advertised as having brand new driver matching engine, speed improvements, 64-bit support, ability to update drivers, creating log files. All these improvements were made by me and I opposed forcing users to pay for that. I didn't mind АrtX taking all money from DVD sales(it's a good service for people with slow/expensive Internet) for as long as the new version would be available for free. Negotiations didn't go too well. АrtX end up making new version available only via paid DVD.
Website said it would be released for everyone on March 1st.
When March 1st came, the note was changed to March 15th.
When March 15th came, the note was removed all together.
The new version finally appeared on April 20th but was heavily loaded with adware.

АrtX put the source code into his own private source code repository breaking his promise of being Open Source. I continued working on public repository at Google Code where I made further improvements into its core functionality. SamLab kept updating driverpacks and releasing SamDrivers each month. It included my version of DPS since it was free of adware and it was on the cutting edge at the time. Eventually АrtX merged his private branch back into public Google Code. While it brought some improvements to GUI, it also brought some nasties which included adware and encrypted scripts. It took me same time to clean it up make it easy to disable, so that SamLab could include DPS in his SamDrivers.

DriverPack Solutiоn is written in JavaScript. АrtX choose it because he was familiar it. Over years I tried to push it to the limit but JavaScript isn't meant to do heavy lifting and some problems with DPS couldn't be solved without a major redesign. This is why wrote Snappy Driver Installer from scratch in C++ and the rest is history.

Great read. Loved to see this information.
 
So far I'm loving SDI, I'll give it a few more weeks of testing but I think I'm actually going to donate.
So far I've only had one Toshiba laptop it didn't like, so after safemode and rolling back drivers I was at least able to get the networking up which was good enough for me at the time.
I'd say so far it's one in 20-ish failure rate for me and that's pretty good
I suggest submitting logs. If you had to install a driver from the dropdown list or download it from somewhere else, you should also specify which driver you end up installing.

------------------------------------------------------------------------------------------

In other news.

R451 is out. It has a new dialog window("Options") which makes it easier to discover features.

As for driverpacks. SamLab recently announced that he'll be optimizing driverpacks for SDI by removing duplicate drivers and markers. It means that he'll be dropping support for DriverPack Solution and Drivers Installer Assistant(since these tools rely heavily on markers and other workarounds to pick the correct driver, and they haven't been updated for a long time). The transition will make driverpacks smaller and easier to maintain.
 
As for driverpacks. SamLab recently announced that he'll be optimizing driverpacks for SDI by removing duplicate drivers and markers. It means that he'll be dropping support for DriverPack Solution and Drivers Installer Assistant(since these tools rely heavily on markers and other workarounds to pick the correct driver, and they haven't been updated for a long time). The transition will make driverpacks smaller and easier to maintain.
Sounds like a great plan.
 
Just had a thought.

How hard would it be to write a "HOME" version that is able to get only the drivers for the machine its run on and a TECH version leave it as it is. That way you can market it both ways.
 
One time users can download indexes first and SDI will suggest downloading only driverpacks that they need. But I think many of them aren't aware of that and end up downloading the whole thing.
 
What exactly do you suggest? We can't afford to host each individual driver on website. Besides, distribution via the torrent technology is free and fast.
 
SDI lite still gets drivers via torrent. But rework the interface to just get drivers for the machine it is run from. Call that "Home" and market it that way. Make it home user stupid simple.

The rest of us "Tech's" can do the whole driver packs. Leave the current interface the way it is for us. Call it Tecn edition.

Another thought... Can you write into the program to turn on system restore BEFORE a restore point is made. Win 10 for example has restore off by default on many machines.
 
Last edited:
I don't know how usefull would a home edition be. The idea behind the project is to be able to install drivers offline, what good would SDI be if it needs internet access on a computer that does not have the LAN adapter driver installed. If you are even considering this, the LAN drivers must be included at all times to ensure connectivity.


Wouldn't it be better to just add an option in the GUI, and CMD to download the drivers in %TEMP% and delete them afterwards?
 
I don't know how usefull would a home edition be. The idea behind the project is to be able to install drivers offline, what good would SDI be if it needs internet access on a computer that does not have the LAN adapter driver installed. If you are even considering this, the LAN drivers must be included at all times to ensure connectivity.


Wouldn't it be better to just add an option in the GUI, and CMD to download the drivers in %TEMP% and delete them afterwards?
SDI was designed to be used without requiring an Internet connection by allowing users to download all drivers(or just LAN/Wi-Fi related) beforehand for offline use.

You can make a script that removes downloaded driverpacks after each use but if you're using SDI on many computers, you're just wasting time and traffic by downloading the same driverpacks over and over again.
 
Back
Top