As I was writing to someone else this weekend, while the strategy that Apple adopted of making their own hardware to go with their software means you pay more for the package (due to lack of competition), you do not get any of these wonderful problems as they control every piece of your system: hardware, bios, firmware, drivers and operating system. Luckily their quality control is amazingly good and things "just work" and they do so for a long time. In our house, if you see a computer more than 3 years old being used, its a Mac. We typically use the same Mac hardware for 5+ years without even thinking of replacing it.
Apple puts their designer, production manufacturer amd software head on video for their products so you get a "behind the scenes" look at the thought processes on the decisions they make (this is on their consumer site, not their development site) and its very interesting. I am typing this on a unibody 17" macbook pro and its amazing (and not cheap!). Just the nicest piece of non-Flex equipment I own. Come on Deep Impact!!! 73 Neal Campbell Abroham Neal Software www.abrohamnealsoftware.com (540) 645 5394 NEW PHONE NUMBER Amateur Radio: K3NC Blog: http://www.abrohamnealsoftware.com/blog/ DXBase bug reports: email to [email protected] Abroham Neal forums: http:/www.abrohamnealsoftware.com/community/ On Tue, Mar 2, 2010 at 9:52 AM, Peter G. Viscarola <[email protected]> wrote: > <QUOTE> > Could latent devices installed from other motherboards really do this if > not active? It truly could be any number of problems that the fresh install > solved besides "driver hell" but just wondered if anyone else had this > experience. > </QUOTE> > > The key phrase is "if not active." If the driver is truly not active, the > answer is no... it cannot affect the running system. Typical PnP-enabled > drivers are only loaded when a device for which they claim support is > discovered. If there's no hardware involved, there are no interrupts. And > if there are no interrupts (and no timers) then there can be no DPCs. But, > even with no DPCs, a driver could STILL contribute to DPC latency. > > However, having lots of "unused" drivers hanging around in an installation > CAN complicate matters and affect overall system performance. Most drivers > provide a long list of devices they support and many end their list with a > claim that they support a wide variety of generic hardware for compatibility > reasons. So the driver starts out listing their support for a SPECIFIC > vendor id and device id, a specific vendor system and subsystem, and a > specific revision, and ends the list by saying "oh, and in a pinch, I'll > support any type of xyz device." > > When multiple drivers claim that they can support the same device, Windows > determine which driver to select for a device using a complicated algorithm > that is defined by business policy, not best technical match of driver to > device. > > Many vendor-specific drivers are implemented as "filter drivers" which > modify the function of a basic Microsoft-supplied driver. Such drivers > might load over an entire class of device -- ready to support a > vendor-specific model of that device should one be plugged-in (good examples > here range from keyboards and mice to DVD drives). > > There are also drivers that are implemented as hybrids: Sort of PnP, sort > of filter, and installed and activated by default. > > Finally, there are often drivers for lots of "system" resources that > really, really want to be matched properly to the motherboard in use. These > include drivers for BIOS-related devices (Do you have a "volume up" button > on your keyboard? Ever wonder how it manages to (a) change the volume on > your audio device, and (b) display a volume slider on your monitor? It's > partly done in the BIOS -- that's a trivial example, but an easy one to > understand). And there's a ton of BIOS-related stuff that can't be disabled > without secret monkey magic known only to the mainboard vendor (for example, > one mainboard I'm familiar with disables certain extensive BIOS extensions > when there's no RAM placed in a specific slot on the mainboard). > > And we haven't even BEGUN to discuss weird things like dynamic BIOS patches > (with stuff loaded via the registry), or other drivers that fall into the > category of "there's a bug but we can fix it in the driver." > > Getting the right set of drivers on your system for the best (or even > correct) performance can be a major task. That why I don't even TRY to build > my own system. I just order a machine from Dell or HP. OEMs control their > BIOS and tend to do a reasonable job of systems integration. While any > system you buy directly from an OEM will be plagued with lots of EXTRA goo, > removing stuff is waaaay easier than trying to find all the right stuff in > the first place. For computers designed to run PowerSDR, Neal provides this > system integration service which is custom tailored to our needs and > environment. > > It's all pretty complex stuff... and the more powerful the support chipsets > (like the ICH) become the more tightly intertwined with the BIOS things > become and the more critical and complicated system integration gets. > > Fun! > > Peter > K1PGV > _______________________________________________ FlexRadio Systems Mailing List [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kc.flex-radio.com/ Homepage: http://www.flex-radio.com/
