Windows Drivers

If you start sending it "magic packets" it's probably surprising to many how many "features" it has.

"Star codes" I guess they call it.

There's definitely an idea that an o.s. design could include all the drivers necessary to make for PCIe and USB for most usual sorts of NICs and peripherals and usually entirely 0-many bytes "closed third-party binaries".

Something like UEFI is surprising, what with TFTP, BOOTP, an Internet stack, secretly stealing packets off the NIC, ....

The latest outrages of Linux escalation exploits all have been due "modules" alike "drivers" that 99% of people don't need. Then again the usual greater outrage is the simple use of Intel's/AMD's/ARM's various "system management" protocols that run on their own little on-board chip and reserve their own little fiefdom of memory and install hypervisors like Xen and sit there constantly stealing all the I/O. Of course the system management stuff is widely publicized since at least a decade, while the latest round of virt-ing seems a lot simpler to intruders than root-ing since the architecture makes it so easy for script-idiots.

Anyways it's pretty easy to look around and find "compromised" systems everywhere.

Probably bloatware for some kind of wireless control panel you don't need.

I generally get drivers from here

Memory is free, in the sense that it's not the developer who needs to pay for it. Man-hours cost money. Bloat and laziness, really.

Jeroen Belleman

Granted, a poor example (it just happened to be the "driver" that I was downloading, at the time).

But: Audio ~150MB USB3 ~12MB Video ~200MB Card Reader ~15M even the "keyboard/mouse" driver is a few megabytes (and *it* doesn't have to the dynamics of scanning the switch matrix, detecting up/down events, etc.)

Of course this doesn't represent *installed* sizes. Or, how much is wired-down, of necessity (you'd likely not want a "driver" being paged out though arguably could do so with the associated handler)

But, how much "fluff" is there just to tell the user "This is an XYZ driver. Click to accept license and install" -- even assuming the *driver* (and not the OS) has to police its own installation (compatibility, revision, level, etc.)?

I visit the manufacturer(s)'s web site and DL the sets of available drivers, per supported OSs. I suspect they have more finely tuned their drivers to their hardware than someone at MS (who likely just wants to ensure the driver SILENTLY keeps trying to do whatever it should instead of actively reporting about problems it encounters). ISTM there would be too much temptation to make a more "generic" driver at MS (and, as MS has such abysmal reputation for HARDWARE design...)

These seem to decompress to actual applications that are likely scripted in the installer. Has me wondering why it can't just "do its thing" without interacting with the user so much.

And, likely each has support for a "/silent" switch when installation is automated/scripted!

I'm not particularly concerned with space on disk. I expect MS builds to be fat and heavy (My FreeBSD boxes boot of a 1GB thumb drive -- and that includes a full userland, man pages, compiler suite, etc.). I can

But, it makes me wonder what *basic* assumption they made in their approach that is (likely) "wrong"...

The biggest sys file in my C:\Windows\System32\drivers is 8 MB and that appears to be an Intel wifi driver.

Most downloads will include 32 and 64 bit versions. Anything more than a few tens of MB is likely to be not strictly necessary but you may want a control panel for graphics and audio.

I do too sometimes if I can't find it elsewhere. BIOS updates may only be available from the manufacturer although that seems to be changing.

Hence my comment: "Is there THAT much installer overhead involved?"

Dunno. I see an option to select which *version* of which OS to install (x86 vs x64) so assume there is some difference in the offerings provided by each.

Card Reader? USB? Keyboard/Mouse?

I look at the kernels on my *BSD machines in the ~20MB range, KNOWING they haven't been strip(1)-ed AND are "GENERIC" -- including drivers for a variety of USB controllers, NICs, disk controllers, etc.

OTOH, I assume Windows uses a dynamically-linked kernel so can make allowances for a *small* bit of symbolic overhead, there.

Most of my boxen are from mainstream manufacturers. I think I only have one "beige" (black) box -- and even that uses a supermicro MB. Im comforted knowing the components are signed by a "legitimate" entity.

The downside is a particular box may not be supported for a particular OS or release. Or, some aspect of the hardware manifest may not be supported. But, this is usually not important to me; definitely not worth the uncertainty of wondering if a component for some *other* OS/release *might* work.

I update BIOS when I acquire a box and rarely thereafter. It is likely that the BIOS update will require Windows (that is changing; and, not necessary for server-class machines) and it is unlikely that the box will end up *running* windows, once deployed (and installing windows AFTER that point just to update a BIOS is a PITA)

