OSNews: http://www.osnews.com/story/23556/BareMetal_OS Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Fri, 24 May 2013 10:26:41 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com Nifty http://www.osnews.com/thread?433499 http://www.osnews.com/thread?433499 I don't think 'innovative' is the right word; that implies new and different, even at the expense of clarity or simplicity. This seems to be more basic and clean, the bare minimum bread and butter an OS needs. Not that it's a knock against the system; simplicity is good.

Poking around their SVN tree, it seems they're missing a few core functions. Well, I've been meaning to poke around with x86-64 assembly anyways...Edited 2010-07-14 22:07 UTC Wed, 14 Jul 2010 22:01:00 GMT donotreply@osnews.com (Almafeta) Comments Welcome home again, OSnews! :) http://www.osnews.com/thread?433516 http://www.osnews.com/thread?433516 Welcome home again, OSnews! ;)

This kind of news are what we, your readers, were waiting for ;)

I know, these news are rare these days but I am happy that these research, hobby, alternative OSes still have a place (this place) where they can be introduced and divulged. Thu, 15 Jul 2010 01:51:00 GMT donotreply@osnews.com (ebasconp) Comments LLVM? http://www.osnews.com/thread?433523 http://www.osnews.com/thread?433523 Assembly for x86 may have a stable target, but it just isn't where that kind of tightness is needed. Use the assembly language for LLVM and you can target the architectures in mobile devices - or if you are on a desktop, more readily offload onto the GPU or other resources. Still, who cares? Sounds like these guys are having fun. Thu, 15 Jul 2010 03:29:00 GMT donotreply@osnews.com (Dasher42) Comments Under 16Kb small? http://www.osnews.com/thread?433525 http://www.osnews.com/thread?433525 It's under 2 KB? That is compact, like under 8-bit operating system compact. Thu, 15 Jul 2010 03:54:00 GMT donotreply@osnews.com (bousozoku) Comments FINALLY!!! http://www.osnews.com/thread?433528 http://www.osnews.com/thread?433528 Finally! Some OS NEWS! I wish them good luck in their endeavours. And it's interesting to see some people still building OSes using assembly (Compact).Edited 2010-07-15 05:04 UTC Thu, 15 Jul 2010 05:03:00 GMT donotreply@osnews.com (Quake) Comments HPC software stack http://www.osnews.com/thread?433531 http://www.osnews.com/thread?433531 So I guess this wouldn't be for any generic HPC clusters, but for when you have a specific application that you have the ability to either port or write from scratch, then.

Would be interesting to hear about implementations later on when they get a little more hw support (like network).

Wonder if MPI and InfiniBand and such things are on the map for the future? Thu, 15 Jul 2010 06:28:00 GMT donotreply@osnews.com (reflect) Comments New kid on the block http://www.osnews.com/thread?433532 http://www.osnews.com/thread?433532 It is always nice to see a new kid on the block. They are doing another menuetOS (http://www.menuetos.net/) hope they have at least the same success Thu, 15 Jul 2010 06:48:00 GMT donotreply@osnews.com (vasper) Comments Message from the author http://www.osnews.com/thread?433534 http://www.osnews.com/thread?433534 We still have a ways to go but we are getting to something that I think has a lot of promise.

Network support is currently the major thing that is lacking. We plan to have some limited support in v0.5.0 (most likely targeting the Realtek 8139 chipset or similar). BareMetal OS nodes will communicate via raw Ethernet frames. Once network access is complete we can use a real cluster of BareMetal OS machines.

Work on the C library needs to be done as well. Currently it is using custom calls for basic operations but we would like to include all of the ANSI C standard functions (printf, scanf, fopen, etc..).

Maybe in the future BareMetal OS could replace Linux on Pixar's Renderfarm ;)

