OSDev.org

Hello everyone.

After lurking here for a while and doing a lot of research on my own, I've finally started off down the road of developing an OS. It's something that I've wanted to do for a few years now, and I think I finally have the work ethic and skills to have a decent shot at getting somewhere with it.

Following some tutorials I've found and using some of my own experience, I've managed to set up the tools and environment necessary to begin, and have gotten a very basic Hello World bootloader done. Now comes that dreaded moment: what next?

I decided immediately that I should plan out my operating system before I got very far at all into it, and so, I figured I'd ask some things here before I got hopelessly lost. I've done a good bit of research on my own, but I still have some questions on basic design that I think I need some advice with.

First and foremost, I suppose I should ask the question of whether or not I'm really ready for this (I've read the wiki article on it, but I'd like some reassurance). I have around 7 years of working with C++, and that's the language I intend to write my kernel in (yes, I understand the implications of writing a basic run time library for it), and I have a pretty good amount of experience with working with moderately complex projects like 3D game programming. But, there are two skills that I'm somewhat concerned about. First, while I do have experience with assembly languages, I've never written an OS hosted application with it (only for 3D games with first generation fragment / vertex programs). Next, I have no experience whatsoever with using multithreading. Since it seems to be a somewhat important part of an operating system / API, I'm worried I won't be able to satisfactorily learn the material while trying to do something as hard as writing an OS. Do you think it's reasonable that I can overcome my inexperience with ASM to learn it while writing those parts of my OS?

Next, I have a few questions on design of the OS itself. I tried to answer these sorts of questions myself, but most are a sort of philosophical take on the problem. First up, I guess I should explain what my goals for the OS are.

I want the OS to have the following features when I consider it "done enough":

