Java vs C to make an OS

Sorry if this is the wrong section. I'm new here and did not see a topic for Misc programming topics and its not in the FAQ one. Its either specifically this language or specifically not programming at all along with no Java sections. I picked C since thats the OS language I am assuming. Unix and Windows is C I believe and not C++. Thats not what I am asking though.

I'm a beginner programmer. I'm learning C for a few reasons including its the OS language. One of my teachers at college thinks Java is the worlds best language and can do anything. I dont remember how it came up but someone said that Java can not make an OS. He said otherwise and because no one could specifically say why Java cant do that, he wins the argument. I really need to know why :P

Can someone enlighten me on this?

Welcome, we actually use the Tech board for such questions, so this thread has been moved.

Java "can" make an O/S that would run off of a VM of sorts. Does that mean it's appropriate?

You came to a C board, so the answer will probably be no. ;)

As MacGyver said you'd need a VM. Java is interpreted by a VM, and you couldn't write the VM in Java 'cause you'd need a VM to interperate your VM.

SunOS (Solaris) is mostly in Java, except the kernel. However the Kernel is the biggest component of the OS. So you could write an OS in Java, just not entirely in Java.

I myself am not a fan of Java, and your teachers comment is rather narrow minded. Creating an OS that is run through a VM is stupid and slow.

An OS is responsible for handling low-level hardware interfaces. Java doesn't provide any means for low-level access to hardware. Calling anything written in Java an Operating System is like calling Windows Explorer an Operating System.

Besides, Java necessitates the presence of virtual machine. The OS is responsible for loading and providing memory for the virtual machine. If the OS is written in Java, you end up with a very nasty bootstrap problem.

Quote:

---

Originally Posted by zacs7

SunOS (Solaris) is mostly in Java, except the kernel. However the Kernel is the biggest component of the OS. So you could write an OS in Java, just not entirely in Java.

---

Sun developed both Solaris and Java, but Solaris is definitely not written in Java in any way.

Quote:

---

Originally Posted by QuestionC

Sun developed both Solaris and Java, but Solaris is definitely not written in Java in any way.

---

I believe he's referring to the Java Desktop System, though, whatever he meant he clarified he was not talking about the kernel.

You can't write a complete OS in C, much less Java. I shudder to think how slow it would be if it were coded in Java.

If you want information on programming operating systems I suggest the book MMURTL. It is very heavy on assembly language (but OS programming necessitates being heavy on asm) so you may want to brush up on that or learn it. I don't have a link for the book but perhaps Fordy might.

The Solaris front-end (Java Desktop System) is written entirely in Java. As I said, the kernel is not.

An OS is a mixture of C and C++ as MacGyver stated on a thread a while back. With some assembley thrown in the pot too.

Quote:

---

Originally Posted by zacs7

As MacGyver said you'd need a VM. Java is interpreted by a VM, and you couldn't write the VM in Java 'cause you'd need a VM to interperate your VM.

---

Unless of course the VM is the actual hardware. http://www.soc.tuwien.ac.at/courses/jvmhw

Also someone is already trying a Java OS. http://cjos.sourceforge.net/archive/

Quote:

---

Originally Posted by swgh

An OS is a mixture of C and C++ as MacGyver stated on a thread a while back. With some assembley thrown in the pot too.

---

I don't remember saying that, but sure. ;)

Quote:

---

Originally Posted by Frobozz

Unless of course the VM is the actual hardware. http://www.soc.tuwien.ac.at/courses/jvmhw

Also someone is already trying a Java OS. http://cjos.sourceforge.net/archive/

---

I suppose the debate would then be about the performance of the VM-turned-hardware. :p

Another book I'd recommend is "Operating Systems: Internals and Design Principles". Although it has nearly no code, it takes a very in-depth look Linux, Solaris and Windows and discusses things every OS has to do.

Quote:

---

Also someone is already trying a Java OS. http://cjos.sourceforge.net/archive/

---

FOOLS!, They belong in the same group of people whom are porting the idea of a 'registry' to Linux, and porting VisualBasic to Linux.

You really have to weigh the benifits of Java, Java is portable thats really its only upside. Now a portable OS? Eh???

Quote:

---

One of my teachers at college thinks Java is the worlds best language and can do anything. I dont remember how it came up but someone said that Java can not make an OS. He said otherwise and because no one could specifically say why Java cant do that, he wins the argument.

---

It is not much of an argument though: it is just opinion that Java is the world's best language. If the argument is that this is because it can "do anything", then a counterexample easier than trying to prove that an OS cannot be written in Java is to point out that assembly language, C, C++, etc, can also "do anything". In the end, use the best tool for the job if you can, rather than always try to use the "world's best programming language" even when it (whatever it is) is not the best tool for the job.

Perhaps then the definition of "the world's best programming language" is, "The best language for the job" :)

Is this like asking a golfer which golf club is best? :D

Windows xp was written in C++. *cheers* Answer your question? :D
Java is to high-level to write a good os with anyhow.

You could write an OS in Java essentially in the same manner Singularity was wrote using C# (information here.) Of course, you're not going to write your OS in one single language by any means: otherwise, pretty much every major operating system would violate this rule, so that's kind of a bad way to define an operating system if you're thinking of it in that way.


Java is not inherently tied to the JVM either: that's just an implementation of Java. You can compile Java to native code (see: GCJ,) and you can link it into a simple flat binary; it is by no means impossible (impractical? I dare say maybe.) It's been a while since I've been interested in real operating system design/implementation. I wouldn't say Java is the best choice, but it's not an impossible choice.

To go off topic at a sig,

Quote:

---

Originally Posted by Mad_guy

Code:

---

-- haskell
import Control.Monad.State
s :: StateT Int IO ()
s    = do
  n <- get
  liftIO $ putStrLn ("hello "++ show n ++"!")
  unless (n >= 10) $ do {
      put (n+1); s;
  }
  return ()
main = evalStateT s 1

---

---

I must say, that's disgusting. What's wrong with

Code:

---

s :: StateT Int IO ()
s = sequence_ . replicate 10 $ do
      n <- get
      liftIO $ putStrLn ("hello " ++ show n ++ "!")
      put (n+1)

---

But no, seriously, what do you have against

Code:

---

main = mapM_ (putStrLn . ("hello " ++) . (++ "!")) [1..10]

---

You're making me cry :-(