Thanks,
- Ian Seyler @ Return Infinity Thu, 15 Jul 2010 07:53:00 GMT donotreply@osnews.com (iseyler) Comments RE: Welcome home again, OSnews! :) http://www.osnews.com/thread?433536 http://www.osnews.com/thread?433536 I think Osnews is dead, I haven't seen much of anything of late. Really I come here out of habit and always leave feeling disappointed. Phoronix always has something new and exciting, I just wish OSnews could do the same. I guess though this is just a hobby website and it doesn't make any money. Thu, 15 Jul 2010 08:11:00 GMT donotreply@osnews.com (sc3252) Comments RE[2]: Welcome home again, OSnews! :) http://www.osnews.com/thread?433542 http://www.osnews.com/thread?433542 I think Osnews is dead,

Hmm, I personally like OSNews. I've been a daily visitor for who knows how long now and I can't say I am disappointed in any way really. One thing I especially like about OSNews is that commenting really works well and there's often interesting discussions here whereas f.ex. Slashdot's comments area tends to be full of useless stuff and flamebaits.

But well, each to their own, I s'pose. Thu, 15 Jul 2010 09:32:00 GMT donotreply@osnews.com (WereCatf) Comments Comment by bloodline http://www.osnews.com/thread?433545 http://www.osnews.com/thread?433545 I like OSNews too... No complaints from me.

On topic... Any chance of an Obj-C runtime? ;) Thu, 15 Jul 2010 11:18:00 GMT donotreply@osnews.com (bloodline) Comments RE: Message from the author http://www.osnews.com/thread?433550 http://www.osnews.com/thread?433550 Hi, that's an interesting goal! To run RenderMan, it's mostly C bindings, and the shader language is all in software (REYES algo). That should eliminate huge parts of a full POSIX API. Plus, you wouldn't need proprietary HW drivers, right? You would definitely need networking working for the bytestreams. How are you handling the FS? Just hiding it behind the networking layer? I suppose you could, since the bytestream is god in RenderMan.

Very interesting goal. Good luck! What about more normal MPI/OpenMP type stuff? Thu, 15 Jul 2010 12:33:00 GMT donotreply@osnews.com (kjmph) Comments Why x86 assembly? http://www.osnews.com/thread?433552 http://www.osnews.com/thread?433552 I know from personal experience (SPARC v9) that assembly programming can be cool, but it has severe limitations:

1. Not suitable for large and complex programs. Every hobby project starts small, so coding everything in assembly may seem like a good idea, but in several years time when the codebase grows and you start adding many more features, it will become difficult to make big changes/additions.

2. Not portable. You wouldn't be able to port it to a different architecture. I know x86 architecture has lived for many years, but sooner or later it will be superseded by something else. Even advances in the same architecture 32-bit x86 to 64-bit x86 require big changes to assembly code.

I'm pretty sure you all know these things, I just don't understand why commit everything to one specific architecture. Operating systems can grow to be very complex and the hardware changes/evolves pretty quickly. Thu, 15 Jul 2010 12:56:00 GMT donotreply@osnews.com (rom508) Comments Use it in VM's http://www.osnews.com/thread?433559 http://www.osnews.com/thread?433559 I could see this or other low footprint OS's used for specialty applications deployed on VM's. Use many VM's, each one with a different application. Thu, 15 Jul 2010 15:44:00 GMT donotreply@osnews.com (Bodger) Comments RE: Message from the author http://www.osnews.com/thread?433560 http://www.osnews.com/thread?433560 Or replace the now dead SkyOS ;) Thu, 15 Jul 2010 15:53:00 GMT donotreply@osnews.com (Shannara) Comments RE: Nifty http://www.osnews.com/thread?433562 http://www.osnews.com/thread?433562 Agree. Nothing innovative about this. Just another underpowered hobby project with no useful goals. Not to say that writing an OS or similar project isn't fun, but it certainly isn't newsworthy. Thu, 15 Jul 2010 15:57:00 GMT donotreply@osnews.com (siride) Comments RE[2]: Welcome home again, OSnews! :) http://www.osnews.com/thread?433564 http://www.osnews.com/thread?433564 If you really come here out of habit you'd know why news has been slow the past month: Thom Holwerda is on a sabbatical for school. David Adams is doing a great job in his absence but as most of the daily news came straight from Thom, there has naturally been a visible effect.

