Planning on writing operating system in Objective-C [closed]

Closed. This question needs to be more focused. It is not currently accepting answers. 开发者_运维知识库

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

At the moment I'm learning objective c 2.0, and soon I plan on learning assembly language, so I can write an operating system. I know it won't be easy, and I know it will take months, perhaps years, of time and patience. However, I plan on writing most of it in Objective-C(excluding the stuff you have to write in assembly), because not only do I know objective-c better than I know C (I barely know any C), but I, personally, also like objective-c a lot better. Is this possible?? If not, how much C do I need to know? Should I get a great understanding of C through a book? or just learn the basics online?

---

If not, how much C do I need to know?

All of it. Objective-C is C and then some, so you really can't claim to know Objective-C until you know C.

---

It's possible...

The greatest problem you'll have is the runtime.

Assembly is needed for an OS, that's right. Bootloaders, HAL, GDT, etc...

Then you can use another programming language.

C is good, because it doesn't need a runtime, so you can code straight on.

Objective-C relies on a huge runtime, for message passing, polymorphism, etc...

Writing an OS in C++ would be easier, IMHO, because the runtime is not as important as it is in Objective-C...

That said, it's possible...

I wrote myself a little OS using C, and, as an Objective-C lover, I'd also like to use Objective-C... It's OpenSource, BTW, if you want to take a look: http://www.eosgarden.com/en/opensource/xeos/

But remember that Objective-C is based on C. It means you'll have to code a Standard C Library, before writing the Objective-C code, because it just rely on it. That's a hard stuff, even if possible...

It means you'll have to code stdlib, stdio, etc...

You can also try to port existing Standard C libraries. Then you might take a look at GNUStep, if you don't want to recode all the Objective-C stuff...

Good luck : )

---

Well I have some similar plans too so maybe cooperate? I'd like to open source my project so if you are willing to as well...

This is a big project. My best suggestion is to stick with OS X or Linux with GNUstep. But if you insist, I do have a plan, a microkernel:

• The entire thing is built with clang/LLVM, enabling ARC whenever I can.

• Kernel itself is minimal. Its sole purpose is to load kexts that will make it work. Some functionalities are built into the kernel:

  • ELF binaries support. No dynamic linking yet.

  • "Filesystem" driver for GNU tar. This is adequate for a reasonable ramdisk.

  • A partial libc (syscalls) and libobjc2 that is adequate for running Objective-C with ARC and some reflection that is required for loading kexts. No other fancy feature will be built in yet.

  • A partial Foundation that will allow loading of NSBundles by path and load their classes and kernel command-line processing.

  • All kernel-provided functionalities will be reimplemented in userland.

• Early kexts (ones in the ramdisk) including filesystem driver and terminal driver.

• After the FS and terminal kext is loaded, kernel will proceed and mount root FS and loadkexts from there, including:

  • Remaining parts of Foundation, libobjc2 and libc. syscalls are implemented by Distributed Objects over sockets.

  • POSIX syscalls.

  • Multithreading and scheduler (based on the interface of libdispatch, or GCD if you prefer)

  • Hardware abstract layer that will enumerate all devices with minimal loadable drivers and expose them as low-latency device nodes. (This is microkernel that expose HW access to userland - daemons are new drivers.)

And in the userland:

• Userland libc (that calls syscalls exposed through kernel Distributed Objects interface)

• a full userland GNUstep

• A dynamic linker that will work with ELF in Apple fashion (e.g. respect frameworks, library injection and more)

• launchd, who want's sysvinit?

Any further ideas?

---

You can minimize the amount of assembly code needed for simple operating systems by using GRUB's multiboot environment. GRUB can bring the CPU up into 32-bit protected mode (or 64-bit mode on newer chips :) for you, and drop control to your kernel's code easily.

If your Objective C toolchain can prepare ELF objects, then Objective C ought to be possible for a kernel, though you may need to provide some of the 'free' services yourself. (For example, the C standard specifies that free() is used to allocate memory, but allocating memory inside the kernel cannot just use standard libraries -- so the kernel must provide its own memory allocation routines.)

Of course, at some point, you'll need to use assembly to write the tools you'll use for spinlocks, mutexes, page table mappings, PCI bus configuration, and so forth, but hopefully by then you'll have learned plenty on simpler operating system designs.

---

Take a look at Julien Le Comte's blog. He started writing Simplix to "brush up his core CS skills". http://www.julienlecomte.net/blog/category/system-programming/