Re: Why is an OS kernel usually written in C?

[Pavel Lebedinsky [MSFT]]

OS interfaces have to be C because many clients use C.

Implementation can be in C++ but the "safe" subset of C++
is pretty small, and it's very easy to introduce subtle problems
if you're not careful:

http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

"tommazzo" wrote:

> I wonder why OS kernels are usually written in C only. After all Windows,
> Linux and OpenBSD are pure C and assembly in the kernel. Why isn't there
> any
> C++ anywhere?
> I know that a part of the answer is the big existing code base, but apart
> from that what else is it that keeps C++ from coming into kernel
> development.
> I know that some basic functions have to be implemented first, so that you
> can use classes, but once they are there C++ could be used in the code.

[Joe]

One part of the Windows kernel that uses C++ exclusively is Kernel
Streaming.

"tommazzo" <tomm...@discussions.microsoft.com> wrote in message
news:064F530C-A6CB-402C...@microsoft.com...
> Hi!

>
> I wonder why OS kernels are usually written in C only. After all Windows,
> Linux and OpenBSD are pure C and assembly in the kernel. Why isn't there
any
> C++ anywhere?
> I know that a part of the answer is the big existing code base, but apart
> from that what else is it that keeps C++ from coming into kernel
development.
> I know that some basic functions have to be implemented first, so that you
> can use classes, but once they are there C++ could be used in the code.
>

> Thanks in advance!
>
> --
> Check out my development website http://www.tommazzo.com

[Tim Roberts]

"tommazzo" <tomm...@discussions.microsoft.com> wrote:
>
>I wonder why OS kernels are usually written in C only. After all Windows,
>Linux and OpenBSD are pure C and assembly in the kernel. Why isn't there any
>C++ anywhere?

Part of the reason is predictability. With C, one can be relatively
certain of what assembler will be produced from a given piece of C code.
With C++, especially at the time the basic Linux and Windows NT kernels
were written (1990), C++ was somewhat unpredictable. Unless one is very
careful, simple C++ constructs can generate a lot of code.

That's highly undesirable in an operating system kernel.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Doron Holan [MS]]

that would be a set of device drivers,not the kernel itself.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.

This posting is provided "AS IS" with no warranties, and confers no rights.

"Joe" <j...@nospam.org> wrote in message
news:ujaGpuEK...@TK2MSFTNGP14.phx.gbl...

[Robert Marquardt]

tommazzo wrote:

> Hi!
>
> I wonder why OS kernels are usually written in C only. After all Windows,
> Linux and OpenBSD are pure C and assembly in the kernel. Why isn't there any
> C++ anywhere?
> I know that a part of the answer is the big existing code base, but apart
> from that what else is it that keeps C++ from coming into kernel development.
> I know that some basic functions have to be implemented first, so that you
> can use classes, but once they are there C++ could be used in the code.

The C++ class API is hard or impossible to access from other programming
languages. So you would make your new OS a C++ only OS.

[Philip Doragh]

"Robert Marquardt" <marq...@codemercs.com> wrote in message
news:uZCRm5IK...@TK2MSFTNGP10.phx.gbl...

As a former employee of IBM and programmer in the group that developed OS/2,
the answer is quickness of exection and minmal use of memory. Because
kernel routines are used by all other code to accomplish the tasks that are
most useful to the user, kernel routines need to support those modules with
an absolute minimum of overhead or you are going to have one slow system.

Phil Doragh

[Carl Daniel [VC++ MVP]]

tommazzo wrote:
> A big thank you to all of you guys. You've all contributed to making
> this clear for me.

Another historical reason that no one mentioned: New kernels were usually
developed for new hardware. C was a logical choice as the lingua franca of
new hardware because it's relatively easy to port a C compiler back-end to
new hardware (comparable to if not easier than writing an assembler for new
hardware). At the same time, C gives you 95% of the power of writing in
assembly but with high level language contructs. In many ways, C is just a
natural choice.

-cd

[Eugene Gershnik]