Personally I like the pace of things here now; it reminds me of the old days when Eugenia was at the helm. And, as much as I enjoy Thom's articles and sense of humor, it's been refreshing to see all the different points of view in recent submissions. Thu, 15 Jul 2010 16:32:00 GMT donotreply@osnews.com (Morgan) Comments RE[2]: Nifty http://www.osnews.com/thread?433565 http://www.osnews.com/thread?433565 Wow, mods don't like the truth. Thu, 15 Jul 2010 16:40:00 GMT donotreply@osnews.com (siride) Comments RE: Under 16Kb small? http://www.osnews.com/thread?433568 http://www.osnews.com/thread?433568 The Kernel binary (which includes the kernel itself, the CLI, as well as all of the system calls) is 16KiB. In reality it is actually much smaller as the binary is padded out to 16KiB. The compiled binary without padding is 10576 bytes as of 0.4.8

- Ian Seyler @ Return InfinityEdited 2010-07-15 17:23 UTC Thu, 15 Jul 2010 17:22:00 GMT donotreply@osnews.com (iseyler) Comments RE[3]: Nifty http://www.osnews.com/thread?433577 http://www.osnews.com/thread?433577 Apparently "truth" does not mean what you think it means... Thu, 15 Jul 2010 18:20:00 GMT donotreply@osnews.com (tylerdurden) Comments RE: Nifty http://www.osnews.com/thread?433578 http://www.osnews.com/thread?433578
Well, I've been meaning to poke around with x86-64 assembly anyways...


Don't you mean MOVe around?

(drumroll and apologies). Thu, 15 Jul 2010 18:21:00 GMT donotreply@osnews.com (vivainio) Comments RE: Why x86 assembly? http://www.osnews.com/thread?433579 http://www.osnews.com/thread?433579 It is their project, so they can do whatever they want. If the goal is embedded or high performance applications, it makes sense to make the OS as simple and bare as possible.

Furthermore any of those "insights" you related are common wisdom items which can be derived without having written a single line of assembly code. Also, if you have programmed in assembly you should know that a lot of code such as interrupt servicing is very architecture-specific so it is not really that portable (regardless of whether you write it in a high level language or not). So writing an OS in C, for example, does not make it automatically portable.

Lastly, betting on X86-64 is a very safe bet, as we can make a clear case that such architecture, unlike SPARC, is not going away anytime soon. Thu, 15 Jul 2010 18:34:00 GMT donotreply@osnews.com (tylerdurden) Comments RE[2]: Welcome home again, OSnews! :) http://www.osnews.com/thread?433580 http://www.osnews.com/thread?433580 I have no problems with OSnews posting non-OS articles once in a while. I for one would rather read about interesting non-OS stuff than the latest boring release candidate from SUSE or Ubunthu.

I have found OSnews fair and balanced and intelligent while everyone else are selling their souls way too cheap for ad impressions and vendor cash (Eldar and the Engadget crew, I am looking at you).

