Siginet

We are all trying the best we can... and it seems like it is getting better with each release. In my experiance the newest DriverPack Base works very well. I still have some troubles with the Realtek audio drivers so I have taken those out of my sound Pack A. But other than that I have not had an issue. I did see that Bashrat made a small utility that can be ran on a system to grab info about your system if all of the drivers did not install. That utility should be (in my opinion) used whenever a user has a problem and attached to their troubleshooting post here at msfn.org. That way Bashrat can easily support your driver issue. As long as people report their issues with as much info as possible... the issue can be fixed more efficiently. I hope that the Realtek issue will someday be fixed... and I myself will try to get into the habit of reporting an issue when I come across it. As for an efficient DriverPack setup: Try this: Use the newest version as of now DPBase 5.07.3 and all DPs (or without Mass Storage DP) and recreate the SoundA DP without the "R" folder. To do this just use 7zip and follow the instructions in the How to make your own driverpacks. This will give you a very stable release... but you will have no realtek audio drivers... which a lot of computers need.

I didn't even put it there. I have no idea how it got there. Sombody must have saw it here and put it there. I am suprised the DriverPacks are not there..??!!

That sounds like a great Idea! I am all for it!!!

Check it out... Windows XP PowerPacker v1.0 RC1 has been posted at www.betanews.com! HERE It has only been there for about a day and it has been downloaded over 1,000 times! And is rated 4.3 out of 5!!!

It was made for winXP... because the DriverPacks are made for XP... But it may work with 2000 because the DP kind of work for 2000. But all of the options are for XP... so you could just select an xp option even though you are using 2000. I am pretty sure it will work with 2000 without the DPs. In a later version I am thinking of adding 2000 support 2003 support and x64 support.

That is a good idea. I have an idea how I can easily do this for the time being... then I will create a better way of doing this for v2.0. I will see what I can come up with soon. I am going to be buisy for the next couple of days though. If I have time tonight I may put something together.

Nice! Everyone should use this whenever they post an error with the DPs!

LOL! Just in time! I was just in the middle of building a new Multiboot DVD. All I need to do is replace the "OEM\DriverPack_Graphics_A_V506.7z" with the new "OEM\DriverPack_Graphics_A_V507.7z" right? I shouldn't need to run the Base over again? Thanks Bashrat!

Thanks a lot for the compliments moesasji! I aprreciate it. I hope evryone enjoys the program as much as we do.

It will not delete the drivers in the end. It will keep them on the drive to be used later if a new peice of hardware is installed, windows will search through the dps for the hardware driver.

BAshrat... I can help you make tools that will help you edit text in some of the files. I am getting pretty good at text editing in autoit. Could you PM me with the issues you are having with text editing? I will work on something to fix your issues. I've tried to PM you... but your PM box is always full! I also tried to email you. Do you have an msn messanger account?

