a Python based OS

[Chandra]

Just to make some people here, happy....

(Where python may be replaced with any higher level language.)

Or may be assembly?

[Combuster]

There's a big difference: if you can't do an assembly OS on your own you have other people's code to steal.

[guyfawkes]

There's a big difference: if you can't do an assembly OS on your own you have other people's code to steal.

ASM OS's are not very easy to steal, they are like a tower of playing cards.
Trying to glue bits of different ASM OS's needs a very good understanding of assembly, which defeats the point.

If your talking about riping a whole OS and just changing the name, then i agree.

[NickJohnson]

If you're not that dead-set on Python as an interpreted language, and instead just want something dynamic, Lua might make a better target for this. Its runtime is very small and a piece of cake to port (it only uses a subset of ANSI C.) It also interfaces with C very cleanly, and if you use LuaJIT, can run nearly as fast as C under good conditions. The virtual machine stores its state in an external structure, so it's thread-safe (unlike Python), and can be separated from the interpreter to make the runtime even lighter. I've already ported it, and plan to use it extensively in my userland, although not in my kernel.

[Rusky]

+1 to Lua.

It's awesome to work with, and extremely easy to extend with C or itself.

[arming]

It's more difficult that I have expected . After reading your advices, I think that I'm going to continue the mini-kernel in C .

Thanks!

Why not?

Because you're asking stupid questions here, that's why. Just do it.

How to create a webpage?

It's a stupid question. Just do it.

[arming]

You've just earned a position in ignore list. Congratulations!

Thanks!

[ishkabible]

I was thinking Lua this whole time too then someone finely said it. anyway, you actually have to port LuaJIT to use the correct allocation functions for your OS. for instance, on windows to properly JIT compile you have to use VirtualAlloc and VirtualFree; malloc and free have no guarantee of being executable(although with MinGW it seems to work). that is hardly a big deal though as your only talking about 2, maybe 3, functions plus the ANSI run-time library. still, it seems like a bad idea as you would restrict your OS quite a bit. have you thought about just making python for the shell?