So whether its about OS or something else, OSnews does a very good job and I am satisfied.Edited 2010-07-15 18:40 UTC Thu, 15 Jul 2010 18:39:00 GMT donotreply@osnews.com (fatjoe) Comments RE: Message from the author http://www.osnews.com/thread?433587 http://www.osnews.com/thread?433587 Get enough of C that Emacs can be ported to it.
Then any computer since the intro of AMD64 can run a very capable OS. It'll be far huger than the OS (probably take about 16mb, as there'd be no graphics support and a number of other functions stripped), but who cares?
I realise this is no small task, but it's a worthy task, I think.
Emacs is a very capable OS, if you think back to the days when computing was younger, and look at what it can do now. People just expect an OS to do so much more than what makes an OS. The core of Emacs adds a scripting language with regex, text processing, (if available) rudimentary graphics(which are being improved), tiling window management, rudimentary multitasking(you can run multiple processes, but one waits for the next to finish anything it's doing, like an old Mac)...
Seriously, with this and Emacs, I'd be at home. Integrate the compiler/debugger with it and you've got a full development environment.

It's a Herculean task, but it's not as insane as one might think. the C portion's relatively small, and once the lisp interpreter/byte-compiler are available, the rest is just not including features that BareMetal doesn't support(yet). Thu, 15 Jul 2010 19:15:00 GMT donotreply@osnews.com (TheGZeus) Comments RE[2]: Nifty http://www.osnews.com/thread?433590 http://www.osnews.com/thread?433590
Agree. Nothing innovative about this. Just another underpowered hobby project with no useful goals. Not to say that writing an OS or similar project isn't fun, but it certainly isn't newsworthy.


You may be missing the point. It might not be newsworthy on Jon Q. Public's Random Tech Blog, but this is OSNews. This is what we come here for. Thu, 15 Jul 2010 19:27:00 GMT donotreply@osnews.com (Almafeta) Comments RE[3]: Nifty http://www.osnews.com/thread?433591 http://www.osnews.com/thread?433591 I don't think it's even newsworthy here. Thu, 15 Jul 2010 19:29:00 GMT donotreply@osnews.com (siride) Comments RE: Message from the author http://www.osnews.com/thread?433594 http://www.osnews.com/thread?433594 Catching stars with the feet on the ground!!!

That's the way you can make the world turn.

Congratulations! ;) Edited 2010-07-15 19:53 UTC Thu, 15 Jul 2010 19:52:00 GMT donotreply@osnews.com (ebasconp) Comments RE[4]: Nifty http://www.osnews.com/thread?433595 http://www.osnews.com/thread?433595 I do. I can't remember the last time I saw news about a 64bit assembly-based OS. Thu, 15 Jul 2010 20:06:00 GMT donotreply@osnews.com (echo.ranger) Comments RE[2]: Message from the author http://www.osnews.com/thread?433597 http://www.osnews.com/thread?433597

Emacs is a very capable OS, if you think back to the days when computing was younger, and look at what it can do now.


Right, emacs actually got anti-aliasing recently:

http://psung.blogspot.com/2008/03/emacs-in-ubuntu-hardy-now-has-ant...

At this pace, it's prone to become sentient soon. Thu, 15 Jul 2010 20:14:00 GMT donotreply@osnews.com (vivainio) Comments RE: Why x86 assembly? http://www.osnews.com/thread?433598 http://www.osnews.com/thread?433598 BareMetal OS will always be lean and mean. Allowing it to get "large and complex" would defeat our goals. The OS provides just the basics (keyboard input, screen output, disk (and eventually Ethernet) access). BareMetal OS will never replace the OS on your desktop/notebook because that is not what it is being designed for. We want something that gets out of the way when an application is running.

As for portability we don't think the x86 architecture will be replaced any time soon. Also the great thing about x86 is that it is everywhere. While high-level compilers do a good job at compiling code we prefer being in full control of what opcodes the CPU is executing (and in what order). Does GCC or LLVM/Clang optimize for "branchless" code if it can?

- Ian Seyler @ Return Infinity Thu, 15 Jul 2010 20:36:00 GMT donotreply@osnews.com (iseyler) Comments RE: Comment by bloodline http://www.osnews.com/thread?433599 http://www.osnews.com/thread?433599 We haven't tested C++ or Objective-C yet, but I see no reason why it wouldn't work. For compiling C applications we support GCC and LLVM/Clang.

- Ian Seyler @ Return Infinity Thu, 15 Jul 2010 20:39:00 GMT donotreply@osnews.com (iseyler) Comments RE[2]: Under 16Kb small? http://www.osnews.com/thread?433638 http://www.osnews.com/thread?433638
The Kernel binary (which includes the kernel itself, the CLI, as well as all of the system calls) is 16KiB. In reality it is actually much smaller as the binary is padded out to 16KiB. The compiled binary without padding is 10576 bytes as of 0.4.8