Certainly it is possible in Java, but in my opinion it is the worst choice possible.

Most OS's will use a heavy amount of Assembly at the extreme lower levels, and then the bulk of the OS itself will be in C, with lots of C++ once you start getting into the higher levels.

To even consider the option of Java makes me shudder...

Windows XP is not written in C++ and for the most part, newsflash here, the versions of Windows since 95 have not changed all that much under the hood.

The core kernel code was ported to pure 32-bit code and uses protected mode but the API has really not changed much. It has acquired a significant amount of 'bloat' since those early days and I'm not sure if that's better or worse.

Actually approx 70%+ of the NT4/XP kernel is in C++. The front end to XP is in C++. Have a look at the link in my sig...

Quote:

---

Windows XP is not written in C++ and for the most part, newsflash here, the versions of Windows since 95 have not changed all that much under the hood.

---

There's been 3 kernels up until and including Vista, the 9x kernel, NT kernel and Vista Kernel. Other than the introduction of a few "features" like .NET and the like, I agree Windows hasn't changed that much over the past 12 or so years.

So, Bubba what you are saying is when M$ created Vista, they hardly touched the core program at all? All they did was change a few files and add some new flashy extras, This is just a guess, so please dont kill me over this assumptsion, im no where near as cluded up as you are about the tech side of Windows ;)

And the NT kernel is a complete rewrite of the old DOS-wrapper kernel of the 9x series. It's got very little in common under the hood with Win95. It's the exposed API that's largely the same.

if you want proof that XP is largely written in C++, just look at the Windows 2000 source leak.

CornedBee is correct. The generally exposed API to the system's application is largely the same, but NT is an extremely different architecture from Windows 95. If you were still running on the 9x series kernel, you'd know it. NT is architecturally very different and it is much more robust all around. These changes are largely not exposed to user-mode however, which is why a large portion of apps written for the 9x series were easily portable to 2k/XP. If the kernel's were "pretty much the same," you wouldn't need two different releases of tools such as, say, Process Explorer. You wouldn't need two releases of one driver for both systems.
The kernel is different. I've done plenty of work pertaining to low-level windows internals, primarily in the NT realm, but just looking at the evidence it's easy to conclude that things have changed in relation to the kernel since windows 95.

Quote:

---

if you want proof that XP is largely written in C++, just look at the Windows 2000 source leak.

---

If that's in reference to being a complete rewrite, it's orthogonal to the point anyway.

Quote:

---

Originally Posted by Rashakil Fol

You're making me cry :-(

---

You make me cry with your haskell skills. :( (edit: changed)

Making a kernel which runs on a run-time environment? Does someone try to make me laugh? :D

Quote:

---

Originally Posted by maxorator

Making a kernel which runs on a run-time environment? Does someone try to make me laugh? :D

---

No, you just can't read:

Quote:

---

You can compile Java to native code (see: GCJ,) and you can link it into a simple flat binary

---

Granted, you may have to have special versions of your libraries, but generally you'll have to bootstrap parts of your libraries regardless of the language anyway if you're going to write an OS.

Regardless of what JVM you are using, and regardless of what platform you are developing for, Java does not let you have hands on access to memory in any way.

Therefore, even if you compiled Java code to a flat binary, instead of interpreted byte code, the fact is that at the code level, when you wrote it, you still didn't have that hands on access to memory.

So, in order to write any type of OS in Java, there would have to be a specialized library written which allows you to access those protected things that Java normally keeps from you.

Quote:

---

Originally Posted by DavidP

Regardless of what JVM you are using, and regardless of what platform you are developing for, Java does not let you have hands on access to memory in any way.

Therefore, even if you compiled Java code to a flat binary, instead of interpreted byte code, the fact is that at the code level, when you wrote it, you still didn't have that hands on access to memory.

So, in order to write any type of OS in Java, there would have to be a specialized library written which allows you to access those protected things that Java normally keeps from you.

---

What point are you trying to argue here? I'm not saying it's practical or the best choice, I'm just saying it's not impossible. It's provable by the most fundamental theories and elements of computer science (see: Turing machines.)

I would expect no less of having to bootstrap your own memory management libraries and the like in C, same with other parts of the OS. I'm not arguing any of that (I even said that almost no OS qualifies as an OS if you have to write it in one single language to fit that specification.) So what point are you trying to make? Or are you simply trying to make the task seem as masochistic as possible?

Quote:

---

Originally Posted by zacs7

The Solaris front-end (Java Desktop System) is written entirely in Java.

---

Actually the JDS is simply a branded version of the GNOME desktop which is written entirely in C, together with programs most of which are written in C (StarOffice, Evolution, Mozilla). Despite the name it has nothing to do with Java.
http://www.sun.com/software/javadesk...em/details.xml

Besides, if the professor that claims that you can make an operating system in Java shouldn't it be him/her who should prove it? He might aswell argue that unicorns exist and let you prove that they don't.

Interesting debates running in this thread...just had to chime in myself :)

There was an experiment in some Scottish university some years ago (sorry, references lacking, not much was ever really released about it) that was an object oriented OS based on an object oriented CPU. C couldn't have been used as an application development tool because the OS exposed it's API as a set of objects. C++ didn't exist at the time, as I recall.

The project evaporated into obscurity, but the concepts were interesting, and demonstrated it could be done. Now, there's .NET, and one could argue the viability of C++ there (MS had to mangle C++ into C++/CLI after the failed 'managed C++' they produced).

I had the great privilege of meeting and working with one of the handful of people involved in developing the Alto at Xerox (the first GUI based system from which both Jobs and Gates were inspired for their attempts). It seems that was largely based on and written in Lisp, an object oriented Lisp if this man's description is to be believed (I'll withhold his name as he's not consented to my discussion of him in public).

A lot of this question about Java (a two part, here I address the question of Java applied to an OS development) really boils down to what you define for an operating system. The popular operating systems (including the now defunct OS/2, AmigaOS, BeOS, etc) expose their API as a set of C oriented functions (perhaps some used an alternate calling definition, like the Pascal convention, but still - a set of function calls). A Java OS would probably expose the API as a set of Java objects, meaning the only language suitable for development of applications would be Java or something compatible with Java. Attempting to fit Java with C like memory exposure would be sacrilege to Java programmers, and largely useless, violating one of the tenets that Java developers identify as the very reason of the languages superiority. That limit alone, however, deprives the world of applications developed in any other language approach, and while it's debatable if that would really matter, the result would be an abandonment of all legacy applications. The platform would be starting from 'under' the level of Linux today. It may prove an interesting experiment, but I doubt the result could escape academia.