Pavel Lebedinsky [MSFT] wrote:
> OS interfaces have to be C because many clients use C.
>
> Implementation can be in C++ but the "safe" subset of C++
> is pretty small, and it's very easy to introduce subtle problems
> if you're not careful:
>
> http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

An interesting article. What I got out from it is that neither C nor C++ in
their *standard* form are usable in the kernel. The difference is that MS C
compiler has an additional support for kernel mode while the C++ compiler
doesn't.
The main problem seems to be non-determinism of many things in *standard*
C++ (for example where the generated code is being put). Assuming you could
control them via #pragmas or some other mechanism all problems mentioned in
the article would disappear.
My conclusion is that C++ isn't used in Windows (or other OSes) kernels
because compiler vendors don't want to support it.

--
Eugene
http://www.gershnik.com

[David J. Craig]

I believe that in some cases the initial ports of a 'C' compiler to a new
processor was done by having the 'C' compiler output assembly code that the
processor manufacture's supplied assembler could handle. It may have been a
quick and dirty to enable bootstrapping all the pieces onto new hardware.

"Carl Daniel [VC++ MVP]" <cpdaniel_remove...@mvps.org.nospam>
wrote in message news:uOAi3LNK...@TK2MSFTNGP10.phx.gbl...

[m]

This is the same argument as before. Please don't start ranting again.

Everyone agrees that it is possible to use either - but much easier to make
a mistake with C++.

"Eugene Gershnik" <gers...@hotmail.com> wrote in message
news:uaXGUGOK...@TK2MSFTNGP14.phx.gbl...

[Eugene Gershnik]

m wrote:
> This is the same argument as before.

Huh? I don't recall anybody including myself making this argument before.

> Please don't start ranting
> again.

Please stop trolling.

> Everyone agrees that it is possible to use either - but much easier
> to make a mistake with C++.

I actually think it is impossible to use C++ but since you are intent (for
no apparent reason) to misunderstand what I have written then so be it.

--
Eugene
http://www.gershnik.com

[Le Chaud Lapin]

Tim Roberts wrote:
> Part of the reason is predictability. With C, one can be relatively
> certain of what assembler will be produced from a given piece of C code.
> With C++, especially at the time the basic Linux and Windows NT kernels
> were written (1990), C++ was somewhat unpredictable. Unless one is very
> careful, simple C++ constructs can generate a lot of code.

I'm going to play devil's advocate here and argue for C++ in kernel. ;)

It's references. I'm not willing to give them up.

I like being able to write this:

void milk_cow (Cow &cow)
{
cow. // 'cow' really is a Cow
}

Some may think it trivial, but being able to name the parameter "cow"
and let it refer to something that really is a cow (instead of a
pointer to a cow), is golden, at least for me. I cannot express in
words how much I prefer this over:

void milk_cow (Cow *cow)
{
cow->...// Yuckkkkkkkk! 'cow' is *NOT* a Cow!!!!!!
} ;

-Le Chaud Lapin-

[Doron Holan [MS]]

for any project that i use C++, the only references allowed are const
references. all other use of references are banned. here is why. there is
no way to tell based on the caller what is being passed in and what the side
affects are.

for instance:
Cow c; milk_cow(c);

does this function make a copy of c? is it a reference? is it a const ref?
does it change c? milk_cow(&c) is very clear. you know that a pointer is
being passed and that it can change.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Le Chaud Lapin" <unorigina...@yahoo.com> wrote in message
news:1139021465....@g43g2000cwa.googlegroups.com...

[Le Chaud Lapin]

Doron Holan [MS] wrote:
> for any project that i use C++, the only references allowed are const
> references. all other use of references are banned. here is why. there is
> no way to tell based on the caller what is being passed in and what the side
> affects are.
>
> for instance:
> Cow c; milk_cow(c);
>
> does this function make a copy of c? is it a reference? is it a const ref?
> does it change c? milk_cow(&c) is very clear. you know that a pointer is
> being passed and that it can change.

Well, not to say that I write perfect code, but it is generally quite
evident from the structure of my programs whether const &-reference or
simply &-reference should be used in any particular situation.

Besides, if there is ever doubt, at least in the world of Visual
Studio, I just move mouse pointer over milk_cow and see its prototype.
But there is hardly ever doubt

