OSDev.org

I have tried to restart my 32bit OS project several times with each time, me getting bored at the point of IDT, and sometimes even at GDT...

The thing that makes me get bored is that I have almost no debugging methods..no debugger will work with OS deving, plus I prefer to be able to actually just say printf("debug1: %i",foo); for debugging..it is just better to me...

The other thing where I get extremely bored is building memory management(just for kernel/physical! much less user and virtual!) I have a very portable malloc method provided by...someone...(it's labeled in the code..) so that part isn't much of a problem..

One more bit is just figuring out how the hell to get things to compile and link correctly under windows with a gcc compiler...

Now another bit is getting interrupts to work easily...
like I always get lost in the design phase of how interrupts should work..(the stub code) and then I always end of reproducing code already out there that is great..

And on that note, also GDT and TSS should be made easier to use in a C enviroment, I actually made a very good set of functions for GDT, though I skipped off on making it portable, so I just haven't bothered messing with it...

Let's see...ummm really, I'd like FDD to be easier to program, but that is really where I draw the line because that goes into devices...


ummm....hmmm

yea...and making keyboard better would be good


Does anyone really have a good, portable set of functions and such to do this(except for the linking and compiling bit)

btw..Vista sucks for OS dev..

And on that note, also GDT and TSS should be made easier to use in a C enviroment, I actually made a very good set of functions for GDT, though I skipped off on making it portable, so I just haven't bothered messing with it...

Which part of the operating system do you actually want to write? Not everything can be done in C. A program which is supposed to control the hardware has at some point got to get its hands dirty with the...... hardware.

I don't mind using assembly...it's mixing (not inline) assembly with C that I hate doing...it's just so troublesome...

anyway..I finally figured out how to get MinGW working on Vista, so I might work on it a bit..

My current OS setup at the moment resolves a few of your issues. I use a Small Assembly Layer that provides a very small layer to the hardware. Kind of like a HAL, but paper thin. It only implements some functions, and they're all in assembly. (eg. print_char, getchar, interrupts, etc.) Then, my C Layer uses the basic assembly functions to create higher order functions. (eg. prink, register_irq, scank, etc.)

My main goal in this whole thing was to make it portable across GCC versions, because my previous system doesn't compile on my newer Linux system. However, I have found that simply coding somethings in assembly made them considerably easier to write. Interrupts, for example. I finished the entire interrupt system in probably 1\2 hour or so in assembly, and they work.

hmmm...
that may be pretty cool..
making whole systems in ASM rather than C..

one of the weird things I did in my last OS was I made an interrupt stub, then I set some labels(global) at points that told what interrupt number we were in, then I copied stuff.....

ummm..anyway, it just used a lot of runtime modified code...
I really think that it is an amazing thing to do...it just takes a bit of initialization, and you save tons of space, and if done right, even save some CPU cycles..
I have yet to find many uses for it though sadly...

but doing more stuff in assembly might be better as I'd have much more control over things..

os development is not an easy thing. what parts exactly of os dev do you want to do? sounds like you've copied lots of code, dont understand what you've copied and dont have the skill to write it yourself.

so which parts of os-dev are you actually interested in?

/me sighs....

I know how to create things like IDT and GDT and such low level protected mode stuff(excluding TSS..) I just get stuck when trying to make them due to lack of motivation because I'm having to rewrite code I've already made before, but I can't use my old code because it isn't portable....at all, and also it isn't exactly the best..

I have written a small OS that had some simple crap in it(at my website below) just, remaking it doesn't hold my interest in the low level bits..especially seeing how many opportunities to make things so much easier using C++...(now that I know it...or at least learning)

hckr83 wrote: The thing that makes me get bored is that I have almost no debugging methods..no debugger will work with OS deving, plus I prefer to be able to actually just say printf("debug1: %i",foo); for debugging..it is just better to me...

These should at least give you a idea help with one problem if they are not useful by themselves which is quite possible.

Function: sprintf (formatting output to a string)
You can look at my sprintf function. If you pass zero for the pointer to a buffer it will use a local buffer that helps to make it quicker to insert it into a function. I use funny identifiers which are not standard.
kstring.c

Macro: Source File And Function Display
Another helpful bit is:
#define KMSG console_write(ksprintf(0, "%s:%s: ", __FILE__, __FUNCTION__)); console_write

Function: .. (Call Stack Trace)
A primitive bit of code to print out a trace of the calls in the stack. Mine includes a bit of extra for printing the thread and process which you are able to remove. It does not support translating the addresses to textual name used in C, but I like to tell me linker to produce a object map. Then use:
grep "0x<address>" ./my_map_file

debug.c

I also tried implementing support for the STABS debugging format, but unfortunately I could not get GRUB to load the .stab section.

While I really do think an OSdever should enjoy the challenge (otherwise you do get bored as hell), have you looked at the OSKit?

hmm..well I'm going to start making an OS again anyway, though this time, I will make my own bootsector, to make sure I fully understand how my kernel is introduced to the system

hckr83 wrote:hmm..well I'm going to start making an OS again anyway, though this time, I will make my own bootsector, to make sure I fully understand how my kernel is introduced to the system

I generally don't like re-using other's code... OK, currently I'm studying the MenuetOS source code to see if I can make it a bit better, but when I write programs from scratch (including, but not restricted to, kernels), it's much more difficult to find some code elsewhere, study it and adapt than just writing my own... Because external code uses other APIs to integrate the rest...

Now, I re-use some code I've written some time ago. For example, I'm completely bored of writing VGA text routines... But I also feel that my latest C implementations (which are all based on each other) are excellent... They support colors and cursor moving, so I don't feel like doomed to write more VGA functions in the near future... I'll just re-use them.

If you want to see them, I can show you... but then don't just copy them to your code... Not that I don't want you to (for now, it's nothing more than public domain, since I've not yet redistributed any of my OSdev-related work), but it's not very instructive to just blindly copy things, as you have just noticed.


Last time I wrote C code to manage x86 CPU data-structures, I freely mixed inline assembly with C code without caring with portability... Writing portable programs (and specially portable kernel code) is a skill that we need to develop, but in kernel land you need to take care of so many things, that sometimes it's better to develop other skills before trying to make things easily portable...

JJ

Windows was written with the idea that it should be portable, but how many platforms has Microsoft actually ported it to? Apart from the 3% of the market claimed by the Mac, the PC standard rules in the world of desktop computers, that's the point, and portability is a non-issue.

I don't like reusing code from others either...I like to be able to understand everything in it..

the only thing I really "copied" was John Fine's VGA mode setting routines..and I really didn't copy them as I adapted it form 16bit dos code, to 32bit standalone code...plus I removed the "getmode" type functions because they were not needed..

probably the weirdest thing I did for "copying" code was I converted DexOS' floppy code to C...that was very fun, but not really..lol

hckr83 wrote:I have tried to restart my 32bit OS project several times with each time, me getting bored at the point of IDT, and sometimes even at GDT...

That's the boring part.. :/ The fun part starts when you've got threading, a floppy driver, a file system driver, and executable loading, then you get to build your user land!

The reason I restarted my OS originally was a lot because of not being thread-safe, like everything was so global...an didn't feel like repairing all that crap..