OSDev.org

berkus wrote:You've got it @$$-backwards. Take ProjectEuler.net for example and implement the solutions in C, that will give you much better learning experience. Or TopCoder.com, or ai-contest.com, really, just anything but OSdev.

oh? Ill take a look when i get home

Can somebody direct me to a linker that works with vista and give me a brief tutorial on how to use it? i am having trouble at this point.... ?_?

Congratulations You've just failed a section of the required knowledge (toolchain knowledge) and violated the forum rules (rule one, possibly rule three).

The answer you're after (even if you think it's not, it is) is to install the Cygwin environment and use the GCC/Binutils compiler set in a cross-compiler configuration. Installing Cygwin should be fairly self-explanatory. Help on building and using a cross-compiler can be found in our wiki.

rofl... oops. xD

Maybe i should give osdev a miss for now, and just focus on learning more regular programming. You see, im kinda a supporter of the instantaneous way of learning things, learn on the way style...

not the best in this situation, so ima juts stick around for the lols and slowly pick it up while i learn other things from just reading other threads and the ocasioanl visit to the wiki :-]

thx JackScott!

You should choose the language which you're best at, though a lot of language's don't support os dev.
And linking C with ASM (you cant escape that) is much much easier than linking it with something like pascal.
But a good way to escape the linking issues and making an cross-compiler is just using ASM.

Maakera,

maakera wrote:And linking C with ASM (you cant escape that) is much much easier than linking it with something like pascal.

Not really. Linking Pascal code works about the same as linking C code.

But a good way to escape the linking issues and making an cross-compiler is just using ASM.

Or not writing an OS at all. The result will be similar.

DJAlexem wrote:hmm, these are really good, thank you adam

But i come across another problem D: ...

I can't find a windows version of qemu, just linux ones, i also cant find a way of compiling C files into O files, eg:

kernel.c --> kernel.o

I got a compiler for .asm to .o, so no worries there.

You can use a normal Windows compiler to produce .obj files, and then use the free linker jwlink to link them into elf or any other format you want. During the early stages of development you will probably need to compile some assembly code into flat binary, and you can use jwasm for that, without a linker having to be involved. C is commonly referred to as a middle level language because it is more low level than something like Basic, but more high level than assembly language.

When it comes to learning C I think you can do worse than Kernighan and Ritchie's "The C Programming Language." That is how I learned C many years ago, after some failed attempts with other books. Don't, however, think that writing an operating system is the way to learn a language, because that is nobody's first project. Become very familiar with the languages you will be using first.

Casm wrote:You can use a normal Windows compiler to produce .obj files, and then use the free linker jwlink to link them into elf or any other format you want.

*sigh*

GCC Cross-Compiler
Bare Bones

or more generally....

The Wiki (also prominently linked at the top of each forum page, reading "Search this first!").

I would absolutely not start-out with a GCC-based crosscompiler if I restarted an OS-project today. The whole idea about making an OS is to make everything that boots-up your PC yourself. When you base your design on an existing GCC compiler, and it's runtime library, you have a solution that is only partly your own. That can be compared with doing device-drivers on top of Windoze, or building your own Linux-kernel / distribution. It would not be yours only.

Also given that the chances that your OS-project will be the next Linux are infinitely small, that will not serve as a good motivation for doing it.

I would start with only assembler, and do all the required stuff like boot-loader for a real machine. Then I'd achieved something that can boot-up all on its own. Only after that would I consider somebody elses work, like using a C compiler / library, porting device-drivers and even whole applications.

To learn low-level programming with a C-compiler is also pretty stupid as most ordinary C-programmers has no idea what happens behind the scenes. They see some library functions but has no idea how it works.

The whole idea about making an OS is to make everything that boots-up your PC yourself. When you base your design on an existing GCC compiler, and it's runtime library, you have a solution that is only partly your own.

Only very few people are enlightened (or more likely, stupid) enough to consider including GCC in the actual bootstrap .
Other than that GCC is not a OS design choice, and everybody should be using a crosscompiler for good practice so that you have no runtime at all you can actually depend on. In other words, that argument is utter nonsense.

The forum rules essentially say that you must program in a language that has no secrets for you, and that you should know sufficient C and Assembly to read other people's code. It no way says that C or assembly must be the language choice for an OS.