For me, it is far more import that there is an appropriate binding
between names and what they refer to, and that means references if I
don't want to keep having to preprend my paramter names with
"pointer_to_....:

milk_cow (Cow *pointer_to_cow)
{
}

-Le Chaud Lapin-

[Eugene Gershnik]

Doron Holan [MS] wrote:
> for any project that i use C++, the only references allowed are const
> references. all other use of references are banned. here is why.
> there is no way to tell based on the caller what is being passed in
> and what the side affects are.
>
> for instance:
> Cow c; milk_cow(c);
>
> does this function make a copy of c?

Pointers don't really help here

void milk_cow(const Cow * pCow)
{
Cow cow(*pCow);
}

Only function docs will tell you whether a copy is made.
In general why do you want to know if milk_cow makes a copy? If it makes a
performance difference (i.e. Cow is expensive to copy) then

class Cow
{
private:
Cow(const Cow &);
Cow & operator=(const Cow &);
};

will solve the problem.

> is it a reference? is it a
> const ref? does it change c?

const Cow c; milk_cow(c);

now I know that c doesn't change. (Assuming people don't cast const away to
deliberately fool you)

> milk_cow(&c) is very clear. you know
> that a pointer is being passed and that it can change.

It relies on the coding standard and people following it. If they don't or
err often then it doesn't guarantee anything. Making object const and/or
non-copyable uses compiler which doesn't suffer from these disadvantages.

--
Eugene
http://www.gershnik.com

[Kim Gräsman]

Hi Eugene,

>> for instance:
>> Cow c; milk_cow(c);
>> does this function make a copy of c?
>>
> Pointers don't really help here
>
> void milk_cow(const Cow * pCow)
> {
> Cow cow(*pCow);
> }
> Only function docs will tell you whether a copy is made.
> In general why do you want to know if milk_cow makes a copy?

I think Doron meant there's no way to know whether the signature is:

milk_cow(Cow c); // by value
milk_cow(Cow& c); // modifiable ref
milk_cow(const Cow& c); // const ref

And I agree, from the call site's perspective, milk_cow(&c) says "by-ref"
better than milk_cow(c). I guess that's why C# added the ref and out keywords
that need to be added both to formal and actual parameters.

--
Best Regards,
Kim Gräsman

[Doron Holan [MS]]

signature is one thing, but readability at the call site (independent of
editor, such as looking at the src in windbg) is important as well. so is
maintainability over *years* of time and with possibly many developers (some
who own the code, others who are debugging it) looking at it over that time.
Furthermore, at least for my work, you need to be able to go back and
understand the code after not touching it for 6 months (or longer) and the
simpler it is, the easier it is to understand at a glance.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Kim Gräsman" <k...@mvps.org> wrote in message
news:453b99c682a498...@news.microsoft.com...

[Tim Roberts]

"Eugene Gershnik" <gers...@hotmail.com> wrote:
>m wrote:
>> This is the same argument as before.
>
>Huh? I don't recall anybody including myself making this argument before.

I _think_ "m" was referring to the "should one do C++ in the Windows
kernel" argument. It has, in fact, flared up with tiring regularity over
the past few years, with very strong opinions on both sides of the
argument. Almost all of the drivers I write are in C++, and that will
continue to be the case.

[Tim Roberts]

"Philip Doragh" <som...@sbcglobal.net> wrote:
>
>As a former employee of IBM and programmer in the group that developed OS/2,
>the answer is quickness of exection and minmal use of memory. Because
>kernel routines are used by all other code to accomplish the tasks that are
>most useful to the user, kernel routines need to support those modules with
>an absolute minimum of overhead or you are going to have one slow system.

Ah, but the world is a very different place from what it was in 1986. It
is only a small exaggeration to say that CPUs are now infinitely fast and
memory is free. On a 10MHz 386, for example, you would never have
considered the kind of thorough parameter validation that is common in
Windows today.

It is certainly possible to write predictable and performant code in C++,
but one has to be careful.

[Carl Daniel [VC++ MVP]]

