Oh dear... overly ambitious plans, changing everything for the sake of change, fearing assembly, using VS for OS development, and not even knowing how the GDT and IDT work. There's so much wrong with this I don't even know where to begin. I sense a doomed project.
I had the opposite reaction. Many of the things the OP wants to change are really bothering me about "modern" operating systems.
A recipe for coming up with good ideas is looking at something that has been around for a while and asking "What would it be like if it had been invented now?".
And if all else fails, this will be a wonderful learning experience.
I know this is a cliche, but before writing comments like this ask yourself if a) you are unnecessarily discouraging somebody for no reason and b) you would have said the same thing about successful projects when they were first started.
Finally, the one piece of advice I'd give on this project is that you shouldn't focus too much on the overly ambitious goals and don't worry if you can't accommodate for all of them just yet. The likelihood of achieving the next milestone is somewhat proportional to the number of milestones you have achieved. Get to v0.01 and take it from there.
"I know this is a cliche, but before writing comments like this ask yourself if a) you are unnecessarily discouraging somebody for no reason and b) you would have said the same thing about successful projects when they were first started."
a.) No, I don't think so. Considering the number of half-started kernels on OSdev.org, the creators of which incredibly often were convinced that they were going to create the newest awesomest kernel everyone is going to use, trying to get the OP to take a good look at his skillset seems like a proper thing to do.
b.) I would have, if the creators seemed completely ignorant about the basics of what they were trying to do.
This is not to say that I would tell the OP to give up on OS development - I personally love it. But I think a serious reality check is in order, and because we get people similar to the OP on the OSdev forums an awful lot, sometimes this frustrates me.
I'd like to think the "everything is a file" mentality would've been taken a touch farther, and the command line tools would deal with networked resources better (eg cp ssh://example.com/~/somefile ~/localcopy)
I would have mentioned it, but I was speaking as if Unix were invented today. Plan 9 is an almost textbook second-system effect; it seems like you have to have invented a Unix first before even starting on something like Plan 9.
Nothing wrong with ambition! It will be a great learning experience if nothing else.
Doomed = not commericailize-able? That doesn't mean its without value to the person behind it if they learn and derive satisfaction from the experience.
While I certainly agree that knowledge of how interrupts work is foundational to writing an O/S, the comment about using VS is just silly. Last time I checked MASM was included.
I've done quite a lot of (embedded) OS development in VS. It's a pretty nice experience, because you can generate a console app that you can use as an emulator that allows you to prototype really fast, and use your embedded toolchain when building for the device.
With the obvious caveats that you write as much of your code to be cross-platform as possible, and be careful with endianness.
Microsoft has lots of great command line tools, I used MASM(Microsoft Macro Assembler) and the compiler and linker when I was learning (long long ago).
Nothing is more flexible that command line tools as it lets you do scripting(programming your own environment).
It does not matter if you want to use "already made by someone else windows, text, menus and buttons", but it is essential when you make (or manage what other people's make) everything.
My point wasn't that OS development is impossible in VS. However, given how much the OP seems to know about the subject, and the fact that virtually all resources about it presume that one is using a Linuxesque environment, I wouldn't recommend VS.
the last I heard (3-4 years ago), the OS/kernel team used emacs. the kernel group has its own build infrastructure that is partially / mostly exported in the DDK.
