Hi!

This is my first post on the board, though I've been an avid assembly guy for several years.

I've been working on my OS project off and on for a few years, and once again have motivation to really get things going.  I've got the project on Google Hosting now, and have already made some progress for the first time in months.  Check out http://code.google.com/p/pwnos/ if you're interested, and if you're interested in helping out, awesome.  People are so divided among so many projects that it's amazing that much gets done on any of them (me being hypocritical, of course, hehe).

As a side note, I recently discovered the documentation generator Natural Docs, and it's really helped me get organized and stay focused.  It should help out for if other people want to be part of the team too.  You can see some of my documentation so far at http://www.scs.carleton.ca/~ndickson/os/documentation/ or download the most recent from the repository at Google Hosting.

A few things I'm completely clueless on, like ethernet card drivers.  Is it just me, or are they completely destandardized at the device control level?  While I'm at it, maybe I should wish for graphics card specs too.  Maybe knowing something about the PCI protocols would help.  Oh well, much of the I/O section can be left for after I have basic functionality.

At earlier stages in its development, I had it rendering 3D scenes from data on a FAT partition, and I had mouse and keyboard I/O.  Ironically, it does none of that right now, it's just a lot better organized to actually be an OS instead of a random conglomeration of code.

Anyway, I'm aiming at January 1st for having basic functionality down (even without any help), including memory management, processes & threads, mutual exclusion, messages, an awesome bootloader (that just seems not to work at all right now, hehe), ATA support (without DMA, since PCI seems a bit complicated to manage for January), NTFS reading support, basic graphics support, and possibly PS/2 support (even though it'll mostly be replaced by PCI when I get around to it).  I've got a lot of stuff started, but I really need to get the bootloader fully functional so that I can test out some of the core.

Just some miscellaneous stuff.  Comments are welcome.

Best regards
Posted on 2006-08-15 00:50:40 by hackulous
Cool. I am running along the lines of the "exokernel" approach myself, with some deviation.

Good luck with your project ;)

You might want to visit osdev.org for some good OS links/docs :)
Posted on 2006-08-15 03:40:46 by SpooK
Yeah good luck, for both of us. Ur livin my dream 4 the immediate future; OS creation. Perhaps our progeny will meet one day in battle! Lol :P. All the best.
Posted on 2006-08-28 13:15:50 by Tr][x
If you'd like to help, I'd be more than happy to have you on the team.  :D  A team of one just isn't as fun.
Posted on 2006-08-28 21:12:18 by hackulous
Anyone by any chance have an idea why the processor always stalls if I try to enable the MTRRs?  I can set the MTRRs and the PAT MSR, but it stalls if I uncomment the WRMSR that enables them.

I've now got an HTML/CSS formatted version of the PwnOS code up at http://www.scs.carleton.ca/~ndickson/os/code/, so people can view the code a bit easier.

After some brutal debugging, I also recently got the bootloader to find and load the kernel on an NTFS drive, so I'm well on my way to making the self-set deadline of September 17th to have all of the basic bootloader functionality down.  I now just need to have it create a process (just a dummy process for now) and hand off to the thread scheduler.

Man I love to code.
Posted on 2006-08-30 00:48:15 by hackulous
I gave a glance on your OS. How do you plan to support hardware acceleration?

Do you (or anyone) know whether reverse-engineering a graphics driver (only to find out how it works) is legal? I ask, because I see it as the only option to make a gfx driver for an unsupported (by gfx manufacturer) OS.
Posted on 2006-08-30 21:57:19 by ti_mo_n
That's up in the air at the moment.  I have little-to-no knowledge of graphics hardware drivers, since, as you suggest, they're hard to find code for, and even harder to find decent documentation for.

I could try looking at the Linux drivers, but that'd probably require a ludicrous amount of work.  However, since the code is in the public domain under the GNU GPL, even though some of it is copyrighted, it is allowed to be modified and used in other GNU GPL projects, as long as the source is cited, so it is an option.

One possible (though maybe still not feasible) alternative would be to provide a compatibility mapping for existing drivers to be used.

As much as the end goal would be an OS geared towards games and gamers, I realise how much work it will be even before it will run the least of programs, so graphics acceleration is a very low priority right now, especially since the current lack of memory caching would mean almost no benefit from acceleration.

Nonetheless, if anyone has any good advice on the matter, it'd be appreciated.  :)
Posted on 2006-08-30 22:49:33 by hackulous
well my advice (and that's what I actually plan to do) is to make the OS as compatible with windows (or linux) as possible. I plan to study kernel-mode driver framework ultra-thoroughly so I can write my own with (almost) same functionality and then hope that the drivers will run. Quite naive approach, but hey it guarantees a lot of fun xD
Posted on 2006-08-31 00:38:50 by ti_mo_n

well my advice (and that's what I actually plan to do) is to make the OS as compatible with windows (or linux) as possible. I plan to study kernel-mode driver framework ultra-thoroughly so I can write my own with (almost) same functionality and then hope that the drivers will run. Quite naive approach, but hey it guarantees a lot of fun xD


Not really naive, it is the basis of an exokernel.
Posted on 2006-08-31 07:10:24 by SpooK
Study www.tinykrnl.org, www.reactos.org, graphics driver samples from the DDK, the linux graphics drivers for embedded VIA/C3 (seems basically a DDraw compatible driver with some linux wrappings), and MicroWindows.
Posted on 2006-08-31 08:20:56 by f0dder
Thanks.

I had already looked a bit at ReactOS.  The major problem with using it as a reference is that it (at least the parts that I looked at) had almost no comments or other documentation, and a lot of the comments that there were, were FIXMEs with no description of what needed to be fixed.  At least it's not as bad as MenuetOS in that area; I consider it amazing that MenuetOS works given the terrible use of magic numbers everywhere without even comments.

I've looked a little bit at TinyKRNL now.  It seems to be well-designed, but it would still take a while to figure out, as with any other option.

Anyway, I'm still much more concerned with immediate problems, like that I haven't yet completed:

  • Basic Process/Thread/Library Management Functionality

  • Memory Management above page-level management

  • Any message sending (and I need to have processes and threads first)

  • Basic I/O protocol management (e.g. PCI, AGP, miscellaneous unknown network stuff, etc.)


All of the above are higher priority than graphics acceleration and 100% driver compatibility at this point, and they're pretty much required before I can feasibly test graphics drivers anyway.

I considered starting with the 100% compatibility premise before, but considering that I'll be extatic if I even make it to version 0.0.1, I figured that it'd just be loads of work for not much benefit in the forseeable future.  It's not realistic to expect that PwnOS will ever really be used significantly by anyone, even if it's compatible, so I'm just keeping it simple.  It's not to hard to map functions and shift them around if I do decide to go compatible later.

Thanks again.

P.S. Anyone have any advice on that MTRR enabling stall I mentioned before?
Posted on 2006-09-01 00:26:35 by hackulous
Well, good luck. You'll probably get more done with PwnOS than I ever will with DynatOS :P
Posted on 2006-09-01 01:38:56 by SpooK
Menuet is a pretty good example of "Assembly because it's omfg leet" - and not much more than that ;)

Dunno about the MTRR stall, but "you're probably doing something wrong" as other people succeed with MTRR programming :)
Posted on 2006-09-01 03:07:09 by f0dder

Menuet is a pretty good example of "Assembly because it's omfg leet"...


Barely :lol:
Posted on 2006-09-01 04:21:36 by SpooK

Menuet is a pretty good example of "Assembly because it's omfg leet" - and not much more than that ;)

