What John Wants From Longhorn
on 05.01.05, 02:42pm in windows • comments (1)
[John Ludwig] What I really want an OS to do is get the most out of my hardware, and more to the point, make my hardware work.
Check out John’s post regarding what he’d like to see from Longhorn. I think he really hits the nail on the head here. In fact, I was just talking to my dad this morning about what a nightmare it is getting his 802.11b wireless working in his house.
Mike Dimmick (May 2, 2005 @ 6:51 am)
I can’t comment on John’s blog so I’ll comment here, if that’s OK:
1. Windows already supports SMART - it’s surfaced through WMI (link: http://www.microsoft.com/whdc/archive/smartdrv.mspx). IIRC, if a predicted failure event occurs, it’s logged in the System event log. There could be better UI for this - I don’t know that many people in the habit of checking the System event log on a regular basis.
2. Video card stability is up to the device and driver manufacturers. See also point 5. Microsoft could make implementing video drivers easier, but it would help - a lot - if users only used signed drivers that have passed WHQL, and if the manufacturers concentrated on making portable, reliable drivers rather than trying to bypass the HAL and violate the driver model to get fractions better performance.
3. USB drives depend on the USB controller implementation on the drive, on the host controller, and on the manufacturer-supplied drivers. Windows provides generic disk support which should work properly. I’d suggest _not_ using your motherboard manufacturer’s drivers, and instead using Microsoft’s generic ones. Unfortunately you tend to get a bundle of drivers for your motherboard, some of which are virtually required (e.g. AGP GART support). USB on Windows can be a bit flaky from time to time.
4. BIOS patching. If this can be achieved while the OS is running, it should be possible to do so through Windows Update on current systems. Distribution of drivers through WU is currently weak, but that’s not Microsoft’s fault. It’s the fault of the third-party hardware suppliers who won’t put their drivers through WHQL test, won’t produce driver-only updates, or won’t sign the legal release to allow MS to distribute the updates.
5. Overclocking is mind-numbingly stupid. Don’t do it. Running devices out of specification will generally cause them to be unpredictably unreliable. See Raymond Chen’s post of 12 April: http://blogs.msdn.com/oldnewthing/archive/2005/04/12/407562.aspx. I would actively resist any attempt to add UI to enable or monitor overclocking.
6. Description of how device states (D0-D3) map to system power states (S0-S5) are up to the driver manufacturer. The manufacturer can be cajoled into doing it properly; Microsoft are already providing encouragement. Hibernation (if we mean S4) isn’t really an issue, since that’s a suspend-to-disk operation - resumption is really a new system boot. However, some devices - like my Linksys Wireless-G PCI network adapter - don’t work correctly after a resume. Power routing doesn’t always work correctly - I’d like to be able to wake my machine from Standby by moving my mouse (MS IntelliMouse Explorer 3.0 USB) but can’t because the power to it is turned off, even with the ‘allow this device to bring the computer out of standby’ option checked.
7. SATA support. SATA controllers might offer support for emulated parallel ATA; if so, no new driver is required. Longhorn should offer native AHCI support for controllers that follow the AHCI standard. The current support for booting from native Serial ATA controllers is the same as for SCSI controllers - a boot driver is required at setup and at boot time for any controller not supported directly by the system BIOS. At present Setup only supports loading such third-party device drivers from floppy disk. Setup is supposedly getting a big overhaul for Longhorn anyway.
8. Windows Server already supports software RAID. The support is also there in XP to _use_ mirrored or striped volumes, I think, but you cannot _create_ mirrored volumes with XP.
9. Power really just doesn’t work like that. When you demand a large current, the voltage may drop, and drop below thresholds which cause values to be misinterpreted. If this happens your computer’s behaviour will be essentially random. You should always ensure that your PSU is sufficient for the maximum possible load on each line. Not overclocking your system may help.
10. MS is already a member of the Wireless USB promoter group. It’s not clear what the host controller driver interface is supposed to be - presumably some extension of USB 2.0 Enhanced Host Controller Interface. The standard doesn’t appear to be finished yet.
11. I’m sure MS would love to do this, and indeed generally only does include the raw functionality required in in-the-box drivers. It’s up to the device manufacturers to decide what they ship. Complain to the device manufacturer, not to MS. If your camera behaves as a USB storage device, it simply appears as a disk in My Computer. As for phone sync, we have the OBEX protocol, but currently no way (that I’m aware of) for applications to advertise information that could be synchronised.
12. I’m not sure what John wants from multicore that isn’t already in Windows. XP and 2003 already understand hyperthreaded and NUMA systems. There’s no point leaving a core idle when there’s work to be done, even if using that core is sub-optimal, so long as at least one thread is using the ‘correct’ core (or a correct logical processor). It’s often better to make slow progress than wait for the ideal situation - by the time the correct resource is free you could have completed it on the slower resource. A lot of computer users seem to want resources to be unused (e.g. ‘how much memory do I have free?’), for some reason, whereas the correct question is, “are all my resources being used sensibly?” IIRC, at PDC 2003, Microsoft announced resource-reservation facilities for Longhorn to ensure that, for example, audio decoding would not be CPU-starved and therefore would not skip.
A lot of John’s requests are largely out of Microsoft’s hands - they could be taken in-house but only at the cost of taking on many staff to implement them, and of offending the hardware manufacturers. Others are either impractical or highly undesirable. Most of the rest are either implemented already or in progress.