I worked on a few proprietary systems where the OS was written in Pascal. That was long before Windows was what it is, and since it competed with Unix of the day, there really wasn't much interest, but at least it's OS exposure was similar enough that tools from other systems could be used, even C compilers.

To hear Torvalds say it, C++ is crap. I'm only repeating what I read. His opinion, drawn from interview, was that C++ couldn't be used for an OS, largely because, in his unsubstantiated opinion, it would be slow and buggy. He lamented that C++ programmers were, and I paraphrase for lack of memory of the exact word, snobs - that should admit they're really using C.

So much for the presumed authority of the great Linus. He may know what he's doing in C, but it seems he really doesn't understand C++, because while I don't recall the rest of the nonsense he muttered in the interview, I do recall repeatedly wondering how on earth anyone could say such things with a straight face and conviction of meaning.

It is from that attitude that most have thought Windows was written entirely in C. Be assured, the guts of Linux are in C, as Linus apparently would have it no other way. I suppose, too, it depends on what you call an operating system. Gates would have us believe IE was an integral part of the OS, and I have little doubt much of that is C++ code. Since the OS is exposed, until .NET, as a set of C function calls (given the caveat of the calling convention for a particular version), I submit those portions we generally regard as OS code within the kernel is largely C, and almost certainly the early versions of NT were all C, because the C++ compilers were so weak to that date, and code written in 1994/96 is quite different from the C++ we expect written today.

.NET is an attempt, among a great many other things, to expose the operating system as a set of objects rather than a set of functions. Laudable, but better if the objects were C++ objects, IMO - or at least there should have been thin C++ wrappers for that kind of exposure. I'm with Stroustrup on this point.

Now, I switch gears to the claim that Java is the best language. Ooooo, them's fightin' words in some quarters!

There's little doubt that C++ is a tad messy, which is largely a relic of history (it's basis upon C, chosen to invite an existing population of developers into a new paradigm). The sentiment already expressed here regarding 'the best tool for the job' is up to you most certainly applies. However, a blanket claim that Java is the best language is hardly backed up by history, example or experiment.

RAII is one prime point that Java missed entirely. As an OOP concept, I find it irreplaceable. It's absence from C# is lamentable, though there is some nearly satisfactory workaround - if I'm considered a member of the Jury, I'm still not voted for C# as a superior language.

Aside from RAII, though, Java has much to offer. Indeed, the absence of pointers and memory management issues related to the machine, which is the C legacy imposed upon C++ (perhaps some might preferred shared with C++) is laudable. There are suitable C++ means by which similar effects are achieved, but as Java fans will no doubt counter, they're optional. Well, curse words are optional to spoken languages - would an insulting idea be poorly conveyed without them? I think it's still possible to sting one's opponent with language clear of the FCC rules, but there is a deliciousness to their use when the time is right, isn't it? I'm told Italian is the best for curses, but I'm not so educated. That famous line in the Matrix 2 about cursing in French certainly tickles my fancy (the villain claimed it was like wiping one's, ahem, behind with silk).

The pejoratives of C++ aren't so nasty, but they do have side effects and seasoned C++ developers respect that, and avoid them at prudent cost. Smart pointers, STL containers and a good knowledge of development patterns goes a long way to making solid code. Bugs are of many kinds, though, and Java has no immunity.

Java proponents also point to it's 'pure' object oriented nature as a superior point in its favor, but I submit that after an application object is opened, there's no reason a novice can't continue to write more procedural code than good design demands.

I'd retort with a simple question. What ambitious, successful, popular applications were written in Java, and which ones were written in C++? That list alone should say something, though just what will still leave the professor's nose in the air in a pose of obstinate defiance as he fashions a retort backed by his authority as the one in charge of the current forum. It wouldn't be the first time a professor waxed for a career about something with which few others ever agree.

Java is superior if your intent is to provide rapid development results from engineers less competent than would be required to do the same thing in C++. If the Java produced application were compared by consumers to that of the C++ version, I'd dare say that the consumer wouldn't be able to explain why they prefer the C++ version (assuming it was generated by competent developers), but the probably would. The lower the ambition of the product compared, the less likely the consumer could tell any difference. It's in the products of higher complexity where features and performance expectations are critical that the Java version would fail to shine. This is less due to the language itself than to the exposure it gives to the developer of the underlying operating system and the speed it runs for a given hardware spec, which itself is highly dependent on the quality of the JVM.

In that way, C# is also superior to C++ - if your intent is to provide productive tools to less competent, and therefore less expensive, personnel. An entire industry depends on this sort of thing - I call them "bag of fields" applications. I did that work for years, years and years ago. I certainly don't profess to demean those thus currently employed - I was one of them for many years - but you must admit, it's quite different to be a developer on a team making products for the market of the ambition of, say, 3DS Max or Photoshop than it is to be a developer creating forms upon forms for a corporate IT department.

C++ is for those that operate without a net (as I write that I'm also thinking without .NET, but I'm just making myself chuckle). C is for those walking without a tightrope and without a net - floating in air, so to speak. For that, I suppose, Torvalds is owed his due. I wrote in C for years before C++ appeared, and I personally would never go back. I've toiled in Java and in C#, but only when required. Once you develop a considerable expertise in an area, you just tend to dive in deeper, becoming even more specialized. It's like the difference between a surgeon and a physician, or the general physician and the hematologists that are curing my son. Specialties can make for fascination in one's career. Torvalds is an example, I'm sure.

He probably meant that Java is compiled into ByteCode instead of Machine code and therefor needs a virtual machine (a software) to interpret and execute or compile it into machine code.

Quote:

---

Originally Posted by JVene

Interesting debates running in this thread...just had to chime in myself :)

There was an experiment in some Scottish university some years ago (sorry, references lacking, not much was ever really released about it) that was an object oriented OS based on an object oriented CPU. C couldn't have been used as an application development tool because the OS exposed it's API as a set of objects. C++ didn't exist at the time, as I recall.

---

Would love to know what is meant by an object oriented CPU.
Im pretty sure C could have been used though because you can write OO code in C easily

Quote:

