Theoretically, you could do that yourself (that's kind of the point with the 3rd party DriverPack).
However, if you feel very unsure about it (even after having read our tut), that's no problem to request an update.
However, I would think of it being considered very kind include a link to the file/the DL page so that the person going to do the update does not have to search very long.

If you feel extra kind, you may even point to a changelog and other additional info smile

Thanks for your understanding!

The problem with Autorun is that any self-respecting half-way computer-literate person I know has it deactivated, for good reason.
Basically, if you are using your PC as a multi-media player, it's a must to shut it off since some malicious copy-protection schemes of CDDAs and DVDs are based on installing a "driver" through Autorun that prevents the system from playing/copying the disc.

Just remember the Sony rootkit fiasco.
That would have never occured if there simply was no Autorun or everyone had it disabled.

So, yes, while Autorun is per se a great feature in a perfect world, it has long been rendered absolutely pointless which resulted in its deactivation (first thing I'm doing when I am being called to a "patient").
So, trying to rely on it to make the world a better place (which an SAD certainly does!) is a bad idea because in 99% of all cases it's not going to work.

OTOH, you can still run the .INF contents by right-clicking on the drive and selecting the (usually bold) entry.
That's great, but does not really save you much time unless you already have an explorer window open where you could easily perform that action.

I guess you could also write a script that would run the .INF on execution and place that to your desktop so you can do the Autorun with selected discs, however, you might as well place a shortcut to the whole drive and execute w/e file was in the .INF, not much different.


Anyway, I totally like the idea and all (just saying so I don't sound too negative here!), but would it really be worth the efford when no one would use it?


Just my .02€...

Firstly, a few more infos would be nice.
Did you prune any duplicated driver files?
Did you include any further possible updates for CRTs?

Secondly, please for God's sake do use the official hosting provided to you by DP.net!
There is absolutely no need whatsoever to use OCHs when our own server is up and running!
The time I have to wait on RS.com for even starting the DL I could already have well finished it were it hosted on our server (speed is higher than on RS.com, too).

Thirdly, you totally messed up the folder structure which will mean not only will the Finisher fail to delete the remaining files, also will %systemdrive% be cluttered with 26 files and folders...


Please read the tut on how to properly create a 3rd party DriverPack again and try to follow it.
Your effords in honour, but you aren't doing anyone favour if you do not stick to our guidelines.



EDIT:
Oh, and fourthly, WTF is a 12MB .BMP file doing in there???
DP_Monitor_wnt5_x86-32_81021.7z\IIY\
Just spotted by coincedence...

279

(4 replies, posted in German)

Danke für den Hinweis.
Da das dortige Forum zwischendurch abgestürzt war, hat sich wohl bei der Neuauflage auch die Adresse geändert.

Zur Zeit scheint die gesamte Seite nicht erreichbar zu sein, sonst hätte ich es soeben angepaßt.
Wird dann erledigt, sobald es wieder funktioniert.


EDIT:
Seite wieder erreichbar, Verweis angepaßt.

Ok, that means we should prune the old pack of any LCD drivers (but only if they are really duplicated, otherwise, migrate them to the new LCD pack) and rename it to CRT or something to indicate it catches all but LCD drivers.

I don't see any reason to have an driver included more than once, especially, when users can easily customize the dp3ps to fit their needs.

There's already a Monitor pack that also covers LC displays.
Did you check with that one so you only included drivers that were missing from it?

Otherwise, I suppose there will be lots of driver overlapping.

Unless you are using SP3 (either slipstreamed or installed), you will need to install KB888111, otherwise known as HDAudio hotfix.

Usually, it comes bundled with driver releases, as long as you install those via the setup.EXE and not the .INF method.


Besides, this does not qualify as "Site & Forum Issues And Feedback".
Please post in the appropriate section next time.

You can, of course, edit your posts...

Yeah, it's kind of the same, the option was mainly added because it was requested much and it certainly is more convenient to work from the BASE GUI seeing as we already have it.

284

(6 replies, posted in DriverPack LAN)

JakeLD wrote:

It's required, it's the driver itself.

Probabaly.

.SYS and .INF files are the most fundamental files in a driver.
It's strange that it is not referenced in the .INF, but if no other .SYS file is, it has to be the driver file.

OverFlow wrote:

PS jinkazama your title of this post is no longer accurate wink

Well, then let's put a SOLVED tag on it, shouldn't we? wink

Registered wrote:

now what this all means i'm not going to say this is the 1st time in a very long time i have benchmark something, there are some smart people here that hopefully will confirm i done things right, and even better do further tests to see if the M3 Raw idea is veasable without some kind of container for the many many thousands of files that driverpacks have and can dvd-reader and writers handle this new method in general.

You still do not seem to have grasped my point:

There's no difference between small, single files or a large container file that houses these small files.
If the sector-based access (and that is what matters for the ODD, it does not care about the overlayed file-system) is non-linear, then that means the head will need to shift often, access times will rise, throughput will go down and the driver will make "funny" noises.
Why do you assume files in a contained would all be consecutively arranged while single files aren't?
It's still the same data inside the container, the same sectors to be read and possibly even at the same positions.

As I said before, for random data access, Flash memory is the best because it has no movable parts that would slow down the scattered access process.
Any drive, be it HDD or ODD will suffer greatly from this compared to it's burst data rate.

The only way to overcome this is to know in which order files are being read an to pre-arrange them so that they lay in line.
I am sure this can already be done at ISO level, so there's no need for a container file.

Obviously, even inside a container, there can be fragmentation.
The worse thing about it is that file-system defragmentation cannot even catch it because it's invisible to it (it only sees the big container file).

Think about that for a second.

but personally do fear the workload and extra fatigue added to a dvd-reader could be quite high,

I am sure a PC drive will be designed and tested for such cases of stress.
Compared to an ordinary stand-alone DVD player's drive (which often enough happen to be PC drives anyway), you usually do not only play one large file (the movie) in one given order (from start to end).
The common case is random sector access (same for HDDs), which is why access times play a great role in the performance of different drives and should not be neglected.

in fact i've even seen on many occasions dvd reader's have trouble installing the first steps of windows XP.

That is probably also due to the fact that an unattended medium has to be created by the user on either R or RW media (which are not perfect to read compared to a pressed medium) or the fact that Windows setup is extremely pricky about BIOS settings, RAM timings in particular.
It usually helps setting the BIOS to "Safe Mode" if you encounter file read errors during setup.
You can re-enable your ordinary ("Optimzed") settings once it's installed.

287

(6 replies, posted in Other)

Everything downloaded from windowsupdate.com is logged to WindowsUpdate.log (d'uh) in %systemroot%.
Apart from that, you can directly access driver updates through that system by going to http://catalog.update.microsoft.com/v7/site/Home.aspx

Heh, almost same for me.

I don't mind whether it's German or English as long as it's uniform.
I hate mixed-language OS and apps.
It's just confusing and doesn't look right, IMO wink

There was indeed a problem with DVD writes being used as reader would wear quite fast due to the heavier read/write head as opposed to the more simple read-only head around the dawn of the new millenium.
Since then, I have only been using RW ODD drives for my tasks (why even buy a read-only one when writing capability does not cost more plus writers usually tend to read better, too).
I could not observe any malfunction that could in any way be related to heavy read duties.
Dust is a much bigger thread, moreso if you smoke in the same room.
Cleaning the lenses usually takes care of that, though.

However, it is true that if files are not being read in the linear order they are being found on the disc, drives will make loud noises during seek operation and the access time gets really bad.
The idea would be to either arrange the files on the disc in such an order that they can be read mostly linearly during installation or to even shift from an ODD to, say, a USB stick.
Flash media does not mind where random access happens, (read) access times do not depend on it.
Most system can actually be booted from a USB stick, plus you wouldn't even need to verify the ODD medium for write/read errors after burning.

Anyway, even if there was some big .BIN file, if data access inside the file was still not linear, you'd still encounter the problem of lens head seeking through the sectors.
It does not matter whether it's on a file system basis or in-file, if the sectors are not arranged consequitively, the problems persists.

Seems to be a common problem as of late.
Too bad, I can't do anything about it hmm

Ok, then this problem still persists.
In such a case, it's perfectly fine to host the file elsewhere and link to it.

Hopefully, we will get the bugtracker bug sorted out...

Fine by me, just saying smile

The trick is to split up the log into several posts and no, we don't mind double or triple posts if that is the reason wink

Dutch pack?
If you mean Dutch language file for BASE, that should have been covered by Bâshrat the Sneaky seeing he's Flemish to begin with wink

.INF and .SYS files (.CAT are optional and only required for the WHQL certification) are what make a driver.
If you find an .EXE file, that means it contains either a self-extracting archive (SFX) or an installer - in any case, inside that file you will also find .INFs and .SYSs once extracted.
Some files can be unpacked with 7-Zip, others will require the use of Universal Extractor or even need to be executed and have their contents grabbed from %TEMP%.

Anyway, you can easily compare driver version on our devices page as found here: http://driverpacks.net/DriverPacks/devices.php?pag=c

Apart from that, I can only urge you to try and simply run a test install.
If there's devices missing afterwards, you're most welcome to come back here and report.

We usually do not appreciate users asking whether it will work when they haven't even tried it wink

Once again, I urge you to upload the file to the bugtracker instead of hosting it on RS or some other OCH.
It's much more convenient for us and the system will automatically notify those in charge of the new version so it cannot be overlooked.

Of course, if the registration at the bugtracker is still broken, please notify us again.

In any case, thanks for your effords! smile

Ow snap...
Thought it was, because I just installed RC1 right before posting, however, I always let it overwrite the old versions so maybe that's how it was placed there...
That's what you get for being one of the testers, always playing with the unofficial versions wink

Anyway, you can either work from the code I posted or check out this file (it's my translation I uploaded but also includes English and French):
http://rapidshare.com/files/142183294/un7zip.7z.html

Ok, here's another job waiting for you smile

http://forum.driverpacks.net/viewtopic. … 330#p24330

Please try to get this done in time so we can have a nice fully translated final release on the new BASE smile

As of now, the new version of BASE that has been released as RC just recently (and which you can get here) will feature an improved un7zip version that provides a more comprehensive progress report which requires translation in order to provide a unified language experience for both slipstreaming as well as installing.

In order to achieve this, ALL translators are asked to translate the following entries from the \bin\un7zip.INI:

[English];GetSystemDefaultLangID
MSG_USAGE = un7zip V1.0 -- Extract 7zip files to target directory with log#13#10#13#10This 32-bit program decompress 7zip files in a target directory#13#10and can append its error log in an existing file#13#10#13#10Usage:#13#10#13#10#09un7zip <Files> <TargetDir> [LogFile]#13#10#13#10#09where:#13#10#13#10#09Files specifies a list of one or several files to decompress.#13#10#09TargetDir is the folder path (created if not existing) where#13#10#09the archives will be extracted (recreates directory structure).#13#10#09LogFile is file where error log will be appended.#13#10#13#10Example:#13#10#13#10#09un7zip "C:\Archive to extract\File1.7z" "D:\My Extracted Files\" C:\error.log#13#10#13#10Batch example:#13#10#13#10#09un7zip C:\Archive\*.7z D:\ C:\error.log#13#10#09if not errorlevel 1 goto END#13#10#09echo ...#13#10#09:END#13#10#13#10
LOG_LINSEP = ------------------------------------------------------
LOG_EXTRACTOK = #09Decompressing file %s (%d/%d) in %s : OK, no errors found.
LOG_EXTRACTKO = #09Decompressing file %s (%d/%d) in %s : *KO*, error occured.
MSG_EXTRACT_INFO = Decompressing#32
ERR_INVALIDFILLST = Invalid files list %s.
ERR_INVALIDTGTFLD = Invalid target folder %s.
ERR_NOSOURCEFILES = No files to extract.
ERR_LOADDLL = Error loading 7-zip32.dll.
LOG_START = Starting un7zip at %s
LOG_CLOSE = Closing un7zip at#32
LOG_RECAP = Found %d 7zip file(s) in directory %s
LOG_ERROR_RECAP = %d decompression error(s) occured

Translations currently done is French and German (with the English version actually being translated from French because that was the native tongue of the coder...).
Please have a look at these to see which lines need to be translated and which don't (i.e. some variables and code pieces).
If there's any questions, please do not hesitate to ask in here.

Because there's no separate files for the translation entries, all need to be merged into the single file.
As we are more than just a handful of translators, having one person translate, then having the next to append his to the previous one is not a good solution.
Therefore, please submit your translation only in TXT format to the bugtracker where it will then be merged into the main INI by the Team and hopefully released on time before going final.

Once again, let me thank you for your efforts and continuous support in the name of the whole Team.
Without you, the DriverPacks wouldn't be as universal as they are! smile

Hehe, if you wish, you may receive.

Here's your sticky wink