You could simplify things a bit and still learn a great deal of things if you just write your own shell (in assembly or C) to work in Linux or Windows. It will be easy to debug. When your kernel has the functionality needed for your shell, it'll be easier to port it, knowing that most of the shell already works and you just need to change 3 major things for interacting with the OS and hardware: I/O (console and file), memory management, launching a program.
This can work assuming that you want your OS to have at least some compatibility with Linux or Windows, or that you write a wrapper that is being called using your API but ends up using the underlaying OS API.
Do you mean file names/paths? In particular, back and forward slashes? Is this something hard to redo if the author doesn't want them or wants something else in their place?
I think there was a misunderstanding here. File names/paths are only a small subset of what I am talking about. Mostly, I meant functions, libraries and programs (let's call them "interfaces") that may not be present either on the OS on the development machine or on your future/final OS.
If you are doing a POSIX-compliant or Windows-compatible OS, what I stated is not a concern, since both the OS on the development machine and your future/final OS will end up having the same "interfaces".
If you are doing an OS that won't be compatible with any other OS (not only binary-code-wise, but also source-code-wise), you can't really write a shell using the "interfaces" of the OS on the development machine and expect it to work on you future/final OS without some kind of compatibility layer (the "wrapper" I said earlier - bad terminology from my part).
A relevant topic might be this one
. Essentially, someone wants to write some "interfaces" of his future/final OS in a way to work on the OS of the development machine.