Combuster wrote:Only very few people are enlightened (or more likely, stupid) enough to consider including GCC in the actual bootstrap .

Combuster wrote:Other than that GCC is not a OS design choice, and everybody should be using a crosscompiler for good practice so that you have no runtime at all you can actually depend on. In other words, that argument is utter nonsense.

It is not, since a C compiler (frequently a GCC-cross-compiler), is translating your code to something that you have no idea about. The usual reason for using C for OSes is for portability-reasons, but unless you write the next Linux system, that is of no interest. Most people will do OSes for x86 PC, and will never try them on any other platform.

Besides, all C compilers I know of (admittedly only BCC, M$ and OpenWatcom) at a minimum has a startup-stub which is in the runtime-library. You ALWAYS must link this stub with your C code. So having images without a runtime-library is impossible, at least for the above listed environments. Incidently, this is the very reason why I had to create a CLIB for OpenWatcom for my C/C++ device-drivers to work. The compiler cannot work without at least minimal support from a runtime library.

rdos wrote:Besides, all C compilers I know of (admittedly only BCC, M$ and OpenWatcom) at a minimum has a startup-stub which is in the runtime-library. You ALWAYS must link this stub with your C code. So having images without a runtime-library is impossible, at least for the above listed environments. Incidently, this is the very reason why I had to create a CLIB for OpenWatcom for my C/C++ device-drivers to work. The compiler cannot work without at least minimal support from a runtime library.

Of course. But with a GCC cross-compiler, you get to supply/choose the startup stub, runtime, EXE format, alignment, padding bytes, exception handling, load address, etc. Your argument does not apply to a GCC cross-compiler and in fact is the same argument we use for using a GCC cross-compiler.

If someone chooses to write an OS in assembler, that's fine. What I say though is that if someone chooses to write an operating system in C then he should choose to use a GCC cross-compiler.

Also, I didn't choose to develop in C because of portability. I chose it for maintainability.

rdos wrote:Besides, all C compilers I know of (admittedly only BCC, M$ and OpenWatcom) at a minimum has a startup-stub which is in the runtime-library. You ALWAYS must link this stub with your C code.

I don't know about BCC, M$ and OpenWatcom, but GCC has several options for not doing this (-nostartfiles, -nodefaultlibs, -nostdlib, -fno-builtin). Yes, you can make GCC output only exactly what you wrote into the binary.

And as gerryg400 said, using C isn't necessarily about portability, but maintainability. (And development efficiency, available help and examples, plus a number of other reasons.) No professional will ever recommend writing a project this size completely in assembler.

And after all these years, I have still to see a thread where someone asks the compiler question, gets pointed to the Wiki (our variant of a "FAQ"), and no-one comes up with "you don't need a cross-compiler" or "you should write your own bootsector" or "just write it all in assembler".

A runtime? there is the libgcc stub for gcc, but sorry, that is not a requirement.. a once you start running into situations where it's useful, at least some of the functions are easy enough to write yourself or borrow from elsewhere (..like the quad functions in BSD's libc).

So you can write C without any runtime for most compilers, and in kernel space, you can even get by with only a small subset of libc.

In a hosted environment, the crt0 is just startup glue that calls main, it can be very small.

Why must you insist on spreading misinformation?

Brynet-Inc wrote:A runtime? there is the libgcc stub for gcc, but sorry, that is not a requirement.. a once you start running into situations where it's useful, at least some of the functions are easy enough to write yourself or borrow from elsewhere (..like the quad functions in BSD's libc).

If the stub is not a requirement, then it must be built into the compiler itself. There are builtin things in OpenWatcom (for instance, intrinsic functions), but those are not memory-model or environment independent. As soon as you go just a little outside of scope of what a *application* creation tool (for instance, GCC) ordinary does, you will get into problems.

Brynet-Inc wrote:So you can write C without any runtime for most compilers, and in kernel space, you can even get by with only a small subset of libc.

In a hosted environment, the crt0 is just startup glue that calls main, it can be very small.

I think you are the one providing misinformation now. Part of the tasks of the startup is to initialize "rtns". These are different types of initializers. The startup also must setup a stack and a call-frame.