Microsoft Ought To Make A Bootable DOS Thumbdrive Image Available

I need to flash my motherboard BIOS in order to install Vista on my dual-processor desktop (I hope that will do the trick). I don’t have a floppy drive anymore, not on any machine. I can’t believe what a problem this has turned into. I go through my half-a-dozen rescue CDs — all of them are either utility-specific or Linux-based. The flash program from Tyan, though, is DOS-based. I started to follow the instructions to make a bootable thumbdrive, but they rely on a bootsect.bin extracted from a floppy! Back to square one. (P.S. Please don’t send me a bootsect.bin — I’m a trusting soul, but I’m not that trusting.)

I wish Microsoft had a “format thumbdrive to boot DOS” utility.

A Few 365-Day Challenges

Ooh, this is tough; I’ve received a couple one-a-day challenges that are on things that I really do need to do. Jimmy Norton invited me into the Flickr Project 365 challenge, which is to post an image a day for a year. I am always dismayed to realize how little I photograph Hawai’i, which is an incredibly beautiful place undergoing profound changes. Plus, if I did more photography, I’d have an excuse to buy a digital SLR.

Worse, Dan Ciruli called me out for his pushup challenge, which is “do 1 pushup and 1 crunch on day 1, 2 on day 2, 3 on day 3, etc.” I hurt my back for the first time in my life a few months ago and know that the lesson is that I have to strengthen my core (#1 way to help your back: strengthen your gut). Plus, although I’m pretty fit aerobically, I have very little upper-body strength, so pushups are good for me, too.

I wonder if I should counter-challenge: “On day 1, swim a distance of 1′ underwater…”

(Photo is me on the bottom at ~80′)

Peter Coffee Leaves eWeek for Salesforce

Peter Coffee, who’s been providing some of the most insightful, technically-based discussions of the IT and software industries for 18 years, has left eWeekto become Director of Platform Research at This is a significant loss to the field (although I am sure a great benefit to When I was an editor, especially at AI Expert, Peter used to keep me honest with pointed questions about the depth and accuracy of what we were publishing; one of my major regrets of my tenure as an editor is that I never got Peter to write for me.

In the years since, I’ve always looked forward to his columns. Peter always provided a great enterprise-level focus to his discussions, even as he stayed grounded in the realities of the programming experience. I think he’s the most trustworthy development tool reviewer of the past decade, providing an invaluable service to countless developers at thousands of companies.

Well, so it goes. I wish the best to Peter and his family on this new direction….

Ruby In Steel (Ruby Development Environment in VS 2005) Goes 1.0

Ruby programmers using Windows should definitely give this a look; this is very high on my “IDEs to look out for” list. It should be noted that this is not a CLR / .NET-based Ruby; it’s a plug-in to Visual Studio (Standard Edition and above; unfortunately, VS Express users are out of luck) that targets the standard Ruby interpreter.

Although Scite has it’s charms (like loading in a fraction of a second), VS is definitely a superior environment for extended development.

SideShow A Breakthrough API?

Scott Hanselman goes ga-ga for the SideShow API, the Vista functions for auxiliary displays. When I was first told about SideShow quite a while ago, the emphasis was on displays embedded in the outer shell of the notebook, just as clamshell phones often have a little aux display on their surface. I wrote an article back in 2004 in which I was more excited about “REM mode” applications (applications which can be run by a computer that’s somewhere between hibernating and fully awake) than by the aux display itself.

Happily, the SideShow APIs seem to be fully decoupled from the physical attachment of the display, so Scott’s excitement is primarily about using the SideShow APIs from one’s main desktop machine to drive alternate displays.

Bad Comparison: 14 Line Python RegEx evaluator vs. Microsoft’s 14K lines

Wesner Moise points to “generalized regular expression matching” as a moderately hard problem that might serve as the basis for comparing programming languages and approaches. He says “Microsoft’s implementation of regular expression matching over strings is spread across 24 files and 14,455 lines of code including comments and whitespace.” (I’m not sure how he’d know that — I assume he’s talking about Rotor source code.)

He wonders if a functional approach could be more efficient and points to a 14-line Python program.

No, no, no: they are two incredibly different capabilities.

The Python program implements something like the original definition of a regular expression –restricted to that which can be expressed in a single line of Extended Backus-Naur Form without recursion. “Regular expression support” for today’s languages means something very, very different, starting with compatibility with Perl5 and going from there. Backslashes, named groups, etc. are complex features that require, in any language, something in excess of 14 lines.

Having said that, regular expressions are a good fit for functional approaches. But, just to point out the lack of silver bullets, attempting to parse a left-recursive grammar (a grammar with a production of the form A->AB) will hang a simplistic recursive-descent parser.  

The Personal Threading Maturity Model

Alan Zeichick’s proposal of an organizational Threading Maturity Model is an excellent contribution. As with object-orientation, it does not suffice for a single person to have mastery or near-mastery; the average ability of the team must be fair in order to maintain quality, chaos can be wrought by just one or two who are unaware, and reaching the higher levels requires cultivating talent for long enough for mastery to become part of the culture. However, the TMM isn’t very descriptive of individual progress and does not provide guidance. I thought that I’d take a crack at a Personal Thread Maturity Model (PTMM) that might be a complementary effort. Opinions more than welcome.

  1. Unaware: Single-threaded, may occasionally use threaded libraries unawares

The first level of concurrent programming is no conscious use of concurrence at all. Since no mainstream language makes threads a first-class concern, threads are only used as, essentially side-effects, in library and infrastructure calls. No useful recommendations can be made for programmers in this category, as by definition they are not part of the conversation.

  1. Casual: Conscious use of high-level abstractions (components, libraries) to solve specific problems

Today, the large majority of programmers are in this category. They are aware of threads and their ability to run a lengthy calculation or IO operation while maintaining a responsive UI. They may use a drag-and-drop component or a Thread object that allows a calculation to run to completion. Their experience with threading is generally positive: the UI remains responsive, the network calls back, etc. They may be taken aback by all the dire warnings about multithreading that are so common to discussions.

Recommendations: Continue! “The simplest multithreading that can possibly work” often does! Become comfortable with callbacks and asynchronous patterns (in .NET, the Event-based Asynchronous Pattern). Avoid guaranteed trouble spots: don’t update the UI from a worker thread, don’t rely on shared data maintaining its state, don’t try to roll your own synchronization techniques.

  1. Rigid: Significant use of multiple cores, coordination based on locking

In this stage, programmers move from using threading as a pain-relief mechanism to a benefit that can be actively exploited. Asynchronous processing becomes an intentional part of design. They face their first wicked problems and gnarly bugs and become initiates in the “threading is hard” camp. Their designs focus on the use of locking to coordinate their programs; while they may occasionally use other techniques, locking is the hammer with which they pound the nail of concurrency.

Recommendations: The problem for this group is complacency. They’ve triumphed over problems and may have reached a plateau. They discover that core logic is often non-parallel and, although willing, may have a difficult time seeing places where asynchrony can contribute. At this level of mastery it may not be clear on today’s hardware that further learning is necessary. Unfortunately, since manycore machines are not yet available and few of us have access to parallel clusters, moving beyond this level of maturity is driven more by faith and reading than by hands-on experience.

  1. Flexible: Attempt to maximize use of cores, use of lock-free algorithms and data structures

This level is characterized by a deeper theoretical understanding of asynchronous processing, mastery of basic techniques, and determination to achieve the best results possible. Programmers at this level seek, not just to exploit their processors, but to saturate them. This stage is additionally characterized by a shift from programming-language-based thinking to hardware-based thinking.

Recommendations: This is a very difficult phase to move through. Popular texts will not guide you past this stage, advancement requires a combination of textbook theory, hardware knowledge, and hands-on experience. (I’m not going to claim to have moved beyond this phase myself.)

  1. Optimizing: Optimal use of parallel architecture

Parallelism is fully incorporated into one’s mental approach to solving problems via symbols. Specific techniques are considered not along any “better-worse” axis, but for their individual benefits and drawbacks. Multiple approaches may be incorporated into a single design. The world appears as falling strings of glowing numbers, bullets can be dodged, and Agent Smith can be defeated.