January, 2009

  • The Old New Thing

    Kids love cake, but that doesn't make them good judges of cake

    • 19 Comments

    My friend who got married last year went to the Seattle Wedding Show (here are some pictures from the 2007 show courtesy of a vendor's blog) and, through a series of circumstances not relevant to the story, combined the visit with a brief stint of babysitting for her nieces, one a tomboy and the other a girly-girl. The children's father came to pick them up after a half hour, but that half hour at the wedding show was quite exciting for two little girls. It was hardly surprising that the "I want to be a princess when I grow up" girly-girl would be completely enthralled by the wedding show. What was unexpected was that the "kissing is yucky, let's go climb a tree" tomboy was also won over despite the high concentration of lacy dresses and frilly things.

    The magic ingredient is cake.

    Now you'd think kids would be experts at cake, and in fact the girls were quite enthusiastic cake-eaters. At the wedding show, there were about ten bakeries all showing off their creations, and naturally there were samples of the cakes available for tasting. Even the most hardened "I'm not cute" child, when faced with the opportunity, will stand sweetly with an adorable smile if it means that an adult will offer her a sample of cake.

    By my friend's reckoning, the girls sampled five different cakes in the span of ten minutes. Despite this broad basis for evaluation, when asked for their assessment of the relative merits of the various cakes, the only response was "It's yummy!"

    By the way, the wedding show also alerts you to all the things you never thought a wedding needed but which, it seems, have become an indispensable element without which your wedding will be a total disaster. Here's a sample from last year's show.

    • Chair covers. Not just seat covers, but chair covers. The great thing about chair covers is that they take a perfectly normal chair and turn it into something uncomfortable and unwieldy because you can't put your feet or your purse or anything else under the chair.
    • Fish in fishbowls as table centerpieces.
    • Flower preservation services.
    • Ice sculptures.
    • A stand-up comic.
    • A photo booth.
    • Sending CDs with the wedding invitations so you can include all the information on the CD instead of forcing your guest to OCR it into their calendar. (That's my only guess.)
    • Videography. (I have yet to meet anyone who watched a video of their wedding more than once. For many couples the count was zero.)

    To see what sort of exciting must-have features are on the agenda for this year, go to the Seattle Wedding show site, and click on Wedding Specialists. Or just buy a ticket to this year's show and find out in person. Though given the recent economic downturn, this year's show is much more budget-conscious.

  • The Old New Thing

    Why doesn't Windows 95 format floppy disks smoothly?

    • 49 Comments

    Welcome, Slashdot readers. Remember, this Web site is for entertainment purposes only.

    Who spends all day formatting floppy disks? From the reaction of geekdom, it appears that there are lots of geeks who sit around formatting disks all day. (Psst, you can buy them pre-formatted.) But why did Windows 95 get all sluggish when you formatted a floppy disk?

    It's that pesky MS-DOS compatibility again.

    As we saw a while ago, MS-DOS acted as the 16-bit legacy device driver layer for Windows 95. Even though the operation was handled by the 32-bit file system, all I/O calls were routed through 16-bit code (if only briefly) so that 16-bit drivers, TSR, and the like would see what appeared to be "normal 16-bit behavior" and continue operating in the manner to which they had become accustomed.

    In the old 16-bit days, disk formatting was done via software interrupt 13h, and many programs took advantage of this by hooking the interrupt so they would know whenever a floppy disk was being formatted. Some TSRs did this, as did backup programs (including backup programs designed for Windows 3.0 which included 32-bit Windows 3.x drivers—VxDs they were called—to monitor the floppy drive). But that doesn't explain everything. After all, Windows 95 sent all disk I/O through the 16-bit vectors, not just floppy disk formatting. Why does floppy disk formatting take such a toll on the system?

    As I noted in the linked article, the 32-bit file system did a lot of fakery to make 16-bit code believe that MS-DOS was in charge, even though it wasn't. Anybody who's done TSR programming (wow, the phrase anybody who's done TSR programming used to cover a lot of people but nowadays describes a few dozen geezers, most of whom are trying very hard to forget those days) knows all about the INDOS flag. This was a flag that MS-DOS set when an MS-DOS I/O call was active. Since MS-DOS was not re-entrant, TSRs had to pay close attention to that flag to know whether it was safe to issue MS-DOS calls or not. This INDOS flag was the 16-bit manifestation of what the 32-bit kernel called simply The Critical Section, with the definite article, because the 32-bit kernel kept the two critical sections (the 32-bit one and the 16-bit one) in sync so that MS-DOS drivers and TSRs wouldn't themselves get re-entered. If one virtual machine claimed the critical section, another virtual machine that tried to claim it would wait until the first one released it. In that manner, the driver or TSR would not get re-entered.

    As I already noted, back in the 16-bit days, the actual work of formatting was done by the ROM BIOS, and for compatibility reasons, floppy disk formatting was still sent through software interrupt 13h on the 16-bit side so any TSRs or drivers could see what was going on. There are a lot of crazy ROM BIOSes out there, and when a floppy disk format request was issued, the 32-bit kernel would do a bunch of extra work to ensure that the ROM BIOS got the execution environment it wanted. For example, the hardware timer ports were temporarily unvirtualized so as not to mess up the sensitive timing loops that ROM BIOSes used for floppy disk formatting.

    Okay, let's add up the damage. When a floppy disk is formatting, the timer is unvirtualized so that the ROM BIOS timing loops will run accurately. Only the virtual machine that is formatting the floppy drive receives timer ticks; the others have to wait. No timer ticks means the scheduler doesn't get told when it's time to let another thread run. What's more, the critical section is held across this operation, which means that no other thread can issue I/O operations either. And on top of that, the floppy disk is a slow medium, so any operations that wait on the floppy disk will have to sit and wait for several seconds.

    Well, at least floppy disks are formatted a track at a time, so the system doesn't get locked out for the entire duration of the format operation. The ROM BIOS would be told to format a track, and when it was done, the timers would be returned to normal (allowing the scheduler to do a little bit of scheduling), the critical section would be released (so that any pent-up I/O gets a chance to run), but then the FORMAT.COM program would turn around and format the next track, and the system would go back into hang on, let's not disturb the ROM BIOS while it does its thing mode for another track.

    Now, as with the 32-bit file system, there was a 32-bit floppy driver that tried to catch the format operations on the back end, and if successful, it would take over the job of formatting one track from the ROM BIOS. It was a valiant effort, but it doesn't matter how high-performance your driver is; the speed of formatting a track is pretty much constrained by the mechanics of the floppy disk drive itself. (The person responsible for Windows 95's 32-bit floppy driver was no slouch. I'll try to remember to tell some more stories later.)

    Sure, if Windows 95 didn't have to be compatible with 16-bit device drivers, TSRs, and squirly ROM BIOSes, it could have gone straight to the 32-bit floppy driver to do the formatting without having to do all this timer and critical section nonsense. But it turns out we already had a product that said good-bye to compatibility with 16-bit device drivers, TSRs, 16-bit Windows programs that talked to custom 32-bit Windows 3.x drivers, and squirly ROM BIOSes. It was called Windows NT.

    If you want Windows NT you know where to find it.

  • The Old New Thing

    Follow-up: A new DUI record set in the state of Washington

    • 9 Comments

    A year ago, I noted that a new DUI record had been set for the state of Washington. It took a while, but the story finally settled out.

    Recapping the story so far (links in the original article): The driver's attorneys eventually succeeded in having her released from jail (where she had been held on $300,000 bail) to a treatment center.

    In April 2008, the driver pled guilty to driving while intoxicated and in June 2008 was sentenced to one year in prison for that offense, plus additional days for other offenses, totalling 440 days in jail; plus 90 days of electronic home monitoring, fines, attendance at alcohol-education classes, and other unspecified penalties. That last article also runs down the four separate traffic incidents the driver has been involved in: Driving on the shoulder past a line of stopped cars and becoming involved in a three-car collision, the incident which raised so much public attention. A hit-and-run accident. And two more incidents of driving while intoxicated.

    Unfortunately, permanent suspension of driving privileges was not listed among the penalties.

    Other high blood alcohol levels:

  • The Old New Thing

    How do I write a program that can be run either as a console or a GUI application?

    • 29 Comments

    You can't, but you can try to fake it.

    Each PE application contains a field in its header that specifies which subsystem it was designed to run under. You can say IMAGE_SUBSYSTEM_WINDOWS_GUI to mark yourself as a Windows GUI application, or you can say IMAGE_SUBSYSTEM_WINDOWS_CUI to say that you are a console application. If you are GUI application, then the program will run without a console.

    The subsystem determines how the kernel prepares the execution environment for the program. If the program is marked as running in the console subsystem, then the kernel will connect the program's console to the console of its parent, creating a new console if the parent doesn't have a console. (This is an incomplete description, but the details aren't relevant to the discussion.) On the other hand, if the program is marked as running as a GUI application, then the kernel will run the program without any console at all.

    There are some people who want to write what I call an "opportunistic" console program. These are programs that will use the console of their parent if available, but do not want a console created for them if not. The kernel doesn't support this type of program, but that hasn't stopped some people from coming up with clever workarounds. Note that if such a program type were introduced, it would create problems with programs such as cmd.exe and Explorer which change their behavior depending on what subsystem a program belongs to. These programs would have to be modified to understand a new pseudo-subsystem called "both".

    I've also seen requests for what I call a "dynamic" console program. These are programs that want to decide at run time whether they want a console or not. For example, a program might want to run with a console only if a special command line switch is passed. To do this the kernel would have to have psychic powers: It would somehow have to know whether to hook up a console to your program or not (which happens before the program begins executing) based on something that happens in the future (when your program actually runs and parses its command line and decides whether it wants to run as a console or a GUI program). Again, people have come up with workarounds (see earlier link).

Page 4 of 4 (34 items) 1234