Sympathy for the devil.

[Ben Hyde <bh...@pobox.com>]

Ok, I'm going to get myself in trouble here.  Sympathy for the devil
and all that.  Worse yet i could be doing it in response to the 
mindless column fodder they fed to IT "professionals."

Marc Slemko writes:
>
I'm not replying to Marc.  I'm just using his comments
as a launching pad to make point to the group.

>    CGI was created for a UNIX environment where processes ...
>
>Erm... so they are saying that NT can't deal with processes so they had
>to push threads.

They are saying: the unix process model and the W32 process
model are _way_ different.  There just isn't a natural mapping
between them.  Threads are the central player in WIN32.  It's
a completely different mind set.

>Also interesting:
>
>The effect of this ... If your IIS application interacts 
> ... (for instance, if it displays a message box),
>it will display that message box on a desktop that cannot be seen
>on the computer's monitor.
>
>So they are saying that IIS will display dialog boxes that 
>no one can see.

This isn't really that different from saying that an Apache module
author that uses stdin/out/err maybe surprised that his I/O
disappears.

This warning is more important here because the presumption that W32
applications are built by pasting together a collection of third party
widgets each of which has N threads.  These communicate via method
tables built on the fly as things are dynamicly linked in.

It can be very difficult to find widgets that never do screen I/O and
hence this warning.  What it's saying, in the double speak of
marketing, is "you won't be able to use most of the widgets you
know and love because they probably assume a user is standing by
to talk to them."

These points are important for two reasons.  First is it good
to understand what users want to do on W32.  There really are
a lot of good widgets to be had here and you ignore that pool
of resources at your peril - presuming you want to play in
that market.  

Second this model of assembling applications from widgets is just
better than the Unix model of processes and pipes.  The unix
communities tedious attempts to get threads is just the tip of the
iceburg.

We are drifting in this direction anyway.  What are modules but plug
in widgets?  What is our module table but a dumb attempt to get
dynamic linking into method tables?  How often have you wanted to have
a few threads in your module so you could have some cycles at times
other than when the client browser happens to notice you?

 - ben hyde

  "doubt in faith ... washed his hands, sealed his fate."