Multitasking (what OS can't these days?)
Text only interface (no point getting bogged down with a GUI at this stage)
Very basic video API for applications (possibly text only)
Probably no sound
Support at least a wired ethernet network with TCP/IP
Support for at least one fixed disk filesystem
Single user
Little security
No overconcern for efficiency, just stability

As far as these design goals are, I'd like some input. First up is the question of a sound API. From what I gather, it seems to be possible to get sound on a hobby OS, but there doesn't seem to be any standard way of doing it without drivers (i.e. for video at the very least you can use direct text mode without support drivers). Is it too much of a hassel to expect sound?

One of the biggest reasons I wanted to write this OS was to be able to support a simple web server, and for that I'll need networking and TCP/IP. Obviously this is also possible, but is it completely impractical for my first OS attemp? I know it won't be easy, and to write the drivers I'll probably have to get a specific card with known hardware, but I'm willing to try.

As far as 64/32 bit goes, is there any reason to not go 64-bit? I've seen some things about it not supporting hardware multitasking, but I assume that most modern OSes use software multitasking, correct? Are most of the examples that I've seen for 32-bit OSes going to work in 64-bit? (Barring certain ASM things like address lengths and certain instructions, of course).

Possibly pointless, but I was also wondering a bit about the traditional ring0 - ring3 protection scheme of most OSes. Is there any tangible benefit to, say, make drivers run in ring1? As far as I can tell, it wouldn't be terribly different than running then in ring3 (micro kernel?). Should I just stick to the monolithic ring0 - ring3 convention?

One other big question nagging me is the support for SMP / multithreading. I seriously doubt that I will end up porting any known application or STL to my OS, so I honestly don't know if multithreading will be necessary, since I'll be doing all of the programming and I don't know how anyway. Is this ridiculous? Obviously multiple processes is going to be present, but with only a single thread. As far as SMP goes, I'd love to take advantage of multiple cores or processors, but I haven't found much in the way of examples of using SMP in an OS. I found the manual from Intel, but it's so heavy in hardware design and related stuff that it can't possibly hope to answer the question of whether or not it's reasonable for me to try and implement it.

Also, how practical is it to implement basic USB functionality? I know that some things like this are proprietary (PCI spec is, isn't it?). Basically, the only important things would probably be basic USB support and a standardized driver for Mass Storage Devices. USB keyboards / mice are emulated in the BIOS, right? I forgot to look into this earlier, I'll try to remember to do so later.

Lastly, I wanted to know what's reasonable for implementing file systems. Obviously, FAT12 is going to be very important. But, that's where the obviousness ends. I originally wanted to devise my own file system (that's one of the joys of writing an OS, I'd say), but after some thought I figured that since I'm so used to using Windows that implementing FAT32 and just using Windows to manage my disks between tests and boots might be much more reasonable. Should I go ahead and try and do that instead of wasting time trying to devise my own system and ending up writing utilities that would manage the virtual disk in a file or something?

Thanks for any help you guys can provide, and sorrry for the length of the message. I'm a little long winded sometimes. (Also, I'm sorry if this post really belonged in the OS Design / Theory forum, but my search seemed to favor posts like this in the development forum).

Edit: Added a few more questions to avoid double posting.

Hi,

Random notes scattered throughout...

Telgin wrote:First, while I do have experience with assembly languages, I've never written an OS hosted application with it (only for 3D games with first generation fragment / vertex programs).

For most OS's, most of the assembly language consists of small pieces of inline assembly to handle things that the compiler can't (low level task switch code, accessing I/O ports and MSRs, switching between CPU modes, interrupt handler stubs, re-entrancy locks, etc). You don't really get experience with these sorts of things by writing applications in assembly, but most of it is fairly simple anyway.

Telgin wrote:Next, I have no experience whatsoever with using multithreading. Since it seems to be a somewhat important part of an operating system / API, I'm worried I won't be able to satisfactorily learn the material while trying to do something as hard as writing an OS. Do you think it's reasonable that I can overcome my inexperience with ASM to learn it while writing those parts of my OS?

If you're worried, I'd suggest writing something that uses pthreads (the POSIX threading library). It doesn't need to actually do anything useful, although it should use 2 or more threads and involve some sort of shared resource that's repeatedly modified by several threads (and some re-entrancy locking and/or condition variables to prevent the shared resource getting messed up). Here's a reasonable POSIX threads tutorial.

Telgin wrote:As far as these design goals are, I'd like some input.

There's 2 fundamental descisions you've left out.

The first is why you're writing the OS - to learn more, for fun, for profit?

The other descision is the kernel type - monolithic, micro-kernel or something else? There is no right or wrong answer (just advantages, disadvantages and compromises), but this descision effects almost everything else.

Telgin wrote:First up is the question of a sound API. From what I gather, it seems to be possible to get sound on a hobby OS, but there doesn't seem to be any standard way of doing it without drivers (i.e. for video at the very least you can use direct text mode without support drivers). Is it too much of a hassel to expect sound?

One of the biggest reasons I wanted to write this OS was to be able to support a simple web server, and for that I'll need networking and TCP/IP. Obviously this is also possible, but is it completely impractical for my first OS attemp? I know it won't be easy, and to write the drivers I'll probably have to get a specific card with known hardware, but I'm willing to try.

Start with boot code, physical memory management, linear memory management, scheduler then IPC. Then add hardware autodetection. Sound and TCP/IP probably won't matter for 6 months or more.

Telgin wrote:As far as 64/32 bit goes, is there any reason to not go 64-bit? I've seen some things about it not supporting hardware multitasking, but I assume that most modern OSes use software multitasking, correct? Are most of the examples that I've seen for 32-bit OSes going to work in 64-bit? (Barring certain ASM things like address lengths and certain instructions, of course).

For most of the code (if you're using C or C++) it won't make any difference. For the rest it won't make much difference (same principles and mostly the same instructions). The main difference is that long mode doesn't support hardware task switching (but nobody cares), doesn't support segmentation (but nobody cares) and also doesn't support virtual 8086 mode. No virtual 8086 mode means it's hard to use code designed for real mode, including old/crappy BIOS functions (but nobody cares) and video ROM functions (which may or may not be a problem).

There's also some minor differences with interrupt handling (the optional "Interrupt Stack Table" and 16 byte stack alignment), and minor differences in the format of some of the CPU's structures (GDT/LDT/IDT entries).

For "64-bit only" you also don't need to worry about a lot of the "backward compatability" hassles - if the CPU/s support 64-bit, then you know they also have things like CPUID, FPU, MMX, SSE, global pages, large pages, INVLPG, RDTSC, etc.

Telgin wrote:One other big question nagging me is the support for SMP / multithreading. I seriously doubt that I will end up porting any known application or STL to my OS, so I honestly don't know if multithreading will be necessary, since I'll be doing all of the programming and I don't know how anyway. Is this ridiculous?

Why are you writing the OS? How long will it take? What sort of hardware are people likely to be using when the OS is usable?

For me, I'm writing the OS in the hope of eventually ending up with a commercial quality alternative to existing OSs (Windows, Linux, etc). I know it'll take at least 5 more years, and I know people will probably be using "4-or-more core" 64-bit CPUs by then. For me, this means multi-threading and SMP (and NUMA) are required.

For you? I have no idea...

Telgin wrote:Lastly, I wanted to know what's reasonable for implementing file systems. Obviously, FAT12 is going to be very important. But, that's where the obviousness ends. I originally wanted to devise my own file system (that's one of the joys of writing an OS, I'd say), but after some thought I figured that since I'm so used to using Windows that implementing FAT32 and just using Windows to manage my disks between tests and boots might be much more reasonable. Should I go ahead and try and do that instead of wasting time trying to devise my own system and ending up writing utilities that would manage the virtual disk in a file or something?

For security purposes, it'd be good to have a filesystem that enforces file permissions (not FAT). Of course most OSs support more than one filesystem, and there's no reason you can't support FAT in the beginning and add support for other filesystems later.


Cheers,

Brendan

Hello,

A few thoughts from someone writing a 64 bit OS in C++

Telgin wrote:Do you think it's reasonable that I can overcome my inexperience with ASM to learn it while writing those parts of my OS?

Absolutely - it sounds like you have a very reasonable amount of programming experience. For all that it can do, basic assembly isn't actually that difficult - it just does everything on a 'micromanagement'-type scale. I think you'll find it's just a matter of getting to know some of the more common instructions you'll use. When you can't remember what an instruction does, there are plenty of good online references and, of course, the Intel manuals.

Telgin wrote:One of the biggest reasons I wanted to write this OS was to be able to support a simple web server, and for that I'll need networking and TCP/IP.

In which case, I would suggest supportign multithreading. If you can do multitasking, multithreading is very easy to add. In fact, most hobby OS developpers on this board seem to start of with a form of ring 0 -> ring 0 kernel multithreading and add ring 3 multitasking support with separate memory spaces from there. If you have multithreading, it will give you the option of some listening services to spawn new threads rather than new tasks on accepting connections (you may want tasks for some things, but at least you have the option if it's built in).

Oh - and I would definitely stick with just ring 0 and ring 3 - although segmentation worries about three distinct rings, the paging mechanisms only worry about user / supervisor levels. If you are in 64 bit mode (which I would advise for most new startup OS's), you can forget about segmentation.

One of the big things people find when porting to x86-64 is that they don't have v86 mode any more and some people use this for e.g. switching VESA video modes - simply do this before you launch your OS and there's no problem - I guess if you are sticking with an 80*25 TUI, you probably don't care about that anyway.

As for C++, basic runtime support can be added to your OS at an early stage. You are probably going to be implementing memory management as one of the early OS goals - this gives you new and delete. Once you have this, calling global / static constructors is pretty simple (and is covered in the wiki). I would personally leave other runtime support until you have a working system call interface and can port Libstdc++ - unless you can't live without exceptions and RTTI

HTH
Adam

Thanks a lot for the replies guys.

Why are you writing the OS? How long will it take? What sort of hardware are people likely to be using when the OS is usable?

You're absolutely right in that I forgot to mention my ultimate expectations and reason for writing the OS. Really, I'm doing it for fun and my own learning experience. On top of that, I have no plans to make it commercial and I know good and well that I could never write anything that would compare to Windows / Linux. So, I'm not going to try to. Like I listed earlier, I don't plan on having a GUI in the first complete version of my OS, no user accounts (just one implied administrator), little security, spartan hardware support, and so on. I figure that it will take me around a year to get to a workable fashion (I've seen six months listed as a reasonable time period, but to get TCP/IP and all that jazz too I figured it take longer than 6 months).


Also, I forgot to mention that I'm planning on making it a monolithic kernel (seems to be the norm, and I don't feel comfortable wrapping my head around the distributed nature of a micro kernel). Although it's going to be monolithic, I plan on keeping drivers and such separate from the kernel proper, like Windows (and most Linux drivers). Isn't that generally called a hybrid kernel?

For most of the code (if you're using C or C++) it won't make any difference. For the rest it won't make much difference (same principles and mostly the same instructions). The main difference is that long mode doesn't support hardware task switching (but nobody cares), doesn't support segmentation (but nobody cares) and also doesn't support virtual 8086 mode. No virtual 8086 mode means it's hard to use code designed for real mode, including old/crappy BIOS functions (but nobody cares) and video ROM functions (which may or may not be a problem).

Going by your statements, I guess I'll just go full steam ahead with 64-bit. There doesn't really seem to be anything to lose, and I assume that any differences between 32-bit tutorials and what the processor expects (GDT, IDT, etc) shouldn't be hard to fix.

For security purposes, it'd be good to have a filesystem that enforces file permissions (not FAT). Of course most OSs support more than one filesystem, and there's no reason you can't support FAT in the beginning and add support for other filesystems later.

I understand completely, but I was mostly going from a point of view of practicality. Since I don't really intend to have any real internal security in my OS (I'm going to be the only person using it, I'd wager), FAT32 would probably be fine for me (no 4GB files either). I'd love to have NTFS or the like so Windows could still write to my filesystem and have security, but it's a closed spec, isn't it? Some filesystem flavor from Linux / Unix is a possible long term goal.

One of the other reasons I thought about implementing FAT instead of something else entirely is that I read that it was commonly used in flash drives, but I have no idea what is involved in getting that to work in an OS, and may never happen. We'll have to see, any rough ideas on how hard it is to implement USB? If it's not worth it just for flash drives, I may not even bother.

In which case, I would suggest supportign multithreading. If you can do multitasking, multithreading is very easy to add. In fact, most hobby OS developpers on this board seem to start of with a form of ring 0 -> ring 0 kernel multithreading and add ring 3 multitasking support with separate memory spaces from there. If you have multithreading, it will give you the option of some listening services to spawn new threads rather than new tasks on accepting connections (you may want tasks for some things, but at least you have the option if it's built in).

I suppose from the OS's point of view, managing threads isn't terribly different than doing so for processes, but then there's the whole mess of dealing with things like memory protection (mutexes and related things). If it's not as bad as it sounds, I guess I can handle it. I probably really need to follow Brendan's advice and try to work with threads before I get to that point in the OS. The web server certainly would benefit from being able to run on multiple processors with new threads spawned for connections, I guess I really do need to look into it. Just maybe trying to write a web server on my own OS is asking a bit too much, but again, I'll see.

Oh - and I would definitely stick with just ring 0 and ring 3 - although segmentation worries about three distinct rings, the paging mechanisms only worry about user / supervisor levels. If you are in 64 bit mode (which I would advise for most new startup OS's), you can forget about segmentation.

Okay, sounds good. You mention that segmentation deals with the rings in the processor, but in long mode segmentation is gone. Does that mean that there is no such protection in long mode? I can't recall at the moment from my reading whether or not the protection rings were tied to segmentation or not.

One of the big things people find when porting to x86-64 is that they don't have v86 mode any more and some people use this for e.g. switching VESA video modes - simply do this before you launch your OS and there's no problem - I guess if you are sticking with an 80*25 TUI, you probably don't care about that anyway.

Okay, doesn't sound like a big problem. But, I was entertaining the idea of having the OS run in a higher VESA mode and emulate text mode by drawing characters directly instead of working with text mode. But, in my brief research I wasn't able to determine if running in VESA mode prevented you from using text mode or not, so if it did support it there's no big deal. I also noted that newer versions of VESA supposedly supported working in modes other than v86 (long mode perhaps?), but if that's true I don't know what would support that or not. I may just stick with text mode and save myself the trouble.

Also, I noticed that in one of the newer specifications for VESA, there seemed to be a sound extension set, but I gather that since I haven't heard about that on here anywhere that it is either not well supported (if at all), or impractical to use.

As for C++, basic runtime support can be added to your OS at an early stage. You are probably going to be implementing memory management as one of the early OS goals - this gives you new and delete. Once you have this, calling global / static constructors is pretty simple (and is covered in the wiki). I would personally leave other runtime support until you have a working system call interface and can port Libstdc++ - unless you can't live without exceptions and RTTI

Yeah, that's what I gathered from the wiki article I believe (and some other sources). I don't think it's going to be a huge deal, and honestly, I never really used exceptions and RTTI (or even global objects / static objects, but an OS might be the first place where such a thing might be important).


Once again, thanks for the help guys, I appreciate it. Maybe now I can get my design sorted out before I get too far into the inner workings of the kernel.

Hi,

Telgin wrote:I plan on keeping drivers and such separate from the kernel proper, like Windows (and most Linux drivers). Isn't that generally called a hybrid kernel?

That would probably be a modular monolithic kernel (it only becomes a hybrid when some of those modules run in user space), although there's many conflicting definitions and corner cases (like systems that don't have/use hardware protection).

For me, monolithic or micro-kernel is more about the isolation between pieces. If the kernel can talk to a device driver using normal function calls (including dynamically linked functions and function pointers) then it's a monolithic kernel, but if the kernel needs to use IPC (e.g. messaging) to talk to device drivers then it's not monolithic.

Telgin wrote:

Oh - and I would definitely stick with just ring 0 and ring 3 - although segmentation worries about three distinct rings, the paging mechanisms only worry about user / supervisor levels. If you are in 64 bit mode (which I would advise for most new startup OS's), you can forget about segmentation.

Okay, sounds good. You mention that segmentation deals with the rings in the processor, but in long mode segmentation is gone. Does that mean that there is no such protection in long mode? I can't recall at the moment from my reading whether or not the protection rings were tied to segmentation or not.

The protection rings are a fundamental concept within the (80x86) CPU, and are used for segment based protection, paging based protection, I/O port protection, interrupt protection, etc. In long mode all of that is all still there, except that the segment based protection is mostly ignored *if* you're running 64-bit code (you can run 32-bit code or 16-bit code in long mode and segmentation is all still there).

Telgin wrote:I also noted that newer versions of VESA supposedly supported working in modes other than v86 (long mode perhaps?), but if that's true I don't know what would support that or not. I may just stick with text mode and save myself the trouble.

Newer version of VESA's VBE specification include a 16-bit protected mode interface and a 32-bit protected mode interface (that are both optional and have reduced functionality). These interfaces can be used in long mode (because you can run 32-bit code or 16-bit code in long mode).

Note: Long mode has 2 sub-modes: "long_mode.64-bit" and "long_mode.compatability". The kernel normally uses "long_mode.64-bit" (and must use 64-bit for some things) while applications may use "long_mode.64-bit" or "long_mode.compatability".

Telgin wrote:Also, I noticed that in one of the newer specifications for VESA, there seemed to be a sound extension set, but I gather that since I haven't heard about that on here anywhere that it is either not well supported (if at all), or impractical to use.

VESA is an organisation that creates standards. One of their standards is "VBE" (or Video BIOS Extensions). They've also done a lot of other standards that are less well-known (including standards for different monitors, hardware accelerated video, sound, etc).


Cheers,

Brendan

Ah, ok, thanks for clearing that up.

I guess my kernel would be considered monolithic in that case, I like the idea of highly modular kernel components / drivers, with parts running in user mode to help keep things stable in the case of a driver failure, but for my first OS I'd like to keep things relatively simple (as simple as OS development can get, of course).

Newer version of VESA's VBE specification include a 16-bit protected mode interface and a 32-bit protected mode interface (that are both optional and have reduced functionality). These interfaces can be used in long mode (because you can run 32-bit code or 16-bit code in long mode).

Note: Long mode has 2 sub-modes: "long_mode.64-bit" and "long_mode.compatability". The kernel normally uses "long_mode.64-bit" (and must use 64-bit for some things) while applications may use "long_mode.64-bit" or "long_mode.compatability".

Hmm, by reduced functionality, I take it that you mean that I'd be better off starting up a higher video mode before transistion to long mode. If I were to do that though, would I be able to work with it after transistioning to long mode? For instance, I gather that in text mode, it's possible to directly write to the video card's memory to set characters, if I were to set the display up in a higher VESA video mode, would I be able to write to video memory directly or would I have to work in v86? I guess I've got a lot of reading to do, but that's the norm when working in this field I guess.

VESA is an organisation that creates standards. One of their standards is "VBE" (or Video BIOS Extensions). They've also done a lot of other standards that are less well-known (including standards for different monitors, hardware accelerated video, sound, etc).

Ah, I see. So, I take it that most of their other standards (sound for instance) are probably not worth my time looking into? I'll probably look and see what sort of information I can find for certain hardware I own (i.e. AC'97 sound or something). Unless what I find is remarkably easy to locate and understand though, I'll probably just do without sound. I think I remember something like the Soundblaster cards requiring some rather clunky legacy stuff to work...

Hi,

Telgin wrote:

Newer version of VESA's VBE specification include a 16-bit protected mode interface and a 32-bit protected mode interface (that are both optional and have reduced functionality). These interfaces can be used in long mode (because you can run 32-bit code or 16-bit code in long mode).

Note: Long mode has 2 sub-modes: "long_mode.64-bit" and "long_mode.compatability". The kernel normally uses "long_mode.64-bit" (and must use 64-bit for some things) while applications may use "long_mode.64-bit" or "long_mode.compatability".

Hmm, by reduced functionality, I take it that you mean that I'd be better off starting up a higher video mode before transistion to long mode. If I were to do that though, would I be able to work with it after transistioning to long mode? For instance, I gather that in text mode, it's possible to directly write to the video card's memory to set characters, if I were to set the display up in a higher VESA video mode, would I be able to write to video memory directly or would I have to work in v86? I guess I've got a lot of reading to do, but that's the norm when working in this field I guess.

Usually (especially for PCI video cards) the video display memory can be accessed in a simple, linear way (e.g. 4 MB of display memory that is mapped from 0xE0000000 to 0xE0400000 in the physical address space) - this is called a LFB (or a Linear Frame Buffer).

Sometimes (especially for old video cards) this isn't supported and bank switching is used. For example, you use a VBE function to tell the video card which 64 KB area of video display memory you want to access, and then access that area by writing to the 64 KB area from 0x000A0000 to 0x000AFFFF.

However, for a "64-bit only" OS you don't need to worry much about old video cards (or supporting banked switched video modes) so you can assume that you'll be able to access all video display memory directly.

Telgin wrote:

VESA is an organisation that creates standards. One of their standards is "VBE" (or Video BIOS Extensions). They've also done a lot of other standards that are less well-known (including standards for different monitors, hardware accelerated video, sound, etc).

Ah, I see. So, I take it that most of their other standards (sound for instance) are probably not worth my time looking into? I'll probably look and see what sort of information I can find for certain hardware I own (i.e. AC'97 sound or something). Unless what I find is remarkably easy to locate and understand though, I'll probably just do without sound. I think I remember something like the Soundblaster cards requiring some rather clunky legacy stuff to work...

IMHO there's only a few VESA standards that are worth looking into (and sound isn't one of them). The VBE (Video BIOS Extensions) is the first. The AF (Accelerator Functions) is another standard that's used for hardware accelerated video, hardware cursor, etc. The last standards are DDC (Display Data Channel) and EDID (Extended Display Identification Data), that are used to find out what sorts of video signals/modes the monitor can handle.

About device drivers in general (except for some sort of default "doh, no video driver" video support), don't worry too much about them - device driver interfaces and the device drivers themselves come after basic kernel functionality (memory management, scheduling, etc), not before. It's a bit like choosing your children's names when you've got no spouse...


Cheers,

Brendan

Telgin, you seem to have put a lot of thought into your OS, which is a good start.
I would like to add my findings on one or two points.

My OS is single-tasking, but i have a web-server ver, that users multi-threading to deal with many connections at a time.
The is part of the web server and only needs to hook into the time IRQ .

Next i would stick with fat32, but ntfs is not that hard, i have asm example code that is small and demos loading a file off a ntfs partion.

I have also written AC97 drivers, and i would say they are about the same as a atapi driver, but one problem you will find is that they are not a one fits all, as you would need to code about 5 ver to get 60% coverage.

Yeah, I understand, makes perfect sense.

I guess I should do as recommended and get the important basic stuff out of the way first, then worry about what sort of hardware I'll be able to support. Even the design considerations of driver interfaces can probably wait until after I've written the basic stuff like you said.

Thanks for the clarifications. Let's hope that I don't end up being one of the countless people who start an OS, get the boot loader done and then get no where fast.

Telgin, you seem to have put a lot of thought into your OS, which is a good start.
I would like to add my findings on one or two points.

My OS is single-tasking, but i have a web-server ver, that users multi-threading to deal with many connections at a time.
The is part of the web server and only needs to hook into the time IRQ .

Next i would stick with fat32, but ntfs is not that hard, i have asm example code that is small and demos loading a file off a ntfs partion.

I have also written AC97 drivers, and i would say they are about the same as a atapi driver, but one problem you will find is that they are not a one fits all, as you would need to code about 5 ver to get 60% coverage.

Wow, really? I thought that Microsoft kept NTFS completely proprietary. Well, then again there are those free tools to read NTFS partitions, but isn't write support very lackluster? I would be interested in seeing how complicated it is to write / read an NTFS partition, but I'm afraid that an ASM example wouldn't do me a whole lot of good. (I've noticed from a lot of your posts that you seem to use ASM almost exclusively for your OS, you have my respects, I'd be terrified to attempt such a task).

So, AC'97 isn't too bad? Perhaps one day I'll get around to just writing drivers for the hardware that I own (since I'm the only one who will probably use my first OS). I'll just have to find out what specific chipset or whatnot it's using.