Why Windows is not ready for the desktop!

OK – yes I know this is a provocative title. But it is often claimed that Linux is not ready for the desktop. I have been using Linux as my primary desktop environment since 1996, so the statement always surprises me when applied to Linux. Prior to that, Solaris 1 was my desktop from 1990, and before that it was Mac. Each step was an improvement on what came before. Compared with the Windows of the day (Windows 95), the Linux desktop was so many light years ahead that it was a butt of jokes (eg “PC-contemptibles”).

However, inevitably, the Windows juggernaut caught up with me. For a variety of reasons, my paid work now involves working with Windows machines a substantial fraction of the time. In 2006, I started to use Windows for the first for anything more significant than driving a scanner, or running a web browser. This was Windows XP, which I would consider to be the first release of Windows that might be ready for the desktop. It has proper multitasking, remote administration (though not in the “Home” version), schedulable tasks, and services. It lacks, though, in the multiuser department, although for my day to day work, that is not too important.

However, as I began to use Windows more, the more its deficiencies became apparent. Bearing in mind the long history of posix systems for my desktop, it is crucial that my desktop support posix functionality so that I don’t take an immediate productivity hit from trying figure out an alien way of doing this. Bear in mind, that all modern desktop operating systems (eg Linux, MacOS, Solaris, etc), with the single exception of Windows, supports posix natively out of the box. I have invested heavily in the platform, and have a raft of open source tools that I can use on a posix platform, at the cost of a bit of compilation if the application is not available out of the box.

Fortunately, however, through the efforts of RedHat and other volunteers, an almost complete posix environment called Cygwin is available as a free download. Most of the applications I have grown to love and use are simply available via a simple point and click installer. Full kudos to the Cygwin team for taming Windows and making it a usable and productive platform.  Nevertheless, even with Cygwin, there are very many nasty sharp corners with Windows, and I want to document these peeves: Why Windows is not ready for the desktop.