---

Originally Posted by KIBO

Im pretty sure C could have been used though because you can write OO code in C easily

---

No. According to the definition,

Quote:

---

object-oriented programming language (also called an OO language) is one that allows or encourages, to some degree, object-oriented programming techniques such as encapsulation, inheritance, interfaces, and polymorphism.

---

C is definitely NOT an object oriented language.

Quote:

---

Would love to know what is meant by an object oriented CPU.

---

Since the project never reached out beyond Scotland that much, there's only scant material, and I don't think any of the terms and concepts were formalized; everything was experimental.

From what I got out of the paper I read, the idea was like this.

The CPU was implemented partly in a logic array, which means most of it was simulated by circuits designed to study example CPU configurations. The language of the CPU was grouped into objects, like machine I/O, math operations, string operations, etc.

The paper didn't include much coding example, but I recall that each process or thread had it's own object held in a table within the CPU, such that what we currently think of as registers were never actually pushed out and popped back in a task switch. It's like what we think of as the registers of the x86 CPU were an object, and the circuits which operate upon them (ALU, for example) switched between these objects to service threads.

The Power PC does something like this - perhaps we might shrug a shoulder and say it's just a machine instruction that 'does a task switch'.

However, from the design of the CPU language, it's general plan for circuitry, out to the language used to create applications, objects were the key theme throughout.

There was a section on a VM management object that described VM trackers that were part of each thread object. It was like making a CPU specifically for an operating system based on an object oriented language related to smalltalk - it might even work for Java.

This project was probably started around or not long after John Cooke 'invented' RISC computing, which actually turns out to be more important in the short term than an object oriented CPU, at least at that time. It may be that the idea was so far ahead of what was possible (remember, these were days when 10 million transistors on a chip was either new or still in the future), that it is only now that such a notion would be practicable.

The paper's conclusion did convey the sense that the project was deemed successful in that development reach a point of a functioning operating system, an application development language, the machine itself, and a handful of user applications - what I don't recall they listed.

Cooke's idea was to consider the electronics of the CPU and the operation and intelligence of the compiler as two ends of a single engineering puzzle, which was the opposite of previous practice for decades (slow progress, too). So we currently have Cooke's notions taken out of IBM and moved into non RISC mainstream designs - the two most important aspects of which were the idea that increasing the circuit complexity such that one clock tick does more real work, and that of the compiler being an integral part of how that's operated to benefit and gain. When Cooke started, I think it was '78, the Z80 didn't have half a million transistors. By the time Cooke's idea became a product, the CPU wasn't a single chip - it was two (the CPU was in two parts, not dual CPU's), and chips had maybe 1 or 2 million, somewhere around the time this object oriented CPU was being experimented upon.

That project died out after, presumably, the graduation of the doctoral candidate that drove the project about that time. 2 million transistors would never even come close for a 32 version of this design notion. Now, however, with the 400 million + we can put on a core, someone might, someday, prove the concept worth it - but then, the monopoly that is Microsoft/Intel would have to either be willing to change or let go, or it will have to wait for a 'revolution' of it's own self proving.

Cooke's idea proved practical because it can be implemented within existing streams of industrial/technical practice.


KIBO: Please pardon me for an opposing view, but....

KONI: I second your opinion about

Quote:

---

Im pretty sure C could have been used though because you can write OO code in C easily

---

I hear this now and then, and it has never made sense to me.

Obviously the objects CAN be written out for C to digest, that's how C++ was first implemented (and there are still C++ compilers available that do this).

The word easily is the part that I just can't swallow. I see examples of how some of the tenets of OOD and OOP may be implemented in C, but consider these two...

There is without a doubt no possible way to implement RAII in C, unless the concept is trivialized down to an integer on the stack or something like that.

There is no way to implement an equivalent to smart pointers that provides any leverage remotely analogous Java's references, which most C++ smart pointers do.

These two alone are capable of magnifying the solidity of code.

Now, I actually agree one can generate objects of a rudimentary kind, but as the complexity of design increases, it becomes a burden, not a leverage, to continue with it in C.

I've yet to find anyone provide convincing examples that demonstrate the contrary.

To that extent, there is a way to code objects in assembler - the way the compiler does it when it processes C++ code, for example :)


Joni:

Quote:

---

Besides, if the professor that claims that you can make an operating system in Java shouldn't it be him/her who should prove it? He might aswell argue that unicorns exist and let you prove that they don't.

---

You know, that's entirely true - and it never really occurred to me.


Then, too, I read, here and there, that Java WAS a system, embedded within the host system. Think about it - Java presents to application code an API that's common to all platforms, and perhaps it parasitically depends upon that host to do the mundane work, but there's no reason a Java specific CPU or computer (which I recall was planned at one point), which only runs Java applications BTW, couldn't be devised (ironically, the JVM would probably be implemented in C++ in a commercial implementation, just like the best JVM's are now).

Wasn't that the whole point all along though? Not just run on a virtual CPU, but run as if in a virtual operating system/environment, independent of the host? To me, making that into an operating system, depending on one's definition of that, is trivial - just take the current endpoints of the attachment to the host, like Linux, and write drivers from there to the real hardware. Done!

Of course, it's Java. Whoopty do, nothing new - same as if it were in Linux or Windows, so what's that worth on the market?

Now, in a smart phone, sure!

Refrigerator controller, yeah!

Don't they have these things already?

Quote:

---

Originally Posted by Mad_guy

No, you just can't read:

---

Oops! :D

But still, critical kernel components shouldn't be made in high-level languages.

Quote:

---

Originally Posted by JVene

I hear this now and then, and it has never made sense to me.

Obviously the objects CAN be written out for C to digest, that's how C++ was first implemented (and there are still C++ compilers available that do this).

The word easily is the part that I just can't swallow. I see examples of how some of the tenets of OOD and OOP may be implemented in C, but consider these two...

There is without a doubt no possible way to implement RAII in C, unless the concept is trivialized down to an integer on the stack or something like that.

There is no way to implement an equivalent to smart pointers that provides any leverage remotely analogous Java's references, which most C++ smart pointers do.

These two alone are capable of magnifying the solidity of code.

Now, I actually agree one can generate objects of a rudimentary kind, but as the complexity of design increases, it becomes a burden, not a leverage, to continue with it in C.

I've yet to find anyone provide convincing examples that demonstrate the contrary.

