POSTING RULES - REQUIRED READING - FAQ

[Combuster]

To all the newcomers to this forum:

Prerequisites
OS Development is one of the most difficult aspects of programming. Without the needed skills, you will not make it. If you don't meet the Prerequisites, we recommend that you gather the needed experience in different subjects first. We are not here to babysit people who are unable to program decently.

Frequently asked questions
Many questions have been asked, and many have been answered already. Everything to get you started is available in the wiki. A list of frequently asked questions can be found on the FAQ page. Furthermore, you should download the manuals for the platform you want to develop on. For the PC, that means you should get the software development manuals from Intel or AMD and read them through. If you don't understand them, read again.

How not to make a fool of yourself
We can see from your style of questioning how hard you have tried to solve the problem. Do read the essay on how to ask questions the smart way, and the related notes on the wiki. Offences will result in flames, STFWs, RTFMs and other noob-related insults.

I wish you all good luck with your endeavours.

[piranha]

I also suggest making your titles of your posts so they tell us whats going on and what you want to know.

Something like GETTING STARTED!?!!!?!!! is going to get you flamed.

Never Ever type your entire post in IM slang.

Don't offend people.

Be willing to share your opinion, but listen to others and do research before you blankly say they're wrong.

-JL

[pcmattman]

Before you even think about OS development, make sure you understand C and have worked on at least 1 large-scale project in the language before.

You should also understand how to use a command line. If using Windows, you should know how to modify your PATH (if using DJGPP) or get some experience with Cygwin.

Write some "hello world!" programs and invoke the compiler on them via the command line (preferably GCC). Learn about linker scripts and what they do.

Read How_To_Ask_Questions first. Actually, read all the getting started topics in the wiki and then ask your questions.

[inflater]

Before you even think about OS development, make sure you understand C

This isn't required. Even with BASIC and some knowledge of assembly you can make a 32-bit OS, don't forget FreeBASIC

//EDIT: The quote got messed up somehow, before making this thread as sticky, it was quoted correctly, so I've fixed it.

Regards
inflater

[Combuster]

This isn't required. Even with BASIC and some knowledge of assembly you can make a 32-bit OS, don't forget FreeBASIC

what isn't required?
1. C knowledge? Everything you find is either in c or assembly, and OSDeving in higher languages like FreeBasic requires a mindset you do not get from normal programming.
2. Experience with larger projects? obviously this holds as good for basic as it does for C. If you can't design and manage your code properly, you'll be doomed even before you started.
3. command line experience? Freebasic is command line oriented.
The similar line of reasoning can be applied to Pascal, Java and any other language you want to try.

[inflater]

Also, to be said: Know your host OS from A to Z before doing a new one !

3. command line experience?

Of course, I fully agree with this. I do have the full knowledge about DOS prompt syntax, look, and commands, basic, and extended thingies. But I can't say the same about bash in *nix though
I wonder why I have the "open DOS command window here" at the main directory/file submenu in WinXP Some things are more easily done at the command prompt, unlike the GUI... That's why I do not like Vista as it doesn't have the DOS subsystem (no more posts about this OS please )

Regards
inflater

[AndrewAPrice]

That's why I do not like Vista as it doesn't have the DOS subsystem

MS is trying to _very_ gradually faze out the old cmd in favour for Windows PowerShell (a scriptable .NET command line environment). It is one of the most powerful shells I've come across. You can directly interact with any .NET dll which means you could, theoretically, have a PowerShell script that could render something on screen with DirectX, or act as a miniature web server using System.Net.

[Alboin]

That's why I do not like Vista as it doesn't have the DOS subsystem

MS is trying to _very_ gradually faze out the old cmd in favour for Windows PowerShell (a scriptable .NET command line environment).

It's always interesting to me how as Windows gets more and more 'advanced', it seems to simply incorporate more and more features that have been in *nix for ~30 years.

[AndrewAPrice]

That's why I do not like Vista as it doesn't have the DOS subsystem

MS is trying to _very_ gradually faze out the old cmd in favour for Windows PowerShell (a scriptable .NET command line environment).

It's always interesting to me how as Windows gets more and more 'advanced', it seems to simply incorporate more and more features that have been in *nix for ~30 years.

It's separated from most Unix shells since their pipelines are based around text. PowerShell works around the principle of passing around .NET object (which can be converted to text for output)

[Alboin]

PowerShell works around the principle of passing around .NET object (which can be converted to text for output)

Yes, but if we consider a .NET object to simply be a piece of executable code, how is it any different from a normal *nix shell using programs like cat and grep? It's just syntactic sugar.

[Colonel Kernel]

Yes, but if we consider a .NET object to simply be a piece of executable code,

An object is code + data, not just code.

how is it any different from a normal *nix shell using programs like cat and grep? It's just syntactic sugar.

No, it's not. The difference is that *nix commands pass unstructured text between each other. if I do "nm foo.so | grep main", grep is just getting a stream of text that it has to parse. In PowerShell, commands pass structured data around instead of text, so it's more like composing sub-programs in a higher-level programming language than just doing text processing over and over again.

[Alboin]

No, it's not. The difference is that *nix commands pass unstructured text between each other. if I do "nm foo.so | grep main", grep is just getting a stream of text that it has to parse. In PowerShell, commands pass structured data around instead of text, so it's more like composing sub-programs in a higher-level programming language than just doing text processing over and over again.

But it's so similar. The only difference is that it passes objects. That's why I called it syntactic sugar. It's just makes everything cleaner to write; there's still no new ideas. The thing to change would be the idea of pipes, not their format.

[Colonel Kernel]

But it's so similar. The only difference is that it passes objects. That's why I called it syntactic sugar.

Ok, let me spell it out for you. Let's say you write a *nix command (program or script) that dumps out a table of information in comma-separated values. I'll use a really dumb example: firstname,lastname,phonenumber. If you want to write another *nix command that processes that table of information somehow. Your new command will have to do text parsing. The data is unstructured -- it has no schema. Yes it is flexible, but parsing is a pain in the butt.

If you do the same thing in PowerShell, you can define a type that includes fields for firstname, lastname, and phonenumber. Your first command can create instances of this type, and your second program will simply receive them and use them, no parsing required.

It's just makes everything cleaner to write; there's still no new ideas.

I've never heard of an objected-oriented shell before PowerShell. Have you? Besides, isn't making things cleaner to write the whole point? This isn't about satisfying your personal sense of aesthetics...

The thing to change would be the idea of pipes, not their format.

Why? Pipes are *nixes gift to the world!

[Alboin]

But it's so similar. The only difference is that it passes objects. That's why I called it syntactic sugar.

Ok, let me spell it out for you. Let's say you write a *nix command (program or script) that dumps out a table of information in comma-separated values. I'll use a really dumb example: firstname,lastname,phonenumber. If you want to write another *nix command that processes that table of information somehow. Your new command will have to do text parsing. The data is unstructured -- it has no schema. Yes it is flexible, but parsing is a pain in the butt.

If you do the same thing in PowerShell, you can define a type that includes fields for firstname, lastname, and phonenumber. Your first command can create instances of this type, and your second program will simply receive them and use them, no parsing required.

I kind of got that the first three times...

I've never heard of an objected-oriented shell before PowerShell. Have you?

This is from 1987. The only problem is that I can't tell if it really has any relation to what we're talking about or not...

[dengll23]

My English is not very good, but I will study hard !

PS: This is my first reply