MadBoy

Well the new version crashes on detecting Plug and Play devices which uses dll call and if i am right autoit changed something in that command. But to be realy sure it's that you can Change <plug_and_play> <option>Internal</option> to <plug_and_play><option>Devcon</option> and see. If that works and you won't get that Autoit error then i'll check the DllCall with some autoit mastah

But the other error is gone? Or still there? Due to upgrade to newest beta of AutoIt some things are probably broken still that's why i didn't released new version officially

hardware_config.xml pro-s_hardware_installer_2.0.0.12.exe Works fine here

Try this version. I may have introduced other bugs as this is open code release but at least logging is fixed so you should have easier way to report problems http://pro-solutions.org/download.php?id=3284911232

For sure there's a bug in creating log But lets skip it for now. After you see that com errror when you browse thru the 3 tabs DeviceSimpleView, DeviceAdvancedView and ErrorDeviceView do you see on all tabs some devices? Just like on the screens below?

I've just read your EDIT. If your drivers are on pendrive in directory lets say E:\Drivers\Wan E:\Drivers\Lan etc you should use: <drivers_drive>RELATIVE</drivers_drive> <drivers_directory>\Drivers</drivers_directory> As for the XML settings try: Don't worry that it's over 4096. Just test it if it's a bit better. About the error. Can you tell me at which point it happens? What currently is shown in the log window?

IceMan by editing the post you damaged the code a bit Take a look at it yourself You can easly see tags like <span..> etc

It would be easier if you explained the error? Maybe post a screen shot? The Wizard comes up because it can't find drivers so somewhere here is a mistek. Also you're using SetupCopyOemInf. Was this intended or you just choose it because someone else did?

What made you to stop loving Bashrat Driver Packs? Those are still available at http://driverpacks.net/ ? Or maybe i misundestood you ?

More or less it would be like this but i haven't tested it so just try it out yourself. I will probably add that functionality later on directly into program but for now i am busy with other projects net use X: \\someserver\Share password /USER:Domain\Username run program net use X: /delete

Forced mode is used to get things running even thou that there are no devices with problem. Other then that your .XML look fine but you won't be going far without 'real testing'. Unless i made mistake somwhere ....

The orginal question wasn't precised We can assume that by integration he meant unpacked drivers.

Well over 500mb? It's a looot more Is is more than what CDs max out at? Drivers Pack Graphic A - Decompressed size: 174 MB Archived (7-zipped) size: 66.2 MB Drivers Pack Graphic B - Decompressed size: 389 MB Archived (7-zipped) size: 51.9 MB Drivers Pack Graphic C - Decompressed size: 205 MB Archived (7-zipped) size: 64 MB And that's just Graphic Packs. There are sounds, wifi etc. Check it on http://driverpacks.net/DriverPacks So yes it will be more the CDs max out. Keep in mind you would need to put Windows on that CD aswell

Well over 500mb? It's a looot more

@slatz the config file can be downloaded (just checked now). From all things only config file is located on this forum (due to size restrictions) so it must have been forum problem. If you still won't be able to download it lemme know and i'll put it on my server.

Tnx, fortunetly that option isn't in use yet so changed it asap. As for other typos... i was planning at a later date to make it multi-lang and have it load setttigs from .xml file. But first things first. There's much more important things to add/fix Thanks for your comment I'm glad program works.

If you want i can write you quick gui in AutoIt Shouldn't take long (not much lines either)... Maybe you could also try my program which does what SetDevicePath is doing just is a bit more advanced. Check my signature for it.

It's not difficult Just focus on those settings only and leave rest as in example on first page. Read information what those do and play with them. If you don't use packed drivers set drivers_packed to No and then you can ignore 3 next topsions and just focus on RELATIVE means that if it finds my program on drive E (which is pendrive, cd, whatever) it will take "E:" and look for drivers on E:\Pendrive\Drivers . Best would be if you unpack bashrat drivers straight on root dir. So then you would have like And that would be enough for it to work i guess LAter on you can play with other options.

