Where to now?

[alaroldai]

I've got a kernel running in text mode and a free-list based memory management system. What should I do next? I've been thinking of doing a basic string manipulation library (to make writing a kernel-out function easier), but I'd rather avoid inline assembly if I can and most of the implementations of vsprintf and printf that I've seen either rely on the C standard library or use inline assembly. But assuming I finish that library fairly quickly, what's next? Most of the major components of operating systems seem to rely on each other, are there any components I can build and test on their own?

[Nessphoro]

Virtual File System, File System, Process Management, VESA VBE Graphics mode

[bluemoon]

I've been thinking of doing a basic string manipulation library (to make writing a kernel-out function easier)

If you want to use libc, you get the strings library for free. However some people more like to do everything from scratch.

And I agree that process management and VFS are good start, not because of technical reason but as once you have an application for your OS you will get motivated.

[Artlav]

Try to think it over from the end point.
Assuming you want to run applications under your OS, what kind would there be?
Let's say you want to be able to play M.A.X. (a strategy TBS game), that would need graphics, files, input, processes.

Input - mouse and keyboard.
Graphics - drawing library, graphics server, window manager (optional), graphics driver.
Files - filesystem abstractions, filesystem driver, storage device drivers (r/only and r/w)
Processes - memory manager, task manager.
And so on.

Bridge the future with the present and start building.
If you want quick satisfaction, makeshift the chain to the applications.
If you want stability, build layer by layer until applications would just happen to work already.

Assuming latter, find the pieces that depend on least and make them.
Rinse, repeat.

You may need to start lower - how are programs loaded, how are shared libraries implemented, etc.
Are you interested in making all from scratch, or to use existing solutions?
First calls for making some common libraries, then the above, latter calls for porting over something like newlib (libc), and again, above.

Shortly speaking, that's about it.
For longer answer, combine your desires with http://wiki.osdev.org

[Solar]

...most of the implementations of vsprintf and printf that I've seen either rely on the C standard library or use inline assembly.

Well, when you're doing an implementation of vsprinf() / printf(), you are implementing (parts of) the C standard library, so it's somewhat fair game to assume that the rest of the lib you're writing will be there, too.

Aside from the freestanding headers <stdarg.h>, <stdint.h>, and <stddef.h>, you need something like strtol() et al., and something like putc() to actually print something.

I know that the glibc implementation of the printf() family is pretty heavy in the dependency department, so I feel justified in advertising my PDCLib (see signature). Any glue functions you'd need are declared and documented in this header.

I haven't tried ripping my *printf() implementation from the rest of the lib, but it has been designed with both portability and usefulness in kernel-space in mind. It's not complete (still missing locale, wide char, and floating point support), but you would get a sizeable portion of the standard library at minimum ballast.