I have tried to search several sites on this subject, and I found no answers (gamedev was having a bad day). I would like someone to point me to a tutorial that explains what an OS needs to do to run without something like DOS or windows in the background. I came up with a neat idea for an OS and I want to try to make it. Thanks. --------------------

You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming
You are unique. Just like everybody else.
"Mechanical engineers design weapons; civil engineers design targets."
"Sensitivity is adjustable, so you can set it to detect elephants and other small creatures." -- Product Description for a vibration sensor

Yanroy@usa.com

You could do a search for operating system design, or some other search. I''ve found several sites before that give code to boot the computer into a basic "hello world" type os. These don''t require dos or windows that I know of. There is also a unix clone called minix that you can buy a book of, or visit this website:
http://www.cs.vu.nl/~ast/minix.html

This is the os that got Linux started when Linus Torvalds wanted to alter minix beyond what the designer of minix wanted.

*Martee whips out his stash of OS development links*
http://alexfru.chat.ru/epm.html
http://www.osdev.org/
http://www.execpc.com/~geezer/osd/ (Very good!)
http://nondot.org/sabre/os/
http://www.thesky.demon.co.uk/os-development/index.html
http://www.acm.uiuc.edu/sigops/roll_your_own/






~~~~~~~~~~
Martee
http://www.csc.uvic.ca/~mdill

Woah...there''s a bug...I replied, and it didn''t go to the top.
???

~~~~~~~~~~
Martee
http://www.csc.uvic.ca/~mdill

My little collection of links on the subject:

OS Dev and Programming

SigOps

OS Development homepage

OS Development

OS Tuts

AtheOS Homepage (Very cool little OS!!)


And if you''re really serious about OS development, I''d recommend grabbing this book: MMURTL

Have fun!!

theres also a good book you can buy that talks about all the various aspects of os theory. its pretty interesting stuff that goes into the various levels of components needed to program an os. and it also has the history of various os'' ranging from the first os''s developed all the way to windows nt.

its called operating system concepts by silberschatz galvin

All those links have been very helpful. I especially like the one that doesn''t require knowledge of ASM There was just a little problem with that one. It assumed that I have a Unix-based OS already with some odd console commands and that I was using GCC. I was hoping that I could do everything from windows or dos, using MSVC++. I think I may be trying to go in over my head... I don''t want my OS to have any of that worthless console text or VGA graphics... how hard is it to get 1024x768 resolution with 16bit color?

On a slightly different note, is it a mistake to try writing my OS as a windows application with all the windows-specific stuff encapsulated in classes so that I can replace them with my own OS code sometime in the future? The only major problem I forsee here is that my OS will *execute* the programs just a windows executes a hello world program, but the windows version of my OS (really just a console, I guess) wouldn''t be able to do that. Any more links, help with this problem, thoughts/hints would be great.

--------------------


You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

"Mechanical engineers design weapons; civil engineers design targets."
"Sensitivity is adjustable, so you can set it to detect elephants and other small creatures." -- Product Description for a vibration sensor

Yanroy@usa.com

You can''t really use MSVC for writing an OS. I would recommend using DJGPP, Turbo C 2.01, or NASM (they are all free). It is actually quite difficult to get 1024x768 @ 16 bits. That would require either VESA, or direct support for your video card''s chipset. You probably want to stick with console mode text for now. And you can''t make your OS as a Windows app, as it would contain Windows specific code (that''s why MSVC is bad for OS dev). You basically have to start from scratch, and write all your own standard library functions (or borrow them from something like Linux).

~~~~~~~~~~
Martee
http://www.csc.uvic.ca/~mdill

Start to enable the 4Go addresses memory model and multithreading in the processor with 320*240 for avoid start with VESA things.

Actually, I think that is a good idea, Yanroy. Many people write a virtual machine (i.e., Intel 80386), and then they can test their OS in their GUI of choice by emulating the assembly and having the virtual machine check register values and so forth. You would need a good knowledge of assembly languages in general and a bunch of boring things such as addressing. There are some free tools to get you up and running quickly, but isn''t learning how the machine works the fun part of building an OS?

From what I''ve read, the hardest part is getting the basic bootloader up and running. You have absolutely nothing to work with except what you code yourself. That mean''s no C standard library, no C++ standard library, no compiler, no debugger, etc. You might as well use assembly, because you can''t depend on anything except a few conventions and some BIOS function calls. Besides, if you write everything yourself (bootloader included) you will need to know the exact state of the CPU during most steps. You will have to find a very basic assembler that allows you to control the exact format of the generated image; MSVC will not do.

If I were going to write a cool OS, here are the steps I would take:

1. Learn some simple pseudo-assembly by building a few very simple emulators. They can be extremely small (my first one was an 8-bit processor with a whopping 256 bytes of memory!), but assembly languages are very simple once you get the hang of it. Make sure you implement each VM fully and work out all of the bugs. When you understand how it works, learning Intel assembly for the 386 will be a snap.

2. Write a very basic yet flexible bootloader. A bootloader is a program that resides in the very beginning of a disk (even a floppy!) that just loads what most people think of as the -real- startup code. It should be able to put the processor into the desired mode (probably 32-bit protected mode) and locate and load a dummy kernel, which is the core of the OS. There are some well-documented examples of this. The kernel handles startup, shutdown, and all the related tasks.

3. Read a lot of material on 32-bit protected mode, and some conventions such as which memory locations apps should run at, and so forth. Learn how to write to devices. Devices are manipulated either using BIOS calls or memory mapping. Memory mapping basically means that you read and write to an address in system memory, and those requests are forwarded to the device (or at least that''s how I understood it).

4. Read up on processor features and operating system features. I personally like Windows'' threading model, but I dislike the ability of apps to write to OS memory - so I pick my own rules and set the processor up accordingly. This is the stage where you begin to design a -real- kernel, the core of the operating system. Look at exceptions (hardware, software, pre-defined, and reserved), and briefly consider some of the changes in the x86 CPUs. Look at what you want to add, and keep your eye open on how programming languages are translated into assembly, because...

5. You will need to write your own compiler. Initialially it should be simple; it doesn''t even have to support all of your language''s keywords. This is where you do what is called bootstrapping; the term means that you are trying to lift yourself by pulling at your own bootstraps. Basically, you write a very basic version of the compiler in assembly. When it has been tested and debugged thoroughly in your emulator (it won''t take long, it''ll be so simple), you write the next version of the compiler in your language of choice (most likely C, C++, or Pascal), and then compile it using the first version of the compiler. You keep doing this until you have all of the keywords implemented and a little bit of optimization going.

6. Write the standard library. You can probably do it in mostly your language of choice, with some bits written in assembly. Find out which portions of the standard library rely on other portions, and code the parts with the least dependencies first. Then build upon it.

7. File system, and installer. Don''t forget to make a FAT32 driver (or whatever file system you are using), because soon you will want to. You should iron out the file system layout, such as where operating system and user-defined files will go. It would be nice to make a fool-proof installer that automatically generates its own uninstall and repair scripts from the install scripts. It would have to be a very limited yet flexible installer that doesn''t allow user post-install programs and the like, which could perform steps that the installer/uninstaller couldn''t be able to detect. I hate most Windows device driver distributions, because the manufacturers rarely use them correctly and the Windows installer seems somewhat limited with regards to device drivers.

8. Obviously, you will need some kind of a registry or central repository for storing data for your operating system. I have found Windows Me''s System Restore wizard to be very useful, especially with rogue driver installations; however, you could probably implement it in a much simpler and more efficient fashion because you can build it into your operating system and environment from the start. Add to this some means of backing up user files periodically, and perhaps a nice little paradigm for referring to network resources (shared folders, printers, servers, etc.). Implement anything that users would find helpful for all apps on the system, since it will be that much less redundant code.

9. Work on the device drivers and enumeration system. You''ll want to get ACPI or PnP up and running so you enumerate devices. Your goal right now is to make a generic VGA driver and some driver standards. It would help a lot if you could make a video driver for your chipset or at least a VESA driver so that you could get a basic GUI and messaging system going.

10. Make things more portable with an eye for optimization and performance. Move the system timer and a lot of miscellaneous devices over to a standard interface so that later on you can support other hardware. Another cool idea would be to develop some kind of intermediate code for your compiler. Your compiler and the images it generates could have some of the power of C# with even a very limited version - perhaps your operating system could have a patching system that optimizes (read: dynamically recompiles) certain key sections of code when it loads or installs programs. If build in some functionality for detecting CPU/chipset types and speeds, you could have one heck of an optimizer. Think of the possibilities: when a new chipset feature or set of processor extensions is implemented, all code on the user''s hard drive could be optimized for it (on demand, of course, not all at once). If you build this functionality into the OS, you could make it completely transparent to both the programmer and the end user, without sacrificing security.

11. When everything is working properly, test it. Try placing a new bootloader onto a floppy and using it to boot directly into your OS. If it doesn''t work, chances are that the emulator has a bug...

Of course, that''s a bit ambitious, but those are just ideas. Most are optional, and developing an OS doesn''t have to be that complex. I just thought I''d spew out some ideas that have been flying around in my head for ages.