Dunno about the MTRR stall, but "you're probably doing something wrong" as other people succeed with MTRR programming :)


On the first point, there's not much to say other than "lol, tru dat, it +3h h4X0rZ  8)".  I'm just using assembly language for the kernel (at least most of it) because it's simpler for that type of stuff than C, since many functions require things that aren't built into C (excluding inline assembly), like atomic locking, control register access, and task switching, and a few things are just more complicated in C.  As such, I probably won't use much or any assembly for the funky user interfaces (except in some related libraries), because it's not really any benefit.

On the second point, I'm definitely doing something wrong.  I just have no clue what it is. ;)  I wish that the IA-32 System Programming Guide said more clearly what should be done, since it says that the BIOS should do all this, which it can't, since it doesn't know what memory caching scheme I need, (though it'd be awesome if it could, but I'm not going so far as to write my own BIOS yet).

Anyway, just 16 days left for me to meet my deadline for the bootloader basics, but I think I'll make it unless I get caught up in something else.

Thanks, and I'll keep you guys posted on progress.  :)
Posted on 2006-09-01 11:23:04 by hackulous
My first toy kernel attempt was 100% assembly as well. Partly because it's 6 years ago when I *blush* had the "omg 100%-asm is teh leetz0r" attitude myself, partly because - as you say - some things are just easier in assembly.

The current plans, though (if I ever get back to it :P) is mostly C, a little C++ where it makes things cleaner & safer, and "more assembly than linux and NT, but still not extremely much".

I sorta started the convertion process, but stopped after it was just functional enough to run a text-mode matrix screensaver (so kbd handler etc. weren't ported over). It did, however, mean a transition from DJGPP+NASM to MSVC+FASM, and a compressed PE-exe kernel.


Anyway, just 16 days left for me to meet my deadline for the bootloader basics, but I think I'll make it unless I get caught up in something else.

MTRR isn't *critical*, so you can postpone it a bit. At least don't get hung up on details like this, it's the sure path to damnation :)
Posted on 2006-09-01 11:40:53 by f0dder

MTRR isn't *critical*, so you can postpone it a bit. At least don't get hung up on details like this, it's the sure path to damnation :)


Definitely, getting caught on the unimportant details sucks.  That's why I've had that one line of code (a WRMSR) commented out for the past few months.  It works fine without that one line, so I won't stress over it, and it's definitely not a priority for the time being.  It's just that I know that I'll probably be able to figure out everything else in the short term, and it's probably only a small lack of understanding on my part or small bug, and it'd be nice to have by January.
Posted on 2006-09-01 12:38:19 by hackulous


Barely :lol:


am i seeing a touch of the green eyed monster?  ;)


If it was any ASM OS Dev project that would strike jealousy in me, it would be Bogdan's SolOS project ;)
Posted on 2006-09-03 19:54:59 by SpooK