Re: Why no one operating system is wrtten in an object language...!!!

Responding to Frye...

reasons.)  Only the RTOSes and ones with substantial legacy code are
still done procedurally.  (Even that bastion of legacy code, WinX, is
being slowly rewritten in C++ and now C#.)


<clip>

I recently went to a user group presentation on C# and the question was
asked how much of the operating system Microsoft intended to convert to
C#.  The answer was that Microsoft will NEVER write any of the OS in
C#.  C# is a managed language and you don't write operating systems in
a managed language.


Could you clarify what you mean by 'managed language'?



(According to Brad Abrams, a member of CLR team at Microsoft, on his
blog: http://blogs.msdn.com/brada/archive/2004/01/09/48925.aspx)

"Managed code is code that has its execution managed by the .NET
Framework Common Language Runtime."

This means that, like Java, the CLI languages exectute on a run-time.
Therefore writing a OS in these languages would require that the system
have the runtime installed before the operating system.  This doesn't
make sense.

IOW, they are interpreted. B-) I would agree, but for a different reason. Today OSes are layered just like other software, so there is nothing to prevent code in higher layers from running in a VM provided by a lower layer. And MS has to provide the .NET FCLRT anyway, so why not with the OS?

But interpretation would still be slow, which is usually not a desirable characteristic of OSes.

Since MS has adopted the CLI compiler rear end for all of its languages, 


I'm not sure what you are referring to here.  Maybe something I haven't
heard about?  I know the CLI is just-in-time compiled form Intermediat
Language (IL) and there are compliers that will pre-complile this IL,
but I think they still run on top of the run-time.  If there is a
compiler that lets you create exectutables that can be run on a OS that
doesn't have the runtime installed, I haven,t heard of it.

As you indicate, the CLI provides an intermediate language. That language can then be run via a VM or it can be compiled. The CLI provides a big advantage for platform compilation because one just has to expend resources for platform optimization once for all the languages that are precompiled to the CLI. [DEC pioneered this by having exactly that sort of optimization rear end. The result of those economies of scale was blisteringly fast executables for all of the languages they supported on all their platforms. Unfortunately the Assembly was virtually unreadable if one had to debug w/o sources. B-)]

Since C, C++, FORTRAN, COBOL, et al are normally "unmanaged", one needs a common compiler for CLI. (Does MS still provide FORTRAN and COBOL compilers?) Since Basic, VB, and C# were designed for interpretation, one also needs a common interpreter rear end, which is where the .NET FCLRT comes in. However, once one has those, then it follows that any language producing CLI via precompilation (JIT or otherwise) can be compiled. Conversely, they can all be executed on a common interpreter (if one wanted to do that for some reason). So one should have a choice for C# of either compilation or interpretation.

[Caveat. MS /said/ they were going to to use CLI and a common compilation rear end for all their languages several years ago when they originally announced CLI. I don't pay a lot of attention to MS, so I don't know if they ever actually did it. But it certainly makes a whole lot of sense for internal resource allocation, so I don't know why they wouldn't follow through.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Python vs. Lisp -- please explain
    ... Python is interactive, and yet it has a bytecode/vm ... breaks down the barriers between compilation and interpretation. ... flexibility that only an interpreted language can give", ...
    (comp.lang.python)
  • Re: A very interesting book
    ... I think that /any/ language can be interpreted or compiled. ... places the boundary between what one considers interpretation or ... compilation are almost non-existent. ... [snip - as nothing you say further seems to explicitly contradict what ...
    (comp.std.c)
  • Re: interpretive vs. compiled
    ... your real point was that language ... compilation or interpretation. ... Some language features require an interpreter, ...
    (comp.programming)
  • Re: Attempt to de-mystify AJAX
    ... I choose to minimise the Javascript because ... But to say that a language is somehow ... a compilation phase gives you the chance to ... Even PHP (though I have my own reasons for disliking PHP). ...
    (comp.databases.pick)
  • Re: Survey of intermediate program representations?
    ... > Approaches in Language Translation ... > an interpreter and for deployment, ... IMO VB is a bad example for compilation. ... portability is restricted to the platforms known to the developer, ...
    (comp.compilers)
Loading