Where to start when making a DOS
-
- Posts: 2
- Joined: Sun Aug 28, 2016 4:36 pm
- Libera.chat IRC: noobking111
Where to start when making a DOS
Trying to craft my own DOS, just a basic run of the mill dos like OS. Don't know where to start, any idea?
-
- Member
- Posts: 232
- Joined: Mon Jul 25, 2016 6:54 pm
- Location: Adelaide, Australia
Re: Where to start when making a DOS
Have you looked at OSDev wiki - Getting Started and OSDev wiki - Bare Bones?
Beyond that, try to make up a list of things you want your OS to be able to do, if by DOS you specifically mean MS-DOS then look up how MS-DOS worked. How it executed programs, organized memory, what protections it did, or didn't offer for programs and user data.
From my own experience, the best place to start is to try to come up with goals for your project, break it down into simple steps. Once you know what you want to do, it's usually not that hard to find out how to do it.
Beyond that, try to make up a list of things you want your OS to be able to do, if by DOS you specifically mean MS-DOS then look up how MS-DOS worked. How it executed programs, organized memory, what protections it did, or didn't offer for programs and user data.
From my own experience, the best place to start is to try to come up with goals for your project, break it down into simple steps. Once you know what you want to do, it's usually not that hard to find out how to do it.
Re: Where to start when making a DOS
Hi,
The reason for this is that UEFI has everything DOS does (FAT, memory management, shell, etc) but is more modern (is 64-bit, has proper network support, is able to handle 2 or more monitors, etc); and this will help to make it obvious that your OS (when it's finished) will be less useful than not having any OS installed at all.
Cheers,
Brendan
My advice is to start with UEFI.noobking111 wrote:Trying to craft my own DOS, just a basic run of the mill dos like OS. Don't know where to start, any idea?
The reason for this is that UEFI has everything DOS does (FAT, memory management, shell, etc) but is more modern (is 64-bit, has proper network support, is able to handle 2 or more monitors, etc); and this will help to make it obvious that your OS (when it's finished) will be less useful than not having any OS installed at all.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Where to start when making a DOS
You can see how to compile the latest FreeDOS 1.2 here:
Tutorial: Compile and Use FreeDOS 1.2
You can get the book "The FreeDOS Kernel", by Pat Villani. It also contains source code.
There's a copy at the Internet Archive. The copy at the Internet Archive contains code for FreeDOS 1.0b2 and FreeDOS 0.90, although the book originally comes with FreeDOS 0.91a, compatible with DOS 3.3, but 0.91a is very hard to find without a book with the floppy disk.
http://archive.org/search.php?query=freedos%20pat%20villani
To connect the functionality of your OS with the BIOS, you will also need to understand the BIOS. For that you will need to use the 3 System BIOS books from Phoenix. There are copies at the Internet Archive:
Phoenix System BIOS Books/Manuals from 80's/90's
Tutorial: Compile and Use FreeDOS 1.2
You can get the book "The FreeDOS Kernel", by Pat Villani. It also contains source code.
There's a copy at the Internet Archive. The copy at the Internet Archive contains code for FreeDOS 1.0b2 and FreeDOS 0.90, although the book originally comes with FreeDOS 0.91a, compatible with DOS 3.3, but 0.91a is very hard to find without a book with the floppy disk.
http://archive.org/search.php?query=freedos%20pat%20villani
To connect the functionality of your OS with the BIOS, you will also need to understand the BIOS. For that you will need to use the 3 System BIOS books from Phoenix. There are copies at the Internet Archive:
Phoenix System BIOS Books/Manuals from 80's/90's
YouTube:
http://youtube.com/@AltComp126
My x86 emulator/kernel project and software tools/documentation:
http://master.dl.sourceforge.net/projec ... ip?viasf=1
http://youtube.com/@AltComp126
My x86 emulator/kernel project and software tools/documentation:
http://master.dl.sourceforge.net/projec ... ip?viasf=1
- obiwac
- Member
- Posts: 149
- Joined: Fri Jan 27, 2017 12:15 pm
- Libera.chat IRC: obiwac
- Location: Belgium
Re: Where to start when making a DOS
I don't know much about UEFI, but, for me, the fun of making an os is doing everything myself. UEFI removes that. Again, I don't know much about UEFI, so correct me if I'm wrong.Brendan wrote:Hi,
My advice is to start with UEFI.noobking111 wrote:Trying to craft my own DOS, just a basic run of the mill dos like OS. Don't know where to start, any idea?
The reason for this is that UEFI has everything DOS does (FAT, memory management, shell, etc) but is more modern (is 64-bit, has proper network support, is able to handle 2 or more monitors, etc); and this will help to make it obvious that your OS (when it's finished) will be less useful than not having any OS installed at all.
Cheers,
Brendan
Re: Where to start when making a DOS
The question is always how you define "everything". DOS relied heavily on the BIOS, so you could argue that it wasn't doing everything by itself either. Relying heavily on UEFI would indeed be the modern-day equivalent. Of course, UEFI does a lot more than the BIOS did, so you'd have to figure out what pieces of additional functionality you can still deliver (I think this is Brendan's point).obiwac wrote:I don't know much about UEFI, but, for me, the fun of making an os is doing everything myself.
Of course, when someone talks about making "a DOS", I understand that they want to make something that can run existing DOS programs. In this case, you obviously have to make the same design decisions as DOS made back then and keep using the BIOS. Well, or I guess you could just implement the necessary BIOS interfaces yourself and basically just treat them as part of your syscall interface.