Tim Roberts wrote:
> It is certainly possible to write predictable and performant code in
> C++, but one has to be careful.

... as is the case in C, or any other language. In C++ there's just more to
be careful about at the language level.

-cd

[Eugene Gershnik]

Tim Roberts wrote:
> "Eugene Gershnik" <gers...@hotmail.com> wrote:
>> m wrote:
>>> This is the same argument as before.
>>
>> Huh? I don't recall anybody including myself making this argument
>> before.
>
> I _think_ "m" was referring to the "should one do C++ in the Windows
> kernel" argument.

Could be. But this has nothing to do with the point I was making. Note that
I said nothing about "should".

> Almost all of the drivers I write are in C++, and that
> will continue to be the case.

I don't have a strong opinion on the matter. In any case it all depends on
what is meant by C++.

--
Eugene
http://www.gershnik.com

[Eugene Gershnik]

Kim Gräsman wrote:
>
> I think Doron meant there's no way to know whether the signature is:
>
> milk_cow(Cow c); // by value
> milk_cow(Cow& c); // modifiable ref
> milk_cow(const Cow& c); // const ref

Sure, I got this. My point is why do you *really* need to know it?
Unless you care about performance the only other reason I know is the code
being a total mess to begin with.

--
Eugene

[Eugene Gershnik]

Doron Holan [MS] wrote:
> signature is one thing, but readability at the call site (independent
> of editor, such as looking at the src in windbg) is important as
> well. so is maintainability over *years* of time and with possibly
> many developers (some who own the code, others who are debugging it)
> looking at it over that time. Furthermore, at least for my work, you
> need to be able to go back and understand the code after not touching
> it for 6 months (or longer) and the simpler it is, the easier it is
> to understand at a glance.

I don't think anybody would disagree with these goals. I just don't get what
call by reference has to do with it.

--
Eugene

[Doron Holan [MS]]

it has to do with call by ref b/c at first sight, esp if you don't own the
code, it is unclear at the caller what is being passed. it is all about
transparency in both the function implementation and the caller of that
function.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Eugene Gershnik" <gers...@hotmail.com> wrote in message

news:%23PMo75n...@TK2MSFTNGP12.phx.gbl...

[Le Chaud Lapin]

Doron Holan [MS] wrote:
> for any project that i use C++, the only references allowed are const
> references. all other use of references are banned. here is why. there is
> no way to tell based on the caller what is being passed in and what the side
> affects are.
>
> for instance:
> Cow c; milk_cow(c);
>
> does this function make a copy of c? is it a reference? is it a const ref?
> does it change c? milk_cow(&c) is very clear. you know that a pointer is
> being passed and that it can change.
>

It can? What if the purpose of taking address is to simply avoid the
overhead of the copy?

void milk_cow (const Cow *);

In this case, contract says that milk_cow is not allow modify the Cow
that is being pointed to.

-Le Chaud Lapin-

[Doron Holan [MS]]