To that extent, there is a way to code objects in assembler - the way the compiler does it when it processes C++ code, for example :)

---

This hardly seems fair. You're creating a definition of OO in terms of features based on
1) Not being able to do them in C.
2) Them being good.

Why even mention RAII? You've crafted an argument one could use to say Java can not perform OO programming.

The claim was that you can easily perform OO programming in C. OO programming boils down to
[1] Abstraction -- providing some form of classes and objects.
[2] Inheritance -- providing the ability to build new abstractions out of existing ones.
[3] Runtime polymorphism -- providing some form of runtime binding.
I pulled this definition from http://www.research.att.com/~bs/oopsla.pdf, it begins with a good discussion on defining OO, and the importance of having a historically reasonable definition of words if you are trying to communicate.

All of these can be done in C. All three of these are easy to do. C code which does any of these properly is not by nature complicated or not self-explanatory. The reason C++ compilers could compile out to C is because it is for the most part a simple transformation.

No, C is not an OO language. That is a straw man. It wasn't designed around these ideas. Polymorphism, for example, has no native means of being expressed in C. It is the programmer's job to build that sort of functionality out of what C does provide. I am not claiming C is an OO language. KIBO never made that claim either.

>All three of these are easy to do

Well that certainly depends on your definition of easy. They are certainly easier to do in Java.

Quote:

---

Originally Posted by QuestionC

This hardly seems fair. You're creating a definition of OO in terms of features based on
1) Not being able to do them in C.
2) Them being good.

---

indeed, not being able to write smart pointers has nothing to do with OO, more with features like automatic destructors and copy constructors etc that C++ has and C doesnt.

You can do data hiding, inheritance and polymorphism in C, in fact even low level driver code I've seen uses this through functions pointers

Quote:

---

Originally Posted by maxorator

But still, critical kernel components shouldn't be made in high-level languages.

---