- Ian Seyler @ Return Infinity


Reminds me of the days of the Atari ST (1986 and later), when the entire OS fit into 192Kbytes of ROM.

If you were to do a 64-bit BareMetal OS version of the Atari ST TOS/GEM, I wonder if you could STILL do it in that amount of space (or less)! I think it might well be VERY possible... and it would be on a 64-bit computer!

You think the Atari ST was fast for it's day? This type of system would blister the surface of the sun, it'd be so fast! :-D Fri, 16 Jul 2010 02:53:00 GMT donotreply@osnews.com (Luposian) Comments RE[3]: Message from the author http://www.osnews.com/thread?433645 http://www.osnews.com/thread?433645

At this pace, it's prone to become sentient soon.

Heh. It's not very advanced when compared to the systems in which it runs (at least in the flashy parts), it is a pretty impressive achievement when you compare it to DOS or a BASIC prompt. Fri, 16 Jul 2010 05:11:00 GMT donotreply@osnews.com (TheGZeus) Comments RE: Comment by bloodline http://www.osnews.com/thread?433646 http://www.osnews.com/thread?433646

On topic... Any chance of an Obj-C runtime? ;)


Why on earth would one need to support objc on a system like this?

C, C++ and a minimal scripting environment (elua?) would seem to make more sense. Fri, 16 Jul 2010 05:23:00 GMT donotreply@osnews.com (vivainio) Comments RE[3]: Under 16Kb small? http://www.osnews.com/thread?433667 http://www.osnews.com/thread?433667 Good reading about fitting a complete OS, including GUI, in such a small amount of ROM :

http://www.dadhacker.com/blog/?p=995
http://www.dadhacker.com/blog/?p=1000

Kochise Fri, 16 Jul 2010 08:28:00 GMT donotreply@osnews.com (Kochise) Comments Nice http://www.osnews.com/thread?433682 http://www.osnews.com/thread?433682 This really is a step in the right direction for HPC. The overhead of memory management doesn't really make sense for a node that is dedicated to one application. If it dies, the job manager can just reset the node!

I'm wondering if it will be a problem that applications have full control. they can push a lot of pakages to the network, which could be damaging for the rest of the system.

A solution might be to use LLVM byte code, or similar, for applications. Then verify that they only use the network through a controlled interface. The job manager could do this and perform the final compilation. Fri, 16 Jul 2010 11:48:00 GMT donotreply@osnews.com (happe) Comments RE: Use it in VM's http://www.osnews.com/thread?433687 http://www.osnews.com/thread?433687 That's a project someone needs to take up. Lately, I've been wondering why I need the rest of the junk when I only what to run BIND in a VM. Fri, 16 Jul 2010 13:11:00 GMT donotreply@osnews.com (Flatland_Spider) Comments RE[2]: Why x86 assembly? http://www.osnews.com/thread?433688 http://www.osnews.com/thread?433688

As for portability we don't think the x86 architecture will be replaced any time soon. Also the great thing about x86 is that it is everywhere.

And good to see you going for the x86-64 cpu generation. Those extra registers must sure be handy.

While high-level compilers do a good job at compiling code we prefer being in full control of what opcodes the CPU is executing (and in what order).

Heh, I can certainly understand the preference of 'full control' since it's also part of my own nature. That said, compiler optimization has matured alot these past years and although they will never offer the same level of control (and likely not the same level of optimization as that of an assembly guru) I personally find it 'close enough' for the majority of cases. Newer optimization techniques like PGO (profile guided optimization) offers you branch prediction, efficient instruction cache usage, function reordering, loop unrolling etc in an automated way. Again, a great assembly programmer can beat this I'm sure, but it will require a great level of skill and more time. Please don't think I'm putting your efforts down, I admire your willingness and skill to write an os in pure assembly and having programmed alot in x86 assembly during my time I find it very inspirational. Today, most of the places I see assembly code is in BIOS'es, really low level OS stuff and special optimizations such as video encoding/decoding. Seeing it applied on a whole OS project is very impressive.


