Since NeXT Computer Inc. made the OPENSTEP announcement I have wondered
what platforms are the easiest to get OPENSTEP up and running.
Being NEXTSTEP implemented on top of Mach, those platforms that have Mach
are the most likely to have OPENSTEP. IBM has Mach on PowerPC. DEC with
OSF/1 on Alpha probably does, I'm not sure.
Is there anyone out there that has had some experiences with OSF/1 on
workstations with the Alpha chip? Does it have Mach 3.0? What areas
specifically does the Mach 3.0 API and NeXT's Mach differ? I've done a
lot of NeXT Mach programming but none Mach 3.0 programming. All the
examples I have tried from my book "Programming under Mach" compile under
NEXTSTEP for example. Are most of the differences transparent (i.e. BSD
compatibility via a personality module as oppossed to BSD inside the
kernel). I've read or heard (don't remember) that they differ in advanced
features that are used by database implementors to increase performance
(i.e. allowing for custom memory pagers for example as oppossed to Mach's
default memory pager doing the paging).
If DEC has Mach 3.0 already on their OSF/1 operating system then it would
be smart of them to go quickly with an OPENSTEP implementation. Who cares
about NT at this point. Really the only advantage I see is that you don't
pay to run DOS/Windows programs. But if I'm getting OPENSTEP I don't care
paying for SoftPC. It does a great job on the Intel platform, and
eventually ALL the apps will be NEXTSTEP/OPENSTEP apps because they are
nicer to use, highly integrated and very high quality. At least on
NEXTSTEP they are.
IBM doing the same thing with OPENSTEP makes sense to me too. Most of the
Mach 3.0 documents that I have read have come from IBM so I guess they
really like and appreciate Mach. It would make sense for them to also
have OPENSTEP on their Mach. Besides the PowerPC platform is suppossed to
be an open platform and run all kinds of operating systems (or
enviroments, i.e. OPENSTEP). They are already doing NT on the PowerPC so
why not OPENSTEP that has such a great programming object-oriented
environment, better than anything I've seen. And it's hard to think of
something better or more elegant than NEXTSTEP.
If the Mach API that NEXTSTEP was implemented with is still present on the
other Mach versions the it would be easy for vendors that already have
Mach to get OPENSTEP up and running once they license the code from NeXT.
If OPENSTEP includes the protocols such as drag and drop and filter
services it would make the user environment feel just like NEXTSTEP. If
they implement equivalents to Mail or the Workspace Manager one can still
drag and drop a picture from Mail and have it converted to an appropriate
format transparently by the filter service and put it right on a Diagram
document for example. That would be amazing. "Advanced operating systems
reaching the ease of use of the Macintosh and NEXTSTEP!" -- What I've
always dreamed of. This is what really makes OPENSTEP attractive to me as
a programmer and as a user.
_______________________________________________________________________
Ricardo J. Parada
Pencom Software
Austin, Texas
I'm a happy NEXTSTEP/Intel user operating in a roomy 1408 x 1024 15-bit
color screen with 16 icons on the Dock.
NeXTMail Welcome: ric...@pencom.com
_______________________________________________________________________
> Is there anyone out there that has had some experiences with OSF/1
> on workstations with the Alpha chip?
Well, OSF/1 is not bad. But I think one would want to do a native
NEXTSTEP Mach port if possible - get it out the door quickly. And
Dec isn't as tied to OSF/1 as Sun is to Solaris. Although, after
the Solaris port, hopping to other OSes should be a managble (though
still not easy) task.
As for the machine itself, it would be an excellent hardware platform
for NEXTSTEP. It's video interface is very good, and Display
PostScript absolutely flies on it (IMBO).
--
Scott Byer NeXTMail: by...@mv.us.adobe.com
Adobe Systems Incorporated These are *my* opinions, and
1585 Charleston Road, P.O. Box 7900 do not necessarily reflect
Mountain View, CA 94039-7900 the opinions of my employer.
---------------------------------------------------------------------
NT seems to be based on mach 3.0...true?
Denis
--
--------------------------
Denis Lafont.....cs438@cleveland.freenet.edu
Tel: (+33) (1) 43.45.99.67
--------------------------
>
> The DEC's UNIX (OSF/1 AXP) is based on Mach 2.5.
>
Actually, I think, DEC OSF/1 AXP (V2) is based on Mach 3.0.
> NT seems to be based on mach 3.0...true?
--
David Bellamy.
Deparment of Commerce. The University of Queensland. Australia.
Internet: bel...@commerce.uq.edu.au
NT is not based on any Mach code, though Microsoft claims that some of the
microkernelish aspects/ideas of NT are derived from Mach.
- todd
--
Todd C. Miller Sysadmin--University of Colorado mil...@cs.Colorado.EDU
NT is based on a kernel of Microsoft's own design, kinda.
If you look at their propaganda on NT, it looks like they
musta read about Mach pretty carefully, and thought:
"We can do that!" Writing their own version of anything
is a bonus to them, because it allows them to be different
from everyone, make more money selling bug-fix "upgrades"
and they don't have to pay licensing fees.
NeXTSTEP 3.2 is based on a 2.x version of CMU's Mach, with
some changes made at NeXT. In CMU Mach 3.0, the pager,
and possibly a few other remaining functions, were stripped
from the kernel, leaving what is regarded as a microkernel.
Though many people claim there is debate on what exactly
constitutes a MicroKernel, most people seem to agree that
the CMU Mach 3.0 falls within the general definition, and
many even claim that it is the standard-bearer of the
MicroKernel architecture.
I've noticed a few things that lead me to speculate that
NeXT is planning to move to a 3.x release of CMU Mach
(possibly in NeXTSTEP 4.0 ?)
1. In the Driver Kit docs with NeXTSTEP 3.2, mention
that drivers should run at the User level,
(enables easier driver development and testing,
as well as preventing a driver from crashing
a kernel) but that this feature has not yet
been implemented in the Driver Kit.
--Assumption: this will be easier to implement
under Mach 3.0.
2. In this week's InfoWorld, Steve Jobs is quoted in a
small article about IBM's plan for the PowerPC.
(Their plan? Encourage everyone to port their
OS to the PowerPC, so that the chip can dominate
the market, then blast them all off by shipping
a Mach based, object oriented OS.) In this
story, they claim that NeXT has a version of
NeXTSTEP for the PowerPC that was designed to
run on the NeXT RISC Workstation, which was to
be based on dual PowerPC 601 's running in a
Symmetric MultiProcessor architecture.
--Assumption: SMP is easier to implement,
and may offer performance advantages, with
a leaner microkernel.
3. It has been widely reported that NeXT is developing
their own object-oriented file structure, for
possible inclusion in NeXTSTEP 4.0. Although
NeXTSTEP already supports loadable file systems,
there may exist reasons why a 3.x "lean" microkernel
is superior to a 2.x "fat" microkernel for this
project. I've never hacked a kernel, so I don't
know what these might be, specifically.
In general, it would seem that moving to a Mach 3.x
microkernel might provide some advantages for future
growth of the OS, but probably isn't necessary for
survival just now. Any thoughts on this? Has anybody
run across any other stuff in the Developer docs that
might support/undermine this theory?
Gary Longsine
lo...@ncc.centel.com
OSF/DEC ported Mach 3.0 running OSF/1.1 to the DEC Alpha
platform this year. This is running on the Alpha.
Moving to an out of kernel OS personality has a performance
hit of about 30% with no obvious gain in functionality for
a single CPU workstation. I believe OSF will have a version
of OSF1.3 (their Mach 3.0 product) with the Server
recompressed back into the microkernel for workstations.
On MPP machines the microkernel architecture looks attractive.
You may have computer nodes running say a microkernel with
simply a pager server and some disk. The uK is there
for message routing and for VM. Even the scheduler has
been moved out of kernel recently. This is experimental.
DEC's version OSF1 is based on Mach 2.5 but with the VM system
from Ultrix. NeXT's version of Mach also diverges from
vanilla (CMU/OSF) Mach in this and a number of other areas.
With this in mind it is a less trivial task for NeXT to port
to the Alpha using this work. Porting to the Snake was probably
easier as vanilla Mach (2.5 and 3.0) already exists and would
have been available to NeXT - should they have needed this.
[ is it Mach or HP-UX based ?]
From a user's viewpoint the Mach API hasn't changed much from 2.5
to 3.0. Just a general clean and fixup. NeXT would want to
take the latest OSF version though, rather than the one with
the CMU emulation library hack.
>NT is based on a kernel of Microsoft's own design, kinda.
>If you look at their propaganda on NT, it looks like they
>musta read about Mach pretty carefully, and thought:
>"We can do that!"
I'm sure they did, but we all stand on each others shoulders.
NT is quite different from Mach and they have had some good
ideas such as (I believe) thread migration which may be
adopted by the Mach folks.
>NeXTSTEP 3.2 is based on a 2.x version of CMU's Mach, with
>some changes made at NeXT. In CMU Mach 3.0, the pager,
>and possibly a few other remaining functions,
such as the Operating System Personality (Unix etc.)
>were stripped
>from the kernel, leaving what is regarded as a microkernel.
>I've noticed a few things that lead me to speculate that
>NeXT is planning to move to a 3.x release of CMU Mach
>(possibly in NeXTSTEP 4.0 ?)
>
>1. In the Driver Kit docs with NeXTSTEP 3.2, mention
> that drivers should run at the User level,
IBM's OS/2 release 3 has user level drivers... they have
performance problems.
> --Assumption: this will be easier to implement
> under Mach 3.0.
>
I guess it was. However a user level driver crash is still
pretty drastic if it's say the hard disk driver.
> Symmetric MultiProcessor architecture.
> --Assumption: SMP is easier to implement,
> and may offer performance advantages, with
> a leaner microkernel.
I believe it's already in vanilla Mach 2.5 releases, it certainly
was in OSFs. (we had a sequent running OSF1 both on 2.5 and 3.0)
T think NeXT didn't support SMP with their version of Mach.
>In general, it would seem that moving to a Mach 3.x
>microkernel might provide some advantages for future
>growth of the OS, but probably isn't necessary for
>survival just now.
I think one possible advantage is that Mach 3.0 has been ported to
a very wide range of hardware. In OSF's experience moving the OS
server (Unix. DOS, OS/2, VMS etc) is then a much simpler task.
That is you recompile for the new architecture and go... just like
any other user level program. If NeXT were already based on Mach3.0
they would find ports to Sparc, Snake and PowerPC much easier.
The downside is that Mach 3.0 is not a very mature technology and
there is a noticable performance hit. However IBM has staked it's
PC future on Mach 3.0 - they are planning to offer OSF1.3, DOS and
OS/2 all running on top of Mach (at the same time if you like).
David.
This particular point is incorrect. The VM subsystem used in DEC OSF/1 was
a complete rewrite. It does not use Ultrix code. It is also not just the
core VM code, in that the unified buffer cache is tightly bound to the new
VM, and other facilities like the file system are tightly bound to the
unified buffer cache.
- Marc
--
/| -----------------------. ~ . ~
X|=| Marc N. Evans |------------------. ~ .
X| | Software Consultant | Synergytics |-------------------------------.
X| | Ma...@Synergytics.Com | 21 Hinds Lane | Specializing in: |
X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications |
X|=|______________________| 03076-3013 | - X11 internals/applications |
X| (____________________| |
X| (_________________________________|
X|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The last statement is not true. NT entails some of the Mach 3.0 design
concepts, though it is not based on Mach code.
-Jeff
jhen...@microsoft.com not a Microsoft spokesperson.