copies can incur an allocation which can fail. copies take up CPU time in
terms of extra calls. the argument for putting the copy constructor and
operator= under a private scope doesn't fly b/c you might want to make those
calls in other instances. in the end, it is up to you and this will devolve
into a personal style guideline that will never resolve itself. i just
stated my opinion based on dealing with this professionally for 9+ years
(and 4 more as an undergrad inheriting someone else's code) over many
different code bases.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Le Chaud Lapin" <unorigina...@yahoo.com> wrote in message

news:1139173793.9...@f14g2000cwb.googlegroups.com...

[Eugene Gershnik]

Doron Holan [MS] wrote:
> it has to do with call by ref b/c at first sight, esp if you don't
> own the code, it is unclear at the caller what is being passed. it
> is all about transparency in both the function implementation and the
> caller of that function.

Well we'll just have to agree to disagree here.
I know when I see a transparent and easy to understand code and it has
nothing to do with references. The code where you start worrying about these
things is usually unmaintainable mess for other reasons.

--
Eugene

[Eugene Gershnik]

Doron Holan [MS] wrote:
> the argument for putting the copy
> constructor and operator= under a private scope doesn't fly b/c you
> might want to make those calls in other instances.

So make two classes

class Cow {...};

class NonCopyableCow {...};

where the second disables the copying semantics. Both can share the same
internal implementation. Speaking of code clarity and maintainability now
the semantics is clearly spelled out. Unlike the pointer "solution" where
the author of

void milk_cow(const Cow * pCow)
{

};

has no clue whether he is allowed to copy it.

--
Eugene

[Le Chaud Lapin]

Doron Holan [MS] wrote:
> copies can incur an allocation which can fail. copies take up CPU time in
> terms of extra calls.

Yep. And copies take up extra space, either on stack, heap, or both.
I certainly agree with principle of avoiding an unecessary copy (hence
the use of references).

However, to restate, if a programmer uses the pointer method and makes
milk_cow as this:

void milk_cow (const Cow *);

Then when the caller goes to call milk_cow by writing this:

Cow c;

milk_cow (&c);

The (&) being applied to c not necessarily an indicator that c is to be
modified. As matter of fact, if the function prototpye is as written,
then contractually, c cannot be modified.

So not to nit-pick too much, but the argument that &c is better because
it indicates that c is to be modified is not true.

-Le Chaud Lapin-

[Don Burn]

No, the indicator is that "c MAY BE MODIFIED". If you know every call of
the OS perfectly then that is not a problem, but as somebody who has done OS
development for over 30 years for any significant OS, you will not know all
the calls! Yes, it only takes seconds to check that for a given call it
does not modify the param, but each of those is an interrupt and a
distraction for the developer trying to track down a problem.

I've written OS'es in several languages, I was even part of a team that
looked at C++ for a next generation Unix. In every case, the experience OS
developers wanted as much indication in the code as possible of what the
heck was happening.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Le Chaud Lapin" <unorigina...@yahoo.com> wrote in message

news:1139248467.9...@g44g2000cwa.googlegroups.com...

[Gary G. Little]

Tim,

Are you using a third party classe library; e.g. DriverWorks?

--
The personal opinion of
Gary G. Little

"Tim Roberts" <ti...@probo.com> wrote in message
news:pqlau1hti10fcl7qu...@4ax.com...

[Doron Holan [MS]]

if it is not going to be modified, use a const ref (see my original
statement, const refs are acceptable b/c no changes can occur). the point
here is not that the function itself knows or not what it can do, it is what
the caller expects to have happened when the call returns.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Le Chaud Lapin" <unorigina...@yahoo.com> wrote in message

news:1139248467.9...@g44g2000cwa.googlegroups.com...

[Tim Roberts]

"Gary G. Little" <gary.g...@seagate.com> wrote:
>
>Are you using a third party classe library; e.g. DriverWorks?

No. One of my clients used it, so I've had a little experience with it,
but I didn't really think it saved all that much time. I hadn't developed
a trust, so I ended up debugging in the DriverWorks code as much as I
debugged my own code.

In my own personal opinion, the encapsulation that C++ classes provide
simply make it harder for me to make mistakes. For example, I can create a
queue class that includes the data structures, plus all of the methods that
operate on it. Because the data structures can be hidden inside the class.
it isn't easy for me to accidentally operate on those structures in
uncontrolled ways.

Once I gain a little experience with KMDF, it looks like it will be easy to
create wrapper classes for most of the KMDF objects.

[Arkady Frenkel]

Tim!
Such discussions ( "religious wars" ) continue past 10 years :).
You are not alone ( in using C++ ).One of the pioneers of that before NuMega
was Intel http://www.microsoft.com/msj/archive/S35B.aspx
AFAIK MSFT planned C# drivers environment for all drivers classes , but
meanwhile postpone that
Arkady

"Tim Roberts" <ti...@probo.com> wrote in message
news:pqlau1hti10fcl7qu...@4ax.com...

[Le Chaud Lapin]

Arkady Frenkel wrote:
> Tim!
> Such discussions ( "religious wars" ) continue past 10 years :).
> You are not alone ( in using C++ ).One of the pioneers of that before NuMega
> was Intel http://www.microsoft.com/msj/archive/S35B.aspx
> AFAIK MSFT planned C# drivers environment for all drivers classes , but
> meanwhile postpone that
> Arkady

