Thursday, December 13, 2007
Prima Needs a Target
I've been giving considerable thought to the design of Prima. There are a few design aspects that need to be considered such as processes and threads, memory management, and other details critical to an operating system before you can begin coding. While it may be fun, I want to begin testing some of the ideas I have with respect to these topics.
Adding Functionality
It makes sense to set a target in order to test these new designs. While I'm not ready to make a formal release, I do think it is prudent to set a short term target that can readily be handled as a small project. The definition of this new release is simple: it will be a new proof of concept release with a specific capability to run a single binary. I want to keep it simple so I won't select a specific file format because I am still undecided as to the final goal. I would like to use FreeDOS as a platform for development and djgpp is the best choice for that. In that case, the djgpp coff format would make a good choice. If I decide to support win32 in any way, then PE make sense. Of course, there's always elf with its large base of support in the open source community. So for now, it will be a simple stripped binary image, somewhat of a 32-bit "com" file. This is great, but not something I want to keep for the future.
The Project
I now have the beginning of a project: a defined, measurable target. I still need to do more planning, but this is a small project whose goal is to achieve a step to the final goal of a stand alone operating system. As strange as this may seem, this is my preferred way to handle roadmaps. I like to create individual projects that meet each of the roadmap targets and "phases" that create small, achievable steps along the path to the final goal. This is one of those phases. While the roadmap may not be clearly defined, I know one target and this is one of those phases. I need to have in place processes and their relationships to threads and regions. This is how I will do it.
Acknowledgement
I do want to thank Christopher Giese who runs a web site with lots of handy little snippets of code. You can find it at http://my.execpc.com/~geezer/osd/index.htm and it's worth taking a look at. I've borrowed a couple of his code snippets, such as the interrupt handling, but I have adapted the concepts to fit my generic design. For example, I have my own getvect() and setvect() functions modeled after the DOS versions. I also have newer functions that eliminate the passing of the flags. Also, while Chris looks at tasks, my design is thread based, an update of the original task based design from earlier multitasking operating systems I developed.
If you want a good reference to start your own OS coding, I definitely recommend spending some time at this site.
Adding Functionality
It makes sense to set a target in order to test these new designs. While I'm not ready to make a formal release, I do think it is prudent to set a short term target that can readily be handled as a small project. The definition of this new release is simple: it will be a new proof of concept release with a specific capability to run a single binary. I want to keep it simple so I won't select a specific file format because I am still undecided as to the final goal. I would like to use FreeDOS as a platform for development and djgpp is the best choice for that. In that case, the djgpp coff format would make a good choice. If I decide to support win32 in any way, then PE make sense. Of course, there's always elf with its large base of support in the open source community. So for now, it will be a simple stripped binary image, somewhat of a 32-bit "com" file. This is great, but not something I want to keep for the future.
The Project
I now have the beginning of a project: a defined, measurable target. I still need to do more planning, but this is a small project whose goal is to achieve a step to the final goal of a stand alone operating system. As strange as this may seem, this is my preferred way to handle roadmaps. I like to create individual projects that meet each of the roadmap targets and "phases" that create small, achievable steps along the path to the final goal. This is one of those phases. While the roadmap may not be clearly defined, I know one target and this is one of those phases. I need to have in place processes and their relationships to threads and regions. This is how I will do it.
Acknowledgement
I do want to thank Christopher Giese who runs a web site with lots of handy little snippets of code. You can find it at http://my.execpc.com/~geezer/osd/index.htm and it's worth taking a look at. I've borrowed a couple of his code snippets, such as the interrupt handling, but I have adapted the concepts to fit my generic design. For example, I have my own getvect() and setvect() functions modeled after the DOS versions. I also have newer functions that eliminate the passing of the flags. Also, while Chris looks at tasks, my design is thread based, an update of the original task based design from earlier multitasking operating systems I developed.
If you want a good reference to start your own OS coding, I definitely recommend spending some time at this site.
Subscribe to Posts [Atom]
Copyright Pasquale J. Villani