centip3de wrote:You know you need to study when you Googled essentially every word that you just said ( I currently have 56 tabs open, just to get a general gist of what you said).
Dude! I'm sorry. So you have somewhat like a "Hello World kernel" right? So if I understand well, GRUB (I never used this for several reasons) loads your 32bit protected mode kernel and it is standard
protected mode (without
paging)
Your very first task will be to carry out your own
GDT (research: protected mode tutorial -- there are tons of them out there) as the one created by GRUB is
a) likely to be trashed,
b) may not serve your purposes. It is common to have a hardcoded GDT (if you plan to use paging) as you'll probably never need to adjust its size. AFAIK you are loaded at 1MB mark with flat segments (starting from address 00000000h), and your new
descriptors in the GDT will have to match this setting otherwise the CPU will triple fault, thus reset.
Once you have set up the GDT and its pointer (for the GDTR) you'll have to issue an LGDT machine instruction in order to load the special FWORD pointer into the GDTR and do a FAR JMP to flush the instruction pipelines and to reload CS from the GDT.
Usually:
- Code: Select all
db 0EAh ; FAR JMP instruction opcode
dw (offset @jump_right_after_this)
dw 08h ; Commonly, the descriptor for CS is #1 which is 08h (8 bytes increment, so #2 is 10h which is usually for DS/ES/ETC)
Once you made the jump, load other segment registers with the data segment descriptor. From now on, you carry your own weight (i.e. your kernel uses only resources of itself). Don't forget to preserve important data GRUB gave you before using registers!!!
centip3de wrote:1. I was messing around with FreeBASIC (I coded in VB.Net for ~3 years so I can read/write it all just fine) but it occurred to me that the majority of it relies heavily on WindowsAPI's, is there anyway for me to port them to my OS, or do I just have to avoid them? In the case of my avoiding them, how can I tell which ones rely on WindowsAPI's and which don't?
2. Where do I even start? I mean, I know what a Kernel is, but I just don't know where to start? I'm the kind of person who gets absorbed in tasks, but if I don't know where to start the task, then I most likely won't get absorbed in it.
3. Any good places besides osdev/osdever/google to help?
4. What do you suggest for a starting OSDev?
Thanks
~C
1. Well, I'm not too familiar with Basic. It is about 10 years now since I've used some flavor of Basic and to be honest I never knew it well. In the Useful Stuff section of HTS (I guess) you'll find OllyDbg by which you can track DLL usage and API calls. The Windows API is a very heavy bloat, so although it's possible to port it, such project can never be expected to succeed for sure. There is a "freeWin" project, called Wine, which is now being developed for many years and it still has problems with running certain applications.
As one who writes her/his kernel in C has to carry out her/his own implementation of the C runtime library (at least the functions actually used) so do you (if your question was regarding the compiled apps' API dependency). If your question aimed to find out if you can port the IDE itself, then I have to answer "only God knows". No clue which APIs it might be using besides file handling calls (at least ATM).
2. Your first task is to present an own GDT as described above. After that I'd implement some basic exception handlers (e.g. print exception number and halt) as they are key elements of debugging your kernel at runtime as well as these stuff will be used later in system security aspects (not to be confused with the user account security and privileges as they are completely different and are way less privileged compared to the kernel: the kernel owns the whole machine, while a root user can only do things the kernel gives opportunity via the user interface -- again, check out protected mode's privilege levels).
3. No idea. Actually I've Googled all my way down the route. Sniffed around, pulled a few hundred megs of documents from the web for offline availability, mostly tutorials from sites like bona fide and the osdever wiki, and specifications, tech details about hardware, filesystems, file formats, etc.
4. Actually it is up to you what makes you satisfied. These projects can range from (I'll exclude real mode puffs) simple protected mode kernel with character shell (you'll need to write a parser then!) or 80x25 textmode windows, only one filesystem support and no device driver interface (just a few embedded drivers for the most important hardware like keyboard, video and disks), multi/monotasking app management to the full-blown, GUI-controlled, multi-user, multi-processing, multitasking/multihreading, Plug n Play capable, gigaprojects.
If you are happy with a character-based interface (lets say a windowed one), preemptive multitasking, single-CPU-core system supporting only one filesystem, etc. I'd recommend this one. You can hardcode you display driver into the kernel (put 80x25 char CRT management routines in) or even the user interface (you "draw" windows for each app running, all appz are somewhat fullscreen, use a keycombo to toggle windows, other keystrokes for basic functions like "close window and terminate task" or "shutdown" or "show main window" or "show settings panel", etc. I guess you know what I'm saying) and base device drivers. Protected mode for securing system against user apps, you use memory area between 1MB and 15MB which is (theoretically) guraranteed to be free, no paging. This is quite simple and later on you can extend as you like.
You'll need: GDT, an LDT per process (generally same as the GDT, but
Local not
Global), exception handlers and an IDT (again, check protected mode tutorials and the
Intel 80386 Programmers' Reference), disk drivers (refer to Floppy and ATA programming manuals), a task management (you just assign metadata structures and some space where to save CPU state to running tasks), a scheduler (you save and restore CPU states to/from memory based on the timer tick IRQ0) and some file handling code, that just about wraps it up.
1. Have a GDT
2. Have an IDT and ISRs (Interrupt Service Routines) for exception/interrupt handling
3. Reprogram the PIC (to avoid collision with exceptions; put hardware interrupts above INT 1Fh) After this you can STI
4. Reprogram the PIT (set it up to generate 100Hz times ticks; this value is common)
5. Have a simple memory manager (your version of malloc() and free(); simply take care of contiguous 14MB)
6. Have task manager and scheduler
7. Have disk-, floppy-, display- and keyboard handling routines
8. Have filesystem handling routines on top of your freshly created "disk drivers"
9. Have a visual interface and a "keystroke/command parser" (read keystrokes from a queue put there by the keyboard ISR, translate it to ASCII via the keyboard driver i.e. translation routines, determine which task it belongs to and put the value on the task's queue or use it if the keystroke belongs to the user interface)
10. Pick a free interrupt line for system calls (Don't forget the IDT descriptor for it!). Determine the request type by EAX value passed by the app, the carry out the necessary action (e.g. read a file from disk into memory and return a reference of it in EAX)
11. So far you can load files, execute apps, display data driven by user input. Write somewhat-useful applications
That is the simplest partially-usable thing I can think of at the moment. Larger stuff are basically the same, but you get a map of the whole memory, parse it, set up memory manager according to this map, use paged virtual memory and have drivers dynamically linked to the kernel at runtime instead of being hardcoded into and the conform to a specification which lets these modules attach to the kernel. Furthermore, the user interface is a separate task (CPL3 afaik), a process does not necessarily have a task, each process can have multiple threads running, more supported filesystem, and alike...
Next question?
Let him who has understanding recount the number of the beast, for it is a human number: His number is 0x029A.
Whatever decision you take, good luck!
) -- Stack Fault, Page Fault, Double Fault are critical. If you fail to handle a double fault or your system stack is corrupted, it'll triple fault, and again, and again, and again ... (
)