httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: Microsoft Windows NT Server Migration Lab (fwd)
Date Wed, 21 Oct 1998 17:48:55 GMT
On Wed, 21 Oct 1998, Ben Laurie wrote:

> Brian Behlendorf wrote:
> > 
> > ---------- Forwarded message ----------
> > Date: Tue, 20 Oct 1998 12:27:05 +0200
> > From: Magnus Bodin <>
> > To:
> > Subject: Microsoft Windows NT Server Migration Lab
> > 
> > I hate to curse, but it's good to know the enemy ;-)
> > 
> >
> Scary! That's an amazingly short list of Apache directives, and even so,
> they still have "no" under "Migrates" for most of them. So, we have huge
> document describing how to migrate that can only possibly work for
> totally trivial sites.

That is funny.

"TransferLog     No      IIS doesn ot use a transfer log."

"ServerName      No      The host name for your Web Server is stored in
your DNS server"

(well gee folks, Apache does thta just fine as well.  Guess you haven't
heard of misconfigured DNS servers)

DirectoryIndex  No     IIS does not enable you to specify a pre-written
HTML document as a directory index

Server status reports  No   IIS 4.0 does not provider server status

They even mislead you about what IIS does!


    CGI was created for a UNIX environment where processes are the
    basic unit of operation and have less overhead than processes in
    Windows NT Server. In Windows NT Server, where threads are the
    basic unit of operation, processes have substantial overhead. Each
    process receives a private physical memory allocation, is granted
    space in the paged and non-paged memory pools, and is protected by
    the Windows NT Server Security model. In fact, every attribute that
    makes processes in Windows NT Server robust also makes them costly.
    Because each CGI request generates a new process, CGI applications
    have much higher overhead than ASP or ISAPI applications.

Erm... so they are saying that NT can't deal with processes so they had
to push threads.


Rather, the Windows Security Provider interface is used to provide
an encrypted challenge/response handshake mechanism that is
functionally unbreakable

"functionally unbreakable".

Also interesting:

The effect of this, to IIS applications, is that the IIS service
has its own desktop. If your IIS application interacts with a
desktop in any way (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. Similarly, an IIS application will not
be able to send or post messages to an application on the interactive
desktop. If your IIS application needs to interact with the
interactive desktop, you should use another form of inter-process
communication such as named pipes.

So they are saying that IIS will display dialog boxes that 
no one can see.

View raw message