Another *BSD advantage: pull drive and put in another box and "it just works". So, no real downside to bricking hardware (or hardware failure or abandonment)

Of course, this is far worse for *appliances*...

That immediately more than doubles the file size for a driver package. Increasingly as x64 machines dominate x86 32 bit code will drop out.

Graphics driver packages that support exotic hardware acceleration and/or using the GPU for parallel computing tend to be rather large.

As do reliable network drivers that can work around the various strange defects in different manufacturers Wifi chipsets and quirky motherboard implementations by certain laptop makers.

Apple code is very fussy about which chipsets it will work reliably with. It makes Hackintosh machines made from PCs quite tricky to build.

No idea why the audio drivers should be so huge except possibly to cater for the weird oversampling rates that audiophools insist upon.

Card reader code is probably large because they CBA to make it smaller.

Signal processing code is normally very compact as otherwise it would not be able to execute in real-time - especially at stupidly high sampling rates.

But, there are different x86 and x64 downloads. So, it seems likely that the "wrong" binaries have been stripped from the individual DLs.

And, these are *drivers*. Do Windows developers have a different notion of the responsibilities of a *driver* than traditional OS designers? E.g., a NIC driver should just get the packet off the media and hand it to the next higher level actor (fragmentation, message checks, etc.)

A "keyboard/mouse" driver should take up/down codes and use them to update it's internal statemachine, deriving any information REQUESTED by upper levels.

USB* acting similar to NICs.

E.g., the *sources* for these on my *BSD boxen are in the tens of KB range (their counterparts in my RTOS are a bit larger but usually because they have additional responsibilities not required in a desktop OS).

As a crude assessment:

- ~500MB of sources for the entire kernel (ignoring typ config)

- support for *59* different targets

- 85 different device drivers

- that build to a ~25MB (unstripped) kernel

- will run in 4MB of RAM (40MB disk) (i.e., I can pull a boot drive from any of my x86/x64/SPARC/etc. machines and install it in a similar target and "it just works". Despite the fact that the new target likely has different chipset, I/O devices, may support a RAID array, etc.

To a zeroth order approximation, about 20 bytes of source to each byte of binary. So, a 20KB source file might distill to ~1K of executable.

But, these are "consumer" drivers from the VAR website -- not performance drivers from the GPU vendor.

But, the VAR knows what quirks *his* products have -- unlike a *BSD driver that has to operate on any product that includes that chip(set). I.e., you expect teh *BSD to have to deal with more issues than a driver made (?) by <bignamecomputer> company.

Audio drivers seem to often include user-level apps to configure/tune the audio subsystem. E.g., my machines notice when something is plugged to an "audio" connector and give me the option of indicating what that "something" is. Graphically, of course.

I suspect there is something else common to all of this "inflation". But, I no longer have MS compatible toolchains to explore those binaries.

And, audio chipsets often include hardware to do that. So, all the driver has to do is configure it, properly.

The important word here is "properly". Windows PCs are a good example of how not to do things. The Intel hardware audio spec uses a native sampling frequency of 48ksa/s. Windows uses a default sampling rate of 44.1ksa/s although this can be changed. This means that in a typical PC an analogue input will be sampled at 48ksa/s and the Windows audio driver will then immediately resample it to 44.1ksa/s.

John

Yes. CDs were created at 44K while DVDs moved to 48K. One wonders if there was technical merit to the decision or just "lets make sure they aren't compatible".

High end digital audio takes this to extremes.

Yes. I face similar problems in my audio signal processing chains. But, adapt the sampling frequencies used to those available in the original signals (silly to sample telco audio at 40+KHz @ 16b).

But knowing that is the responsibility of the hardware/driver designer -- in much the same way that I don't run my speech synthesizers at such silly rates (there is little to be gained by doing so -- especially if the resulting audio is going to be piped to a POTS connection).

The user doesn't need to interact with these things in the same way he would have to inform an audio application of the placements of his speakers, or whether he was using earbuds vs. studio monitors.

In (traditional) speech synthesis, the actual signal chain makes a notable difference in the fidelity/quality of the output. Much of the existing theory/algorithms rely on outdated models from a time when CPUs (not DSPs) were severely restricted in what they could accomplish in unit time. So, you will see sample rates of 8K, 11K, etc. These introduce artifacts that prove unpleasant to the listener -- yet are difficult for a user to "describe". Pops, whistles, ambiguous plosives, etc.

But, again, the designer is the one to sort these things out, not someone making a unilateral decision as to how the signal processing chain *will* work.