Search options (Page 10 of 58)

Attention, translators, there's a new entry that needs translation:

---------------------------
Warning
---------------------------
3 Language file lng\German.lng invalid: [any_any_any__GUI]\updateChecker_18 entry does not exist! The English text will be shown instead! Please contact the translator for this language (German), Helmi, in the forum to fix this!
---------------------------
OK   
---------------------------

(this is just an example, the German file has of course already been fixed )

Good questions...

I got quite confused myself.
So far, I have simply been adding all of the packs to cover as many drivers as possible, taking potential overlapping and waste of space into account.

Per definitionem, Monitor should cover all visual user interfaces (those "glass tubes" are actually called CRTs - Cathode Ray Tubes, the pack should be renamed to that if it was only that and not LCDs, btw).

Maybe the creators of the actual packs could chime in and shed some light on that.
Otherwise, we will probably have to run a file comparison between packs, delete duplicates, then merge them into one pack (easier than splitting them up...).

By the size of the current Monitor pack, I guess it covers all, LCD and CRT alike.

As I wrote in my last post, yes, we know this and it's fact and easy to understand (solid archive and all) - but we have reasons not to pack all drivers into one single archive.

You can do that all by yourself though, extract all DriverPacks and repack all files (also including .INIs) into one big 7z if you want to save space.
Just please leave DPMS alone

It's just not practical for DL.
Maybe it was if we offered xdelta files or somesuch... (so you really only DL those bytes that have changed within a given file)

Dang, yes, I actually did...

We've already had numerous discussions about how splitting up the packs for the overall best.
The current method seemed the most logical to all of us because it splits HW by use, i.e., pack A has the most commonly updated cards (current ones), B all the business models (CAD etc) and C the legacy ones that are most likely never going to get updated driver ever again.
We figured, you may need only either of the packs really (but you can use all three, of course).
On old HW, you won't need A&B, on business PCs, you won't need A&C and on a gaming PC you won't need B&C.
Reason for this is if all drivers were to be placed into one pack, only a tiny update means you'll have to re-DL the whole bunch.
Some users are on a slower connection and we also don't want to have the server cap out (though unlikely).

You are of course more than welcome you repack the packs to your own liking.

Well, that's probably because there is no such single file of nearly that size (apart maybe from DriverPacks packs with huge wavetables...).

Personally, I'd recommend at least 512 MB to run XP on, but 256 should be ok, if you don't do anything on it

Anyway, I see 256 MB as the bare minimum (I think it's also the official one, below that XP will not let you install it unless you manually eidt the limit) so if we are going to change compression settings, we should not aim below that.
Anyone who is willing to run XP on less memory is either totally incompetent (unless it's the Embedded Edition maybe) or asking for pain.
In that case, we should not deny them that

Anyway, I just tried decompression the DriverPack Graphics A 812 myself and, according to the task manager, it only uses ~350 MB of memory (comparing before and during values)...
So I'm really not sure why our figures differ that much, magon.

This is with 7-Zip 4.62, btw.

The problem is not the 120 DPIs (I've been running this fine on 129 DPIs after all) but the fact that you changed the Windows GUI settings to display large or even extra large fonts.

Unfortunately, Windows does not properly support changing the font DPI settings in the GUI options.
It will lead to distorted (ie not properly resized) icons in the taskmanager, taskbar and desktop, among others, namely not properly scaling GUI windows to fit the larger fonts in.

The questionmarsk should actually be bullet points, maybe your locale doesn't support them?
("?" are a replacement for any codepage letters than cannot be displayed, it's lacking Unicode support of Autoit, maybe?)

Anyway, as the windows uses a fixed size, using larger fonts will naturally result in text being cut off.

May I ask what kind of display you use (inch-wise)?
Ususally, 120 DPI on an ordinary high-res display should still be easy on the eyes in terms of readability.

The amount of RAM needed to decompress is significantly lower than that required to compress!

A dictionary size of 64 MB requires mere 66 MB to decompress (there's a little overhead I guess) but 709 MB to compress.

The lowest-end machine I am using the DriverPacks on has 384 MB of memory in and it has yet to prompt a memory error during decompression.
512 MB of RAM should be more than enough - form my personal experiences, the minimum requirement does not lay at the 1 GB mark...

Plus, XP 64bit is more of a technology demo than a finalized product.
Yes, you can buy it but it never really was supported by MS they way a "proper" OS should have been.

I guess, it was just a big field test by MS to get some 64bit experience before going to Vista or Server 2003.
This may also be the reason why there's hardly any drivers or manufacturer support for it.

Hm, now that you mention it...

I never really tried w/o the special driver on my Habu, as I included it in my personal DP.
When I got the mouse, I installed the software immediately, only to find it too bloated and fancy.
So I just grabbed the driver files and included them on my install disc.

Guess I'll have to try w/o them to find out, however, using just the drivers files and no useless GUI, I can see no negative side-effects.

Well, certain mice, while working fine with the default MS provided driver, feature enhanced capabilities that go beyond the scope of RMB, LMB, MMB and scroll wheel.
For these, you may need to use a special driver.
For instance, mine has a DPI quick selection button that can increase or decerase the sensitinity on the fly.
It's pretty useful because usually, I like a high responsiveness so I can traverse desktops faster, however, when using an image manipulating app, I want absolute precision and not have it skip a pixel so I turn it down then.
Pretty convenient if you switch often.

Of course, you won't notice any difference with some ordinary €15 mouse, so you may want to cut out on this pack.

No, we mean either HW manufacturer sites (e.g. intel.com, nvidia.com, amd.com etc.) or system manufacturers and assemblers (i.e. dell.com, hp.com etc.)

Point out what they are and link to the DL site and they may be added.
Use the HWID tool in my sig to help you on this task.

Uh, no idea, you could check the driver listing on the main page for that.
Then again, a single driver may support numerous devices. so it depends on how you count.

Well, same numers do not necessarily mean same files.
It could just be 50,000 different files so adding them in would bring you to 100,00 total, or it could be the same files (that would be great because you could easily identify them using a file comparison/duplicate tool) or of differen versions (in that case, only the newer one would be installed so it doesn't hurt too much).

You could always have WPI run from an HDD (USB drive maybe) or a network source or even a different DVD; even if that may mean a manual disc exchange.
As you could also install XP directly off a USB drive (http://www.msfn.org/board/Install-XP-from-USB-f157.html), space should not really be the issue, but I can understand that you want to cut down on duplicates (we also hate PCI ID duplicates ).

Maybe you should give VirtualBox a try.

I was very fond of VirtualPC myself (liked it much better than VMWare) but VB has been coming along quite nicely.
As an industry's first, they even added support for 64bit guests on 32bit hosts and 3D support for OGL in the latest version (2.10)!
That's really something to long for in a VM, IMO!