Jan 16 2009
Windows 7 βeta
A Windows Vista-running PC decided to implode the other day, crashing with random noise on the screen (or a really strange frosting-type effect, where slightly off-white static quickly encroaches from the edges of the screen) after Windows has been running for a while, for a few minutes after starting a DirectX game, etc.
It could potentially be malware-related… but it seems too drastic a failure for that.
I’m wondering about whether it may be a hardware problem, perhaps in the graphics card (it is a small form-factor case, so the graphics board is probably getting quite toasty). Nevertheless, software hasn’t been ruled out, so this seems like a good chance to try out the new beta of Windows 7.
The machine is a fairly standard Shuttle SFF PC with a Core2 Duo processor, Intel chipset, and ATI Radeon HD2600 PCI-e graphics. However, after installing the 64bit version of Windows it quickly became clear that, be it because it’s beta or be it because it’s 64bit, the current form of Windows 7 has limited usability:
On this machine, amongst the items for which drivers do not exist are the Realtek USB Wifi module (which, to be fair, wasn’t recognised under Linux either), the ICH9 82801 SMBus (which is about as standard as they come), the onboard Gigabit ethernet controller (seriously?), the integrated fingerprint reader (not necessarily a surprise), and several others. Having no support for any of the available network interfaces, though, is somewhat limiting.
I’m going to try the 32bit version next, and see how that compares. I’ve heard that drivers for 64bit Windows tend to be sparse at best – but I didn’t figure that the situation would be this bad…
16th January 2009 @ 11:52 am
(I tried running Fallout 3 on this machine, and it got to the point where you start to create your character before the graphics failed in the same way and the machine spontaneously rebooted. Hmm – it’s looking more likely that it is a hardware issue. This shouldn’t have affected
Vista’sWindows 7’s ability to detect devices, however)16th January 2009 @ 12:25 pm
I noticed that the 64bit edition of Windows 7 contains a “\Program Files\” and “\Program Files (x86)\”…
My immediate thought, admittedly, was along the lines of “Good God, No!”. For any shared library-based system (e.g. as opposed to older *BSDs where everything was statically linked, or Mac OS where all applications contain any non-system frameworks and libraries within the Resources directory) which is capable of running both 32bit and 64bit code, such as WIndows, then there needs to be the ability to make both 32bit and 64bit versions of libraries available – thus the presence of /lib and /lib64 on 64bit Linux, or /lib, /lib32 and /lib64 on IRIX (which has the advantage of having actually been designed for this from the ground up instead of having it hacked in at a later date). This makes sense…
What doesn’t make sense, to me at least, is why Microsoft would then think that there’s any significant advantage to having separate Program Files folders, though – unless they’re still storing components vital to the operation of the OS within these.
More to the point, now that Microsoft has created an explosion of different storage locations (applications on a 32bit system could, as I understand it, be stored in /Program Files/, /ProgramData/, or either of these two within their home directory and overlaid onto the top-level ones), will this all be doubled again for 64bit usage?
I’m all for the concept of running every user sandboxed, but instead it appears that some files (applications as well as user-specific data) are relocated to a per-user overlay, whilst some aren’t. I’ve not seen much of a pattern – but it certainly does eat up disk space like nothing else.
Indeed, this is how Microsoft should have engineered 64bit Windows: The system should boot into the 64bit environment. 32bit applications are transparently run under a VirtualPC-like emulated environment. Ideally, each separate application should run in its own Virtual Machine, although this should be transparent to the user. In this way, if an application is marked as being designed for, say, Windows 2000 then it could run in a Win2k virtual machine with Win2k system files – and the application would never know any different. If these application VM images are implemented as Copy-on-Write then there’s no disk-space overhead of one Win2k VM compared to one hundred of them.
There would certainly be engineering issues such as IPC/RPC and sharing clipboards for copied and pasted data – but there doesn’t seem to be anything that VMware hasn’t already addressed.
The benefit, of course, is that snapshots and versioning can because integral to and ubiquitous throughout the OS: Install an application, and the VM can then be locked, with user data being written in a home directory without the VM itself. The image can be unlocked for upgrades, rolled back to previous snapshots, etc. It would mean the (thankful) death of the “Repair Application” menu item. Each application would have the libraries it needs to run, and remove the complexity of the side-by-side (SxS) system that is hacked into Windows right now.
Best of all, it might finally lead to the removal (or significant deprioritisation) of the registry: whoever thought that a huge binary blob which any application can write to but is essential for system operation was a good idea was clearly mistaken: how much Windows trouble is attributed to registry problems, and how many tools promise to optimise or fix these? Surely, the registry is only ever accessed by API calls rather than directly, which would allow these APIs to be rewritten to use a different, potentially application-specific, back-ends. Legacy registry services could still be made available to applications which expect them to exist (via the VM they run in), but the OS itself and new applications could move away from this.
I’m not dead-set against databases, and even per-application databases created and maintained by the OS and presented to applications via a simple interface – but it doesn’t seem like good design to lump all of these together in one place. If nothing else, it makes the complete removal of an application very difficult. Moving development in this direction would at least allow the Registry paradigm to be exorcised gracefully.