Thanks.
I guess I should have made this script when putting everything online... Sorry guys!
You are not logged in. Please login or register.
DriverPacks.net Forum » Posts by Wim Leers
Thanks.
I guess I should have made this script when putting everything online... Sorry guys!
Eh... You're the first one to report this! It should work just fine. My guess is that it isn't able to verify the list of updates and therefore is stuck in an endless loop. I'll fix that.
Please submit this at the bugtracker.
Today at the very least updates of DriverPack LAN and WLAN (and Chipset will be made 'official', i.e. the site will be updated), probably also Graphics A and Sound A.
Yes, if you're using VERY deep paths, it may not be handled well.
razormoon wrote:Reproduced. Had both chipset packs in directory (the old renamed using new naming convention). I'm curious...could it be you renamed the old chipset pack with new name? Because there IS a new chipset pack released yesterday...
How many kb is your chipset pack?
I used the latest DP downloaded straight from this forum, v6.05
Nevertheless, please verify by checking the filesize. It should be 688/689 KB, depending on the rounding.
There are a lot of programs that I USED to call from guirunonce (I've sinced moved on to runonce).
I noticed that a lot of my app calls weren't doing crap, specifically an important one called VidChngxxxx.exe. After a few months I finally decided to rename that exe and change the reference in winnt.sif to read vidchng.exe and behold. It worked. (8.3 filename)The reason for the renaming is this...
DPGA603.7z : What the h*ll is this??
DP_Graphics_A_wnt5_x86-32_603.7z : Oh, I see. It's graphics pack A!
Easier to read.
Thanks for clarifying, razormoon
I have found problem :
I have DPs_Base.exe in folder name "DP Base" and destination (XP folder) location in : "DP Base\temp"
But If I suppress space in name folder the conversion is good !
I make many test, Just one reproduce the good ?
I'm not sure what you're saying here...
-Are you saying that the space in the path was causing the conversion to be incomplete/inexistent?
-Are you saying that in your test without spaces in the path only one out of the many tests was successful?
-Or are you saying both of the above?
I rename them , and the base pack is renaming it back......
double work
Nope.
You have to rename to a strict structure, but it's still a long filename. Alot of information is hidden inside them: the name of the DriverPack, for what platform they're designed and its version number. After the slipstream this clearly distinguishable naming system is no longer needed, then we need 8.3 compliancy. So I've made this 'long filenames' especially for you, my users, to make things a bit easier (for the future at least).
FYI: 8.3 compliancy is required for winnt.exe/winnt32.exe initiated installations and I believe some other as well.
After i renamed them all like this : DP_Graphics_A_wnt5_x86-32_603.7z ( example )
It recognized them , but.......
When i opened the OEM folder i saw that they all where renamed againso DP_Graphics_A_wnt5_x86-32_603.7z became DPGA603.7z
What is the use of renaming them then?
And the 3th party drivers all have their own .txt file in the OEM folder.
Example : This file had to be renamed to be compatible with 8.3 filenames.
Original filename: DP_VMWare_wnt5_x86-32_v1.1.7z , text file : DP_VMWar.txt : This file had to be renamed to be compatible with 8.3 filenames.
Original filename: DP_VMWare_wnt5_x86-32_v1.1.7z
What is the use of renaming them then?
8.3 naming compliancy
Nothing wrong with that either. My guess is that it was just that faulty NVRAID entry...
In the new DriverPacks BASE, this is handled by the presetup.cmd batch file. And in fact it's not really there either: thanks to DevPath.exe, which sets the DevicePath registry key for ALL DriverPacks, the Intel Chipset .inf files are integrated in the same way as they would have been with $OEM$\$$\INF. I overlooked that fact in the past (and no one else noticed it either).
Almost impossible. Are you VERY sure you've put only the latest DriverPack Chipset in the DriverPacks directory? Which version does the UpdateChecker show?
That's a weird error... I'd say your ISO/CD/DVD is corrupted.
Please submit it at the bugtracker, or I'll have to.
Could it be that it's the same issue as the one described here?
g is, though, that my laptop which runs NHC, which also requires .NET always installas the CP version of the drivers, which, in turn, do not require .NET.
Any reason for that, Bash?
Yes... The Control Panel isn't developed in C# (which required .NET), but other languages (probably C++) that do NOT need a framework.
NutEdge wrote:So really that means that ATI Catalyst Control Center needs .NET Framework installed and that is root of problem.
Correct.
It's just the GUI which is dependent on .NET, the driver itself works flawlessly without.
Correct.
Bâshrat the Sneaky wrote:In the next version of DriverPack Graphics A, the good ol' Control Panel should be reincorporated though. ATI has added it again, on a request en masse of their users .
Oh, have they?
Last version I found including the CP was 6.3.
Of coure, you could always install the 6.5s, uncheck the CCC in adv. install options and install just the CP from 6.3.
Works like a charm.Could we get an option to chose whether we want to integrate CCC or CP though?
Over the time I've become rather fond of the CCC (ATi did a lot to shorten loading times!) since it offers more options for more recent VPUs.
I already tried ATT but that didn't quite work out for me...
That will be indeed become an option.
If you don't want ANY control panel thingie installed, just open DPs_fnsh.cmd (inside bin\finish.7z) and remove the lines that refer to the ATICCC (do a search for "ATICCC.exe"). In the next version of DriverPack Graphics A, the good ol' Control Panel should be reincorporated though. ATI has added it again, on a request en masse of their users .
I don't know this by heart, but I'd say this is related to ATI's CCC. Do you install the .NET FrameWork BEFORE the finishing batch file gets executed?
Hmm... You can interpret that line in two ways:
1. The thing you mean: where KTD drivers are stored.
2. The way I implemented it: you can specify paths on which KTD will be applied.
I'll see if it's much work to add it... It will be added, but perhaps only after my exams.
I solve this trouble by remove one "=" from
*NVRAIDBUS=="nvraid"
Obviously
I might add that in the future, but it's not for now. (At least not before my exams.)
damn to slow
[edit]
look at the overview too and i can say it is overall
That is that known bug
When the release is final I am sure Bashrat will update the site with newer DriverPacks. As of now it is still in beta. Basically Bashrat is letting more of the members beta test it openly. There has been so much changed since the last DP Base that the new Base needs to be extensivley tested.
Voila
Nope, that's not an issue. I've restructured the site a bit a couple of weeks ago: no other projects than the DriverPacks will be added, so..
Woot Woot!
Whaz Up!
Aha!
The first spammer on my brand new forum!
DriverPacks.net Forum » Posts by Wim Leers
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.083 seconds, 6 queries executed ]