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.

1,878

(8 replies, posted in Other)

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.

Fragbert wrote:
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.

razormoon wrote:

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 smile

Vier wrote:

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?

muiz wrote:

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.

muiz wrote:

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 again

so  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 wink

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?

1,891

(8 replies, posted in DriverPack Graphics)

Helmi wrote:

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.


Helmi wrote:
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.

Helmi wrote:
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 smile.

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. smile

1,892

(8 replies, posted in DriverPack Graphics)

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 smile.

1,893

(8 replies, posted in DriverPack Graphics)

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?

1,894

(3 replies, posted in Feature Requests)

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.

DmitryOlenin wrote:

I solve this trouble by remove one "=" from
*NVRAIDBUS=="nvraid"

Obviously roll tongue

I might add that in the future, but it's not for now. (At least not before my exams.)

hanschke wrote:

damn to slow sad

[edit]

look at the overview too and i can say it is overall wink

http://img86.imageshack.us/img86/3223/15ng2.th.jpg

That is that known bug wink

1,898

(7 replies, posted in Site & Forum Issues And Feedback)

Siginet wrote:

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 smile

1,899

(7 replies, posted in Site & Forum Issues And Feedback)

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..

1,900

(26 replies, posted in Other)

Siginet wrote:

Woot Woot!
Whaz Up!

Aha!

The first spammer on my brand new forum!  cool wink