OSDev.org

Since my kernel is a microkernel, i am writing my shell as an application to be monitored by the IPC, and run in userland. Do i have to establish a static string in video memory as the startup string in the UI? like DOS? DOS starts out with: "C:\ _". and then monitor the commands entered by the user.

Altough DOS starts up with C:\ (to indicate the root directory) you can program it to display any kind of prompt that you want. It is put into the video buffer in the same way as any other text string, which in the case of DOS would probably mean int 21h, fn 9.

The code to display the string would appear at the top of an interactive loop, which goes:
Display the prompt, get a command, execute the command, back to the top. Display the prompt, get a command, execute the command, back to the top..... and so on.

If the command is not one of the shell's internal commands, it will load another program and run it.

The shell, remember, is just another application, so it will use all the same calls to the kernel as any other application would when it wanted to get things done. It will have very few kernel type privileges available to it, and most likely it will have none.

Is there a good shell for hobby OS's? like a shell that you can basically specify your own hooks for and such..but it be completely platform independent, and use a minimal of "advanced" C library functions..(like just putc, string functions,getc..and just malloc/free) so that it can be implemented in a hobby OS with minimal problems...

most people, a shell isn't too hard..infact, to me it was the easiest thing to make in JouleOS(and the easiest to improve)


if anyone would be interested, I could make a small, but extremely extensible shell...it wouldn't be very functional from just the code I provide though..you have to put a few commands..like it doesn't implement "help" for you..

I'd make it to where it could be implemented inside the kernel, in ring0(outside of the kernel), or at ring3...

anyone interested? or would it just be a waste of time?(It'd only take me like 4 hours at the most to get something pretty good anyway...)

You could write a shell in parallel with the kernel. Initially you would have to load it in much the same way as you would load it in a single tasking operating system. If a device driver for the keyboard and screen was one of the first things you implemented, the shell probably wouldn't do much more than accept input from the keyboard, and echo it to the screen. Then as functionality was added to the kernel, corresponding functionality could be added to the shell.

At one point during the development of the OS you might have a shell command which could do absolute disk reads & writes. Then when you implemented a file system they could make way for more sophisticated commands which manipulated files via kernel calls.

That seems like an interesting idea. something like, a shell of a shell, or something. like just a framework that can be customized and modified.
it may even be possible to extend the idea from just a shell to include other utility programs.. just for hobby oses

unfortunately, this seems like it might take some of the fun out of it.
it would prove useful though.

meh...I've basically scrapped that idea...At the point most people can make a getc and puts, they can make there own shell..

utilities, maybe that'd be useful...but anyway..

rocketmanbrad wrote:That seems like an interesting idea. something like, a shell of a shell, or something. like just a framework that can be customized and modified.
it may even be possible to extend the idea from just a shell to include other utility programs.. just for hobby oses

unfortunately, this seems like it might take some of the fun out of it.
it would prove useful though.

The beginnings of a shell are ok, but you can't run too far ahead of yourself. After all, the shell is not going to be particularly functional until you get fairly well into the kernel. By the time you're half way through it might be a useful thing to have around for debugging purposes, but even at that stage there will stiill be an awful lot it can't do; with only a half finished kernel

hckr83 wrote:meh...I've basically scrapped that idea...At the point most people can make a getc and puts, they can make there own shell..

utilities, maybe that'd be useful...but anyway..

At the moment I have got a utility which dumps registers and memory to screen. When I get further down the line I will put a handler for interrupt 1 into it. A bit further on again, and it might be joined by int 3.

Bootstrapping is how the OS gets itself loaded, so it might just as well be how it gets itself written.

com1 wrote:Since my kernel is a microkernel, i am writing my shell as an application to be monitored by the IPC, and run in userland. Do i have to establish a static string in video memory as the startup string in the UI? like DOS? DOS starts out with: "C:\ _". and then monitor the commands entered by the user.

Your shell is just a userland program that is automatically run at startup, just like 'explorer.exe' and 'command.com'.

It's just a layer between the user and the kernel's features.