yep, it runs true applications not some bytecode compiled crap. :P
fbos applications can be written either om FB or in C/C++(djgpp) and linked with special linker.
Crazed idea for a project. (0.0.1 is here -check out)
-
VirusScanner
- Posts: 775
- Joined: Jul 01, 2005 18:45
It sounds really interesting, I'm anxious to see now...
I actually am working on a scripting language in FB, it doesn't use windows specific features in the parser or interpreter (rtlib does), so it should be portable to linux and FBOS when it's ready.Essentially, it's a kernal. So we need an scripting language and a GUI.
-
E.K.Virtanen
- Posts: 785
- Joined: May 28, 2005 9:19
- Location: Finland
Out of Control?
This is an idea in which I would like to help.
Having done this exact same thing under visual Basic 6 (for my ex employer) I wonder, do you want to create a CMD.EXE clone or a kernel?
If you want to create a dos shell you don't need to consider threading etc. CMD.EXE isn't that complex either. Threading etc is something on the OS level and then we are talking about kernel development.
If the new shell gets a command te execute it can do a few things:
1 lookup if its a internal command, if Yes: perform it
2 If its external look it up
3 check for security restrictions
4 Create the I/O pipes (stdin, stdout,sterr)
5 start the executable with the defined pipes
If you want the shell to be more sophisticated, (build in scripting, IPC, task management, event handeling, network capabilities, build in MP3 capabilites etc), then a server which handles these applications can be prefered.
It all starts with a structure of what do we want?
Greetz
Roel
Having done this exact same thing under visual Basic 6 (for my ex employer) I wonder, do you want to create a CMD.EXE clone or a kernel?
If you want to create a dos shell you don't need to consider threading etc. CMD.EXE isn't that complex either. Threading etc is something on the OS level and then we are talking about kernel development.
If the new shell gets a command te execute it can do a few things:
1 lookup if its a internal command, if Yes: perform it
2 If its external look it up
3 check for security restrictions
4 Create the I/O pipes (stdin, stdout,sterr)
5 start the executable with the defined pipes
If you want the shell to be more sophisticated, (build in scripting, IPC, task management, event handeling, network capabilities, build in MP3 capabilites etc), then a server which handles these applications can be prefered.
It all starts with a structure of what do we want?
Greetz
Roel
Well, the only OS part is "DOS". The correct term for what you are describing is a "shell". Maybe a "graphical shell", but still only a shell.VonGodric wrote:you got it a bit wrong:P it's a bit tad more then simple cmd prompt. Think of it as an OS that sits apon plain DOS and adds things like threading and graphical execution enviroment and user intergface.