Hi Arkady,

Could you elaborate a bit? Do you mean to say that Microsoft proposes
to let all drivers be written in C#?

-Le Chaud Lapin-

[Arkady Frenkel]

As I wrote that such program postponed meanwhile...
Arkady

"Le Chaud Lapin" <unorigina...@yahoo.com> wrote in message

news:1139330910.6...@g14g2000cwa.googlegroups.com...

[William DePalo [MVP VC++]]

"Le Chaud Lapin" <unorigina...@yahoo.com> wrote in message
news:1139330910.6...@g14g2000cwa.googlegroups.com...

> Could you elaborate a bit? Do you mean to say that Microsoft proposes
> to let all drivers be written in C#?

The day will come. It may take 16-way systems running at 10 GHz, but sooner
or later it will happen.

I have no inside information on the plans that emanate from the Big House
but it is no secret that they've got an ongoing research project in which
the o/s is written "mostly" in managed code:

http://channel9.msdn.com/ShowPost.aspx?PostID=141858

At some point in the video, one of the particpants quantifies with the
percentage of source files that contain at least some native code. If I
remember correctly it is in the 15-20% range.

Regards,
Will

[Tim Roberts]

"Le Chaud Lapin" <unorigina...@yahoo.com> wrote:
>
>Hi Arkady,
>
>Could you elaborate a bit? Do you mean to say that Microsoft proposes
>to let all drivers be written in C#?

It has been discussed, although it may have been purely blue-sky.

There's no fundamental technological reason why it couldn't be done. You
could do the JIT compiling at driver load time. With an appropriate
driver-focussed class library, it might even be fun.

[Arkady Frenkel]

Will, tnx for link , after seening that the little remark it has 22% of
unsafe C# ( even not native ) code.
Arkady

"William DePalo [MVP VC++]" <willd....@mvps.org> wrote in message
news:e2j%23miSLG...@tk2msftngp13.phx.gbl...

[Eugene Gershnik]

William DePalo [MVP VC++] wrote:
> "Le Chaud Lapin" <unorigina...@yahoo.com> wrote in message
> news:1139330910.6...@g14g2000cwa.googlegroups.com...
>> Could you elaborate a bit? Do you mean to say that Microsoft
>> proposes to let all drivers be written in C#?
>
> The day will come. It may take 16-way systems running at 10 GHz, but
> sooner or later it will happen.

The day had already come. See http://en.wikipedia.org/wiki/JavaOS
I have no doubt that .NET OS will end up in similar markets.

What is funny is that the "Big House" is unwilling to make its C++ compiler
to better support kernel mode (i.e. help customers) but prefers to spend
money researching into yet another way to compete with Java. Kind of
underscores that this guy
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=60d058ca-af57-42ee-a18f-057868f88914
is right on target.

--
Eugene

[Le Chaud Lapin]

Eugene Gershnik wrote:
> What is funny is that the "Big House" is unwilling to make its C++ compiler
> to better support kernel mode (i.e. help customers) but prefers to spend
> money researching into yet another way to compete with Java. Kind of
> underscores that this guy
> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=60d058ca-af57-42ee-a18f-057868f88914
> is right on target.

The idea of trying to put that dog in the kernel is so strange, I don't
know whether to be elated (because Microsoft opens themselves up to
vulnerability if they do this) or frustrated (because their whole
fixation with all things .NET is kinda dumb to start with).

-Le Chaud Lapin-

[JM Lynn]

I cannot resit but to add my view on this topic when someone start
talking about JavaOS is the future. Yes, that may be so and I can
understand the reason for the trend, but being a cell phone user for
many Cell phone generations, I hate the all these Java cell phone. All
my last three Java cell phones take a bit of time to from power up to
fully operational. I recall my big clunker cell phones that were
instantly become operational when I press the power button.

So we may be all running JavaOS or the like kind of OS in the future,
but I am sure the physicists and high power computing users sure will
still want a high performance computing platform.

So the world may be moving towards something like JavaOS, but I for one
don't like it.

JML