OSDev.org

hello again .
i have a question about Os development again .
as far as i know , we develop an OS for a Specific Platform ( special kind of CPU? ) right?
is there the possibility to make an Os which could be used on different platforms ?
im kinda puzzled with the "platform" thing , what exactly a platform is , i mean by platform what exactly do we mean? a special CPU family ? ( like X86- or Arm cpus used in handhelds ?) or what?
I've read that Windows 8 is going to be some kind of portable ! and for that Microsoft removed .net framework and had major changes in the OS structure to achieve such a goal.( they did it so that windows could run on the vast number of hardwares ! )
i just need some explanation on these terms and answer to the question above and find out if we can step on that direction too and have portability in mind while developing the OS.
Thanks in advance

Coderx wrote:is there the possibility to make an Os which could be used on different platforms ?

In any OS, there are parts that are specific to certain aspects of the platform. Easiest example is how the MMU handles the memory (size of pages, organization of page tables and page directories, available flags and their meaning etc. etc.).

A non-portable OS, in this regard, has the memory handling hardcoded, with assumptions (e.g. "magic numbers") spread all over the code base. If you want to port such an OS to a different architecture, you are facing sweeping changes all over the project, and you'd end up with a fork, not one OS running on two platforms.

A portable OS would isolate all MMU-related stuff in a single module, which abstracts the details of the MMU and instead provides some functions and constants for the rest of the code to use. If you want to support a new platform with a different MMU architecture, all you have to port is that single abstraction module, the rest stays the same. (Of course, you'd have to repeat this porting for several other platform abstractions.)

Those abstractions should be close-fitting enough to not become a performance bottleneck, yet loose enough to enable porting to other architectures. That is the difficult part about writing a "portable" OS: You should know as many potential target platforms as possible, as intimately as possible, so you can come up with good abstractions (instead of repeatedly having to redesign them).

To return to your original question, yes, it is possible to make an OS that could be used on different platforms. Given enough effort, it is even possible to retroactively make a system portable in this way, but it's one hell of a trip.

Best example is Linux. Originally designed as an i386-only "free Minix", today it works on x86, PPC, ARM, and several other architectures. (Mind you, NetBSD works on even more. )

I think it would take you 5 minutes to find the answer using something called a search engine.

The most popular is probably Google. The address is http://www.google.com/

Solar wrote:

Coderx wrote:is there the possibility to make an Os which could be used on different platforms ?

In any OS, there are parts that are specific to certain aspects of the platform. Easiest example is how the MMU handles the memory (size of pages, organization of page tables and page directories, available flags and their meaning etc. etc.).

A non-portable OS, in this regard, has the memory handling hardcoded, with assumptions (e.g. "magic numbers") spread all over the code base. If you want to port such an OS to a different architecture, you are facing sweeping changes all over the project, and you'd end up with a fork, not one OS running on two platforms.

A portable OS would isolate all MMU-related stuff in a single module, which abstracts the details of the MMU and instead provides some functions and constants for the rest of the code to use. If you want to support a new platform with a different MMU architecture, all you have to port is that single abstraction module, the rest stays the same. (Of course, you'd have to repeat this porting for several other platform abstractions.)

Those abstractions should be close-fitting enough to not become a performance bottleneck, yet loose enough to enable porting to other architectures. That is the difficult part about writing a "portable" OS: You should know as many potential target platforms as possible, as intimately as possible, so you can come up with good abstractions (instead of repeatedly having to redesign them).

To return to your original question, yes, it is possible to make an OS that could be used on different platforms. Given enough effort, it is even possible to retroactively make a system portable in this way, but it's one hell of a trip.

Best example is Linux. Originally designed as an i386-only "free Minix", today it works on x86, PPC, ARM, and several other architectures. (Mind you, NetBSD works on even more. )

Thank you very very much
by the way , is there any kind of architecture to start making our own Os based on it ? is it even a good idea to start with such motive ?

by the way , is there any kind of architecture to start making our own Os based on it ?

Jezze wrote:I think it would take you 5 minutes to find the answer using something called a search engine.

+1
Actually, it turned out to be two minutes to find a relevant read: http://forum.osdev.org/viewtopic.php?f=1&t=24372

Nevertheless, you should start taking care not to ask questions because you can. It will only demonstrate to us that you aren't capable enough of doing the minimal research needed to survive in this hobby.

Solar wrote:A non-portable OS, in this regard, has the memory handling hardcoded, with assumptions (e.g. "magic numbers") spread all over the code base. If you want to port such an OS to a different architecture, you are facing sweeping changes all over the project, and you'd end up with a fork, not one OS running on two platforms.

Not necesarily. It could be coded in assembly as well, which makes it impossible to port. It could also be a design issue not to clutter code with endian issues (I know I have not coded endian issues in any of my professional projects, because I don't anticipate them to run on a big endian CPU). Additionally, I might not want to clutter my project with custom basic types just to support any compiler and word-size combination.

rdos wrote:It could be coded in assembly as well, which makes it impossible to port.

I always stumble over a too-high bar of common sense which I am assuming in the people I talk to.

Of course an all-ASM OS is the epitome of non-portability.

Additionally, I might not want to clutter my project with custom basic types just to support any compiler and word-size combination.

<stdint.h>.

Solar wrote:

Additionally, I might not want to clutter my project with custom basic types just to support any compiler and word-size combination.

<stdint.h>.

Why would that help? I want to use char, char *, int, long and long long, not LPSTR, LPVOID, int16, or other strange things. And I don't want to include anything when I use only basic types.

I think we have learnt by now not even to bother looking for common sense in rdos. Especially since it's painfully obvious he didn't even bother to figure out what stdint.h is. (and I'm sure he'll go off topic even further to disprove that now)

Coderx wrote:hello again .
i have a question about Os development again .
as far as i know , we develop an OS for a Specific Platform ( special kind of CPU? ) right?
is there the possibility to make an Os which could be used on different platforms ?
im kinda puzzled with the "platform" thing , what exactly a platform is , i mean by platform what exactly do we mean? a special CPU family ? ( like X86- or Arm cpus used in handhelds ?) or what?
I've read that Windows 8 is going to be some kind of portable ! and for that Microsoft removed .net framework and had major changes in the OS structure to achieve such a goal.( they did it so that windows could run on the vast number of hardwares ! )
i just need some explanation on these terms and answer to the question above and find out if we can step on that direction too and have portability in mind while developing the OS.
Thanks in advance

Platform means the specific architecture of the hardware the operating system is going to run on. Some parts of the operating system are inevitably hardware dependent because the OS has to control the hardware. You can try to make an OS reasonably portable by keeping all the hardware dependent stuff together in one place, so that it can be rewritten for each design of hardware the operating system is going to run on.

<stdint.h> is not <winbase.h> or another windows header. It defines unsigned and signed two's complement integral types, as well as an integral type capable of holding a pointer. Unlike the mess that is the windows typedefs, the naming scheme is relatively consistent and obvious. You can still use char, char*, void*, int and others if you want to as char* is a standard way of representing a string and void* just represents any pointer. However, it is useful when you need a data type of a certain size that will be the same on all (or most) architectures.
It would be almost necessary in a portable OS, as there are many times you want data of a specific size, and relying on int being 32-bits and short being 16-bits is not going to get you everywhere.

Tosi wrote:<stdint.h> is not <winbase.h> or another windows header. It defines unsigned and signed two's complement integral types, as well as an integral type capable of holding a pointer. Unlike the mess that is the windows typedefs, the naming scheme is relatively consistent and obvious. You can still use char, char*, void*, int and others if you want to as char* is a standard way of representing a string and void* just represents any pointer. However, it is useful when you need a data type of a certain size that will be the same on all (or most) architectures.
It would be almost necessary in a portable OS, as there are many times you want data of a specific size, and relying on int being 32-bits and short being 16-bits is not going to get you everywhere.

I looked up the file in Open Watcom, and it actually does define fixed-width integers.

Solar wrote:

rdos wrote:It could be coded in assembly as well, which makes it impossible to port.

I always stumble over a too-high bar of common sense which I am assuming in the people I talk to.

Of course an all-ASM OS is the epitome of non-portability.

This is not true.
Lets take a OS coded in fasm using it's macro, it would be easy to port to ARM using FasmArm.

Example here:
http://board.flatassembler.net/topic.php?t=7961

Not really assembly anymore then, is it?

Hi,

Rusky wrote:

guyfawkes wrote:

Solar wrote:Of course an all-ASM OS is the epitome of non-portability.

This is not true.
Lets take a OS coded in fasm using it's macro, it would be easy to port to ARM using FasmArm.

Example here:
http://board.flatassembler.net/topic.php?t=7961

Not really assembly anymore then, is it?

It's "using the assembler's pre-processor to construct an entirely new/different language that isn't assembly at all", which I'd expect to lead to crappy executable code because the underlying assembler won't do any optimisation whatsoever.


Cheers,

Brendan