Actually I have planned to make the Menu system better too. Now that you mentioned it I will work on that aspect. The original menu system was a throw together. It was working so I used it. As for the so many seconds and it boots to the HD... that is allready implimented. (At least it should be... it always worked for me.) The tree format may have to be the way it works... unless I can figure out a different way to code it. See... whenever a new pack is made... sections of the menu's .ini file are deleted to activate that feature. I did it in a tree format so that it will me always organised. I didn't have the tree format in the beginning and whenever I made a new pack that was the order of the list (Which was sloppy). For instance if I made a WinXP Pro Corp With DP... that was the first in the list, Then a Home Retail Without DP... that was the second etc... etc... To me that way was not useable. But I agree the menu needs to be reshaped. In the mean time... if you have knowledge of the cdshell.ini you can costumize it how you like... then when you have finished createing packs you can overwrite the old one. I have many different plans for powerpacker (Like integrating RyanVM's Update packs) but I am running out of space to deal with. The gui window needs to be able to fit inside of a screen resolution of 800/600. If I make the gui much larger then it may not fit. I have thought about using tabs for different sections. But... I think since so far it is working flawlessly... I might add a little picture at the right side of the gui... to give it more of a look... then release it as the full version. Then I can start coding v2.0 which will be made to fit more of everyones requests. My vision of PowerPacker is that it will do a lot of the things people learn at MSFN.ORG. But mainly based on creating multiboot disks.

No offence taken at all Bashrat. I was just joking back.

Yes (With Method 2)

I also released a newer version of PowerPacker which will probably be compatiable with CMD Mod. The new version of PowerPacker does not use .NET... so I don't think it should have an issue anymore. Fixing weird little bugs is so much fun isn't it XPero? hehe!

OK. It looks like all of the bugs have been worked out now. I have written my own Dosnet.inf parser for PowerPacker... so now there is no more need for BootFolder.exe (Thanks Nazgul for allowing me to use it untill I wrote my own version.). My parser is based off of the same idea... but made especially for use with PowerPacker. Since I wrote my parser in a different code language there is no need to have MS Framework .NET installed on your system, There should not be incompatabilities with Xpize CMD mod anymore, and there should be less chance of antivirus/antispyware apps looking at PowerPacker as a false positive. I think this release should be the best and most complete version as of yet. So... I decided to make this release "PowerPacker v1.0 RC1". If no bugs are reported this version may become the full release. Please test it out and reply here with your thoughts, bugs, questions, comments, and accomplishments with PowerPacker. Thanks to everyone who gave me input and helped me create this tool that I think a lot of people will enjoy.

Anyways... I posted a fix before you did. So I guess BTS DriverPacks BASE V5.07.2 is almost "superfluous". LOL! Just Kidding!

I don't know what "superfluous" means... but I hope it means it helped in some way. lol!

Here is what I beleive to be the fix for the hptmv6.sys error I posted above: Edit this file: UWXPCD_ROOT\M2\slipstream_DPM.cmd Find: REM HIGHPOINT %T1% d1,hpt3xx.sys %T1% d1,rhpt3xx.sys %T1% d1,hpt374.sys %T1% d1,hptmv.sys %T1% d1,hpt366.sys Replace with: REM HIGHPOINT %T1% d1,hpt3xx.sys %T1% d1,rhpt3xx.sys %T1% d1,hpt374.sys %T1% d1,hptmv.sys %T1% d1,hptmv6.sys %T1% d1,hpt366.sys =========================== Find: REM HIGHPOINT %T1% d1,hpt3xx.sys %T1% d1,rhpt3xx.sys %T1% d1,hpt3xx.sys %T1% d1,hpt374.sys %T1% d1,hptmv.sys %T1% d1,hpt366.sys Replace with: REM HIGHPOINT %T1% d1,hpt3xx.sys %T1% d1,rhpt3xx.sys %T1% d1,hpt3xx.sys %T1% d1,hpt374.sys %T1% d1,hptmv.sys %T1% d1,hptmv6.sys %T1% d1,hpt366.sys I have tested this with my new PowerPacker v1.0 RC1 and it looks like it copys the file over as it should. I haven't compiled an iso out of it yet and tested that... but I will now and I will edit my post here with the results. You can manually edit this by following the steps above... or you can download the modified file attached. slipstream_DPM_hptmv6_fixed.zip

OK @Bashrat I went ahead and made my own Dosnet.inf parser which goes through the dosnet.inf file and grabs all of the boot files that are needed and places them into a folder I specify. (My code based off of Nazguls BootFolder.exe idea) The difference with my dosnet parser is that it doesn't care about multiple files. So everything copied over perfectly. But... when I go into txtsetup portion it all goes ok until it needs the file "HPTMV6.SYS". I looked inside of the dosnet.inf file and it is not in there (Except I think it was in the [Files] section? But that is not supposed to be parsed.) So I looked in your file "slipstream_DPM.cmd" and I noticed it is placed in the txtsetup.sif file but not in the dosnet.inf file. Which seems to explain the error. If I put a reference to that file in the dosnet.inf file under the section called "[FloppyFiles.2]" Then I get no more errors. In conclusion. I think what I just posted may point you in a direction to look to be able to fix this issue. Good Luck Bashrat. And again thanks for everything. These DriverPacks wouldn't be here at all if it wasn't for you. P.S. Most users will not witness these errors... unless they use winnt32.exe to do an install... or create a multiboot disk. Because dosnet.inf points to all of the boot files needed and copies them to another place. When you do a regular install (By booting to the disk) these files all reside in the I386 directory which therfore means you will not have an issue.

1. That seems like a logical explination. 2. I did not have the problem with the previous version. I do notice that in your scripts FEDIT is supposed to remove the old entries of these exact files. But for some reason I don't think it does. Why it causes a problem I don't know. I would think it would just ovewrite a file if the existing one allready existed... but in this case it isn't copying the file over at all... or deleting it ... or something.?? So... when you go throuth the winnt32,exe portion of setup... you get no errors untill it goes into txtmode setup. I think it is a really weird error.

You can delete UWXPCD_ROOT\M2\Methods_V507.7z from here. It is trash that was left behind that Bashrat must have forgotten to delete.

It seems BootFolder.exe can not Parse the dosnet.inf file of windows using the new DriverPackBase with the Mass Storage DP integrated. I think it is because there are multiple entries in it. Would you mind checking this out? I know it is not a problem with the BootFolder.exe file... but you have a better knowledge of the dosnet.inf file than I do. Thanks

Now there is a bug in the DriverPacks 5.07* Base when using the Mass Storage drivers. That does not add entries correctly to the dosnet.inf file. So if you use PowerPacker do not add the mass storage drivers or you will have problems when you begin installing it. I tried to find out where in the DP scripts it is wrong but I have no clue. My guess is FEdit is not removing old entries like it should. Until this issue is fixed you can use PowerPacker as long as you do not use the Mass Storage drivers.

I can't seem to figure out how to fix this error. I found out the error is there when a user uses winnt32.exe to do an install. So if someone is in windows when they are going to do an install they won't get a message that there is anything wrong untill Windows textmode setup starts.