1. Cygwin is a second class citizen. By this, I mean a couple of things. The filesystem as seen by Cygwin is rooted somewhere like c:/cygwin. The actual drive letters are mounted in the form of /cygdrive/c, etc. Regular Windows software doesn’t understand cygwin paths, and cygwin programs often have trouble with regular windows paths. Trying to interface the output of, say, Microsoft’s Visual C compiler with something that the compilation buffer of emacs understands, is fraught. Similarly, to generate paths that Visual C understands from within Cygwin’s make utility is convoluted and messy. Another aspect of this problem is that you can’t expect bash to be available on all systems, meaning you have to descend into the pit of hell that is cmd.exe programming. More on this later.
2. Opening a file locks it for deletion. This “feature” of Windows has caused uncountable aggrevation for users (not just developers). Ever wondered why you had to reboot your computer after installing software? Its because the install has replaced some dynamic libraries (aka dlls), but existing running software is in memory using the old version of the dll. Similarly as a developer, creating programs, you find your builds fail because either there is a spurious compilation running in the backgounrd (see Peeve No. 3), or because the program your building is still running (eg within a debugger). It doesn’t actually need to be that way. On Posix systems, deleting a file (or overwriting it) simply removes it from the directory. If there are no other references to that file (eg links), the file still exists, but is effectively unnamed until all processes using that file close their file handles. Works a treat. Pity Microsoft chose the less useful semantics when they implemented NTFS.
3. Signals not propagated. This means that ^C and ^S do not work with native Windows programs, only Cygwin programs, because Cygwin has made an effort to support signals. It also means, for example, that when emacs kills a subordinate compilation process, only the toplevel cmdproxy process. This usually means a hunt and kill on the now orphaned compilation processes. A useful tool is Process Explorer, which has sufficient smarts in to allow you to kill a whole tree of processes. However, it is manual – it would be so nice if the operating system supported this out of the box.
4. X-windows copy/cut/paste. If you have ever used the 3 mouse buttons to select, copy, cut and paste in X-windows, you will realise just what a timesave it is, let alone saving on RSI from not having to repeatedly type ^C,^X,^V in intensive edit session. The problem is that Windows does not understand the middle mouse button at all, and the right mouse button is reserved for context menus. X-windows programs running under Cygwin do understand these, as does emacs, but that’s about it. To alleviate this lack of functionality, TXMouse works passably well. The right mouse functionality is not supported, byt you do get swipe to copy, and paste on the middle button. Well mostly – some Windows programs refuse to cooperate (here’s looking at you, Visual Studio). It also does a quite passable job of fixing Peeve No. 6.
5. No virtual desktop. One of the things I love about my Linux netbook is its light weight. The downside of such a small machine is its small screen – 1024×600. Does that mean I’m limited in what I can do? No. I run a virtual desktop,  which is 4000×3000 pixels. The window manager allows me to drag the physical screen around the virtual one – navigation is quite easy, and allows me to have literally hundreds of windows open, spread over multiple projects I might be working on. Even applications requiring larger window sizes (Visual Studio, for instance is unusable on screens less than 800 pixels high), are not difficult to use. I have for instance, requested 1200×1000 remote desktops to manage visual studio development from my netbook. It actually works a treat. Its a toss up as to whether it is better working environment than a dual monitor setup, but it is a hell of lot more portable. The bog standard window managers for Linux (KDE and Gnome) sport workspaces, which gives something like the virtual desktop (not as good IMHO, though), as does MacOSX, but Windows 7 lacks this functionality, out of the box. I tried a workspaces like solution from sysinternals called Desktops, but sadly it didn’t play well with the Cygwin programs I need to use.
6. Click to focus. Click to focus has been the mode of operation since the first Macintosh, and was probably inherited from the original Xerox Parc GUI research. X-windows introduced an alternative mode called “focus follows mouse”. Here, the window under the mouse point has focus. Its a bit confusing going from one system to the other – and I frequently finding myself typing text into the wrong window, since my eye (and mouse) are focussed on one window, but the operating system is focussed on another. So why would I argue that focus follows mouse is superior to click to focus? A very common operation I find myself doing is copying and pasting selected text from one window into another (possibly completely different application). With focus follows mouse, and X-style copy paste this is extremely simple. Just have the source window on top, with a small  part of the destination window showing at one edged. The select text using swipe (or left button-right button when large), then move the mouse to the small part of the destination window, and press middle-mouse. Click to focus destroys this fundamental mode of working, as you need a separate click to bring the destination window to the front, (which may take some time to redraw), followed by the paste followed by another click to bring the original source window to the front. Focus follows mouse is not to everybody’s taste, but it is painful when the computer cannot be configured to use it. Note that TXMouse partially support focus follows mouse, although windows are auto-raised in this case, which defeats the purpose somewhat. Also Visual Studio really behaves badly when TXMouse is running.
7. Modal dialogs prevent windows from being moved. This is a doozy! If an application pops up a modal dialog box, the app’s window remains fixed in place until the modal dialog is dismissed. Even worse is if the application becomes busy, not responding to its event loop. The problem is that in Windows, applications are responsible for moving, raising, lowering and iconising windows – events which are the responsbility of the window manager!
8. No symbolic links. This is an extremely useful feature for organising the file system, and has been added to Windows 7 (yay!). Cygwin will fake symlinks in its own way, because many posix programs will assume the ability to create them. The problem comes from Windows software that knows nothing about symbolic links, making navigation around the filesystem traumatic.
9. Not all programs use ‘/’ consistently. Back in the bad old days of MSDOS, ‘\’ (slosh) was used as the directory separator, even though ‘/’ (slash) had been in use for some years in the unix world. When Windows grew up (gained the NT kernel), the directory separator became the slash, with slosh being recognised as a synonym by most windows software for backwards compatibility. But not all – some software insists on slosh being used (which is hard to input at the bash console), and occasionally software will fail because a path has been entered with a mix of slashes and sloshes.
10. General slowness of NTFS. This is a bit hard to quantify, but on similarly speced hardware, running Windows XP and OpenSUSE Linux, I have noticed a factor of 10 performance difference in writing files. Some of this might be due to Cygwin’s posix emulation layer, and supposedly Windows 7 has a more lively I/O subsystem, but one thing that is painfully obvious is that when the system is performing I/O, such as compiling C++ code, the user interface becomes extremely sluggish (taking 10s of seconds to respond to mouse clicks). This behaviour is not evident on my OpenSUSE Linux system, unless it is actually swapping.

Windows 7

While Windows 7 has improved some things, such as remote desktops for all versions, and symbolic links (see point 8 above), unfortunately its better security model is not well delivered. On Linux, there is a very simple security model – normal users have priveleges to access only their own areas, and a single priveleged user can do anythign on the system. To escalate priveleges, there are the su and sudo commands, which so easily allow one to execute commands with the correct privelege level.

Here are the new peeves with Windows 7.

1. Unfortunately, in Windows 7, there is no equivalent to the sudo command. This means that all shells need to be run as administrator, otherwise you will quickly find that you cannot do something. As a consequence, many other programs will then also need to be run as administrator, as they need to access file that have been created or copied by the shell.
2. “Resource temporarily unavailable”, which afflicts Cygwin processes being forked. The Cygwin team claim this is a problem with the way Microsoft has implemented it process control – I don’t really want to get into the details, but the effect is to degrade the user experience, as often it takes 2-3 goes to get software to start.

Follow these topics: Uncategorized