[rescue] OT: Solaris for Intel

[joshua d boyd]

On Wed, Jul 25, 2001 at 09:44:02PM -0400, s at avoidant.org wrote:
> joshua d boyd wrote:
> > > playing). Although I have to admit, I think it's WinME, not 2K. Not
> > > really sure, though, since I've never actually used it. But you'd think
> > > they'd be similarly crash-resistant, wouldn't they?
> > 
> > Err, they would be as similarly crash-resistant as NT and 95 are.

I'm sorry, I was totally unclear here.  I meant to say that the difference
between 2k and ME is like the difference between NT and 95.  That is, ME
is just a new 95, and 2k is a new NT.
 
> Tha difference being...? (I'm serious. I haven't touched a windows box
> since about when 3.11 was new.)

Well, they don't totally tell us what the differences are, and I'm not
expert enough to be able to understand them.

I know that the way Dos and Windows 3.x compatibility is handled is just
about totally different.  Windows 95 traps bios calls, I think, but I know
that direct hardware calls are allowed to pass through.  Win NT on the
other hand traps and emulates somethings, and denies all direct hardware
calls (except for device drivers, of course).

I also know that shared memory is handled differently.  This apparently is
the major cause of instability on 95.  On 95, all shared memory is stashed
between 2 and 3 gigs (remeber that the real memory you have can be
partitioned up and placed all over the 4 gig address space).  So, any
program that uses shared memory (think DLLs), can bring down any other
program that uses shared memory.  And believe me, almost everything uses
shared memory.  

NT, on the other hand, implements shared memory completely differently,
but at the moment I don't remeber how.  On NT, most stability problems
come from bad drivers, and destablizing important shared services. Like,
if explorer goes badly enough, you might not be able to fix it with out
logging out and back in.  If what gets destablized is something that
doesn't get restarted with a clean login, then maybe you can stop and
start services to fix it, but a reboot also might end up being what is
needed.  Destablizing MTS (Microsoft Transaction Server, something that is
alternately nifty and terrifying) seems to be something that can't just be
restarted, for instance.

Alright.  I going to descend into a bit of heresy here.  MTS (well DCOM,
but it seems pointless to try and seperate them these days) is really
kinda cool.  The following description is rather simplified, so be
kind.  You write your COM control (say in VB), and load it on the
server.  Now, all the workstations can call that COM control as if it were
running locally instead of on the server (not really that simple, but in
VB and python it appears as if it were).  So for instance, if I were a
bank, I could right a COM control that increments or decrements the
balance.  Then as I grew and needed more than one computer, I could move
that COM control to the server, and the teller software would just be able
to use it without being rewritten (keep in mind I'm simplifying).  Then, I
could write a web accont management software, and the ASP code could also
call this COM control without being written.  

And that last is where MTS is largely meant to be used.  It is meant for 3
tier applications.  The top tier is the presentation layer, and this could
be a web server or it could be a VB client app.

The next layer is the business logic.  This is meant to be seperated from
the way things are displayed, and the way things are stored.  This layer
is usually written around MTS for MS hounds.

Then the third layer is the database server, something like MS SQL.

Now, in the more civilised world, CORBA was meant to do this sort of
stuff.  CORBA came before COM, and it new about the network from the start
(unlike COM).  However, the support was never really quite there.  Writing
python and perl programs to make CORBA calls is a lot harder than writing
VB or python programs to make DCOM and MTS calls.

And this is where SOAP and XML-RPC come in.  The are finally doing the
types of things that CORBA should have been used for all along.  However,
XML-RPC and SOAP still aren't usually as easy as DCOM, but I believe that
there is no reason that someone couldn't write perl or python modules to
make it just as easy.

BTW, when I say DCOM is easier than CORBA, I'm talking about from the high
level language view.  From the C++ view (especially if not using MFC), COM
and DCOM are far harder to use.

-- 
Joshua D. Boyd