Does GCC or LLVM/Clang optimize for "branchless" code if it can?

Yes, GCC will transform conditional jumps into branchless equivalents wherever applicable, and I'm certain the same is true for LLVM although I'm too lazy to look it up (hey, it's summer). Fri, 16 Jul 2010 13:37:00 GMT donotreply@osnews.com (Valhalla) Comments RE[2]: Under 16Kb small? http://www.osnews.com/thread?433699 http://www.osnews.com/thread?433699
The Kernel binary (which includes the kernel itself, the CLI, as well as all of the system calls) is 16KiB. In reality it is actually much smaller as the binary is padded out to 16KiB. The compiled binary without padding is 10576 bytes as of 0.4.8

- Ian Seyler @ Return Infinity


That's 8 times bigger than what was written in the article, but I guess typographical errors have to scream to be heard. Fri, 16 Jul 2010 14:55:00 GMT donotreply@osnews.com (bousozoku) Comments OSNews about the OS and what happens on it http://www.osnews.com/thread?433700 http://www.osnews.com/thread?433700 I like OSNews because they talk about applications and generally everything that affects an OS, be it local or remote. Fri, 16 Jul 2010 15:00:00 GMT donotreply@osnews.com (pcunite) Comments Hmm http://www.osnews.com/thread?433734 http://www.osnews.com/thread?433734 BareMetal + WINE = ??? Fri, 16 Jul 2010 20:00:00 GMT donotreply@osnews.com (Wodenhelm) Comments Add secure systems? http://www.osnews.com/thread?433794 http://www.osnews.com/thread?433794 The site suggests BareMetal targets HPC, embedded systems, and education. To that list I suggest adding secure systems. Fri, 16 Jul 2010 23:30:00 GMT donotreply@osnews.com (ThunderBug) Comments RE[2]: Comment by bloodline http://www.osnews.com/thread?433799 http://www.osnews.com/thread?433799 Objective C makes at least as much sense as C++.

A possible reason to support objc would be to write (or port) applications in Objective C. That's all the need you need. Sat, 17 Jul 2010 01:54:00 GMT donotreply@osnews.com (dylansmrjones) Comments RE[3]: Comment by bloodline http://www.osnews.com/thread?433811 http://www.osnews.com/thread?433811
Objective C makes at least as much sense as C++.

A possible reason to support objc would be to write (or port) applications in Objective C. That's all the need you need.


There just isn't any objective c code worth porting, whereas there is a ton of worthwhile c++ code around. Sat, 17 Jul 2010 04:34:00 GMT donotreply@osnews.com (vivainio) Comments RE[2]: Why x86 assembly? http://www.osnews.com/thread?433816 http://www.osnews.com/thread?433816
BareMetal OS will always be lean and mean.
- Ian Seyler @ Return Infinity


But at least multi-threading should be added. Or did I oversee it in the sources ?

Actually, IMHO, something that calls itself an OS today needs to support multitasking and or multi-threading.

Anyway, good to see there are more freaks around doing pure assembly :-) Sat, 17 Jul 2010 05:07:00 GMT donotreply@osnews.com (DeepThought) Comments RE[4]: Comment by bloodline http://www.osnews.com/thread?433822 http://www.osnews.com/thread?433822 I beg to differ. Sat, 17 Jul 2010 06:39:00 GMT donotreply@osnews.com (dylansmrjones) Comments RE[5]: Comment by bloodline http://www.osnews.com/thread?433827 http://www.osnews.com/thread?433827
I beg to differ.


So you know of some portworthy softare written in objc? Is this gnustep or some iFart application? Sat, 17 Jul 2010 07:08:00 GMT donotreply@osnews.com (vivainio) Comments RE[2]: Why x86 assembly? http://www.osnews.com/thread?433847 http://www.osnews.com/thread?433847
While high-level compilers do a good job at compiling code we prefer being in full control of what opcodes the CPU is executing (and in what order).
Good luck controlling the order instructions are executed in... how many years has it been since out-of-order execution was introduced to CPUs? ;)

