Search options (Page 59 of 77)

How is that? If he needs this driver, then he needs it.

rc7 won't have this REMmed out issue anymore. I'm very glad Intel SATA RAID is confirmed to be working again

Please post your DPs_BASE.log.

Of course not

Just to let you know that it would have been a somehow sneaky new feature in one of the next updates

RogueSpear means, at least I think so, that EACH file should be CABbed separetely. And that IS supported by Windows.

Will do RogueSpear, will do This is one of the most obvious features that still had to be implemented.

This will all be fixed in the next release.

Very strange... you seem to be right! It DID work in the past, since I tried it. Will fix it in the morning.

I didn't unzip it yet.... [blushing]... Perhaps you were right when you were insinuating that I did not have enough sleep? Nah, I'm just having so much ideas right now... Alot is going on in my mind...

Download the save_hwids tool that you can find in my signature. Execute it and post the hwids.txt file here on the forum then.

1. Create a settings file for each OS (that is supported by the DriverPacks) you want to include in your multibootDisc: configure the settings as you'd like and then export them.

2. On the Location page (under the group [Settings]), you can browse to a location. If a directory is selected, with in any of its subdirectories an 'I386 directory', multibootDisc mode will be enabled.

3. Add all settings files that you've created in step 1.

4. Start the slipstreaming.

This has NOT been tested yet, since none of my betatesters uses a multibootDisc. There are fewer multibootDisc users than I anticipated...

Please post in English... I don't have the slightest idea what 'CM' is.

@midiboy & Fragbert: obviously, if there would be a professional (paid) product, then that (continuous DriverPacks updates) would be one of the many new requirements. And Fragbert, it's been working for a while already, but I just wanted it to be completely bugfree before this next version would be used by every one.
Better slow and then deliver something that's working smoothly from the first release
I don't mind that you prefer the old DriverPack Sound B, but you have to admit that there were continuously bugfixes for it. There have been several times that I had to put a new version online every single day. Would you accept that, as a user who has paid for a professional product? I couldn't live with that anymore. Hence the rather drastic change.
Now there are still releases every day (or once every couple of days), but with a more complex, yet more manageable codebase that offers more features and is easier to use. And the main difference is that I won't annoy EVERY user by the untested versions, but just those that would like to participate more close with the development (thanks again, my dear beta testers ). This way, I get less useless and timeconsuming 'noobish feedback' and more well-formed, positive critics, which again help to deliver better first releases.

I will soon be focussing on the web-end of this project. That means: one user to rule them all (forum, bugtracker, automated 'DriverPacks donor' status when made a donation), online documentation and tutorials, better website. That's on the frontend. The backend should include managing of downloads and - more importantly - the start of a truly automated drivers library. It's going to be a very complex undertaking, at first. The database structure must be completely be on paper before I start coding it: there are so many inner relationships to take note of.

I guess that last paragraph was some sort of sneak preview. I won't place ANY estimates on when it'll be ready, since a) I'm not being paid and b) I'm really bad at making estimates .