Assembly and C++
So, I have written a basic operating system that loads up off a floppy, and starts a simple .com application (Written in Assembly as well). I want to write a shell now, but I am not sure if I should continue it in Assembly, or if i can do it in C++. If I can, how would I go about doing it? I know it would have to be command line style, but thats about it. Thanks in advance.
Well have you written a c++ compiler that will work with your OS? If not then you pretty much have no choice but to do it in asm.
Well, I can assemble the files beforehand, cant I?
What you could do is write the OS dependent implmentation and use a multitargeted compiler such as gcc.
Try it and see?.. ;) Though I know next to nothing about such matters, I don't imagine there should be any problems unless you're using features that are Windows-specific. Of course, that IS rather hard to distinguish, i.e. I imagine std::cout/cin are specific to the OS; pointers, linked lists, math operators etc. probably aren't. I'm working on the assumption that the same machine code instructions will do the same things on different OS's assuming the CPU instruction set is the same, and that the problems of compatibility arise from expecting certain conditions to exist in the running environment which will only be present on a specific OS. I suppose file I/O might be incompatible too, since different OS use different file systems.
Pretty much everything that isn't a system call should work with the same instruction set. But things like I/O, memory allocation, executing another program (which a shell would do), etc are all system dependent.
I would also look at the source for bash to see how they did it. Though I'd venture to guess they used C as its easier to keep it at a lower level then C++.
The next step for you is to load your kernel into memory and begin coding in C. The quicker you get to C the better and the faster the development time.
Sounds like you have already coded the important parts that MUST be in assembly. However I'm confused about the COM bootstrap. Your boot strap should lie at sector 0 track 0 and be exactly 512 bytes in size. If you are loading a COM file for the interpreter code or command prompt then you would first load your kernel into memory and/or the interrupt handlers you need to install and then load your COM file into memory and far jump to the start of it.
But for a shell or GUI you definitely want to move to C as fast as possible.
Thanks for all your help. Also, Since I am writing my own kernel, is there any must haves that I should have in there? (Like important things it should do?)
And, someone said my shell had to be under 64k because it was a .com application. How can i get around this?
Make it a flat binary in protected mode or in real mode set your selector limits to 2GB and load in the code via that selector. However setting the selector limits to 2GB and then popping back into real mode is quite an unstable environment to work in.
I'd stick with gcc and make your OS capable of running the ELF format. Or might I be so bold as to suggest, write code in C/C++ have your compiler output assembly. Generate the machine code for the exe using the assembler, then write a sepate program to write out the file header for your executable format. Here is the deal though, I'm going to safely assume you don't have something that even runs executables. You may want to get that running before doing anything. Afterall, as we all know a compiler isn't a mind reader when it knows what OS its generating code for, you are making it even harder on the compiler by not supplying it with sufficient knowledge of what to do with machine code it generates.
> (Like important things it should do?)
Lots of reading for one thing
> And, someone said my shell had to be under 64k because it was a .com application
Only if you intend to tie a noose around your neck and stick with a 16-bit world.
Sure if your OS is "dumb" and has a very simple loader, then having executable files which are essentially a snapshot of memory is pretty easy.
But investing time in making a more capable loader (one for say ELF) means you can have a much richer set of executable file options.
hmmm... where can i learn to make my own OS??? I am ok at C++ but thats all i know
There is an operating system called MINIX. It was created to teach you how to write an operating system. MINUX is free, but you have to pay for the book. That's how Linus got started. It would probably be a good idea to look at the Linux code... but you might need a book to guide you through that too... 2.4 milllion lines of code in Linux 2.4 !!!! I'd suggest looking into the history of Linux too.
Coding an OS is no small feat. It's not exactly hard, but there are about a million things you need to consider because your code runs the computer. As such you must monitor everything that goes on - including things we take for granted like disk access, memory management, thread priorities, interrupts or lack thereof, etc, etc. The list goes on for miles and miles. It is quite complex. Any number of events could happen at the same time that your OS must know how to deal with or at least have a mechanism for catching such things.
For instance if one thread is writing to a file and your OS then switches to a task that is also writing to the same file....do you close the first file and/or handle and store the file pointer for it and then create a second handle to the file...or do you create a semaphore mechanism or a mutex mechanism that protects and/or shares files across multiple processes? Do you use shared memory between programs or do you use separate independent memory spaces.
And then for memory management. There are a million ways to go about handling/managing/allocating/releasing memory. Are you going to use segmentation or are you only going to create a minimal number of selectors - those that are for the OS code,stack, and data and thost that are for all programs code, stack, data. If the latter is true then you also must create a system or structure that stores where in the big 'chunk' of memory each processes code, stack, and data reside as well as access limits and/or protection between those segments and other processes.
I would suggest buying the book MMURTL from over at flashdaddee. The link to the book is in the OS-dev board in the first sticky post called OS dev resources.
Incidentally if you do not know assembly now would be a good time to dive head first into the Intel x86 32-bit and/or 64-bit books. The 32-bit set has 4 volumes of books and the 64-bit has 3. You will need these close by your side as well as tons of white papers, tech papers, and docs for hardware, bioses, motherboards, chipsets, drives, etc., etc.
Coding an OS is one of the most complex projects you can take on. There are numerous things that you have to implement (well ) before you can even get text on to the screen.
An OS is a type of project where you code loads and get hardly anything back that is rewarding ( visually ).
Once you have a strong kernel coded ( which in its self can take years! ), you can more on to the more rewarding stuff, like GUI development. Although this sounds fun, it can be as hard, or even harder than writing the kernel its self.
Not to mention networking, API's, etc...
I am certainly not trying to put you of though! I am currently working on my own OS project! I think it's great to know that your code is the only code running on the machine ( or inside VMware, which ever way you like to look at it! ). If you manage to get a OS up an running with a shell, and the ability to run a text editor ( like EDIT on DOS), then you have come an awful long way!
Now this seems completely pointless, when you could just pop up eclipse and create a text editor in 30 minutes! But, that is not the point, coding an OS involves a range of topics, and you must know these well to be able to make an OS. This gives you an immense understanding of C/C++ (or whatever), Assembly, General Computer Science, Memory, etc... Just think how this will help your programming career!
MMURLT is not a very helpful book at all. I have got it and although it explains some concepts well, it does not do what it says on the tin ( or back cover ). It does not teach you how to build an OS from scratch, it just tells you the theory behind it, and then dumps a load of code on your lap in the 2nd half. A great place to start is http://www.osdev.org . This has everything you could want to get started!
I hope this helps!