Hi all,
Since a while I'm busy with program my own OS.
I studied some of Intel's architecture docs, some assembler tutorials, I'm busy learning C and downloaded the FritzOS, an excellent example.
By now, I'm a little bit confused about what's next.
I couldn't find that in the documentation.
I would prefer to implement a shell, so I can write my own programs. But I assume I first have to do some filesystem work, who can help me out.
By now I'm finished with figuring out the FritzOS 0.7, and played around with some basic functions.
Thanks in advance
pkr
implement a shell
Re:implement a shell
Well, a shell...you first need to include a FS...that'll be in a couple of versions ahead of the current FritzOS...possibly pk0.11+.
A file system, so your OS can know what file to load, and the shell...the shell could even be a file loaded from your OS! Look at command.com!
The next step: A IDT. That's what i'm working on. If you see my thread, "Some IDT Code...In C" you'll see some info on making a IDT in C. A idt...lets you use interrups, allowing your OS to have syscalls, and lets say the user presses a key while the OS is busy...the IDT saves the key for later use!
A file system, so your OS can know what file to load, and the shell...the shell could even be a file loaded from your OS! Look at command.com!
The next step: A IDT. That's what i'm working on. If you see my thread, "Some IDT Code...In C" you'll see some info on making a IDT in C. A idt...lets you use interrups, allowing your OS to have syscalls, and lets say the user presses a key while the OS is busy...the IDT saves the key for later use!
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:implement a shell
if you wish to start with a shell, you can start with a very basic memory-mapped file system (the whole partition is read in memory at boot-time and then you just read out of it the bytes you need)
once this is done, you can map programs in memory with paging and start programs ...
Most of the filesystem issues becomes a lot simpler if you decide that your filesystem is read only and created with external tools (which is realistic in early-stage OSes, embedded systems, etc.)
once this is done, you can map programs in memory with paging and start programs ...
Most of the filesystem issues becomes a lot simpler if you decide that your filesystem is read only and created with external tools (which is realistic in early-stage OSes, embedded systems, etc.)
Re:implement a shell
Hey,
So an IDT Lets you use Interrupts in Protected Mode, So could i use "int 0x10" To change the graphics mode in Protected Mode if i had an IDT?
Thanks in advance.....
So an IDT Lets you use Interrupts in Protected Mode, So could i use "int 0x10" To change the graphics mode in Protected Mode if i had an IDT?
Thanks in advance.....
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:implement a shell
please guys, this is a thread about *implementing a shell* ... could you tell me how IDT, graphic mode and pk0.11 are related to this thread ?
i'm afraid you can't. Please keep on-topic ...
i'm afraid you can't. Please keep on-topic ...
Re:implement a shell
You have to admire the guy's persistenceBerserk wrote: Hey,
So an IDT Lets you use Interrupts in Protected Mode, So could i use "int 0x10" To change the graphics mode in Protected Mode if i had an IDT?
Thanks in advance.....
There's actually an interesting thread on OSNews about something called unishell. Might be enough to give you some pointers.
The very basic part of a shell is 2-way communication. That's what it's there for, not for anything more fancy. Your shell allows the user to instruct the computer to do something, and allows the computer to display the results of its attempt to the user.
So right out of the gate you need a user interface (GUI or CLI, choose one and stick to it, you'll need CLI at some point anyway so this isn't going to waste if you choose to ignore graphics for now.) Next you'll need a keyboard driver, then a command parser.
At this point you have to decide a few things. Does the shell contain the common commands (Eg DOS) or are they separate files run by the shell (Eg *nix)? By common commands I mean things like cd, ls(dir), mv, etc. Call them what you will the function will be much the same. If you go the separate file route then a filesystem of is immediate importance, if not you can go a short distance without one.
Once you can get it to interpret one command, and execute that command, then it's just a question of expanding the shell. Limit of expansion is ultimately up to you, but nobody's gonna be happy with a 2gb CLI shell ;D
Hope that at least gives you some pointers.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:implement a shell
what could be funny would be a plug-in able shell: common commands could be read for once the first time they're needed and then executed as a simple function call rather than needing a process fork.
Unishell
Hi There,
I'm the guy who's written the first Unishell code.
Right now you can, like, type "logout" and that's it.
I'm up to implementing an abstraction layer next, to
make Unishell 'properly' portable.
You can find 'releases' and specifications here:
http://sourceforg.net/projects/unishell
Any questions?
unishell-discuss(-subscribe)@lists.sourceforge.net
news.linuxfromscratch.org, Group unishell-discuss
Best regards, Raphael
I'm the guy who's written the first Unishell code.
Right now you can, like, type "logout" and that's it.
I'm up to implementing an abstraction layer next, to
make Unishell 'properly' portable.
You can find 'releases' and specifications here:
http://sourceforg.net/projects/unishell
Any questions?
unishell-discuss(-subscribe)@lists.sourceforge.net
news.linuxfromscratch.org, Group unishell-discuss
Best regards, Raphael