(yeah, I'm nit-picking). Sat, 17 Jul 2010 13:13:00 GMT donotreply@osnews.com (f0dder) Comments RE: Message from the author http://www.osnews.com/thread?433868 http://www.osnews.com/thread?433868 please don't bother with the ansi C functions such as printf and the rest of that stuff. keep the fresh new calls and make this a modern project not burdened by the ancient crap.

i think a great feature would be to make this project based on UTF-32/UCS-4 unicode.

good luck and thanks for sharing this wonderful work. Sat, 17 Jul 2010 16:38:00 GMT donotreply@osnews.com (boushkash) Comments RE[3]: Why x86 assembly? http://www.osnews.com/thread?433869 http://www.osnews.com/thread?433869
Good luck controlling the order instructions are executed in... how many years has it been since out-of-order execution was introduced to CPUs? ;)

out-of-order execution is no problem for assembler programming. Why should it be ? There are always synchronization points like return from subroutine or memory barriers. Only if you need to be sure some code has been executed before another is started, you have to insert such sync-point by yourself. Sat, 17 Jul 2010 16:59:00 GMT donotreply@osnews.com (DeepThought) Comments RE[2]: Message from the author http://www.osnews.com/thread?433893 http://www.osnews.com/thread?433893
please don't bother with the ansi C functions such as printf and the rest of that stuff. keep the fresh new calls and make this a modern project not burdened by the ancient crap.


What are you saying man?

ANSI C functions are the base of everything... everything ends doing a "malloc", a "free" or a "memmov"...

Because you live in the virtual machine on top of virtual machines era, creating a lot of garbage that needs to be garbage collected, living in a world full of framework and classes, it does not mean that all the "ancient crap" is still feeding such virtual world. Sun, 18 Jul 2010 04:41:00 GMT donotreply@osnews.com (ebasconp) Comments RE[3]: Why x86 assembly? http://www.osnews.com/thread?433905 http://www.osnews.com/thread?433905 Multi-threading is supported but not in the way that other Operating Systems use it.

BareMetal OS uses a Process Queue. An application can throw as many "work loads" as it wants into the Process Queue and any available CPU Cores will begin to work on them.

There is a presentation on the topic here:
BareMetal OS Queue Sun, 18 Jul 2010 08:19:00 GMT donotreply@osnews.com (iseyler) Comments Eh http://www.osnews.com/thread?433932 http://www.osnews.com/thread?433932 Too bloated. Sun, 18 Jul 2010 14:48:00 GMT donotreply@osnews.com (Wodenhelm) Comments RE[4]: Under 16Kb small? http://www.osnews.com/thread?433956 http://www.osnews.com/thread?433956 Thanks for the links. I'm not halfway through the first one yet but I'm loving it. Sun, 18 Jul 2010 21:36:00 GMT donotreply@osnews.com (vodoomoth) Comments RE[3]: Message from the author http://www.osnews.com/thread?433999 http://www.osnews.com/thread?433999 of course u need to have calls to allocate and free memory or do string manipulation but it can be implemented in a different way other than the old runtime-library way. for example, i have written countless programs for WinNT using the native ntdll.dll API for all these functions and i can tell u that it makes a whole lot more sense than the runtime-library. another example is qnx.

C!=RTL

all i am saying is that being bound by these rules such as runtime-library being a must will render your OS a replica of the old ones.

even the names of the RTL functions make zero sense.

good luck with your efforts. Mon, 19 Jul 2010 14:02:00 GMT donotreply@osnews.com (boushkash) Comments RE[2]: Under 16Kb small? http://www.osnews.com/thread?434005 http://www.osnews.com/thread?434005 I hereby give you permission to increase the OS size UP TO 1 MB. Anything above that and we will have to take a vote. Mon, 19 Jul 2010 15:21:00 GMT donotreply@osnews.com (AndrewZ) Comments