Aside from perhaps a speed difference (of generally negligable performance in most cases, I'd wager) why not? High level languages offer plenty in themselves; Haskell is probably one of the best examples of a high level, functional language that offers programming precision and correctness, while staying simple in essence. Yes, you may lose 2 seconds of run time, but you'd be willing to throw away benefits such as code correctness, reusability and modularity? For two seconds? I'm pretty sure the users wouldn't notice a difference anyway (also, in a microkernel architecture such as MINIX or an extremely simple yet flexible kernel such as Plan 9's, a lot of your code is in userspace anyway, so you don't have much to lose by writing your user-space system components in a higher level language.)


Again, I'm not exactly saying things such as "operating systems should be written in Haskell" or anything like that; but I think you're looking at the subject too narrowly, or simply not looking or caring about the other side of the fence. It'd be worth it to look into your options, rather than disregard them just so you can go with the norm.

Quote:

---

Why even mention RAII? You've crafted an argument one could use to say Java can not perform OO programming.

---

I think you exaggerate the interpretation of my statements.

I didn't say something along the lines that it's not OOP if there's no RAII.

We're not writing a dissertation here, these are relatively short, causal posts compared to something like that.

I think it safe to assert that RAII is an OOP concept. It's true that you can't use RAII in Java, and for that Java is lacking an important feature. That doesn't mean Java isn't object oriented. RAII is an illustration of a point I think you missed in my statement:

Quote:

---

The word easily is the part that I just can't swallow.

---

I asserted several times that I recognize how object oriented techniques can be implemented in C (I've read the papers on OOPC too - I even found a few on OO assembler - really!), but I do not accept that it's easy to do in C, and since Java has become part of the comparison here, RAII is not easy to do in Java. For every situation in which RAII is used to advantage in C++, that same act can be performed in Java but without OOP leverage - it must be done explicitly, manually (i.e. the hard way).

As the ironically named Perspective replied,

Quote:

---

Well that certainly depends on your definition of easy.

---

I read in one of Stroustrups interviews (maybe it was just a reply to something on his website, I must admit I'm not sure where, and I'm liberally paraphrasing here from an old memory) that his design motivation is one of supporting the thought process of the programmer, providing tools that aid in the psychological act of thinking about programming. To that end, his aim was to provide leverage for expression of one's thought in code. Please don't look for a quote of him in that - I'm re-summarizing my memory, which itself is a summarized paraphrase of Stroustrup's point.

My point is illustrated, not defined by, RAII. Here's a concept that can only be given leverage with an object that has a definite initialization and a definite destruction sequence. Java objects don't have that, and for that matter, C# objects can only provide this through a small extra bit of effort. As such, there's a lack of leverage on this one point when one writes in Java. That doesn't remove the OO moniker from Java (note, for example, I referred to them as Java objects), it just means that there's one example of something it doesn't support within the language.

Obviously you can still initialize a resource and shut it down in Java, C or most any language. Without the leverage of a deterministic destructor, however, their is a mental effort required of the programmer, to manage the resource, which opens the possibility of an error.

Obviously a C++ author is free to avoid using RAII, and as such can disregard this leverage and engage in the same mental effort of performing the destruction of a resource manually. It is an extra effort in Java, as it is in C. The option of gaining the leverage exists in C++, and it is a reduction of mental effort that allows one's attention (and time) to be devoted to other matters - making the management of those resources easier (and the resulting code more solid).

Here again, I return to my previous self quote - it's the easy part I just can't accept.

I assert the reverse. The more OOP techniques one attempts to deploy when writing in C, the more mental effort that programmer must exert in order to manage them because the language doesn't support those features.

We are free to exert what mental effort we wish, and in my repeated disclaimer I agree it's certainly possible to implement objects when writing in C. My point is that these are manual efforts, requiring more attention from the programmer than counterparts would require if the programmers availed themselves of OOP features inherent in an OOP language.

At some point along that continuum, from rudimentary object oriented concepts to the more advanced and subtle, easier become not so easy, and finally not easy at all.

RAII is one point were easy no longer applies, though some may argue trivial for something like a file handle. As the notion of shutdown becomes more involved, like a threaded system that requires an epilogue of activity to properly conclude a concept, like a cache or something, the advantage of RAII returns more powerful benefits.

Smart pointers are an example of RAII, from the viewpoint that an acquisition of memory is made that eventually must be released. While RAII and the use of smart pointers are not the definition of OOP programming (and I wasn't attempting to elucidate a definition), both can only be implemented using OOP techniques, and the features of OOD are lacking in C to implement them easily. I agree that one could create a struct in C that represents a reference counted pointer (in fact, I've seen them in a few C frameworks). However, there's nothing automatic about it - everything from the auto initialization to NULL to the automatic destruction at the last reference's release require manual interventions, which is to say mental effort on the part of the developer. In C frameworks where I've seen this, it is entirely transparent to the C programmer, which does exhibit the concept of encapsulation, but here again - I never said it wasn't possible, and I didn't say it couldn't be done. What I said was (or at least a reasonable re-interpretation of my quote), it isn't easy. In C++, it can be implemented so as to be automatic. There is nothing easier than something that's automatic.

I do think it's fair, when analyzing the ease with which OOD techniques are implemented, to use examples like RAII. If I were attempting to define a language as OOP or non OOP, then your complaint would be quite fair. I wasn't.

I'm talking about support within the language, the leverage the language features provide, which, by example, illustrates the ease or lack of ease with which a concept that's dependent upon OOP can be implemented.

To re-illustrate what I said:

Quote:

---

Now, I actually agree one can generate objects of a rudimentary kind, but as the complexity of design increases, it becomes a burden, not a leverage, to continue with it in C.

---

Burden, as in, not easy. Leverage, as in making it easy.

I'm measuring the mental effort required to implement the OOP concept, which itself is a difficult notion, but that ease probably relates more directly to how much time is absorbed implementing a concept in one manner as opposed to another, the probability of reducing in increasing error in the results, and a host of potential metrics.

I can use a wrench to drive a nail into wood - but that doesn't make the wrench a hammer, even though I may be able to use it as one. Even when we all agree the wrench isn't a hammer, many of us have had an occasion to use a wrench, or some other non-hammer object, to drive a nail - using the wrench AS a hammer.

My point wasn't about the wrench being a hammer. My point was that using a wrench as a hammer isn't easy, but sometimes nails are not that hard to drive into soft wood.

As the force required to drive the nail increase, the wrench becomes a less suitable hammer, and this is my point.

OOPC is possible, and I never asserted it wasn't. Simple OOP in C may be simple to illustrate and deploy. The more examples of OOD you attempt to implement in OOPC, the more work you'll have to exert to make things work, and that to me means its not AS easy, and there comes a point in that comparison were it simply is NOT easy.


Let me extend this discussion with yet another assertion about OOP in C++ vs C. I take this again from a Stroustrup interview, but from a more recent memory.

A matrix library was written as a template class in C++. A counterpart was written in C. These are doctoral candidates or other PhD's like Stroustrup, so we must assume they were written by competent hands.

The C++ version outperforms the C version, and that might be surprising. Stroustrup explained why. It appears that when creating generic code, it's possible to describe a problem such that there's greater opportunity for the compiler to 'understand' the code, and optimize it. Without the example in hand I can't say why, but his assertion was the C compiler didn't get as much information as the C++ compiler did, by virtue of the way the problem is expressed. As such, the compiler optimized the code better in the C++ version.

Here again, I think it safe to say, it was easier for the compiler to optimize - because the expression of the problem was better. Certainly, the C version was possible.

Another illustration that's much clearer, sorting. The C runtime qsort was compared to a sort in the STL. The STL sort is faster in some situations, and here again I rely on Stroustrup's explanation. qsort requires a function pointer as the comparison predicate. Sometimes that's the only way to describe the predicate. However, there are many sort situations that depend on primitive types, in which case the comparison is trivial. The STL provides a means of describing the sort predicate such that the compiler can optimize that into a primitive comparison without generating a function call - inlining the comparison. qsort's dependence on a function pointer makes this optimization impossible.

Even Stroustrup pointed out that it's certainly possible to write a qsort the specifically optimized the comparison. Certainly a CFront output would have done so from the template example, too. The point is, with the STL, the optimization is easy. To make one's one qsort optimization is not.

The expression of the problem in the STL gives the compiler information unavailable to qsort. It was the summary point of Stroustrup's response that the there's a richer expression potential in C++, which gives more information to the compiler for optimization, and I submit that makes things a little easier, too.

Quote:

---

Originally Posted by JVene

Let me extend this discussion with yet another assertion about OOP in C++ vs C. I take this again from a Stroustrup interview, but from a more recent memory.

A matrix library was written as a template class in C++. A counterpart was written in C. These are doctoral candidates or other PhD's like Stroustrup, so we must assume they were written by competent hands.

The C++ version outperforms the C version, and that might be surprising. Stroustrup explained why. It appears that when creating generic code, it's possible to describe a problem such that there's greater opportunity for the compiler to 'understand' the code, and optimize it. Without the example in hand I can't say why, but his assertion was the C compiler didn't get as much information as the C++ compiler did, by virtue of the way the problem is expressed. As such, the compiler optimized the code better in the C++ version.

Here again, I think it safe to say, it was easier for the compiler to optimize - because the expression of the problem was better. Certainly, the C version was possible.

Another illustration that's much clearer, sorting. The C runtime qsort was compared to a sort in the STL. The STL sort is faster in some situations, and here again I rely on Stroustrup's explanation. qsort requires a function pointer as the comparison predicate. Sometimes that's the only way to describe the predicate. However, there are many sort situations that depend on primitive types, in which case the comparison is trivial. The STL provides a means of describing the sort predicate such that the compiler can optimize that into a primitive comparison without generating a function call - inlining the comparison. qsort's dependence on a function pointer makes this optimization impossible.

Even Stroustrup pointed out that it's certainly possible to write a qsort the specifically optimized the comparison. Certainly a CFront output would have done so from the template example, too. The point is, with the STL, the optimization is easy. To make one's one qsort optimization is not.

The expression of the problem in the STL gives the compiler information unavailable to qsort. It was the summary point of Stroustrup's response that the there's a richer expression potential in C++, which gives more information to the compiler for optimization, and I submit that makes things a little easier, too.

---

Well, first of all in the games programming world STL is avoided like the plague because of its inability to do things by reference and always by value.
Yes I believe right away that in some cases inlining and templates can generate faster code but real world application dont end there.
In a real C++ app someone will at some point introduce exception handling around the matrix code and generate unnecessary copy constructor calls because STL only works by value. And changing everything from raw pointers into smartpointers wont help performance either, many many calls are generated that in C will never be. But you never see that in those examples because they just want to make a point that it *can* be faster. And if you want fast matrix math, use fortran which is what is still used a lot in the scientific world :)

There is so much misinformation in this post it is absurd.

Quote:

---

Well, first of all in the games programming world STL is avoided like the plague because of its inability to do things by reference and always by value.

---

And what would make you an authority on this topic? So instead of using a pre-built, pre-tested, and pre-optimized library a game company would code their own container classes? Even when the more time they take the more money they spend? I highly doubt it. Reinventing the wheel is not what game companies will do and nearly every single job application for game programming mentions familiarity with the STL.

Fact is you absolutely 100% cannot code an OS in any high level language. It is not technically possible, feasible, nor worth debating about. Before talking about operating systems perhaps it would do some good to actually research them and how they are coded. This is not simple programming and it most certainly goes far beyond simple items such as how a language allocates memory or does not allocate memory. There is so much to an operating system I could not even begin to scratch the surface here.

I recommend buying a lot of books about operating system design and downloading the Intel/AMD tech refs (if that is your target platform) and read the sections on systems programming and different ways to go about handling process address spaces, memory management, device management, hard drive management, process control, multitasking approaches, task management, and about a ton of other concepts that are ...well far beyond my experiences thus far.

There are those here that have tried to code small OS's with some degree of success. I, myself, never got beyond the bootstrap process because loading the kernel into memory would have only been compatible with FAT 32. Since then more information has become available about different file systems so one could feasibly support NTFS or some other type of file system. Microsoft WILL charge royalties, however, if your system can read FAT32 and/or NTFS and you attempt to release or sell the OS to the public. This was announced by MS sometime ago and is probably just one more way they ensure they have a monopoloy in the retail PC OS market.

If you really want to see how difficult and low-level an OS is I recommend looking at Linux and the Linux kernel. The goal in any OS is to get from assembly to C as fast as possible. Usually after you load your kernel from the drive into some portion of memory you would then begin to load OS drivers followed by user drivers, etc, etc. You would need to provide some type of way to call those drivers and the driver manufacturers would need to know what function you would be calling or what interface to use so that their drivers can be called at the appropriate time by the OS. There is the topic of process and thread privileges, protected mode BIOS support, protected mode interrupt support (it is possible and at times needed), setting up the IDT, LDT, and GDT, and about a ton of other 'things' most of this thread has completely skimmed over.

No amount of waxing eloquent or hogwash is ever going to change the fact that this is simply not possible in ANY mid to high level language much less Java. You use the right tool for the job or you don't get the job done. You could have Java as the GUI but you most certainly would not be able to use Java as is to get any type of OS code to do anything close to managing the entire system. In order to do that would require a nearly complete re-write of Java and it would also need to run without a virtual machine. How can you run a virtual machine when your OS is the 'machine'? Cannnot be done. Java would run on top of your code and interface with your kernel, but more likely with the higher portions of your system like your underlying API and not the kernel at all. You need the power of assembly and C to create an OS. Good luck on even getting to C since this would require a completely new C compiler to even get it to work with your OS.

Quote:

---

Originally Posted by Bubba

There is so much misinformation in this post it is absurd.

And what would make you an authority on this topic? So instead of using a pre-built, pre-tested, and pre-optimized library a game company would code their own container classes? Even when the more time they take the more money they spend? I highly doubt it. Reinventing the wheel is not what game companies will do and nearly every single job application for game programming mentions familiarity with the STL.

---

I got it from the guys in comp.games.programming.misc who work at different games companies. Its not about reinventing the wheel, of course they have their own tested library ready. For tools stl is probably used.

I myself make video casino games for a living, but we work in C on 16 and 40mhz processors, would love to try out C++ with STL one day

Our kernel code (call it the OS) is internally developed in C and of course asm. Its funny to see that some driver code uses the OO approach with "virtual" functions.

I've found several articles on the net stating that STL is in fact used and those companies that refuse to use it are using less tested error prone in-house container code.

Many, many, many titles have shipped on the PC and consoles which used the STL. Unless you can prove with numbers and empirical data that your container classes are indeed faster I would stick with STL. Doom 3's container system was proven to actually be slower than the same coded using the STL.

But anything can be abused and I see it all the time here. If you try to create a map of a map of a list of vectors then of course it's probably not going to set any speed records. Again use the right tool for the job.


But we diverge. Back on the topic of OS code.

KIBO

A point about STL containers.

You can set the type to a pointer to a class, rather than a class, in which case it's not an object copy that's made, and the objects placed in the container can come from custom allocated designs so that the end result is actually faster than default allocations in C, IN REAL WORLD WORK.

Some of us are professionals, some are students - many of us have toured the map. I'm new to this board, but I own my own firm, have 27 years of development history, and I've been a C programmer for years before C++ was released. I don't make games, but I've hired several from the gaming industry. Young (or freshly out of the young stage), overworked, underpaid, nearly burnt out from post college all night adrenal overload.

3 of 4 said they used STL in game development. However, (I just asked one guy) - there are some structures in 3D gaming that are specific to engine design for which either a hybrid is used, or a custom - which is usually made complaint with STL container standards.

That's typical practice in many fields, including neuro-nets for AI, 3D for non-gaming, etc.

KIBO, you seem to outright state that all claims of performance benefits from C++ development are contrived, and in real development things don't work that way.

Please keep in mind, many of us here are professionals, too. You said you write for a rather niche specialty (I mean, in today's environment, a 40Mhz processor is a bit of a unique target, most of us are working with desktop, workstation or server oriented systems - though I managed an IT department for a fortune 1000 company with an array of 10 Unix boxes clocked at 40Mhz). No doubt you have considerable experience, but I urge you to consider that some of us have many years under the belt, too. I, for example, own my own firm, have a staff of loosely knitted contractors, and have developed applications in various platforms for 27 years. I started my business in 1982/83, and a few of my clients date from that time.

I can assure you, the claims of performance in C++ do not fail in real world applications of considerable ambition. 3DS Max, for example, for which I've written (I was trying to count from memory - at least 12) plugins, is an excellent example.

One other point about exception handling. No experienced C++ engineer would put exception handling on the inside of a performance oriented loop. On another forum, a question came up regarding the performance of exception handling, and my reply coincided with others. The impact of the prolog for a try is about the same as the prolog of a function call. One poster claimed that with optimizations, there are certain circumstances where the overhead evaporates to zero, but I can't confirm that claim. Still, unless an exception is actually thrown, there's otherwise no impact on code interior to the exception. An examination of the resulting assembler bares this out. Exceptions ought to be used for 'exceptional circumstances', though I've seen copious misuses that were conspicuously from the hand of an amateur.

Quote:

---

Originally Posted by Bubba

Fact is you absolutely 100% cannot code an OS in any high level language. It is not technically possible, feasible, nor worth debating about. Before talking about operating systems perhaps it would do some good to actually research them and how they are coded. This is not simple programming and it most certainly goes far beyond simple items such as how a language allocates memory or does not allocate memory. There is so much to an operating system I could not even begin to scratch the surface here.

---

I've done the research, I've looked at the linux kernel dating from version .01 to 2.6. I've also investigated and worked with other systems ranging from Plan 9 to MINIX and DynastOS.
No amount of 'hogwash' is ever going to change the definitions of computer science we have today: Turing completeness is something you're just ignoring; that isn't going to make it go away.

You can call it theoretic nonsense all you want, but if you were to ever say something like that in any academic circles, you'd most certainly be written off as a complete fool without second thoughts, and with good reason.

Quote:

---

No amount of waxing eloquent or hogwash is ever going to change the fact that this is simply not possible in ANY mid to high level language much less Java. You use the right tool for the job or you don't get the job done. You could have Java as the GUI but you most certainly would not be able to use Java as is to get any type of OS code to do anything close to managing the entire system.

---

You can call it hogwash and call BS all you want. It doesn't change the facts (particularly, look up singularity and jnode.)

Quote:

---

In order to do that would require a nearly complete re-write of Java and it would also need to run without a virtual machine. How can you run a virtual machine when your OS is the 'machine'? Cannnot be done.

---

It's obvious you haven't read a single thing I've posted in this topic. Aside from that, I've only said it to be possible, I never said it was practical or anything along the lines; I think you're simply confusing the two.

Quote:

---

Good luck on even getting to C since this would require a completely new C compiler to even get it to work with your OS.

---

No, it wouldn't. How much research and work have you actually put into operating systems? You hardly need to write a brand new compiler, all you'd have to do in reality is retarget a compiler to output binaries that your OS will load. This is a lot simpler than simply re-writing your compiler entirely (and it should be, modern compilers have several stages. If you're using a compiler that's so hard-coded it would need to be re-written just to output to a different file format, it's probably a compiler that's either very specific to the OS anyway, or one not worth using.)

Quote:

---

Originally Posted by JVene

KIBO

3 of 4 said they used STL in game development. However, (I just asked one guy) - there are some structures in 3D gaming that are specific to engine design for which either a hybrid is used, or a custom - which is usually made complaint with STL container standards.

That's typical practice in many fields, including neuro-nets for AI, 3D for non-gaming, etc.

KIBO, you seem to outright state that all claims of performance benefits from C++ development are contrived, and in real development things don't work that way.

Please keep in mind, many of us here are professionals, too. You said you write for a rather niche specialty (I mean, in today's environment, a 40Mhz processor is a bit of a unique target, most of us are working with desktop, workstation or server oriented systems - though I managed an IT department for a fortune 1000 company with an array of 10 Unix boxes clocked at 40Mhz). No doubt you have considerable experience, but I urge you to consider that some of us have many years under the belt, too. I, for example, own my own firm, have a staff of loosely knitted contractors, and have developed applications in various platforms for 27 years. I started my business in 1982/83, and a few of my clients date from that time.

I can assure you, the claims of performance in C++ do not fail in real world applications of considerable ambition. 3DS Max, for example, for which I've written (I was trying to count from memory - at least 12) plugins, is an excellent example.

---

Looks like I didnt get my point across lol. I wasnt debating that "C++ and STL is sloooooooow" or anything like that. I've written big server and gui C++ apps too and the only times I've seen performance problems was because the algorithms chosen were wrong or the code was structured wrong. Never needed to do micro optimizations yet.

I was trying to say that statements like, "see this matrix library is faster than C's qsort because of templates and inlining in C++" are twisting reality because when you create a real app around that library you lose that performance gain again. That doesnt mean that it matters!
It will matter though if one would use heavy exception handling and object copying at a kernel level when writing an OS so the lower level one gets the more these high level features arent used anymore. The lower you get the more C like you will start to code :)

Just to make something clear: the 9x-ME kernels and the NT/2000/XP/Vista kernels are completely different. The API and the interface is similar, but they don't share the internals.

Quote:

---

Originally Posted by Sang-drax

the 9x-ME kernels and the NT/2000/XP/Vista kernels are completely different.

---

One example to further prove that is the Blaster worm. If I'm not mistaken, differences in the kernels was blamed for it being limited to the NT range of kernels.

To get further back on the topic, I'd think a Java OS would be possible but only if the hardware implemented the VM as well as the various libraries. That would be interesting to see. :p

Hardware implemented libraries? Once you have the VM you have all of the java libs.

Quote:

---

Originally Posted by Frobozz

To get further back on the topic, I'd think a Java OS would be possible but only if the hardware implemented the VM

---

If the VM is in the hardware, it's no longer a virtual machine.

That's no different than just compiling Java down to native code. You may as well just do that and save yourself the trouble of designing a processor that runs on Java byte code.

Point is, Why would you bother?

Point is, many people bother.

Unless your new java OS can provide something that others already don't, then theres no real point other than learning...

I was talking about compiling to native code, not writing an OS.

Quote:

---

Originally Posted by Mad_guy

No amount of 'hogwash' is ever going to change the definitions of computer science we have today: Turing completeness is something you're just ignoring; that isn't going to make it go away.

---

Turing completeness is a description of the theoretical computability of problems. It has nothing to do with language capabilities that are outside the realm of numeric problems, such as hardware access. Java does not provide a way to access machine registers, raw memory or I/O ports. Without these three, you cannot make an OS, period. To perform these tasks in Java, you need libraries that do it, and these libraries in turn cannot be written in Java. Or else you need to extend your virtual machine or native code compiler beyond the Java Language Specification, in which case you're no longer programming in Java.

Computability has nothing to do with it.

Quote:

---

Originally Posted by Perspective

I was talking about compiling to native code, not writing an OS.

---

And I was talking about writing an OS in java ;)