I have kinda forgot about BartPE Maybe my program works in it aswell. Then i would just have to fix the config settings for it. Anyway if someone can test if it works then i can add some changes (as WinPe uses diffrent commands for shutdown etc). As for command prompt. Well i was thinking about deploy 1 image setting only that you would put in .xml file everything (image name, username, map shares) but there are couple of questions to answer before i could even try to implent this. 1. What about password? For security sake you shouldn't save password in .xml file so maybe this little question for password in Automated mode? 2. I would have to solve how to search for image you point in .xml. Either when you add image name you should be adding relative path to where it could be locatated (cutting out drive letter of course) and my program would go thru each drive it finds (like it does now for config file) and look for that image. On my to do list as soon as i finish my other project (Post Installer) is to fix the configuration file reading at start of a program. Right now at basically any point of time my program refers for value to .xml file. Its okey but for example you have to keep usb pendrive connected once you choose thing to save/deploy. While if it would read it on begining you could get the pendrive out and use it on other computer asap.

http://www.msfn.org/board/Drivers_CD_Any_P...4_G_t70209.html --> as i said. Look at my signature

I know how to add progress bars Especially that if you look closly on those posts i have submited my response to one "Thank You" long time ago. However progress bar is tricky thing. You have to know where you are and where you are heading. You never wondered why Microsoft apps sometimes show 0seconds left and still going? Because they have to predict at which stage progress bar is at 20% or 20seconds left ahead. And it's kinda tricky when you don't know what is gonna happen (and in this case i can't predict few things). Anyways i will try to add more features (including gui's features). Does the current version works thou as it should for you?

Searching for inf's it's not yet implemented. So i'll check the setting device paths function. WHere it's wrong

As for the SetDevicePath my script is ought to do exactly the same. As for your problem. Can you please check HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath if anything is applied there prior to those wizards comming up? I've been working on sat/sunday on function that creates database of all supported HW_ID's by each .inf. It puts them in file in format like: File created from all driver_packs is about 900kb in size. It takes about 20 seconds to create this on my drive (program scans all inf's for data, and believe me if those were exactly the same format it would be great, but some files like voodoo3.inf sucks to work with). I haven't yet build a function to read that file and look for matches but that's a matter of time. What do I need that for you ask? For example program detects that you miss drivers for 3 devices. So instead of going thru all directories with infs and adding them all (and breaking the limit of 4096 chars) to registry (just like SetDevicePath and my program does now) it would scan that db file looking for that devices. If it will found correct HW_ID in that file it will then add path to where the .inf is located to registry. So lets say you got 3 devices you will probably end up with 3 or up to 10 paths added to registry (considering that there might be multiple matches). Now this will: a) speed up detection by windows as windows won't have to go thru all .inf's (not related ones aswell) B) get rid of 4096 limit But that's future Lets focus on fixing what's broken first Awaiting your answer kickarse

Right click on My Computer. Choose Manage. Choose Disk Managment. Right click on any partitions or drives and choose Change drive letter and paths. And that's it. FIrst you will have to change D to K or so to be able to put E to D and so on.

That's why it is default hardware.xml You have every right to modify it to your needs with explanations on first page. I prefer RegistryDevicePath myself. SetupCopyOemInf is slow but it's not due to my program but due to how it was designed. Dllcall is made for every .inf. Nothing we can do about it. Unfortunetly i agree here with you that starting and restarting my program takes ages. Unfortunetly the WMI call is preety time consuming. Well it took me quite a while to port everything from old version (which had some bug i was unable to fix, and was crashing computers) to new version. That's why first i would like to know if new version works If it does then i can think of adding some things to it. I already have thought about adding some kind of pre-db so program would go and scan the whole directory for inf files then read all those inf files for HW_ID's and put them into database.xml file. Then when you would be starting program on any computer it would scan scan for the error devices and look for them in database.xml file. And program would put to registry only those .inf files that have anything in common with those HW_ID's and not all of them. I would like to hear more about method 2 from BTS. It's mentioned it's pyron's menthod?