On Sat, 6 Nov 1999, Gilad Ben-Yossef wrote:

> Apache doesn't care about the API for managing graphics display on the
> screen. IIS on the other hand uses the same API used also for graphics. For
> example, I'm pretty sure IIS maintains some sort of message loop (I am not
> sure how much this statement is correct - any Win* guru's [ Hi Aviram! ;-) ]
> want to correct me? ). The choice of this kind of design for the program is
> inherit by the "choice" to use the Win* API. Apache designers suffered no
> such restraints.

actually, this is the advantage of windows - you can have a message loop
for non-GUI applications, and you don't have to form your own message
loops, thar suffer of many limitations (e.g.; in windows, you have
WaitForMultipleObjects, that has no equivalent in unix, due to the fact
that not all IPC mechanisms or ITC mechanisms have a file descriptor
associated with them. this causes great grief and requires extra work on
behalf of the coder).

> 
> I think this opens up a really interesting line of thought:
> 
> The first skill that a programmer/designer must learn is how to break up a
> problem to different pieces with defined interfaces between them to fight
> complexity. Linux does just that. The Win* API shows a much lesser level of
> this idea, IMHO.

the price for the linux simple API is ofcourse that you have to re-invent
the wheel time and again, even for rather simple staff. more over, you
have not got a proper standard API for acessing many system resources, or
the API is rather fucked up (e.g. enumerate the groups that a user is part
of). and there is no standard API to update or set such parameters.

> The prime reason for this is NOT bad engineering as some people think.
> Instead, the reasons are:
> 
> 1. The need to maintain backwards compatibility with aged technology (and,
> as my good friend Shachar always says, backwards compatibility is
> compatibility done backwards)

this is the reason for the multiple APIs (e.g. OpenFile vs. OpenFileEx).
not necessarily for the complexity of the API (for the complexity of the
system - indeed).

on the other hand, unix systems tend to be quite backwards compatible -
they simply add very little new to the system. that's an easy approach,
actually. it just places us in a rather annoying situation of having to
re-invent many wheels...

> 2. The need to keep complexity as a way to obscurecertain parts of how the
> system works so that MSFT will retain dominance in the market by leveraging
> it's knowledge of those APIs.

here goes the little story about WaitForMultipleObjects. it's a very nice
API call, except for one limit, it can only wait on up to 64 objects.
rumors say that there is an undocumented WaitForMultipleObjectsMS that can
handle more then 64 objects...

> This is not acceptable in the Server environment to which MSFT must adapt to
> in order to survive.

to survive? isn't this wishfull thinking? one of the fastest growing
companies needs to survive? i don't think that evel bill is that paranoid
about his company...

> Moreover, because the result of Moor's law brought
> about such a situation where technologies reserved in the past for the
> Server arena or specific niche markets are now usable on Desktop systems
> (e.g. Unix -> Linux) the users of Desktop system start to expect more of the
> software they use. These (and secondary effects, like NTs inability to run
> on ANYTHING that is not an Intel 32bit platform leading to it being
> perceived as a
> "dead end" platform)

errr. isn't alpha a 64 bit platform? and you really believe that NT won't
run on IA64?

> will lead (again, IMHO) to MSFT either adapting by
> changing its policies (and therefor abandoning that which made it such a
> successful company) or die.

currently, it seems like the only thing that will stop microsoft soon is
the american court system. that is, as soon as year 2002...

guy


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to