Holy cow, I wrote a book!
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
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.
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.
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.)
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
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
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
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
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
But it turns out we already had a product that said good-bye to
compatibility with 16-bit device drivers,
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.
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,
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:
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
(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
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
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).