Ideas for a new XT compatible OS...

[Toba]

I've been thinking of creating an OS lately. I'm hoping to make a text-mode OS in full assembly language that runs fast, has no bugs or security holes, and is the "best" operating system I can think of. Have you ever seen an OS that had nothing you thought could be better?

So far, here are my ideas:

Process handling:

1. Multiple Processes can run at once.
2. ALL processes except the kernel show up in a task manager (no way to hide).
3. When you choose to end a program from the task manager, the kernel just deallocates resources used by the process, stops giving the process timeslices, and clears the memory it occupied. None of this "not responding" garbage.
4. Priority on processes is floating-point from zero to one. Only the task manager can set these priorities, however (removes likelihood that a malicious process can claim all processor power).

File system:

1. Spaces, symbols, and weird characters may not be used in filenames. A-Z, a-z, 0-9, -, and _ are the only allowed characters. The extension is a separate field (no need for worries about periods) as is the directory.
2. Whenever a cluster is added to a file, the time when it was added is written in the cluster header. During defragmentation, empty clusters are left after files that grow often to lessen fragmentation. Also, the defragmentation utility runs in the background when the system is not busy.

Other features:

1. File associations are set up in a very structured way. When a user selects a file to open without specifying a program, the OS looks up the first program that has requested the file type. The OS then calls the specified procedure the the program's executable and gives the program a short time (a couple of milliseconds at the most) to respond on whether or not it is the correct format. If the program responds with a yes, the OS calls a different procedure in the program's executable that actually opens the file. If the program responds with a no, then the OS looks up the next program "in line" for the extension. It keeps doing this until it finds the right program. If a program is not found, the "open with" style window opens. This should take care of the problem of multiple programs that share the same exension having conflicts. :idea:
2. Full upgradability - nothing set up in a way that prevents changes being made.
3. Way more settings than anyone wants - have you ever noticed one of those little things in an OS that would have been so easy to change for the programmer, but they didn't bother? :sad:

If you have any ideas, criticisms, modifications etc. I would be glad to hear them. I want to plan this thing fully before I start working on it - I don't want to make a windows clone. Thanks in advance for your ideas. :cheesy:

[hexstar]

The following are also good ideas IMO:

1) Network support for TCP/IP and NetBIOS with generic PCI NICs and PCMCIA NICs both wireless and not
2) NTFS, FAT, and FAT32 along with Linux/Unix and Mac filesystem support
3) Alt+tab support
4) Print key support for dumping screenshots (configurable in a control panel perhaps), would by default make dumps on the main dir in incrementing file names e.g. screendump1.jpg, screendump2.jpg, etc
5)at least some of the OS opensource or some kind of api kit to aid in app development for the os
6)optional graphical interface
7)some games :p and maybe even a calculator XD
8) a browser, DSL support, and dial-up support (via generic modem driver)
9)a windows/mac/linux/unix emulator

[Puckdropper]

Write it in Ada! Ok, perhaps not realistic... It would make it easier for me to write programs for it, though. (Also, Ada tends to make more secure code.)

You may not want to limit file name characters THAT much.

May I suggest a specific file hierachy?

/OS directory/
/os directory/os specific settings
/OS directory/global DLLs (OS provided)
/OS directory/updated DLLs (Allow for updates, but this is checked first. If a problem occurs, then the OS refers the original.)
/User/username/documents
/user/username/programs
/user/username/programs/program directory

The program directory contains everything in the directory to run the program. No more installing DLLs all over Windows or writing and not removing settings in the registry. If you delete the program directory, everything but what YOU moved elsewhere is gone.

I suggest this file structure because I don't like the way Windows and Linux are set up. Windows requires things to go all over the hard drive, making uninstall difficult, especially if the uninstaller doesn't do it's job. Linux stores things all over the hard disk, also. I suppose it makes it easier for the system, but finding something myself is difficult. Remember, KISS. (Keep it simple, Stupid.)

[Toba]

The following are also good ideas IMO:

1) Network support for TCP/IP and NetBIOS with generic PCI NICs and PCMCIA NICs both wireless and not
2) NTFS, FAT, and FAT32 along with Linux/Unix and Mac filesystem support
3) Alt+tab support
4) Print key support for dumping screenshots (configurable in a control panel perhaps), would by default make dumps on the main dir in incrementing file names e.g. screendump1.jpg, screendump2.jpg, etc
5)at least some of the OS opensource or some kind of api kit to aid in app development for the os
6)optional graphical interface
7)some games :p and maybe even a calculator XD
8) a browser, DSL support, and dial-up support (via generic modem driver)
9)a windows/mac/linux/unix emulator

1) Good ideas, but I'm not sure how feasable that is. How difficult is it to detect and deal with PCMCIA and PCI cards?
2) Also good ideas, but all these different features are going to slow things down.
3) Great idea, I think shortcuts to switch programs are always good. I could also find out the Linux default key shortcuts and make them work as well (both Linux and Windows users would like this).
4) You seem to forget that I was planning on text mode... :)
5) API kit is an obvious one, I would do that. Might make it open source too.
6) :eek:
7) Text-mode games.... bleh
8) Yowsers
9) AAAAAAHH! :eek:

Good ideas, but maybe not for my first version....

Write it in Ada! Ok, perhaps not realistic... It would make it easier for me to write programs for it, though. (Also, Ada tends to make more secure code.)

You may not want to limit file name characters THAT much.

May I suggest a specific file hierachy?

/OS directory/
/os directory/os specific settings
/OS directory/global DLLs (OS provided)
/OS directory/updated DLLs (Allow for updates, but this is checked first. If a problem occurs, then the OS refers the original.)
/User/username/documents
/user/username/programs
/user/username/programs/program directory

The program directory contains everything in the directory to run the program. No more installing DLLs all over Windows or writing and not removing settings in the registry. If you delete the program directory, everything but what YOU moved elsewhere is gone.

I suggest this file structure because I don't like the way Windows and Linux are set up. Windows requires things to go all over the hard drive, making uninstall difficult, especially if the uninstaller doesn't do it's job. Linux stores things all over the hard disk, also. I suppose it makes it easier for the system, but finding something myself is difficult. Remember, KISS. (Keep it simple, Stupid.)

You're probably right about not limiting the filenames so much... that could cause all sorts of problems when people try to copy files onto this system from a different OS over the network. Here is what I'm thinking of for a file hierarchy:

drive number (none of this "you can only have 26 drives because there are only 26 letters" hogwash):/foldername/filename.ext

1:/os/ ;OS components and executables
1:/os/libraries/ ;DLL type stuff
1:/os/settings/ ;Settings
1:/applications/global/appname/ ;Programs accessible to all
1:/applications/username/appname/ ;Programs belonging to a single user
1:/users/username/documents/ ;User's docs
1:/users/username/settings/ ;User's individual OS settings

Applications that want recognition from the OS (file associations etc.) must follow strict rules. When programs are removed, all recognition is removed. For instance, if a program asks to "own" the file extension .jpg, but another program already had it, the OS will ask the user if this should be allowed to happen. During uninstall, the OS will return ownership to the previous program, if it is still installed. This allows completely clean installs and uninstalls. Applications can put whatever they want within their own directory, but it is encouraged to follow the same internal folder structure the OS uses in 1:/os/*.

Of course there would be multiple layers of users, such as limited users (no installing programs, can only work with their own documents, global applications, and their own settings), trusted users (can install own programs, but no installation of global apps), and root users, who can do whatever they darn well please.

I've noticed that this OS has been experiencing "scope creep"... :-|

[big_k105]

is this os goin to be a complete full featured os. if so i think you are goin to have a hell of a time trying to get all the features you want out of this just using assembly. i would create as much as you can with assembly and then do the rest in C. i think it would just make things easier on you :) but do the main development in assembly

[Chainsaw]

What is the intended use for this OS? Since it is text-only, I'm assuming it would be for experimentors or servers.

If it is for servers, you'll need pretty rich device support for networking, disk drives, memory management, printers, and the like. What about dual drive writing (perhaps support for RAID systems)? What about multiple processors, or some sort of failsafe/failover system for reliability.

I think you have a good idea, but I also think that Unix started this way: a very simple alternative, text only, reliable, etc. Now look at it! It is everywhere, and can be as clean or as buggy as anything else, based on what other stuff you load on it.

What about an approach where the OS actively protects apps from doing stupid things and from other apps. Not just memory management, but maybe a 'profile' that limits the program in some ways (disk use, cpu hogging, memory space/use, network use). If you did it well enough, no one would need virus checkers! Spyware wouldn't work unless specifically authorized!

[Toba]

Yes, I know it will likely be very challenging to do most if not all of this in ASM. I'm going to do as much as I can that way anyhow... but I don't know how long my zeal for small and fast code will last though once I start development. The kernel and most OS components will be done in ASM for sure - I don't want to have something that's running all the time wasting processor power.

Chainsaw, I'm not really sure what this OS will be for...
I'm just going to go with making a boot loader and kernel at first. I'm still not sure how to interface to network hardware without drivers and I don't want to have to write drivers for every bit of hardware I use. Does anyone know how use hardware without drivers?

BTW Chainsaw, spyware and viruses won't really be as big an issue - security through obscurity. This doesn't mean that I wouldn't make AV software later if viruses did come out, however.

[rishi]

I've been thinking of creating an OS lately. I'm hoping to make a text-mode OS in full assembly language that runs fast, has no bugs or security holes, and is the "best" operating system I can think of. Have you ever seen an OS that had nothing you thought could be better?

So far, here are my ideas:

Process handling:

1. Multiple Processes can run at once.
2. ALL processes except the kernel show up in a task manager (no way to hide).
3. When you choose to end a program from the task manager, the kernel just deallocates resources used by the process, stops giving the process timeslices, and clears the memory it occupied. None of this "not responding" garbage.
4. Priority on processes is floating-point from zero to one. Only the task manager can set these priorities, however (removes likelihood that a malicious process can claim all processor power).

File system:

1. Spaces, symbols, and weird characters may not be used in filenames. A-Z, a-z, 0-9, -, and _ are the only allowed characters. The extension is a separate field (no need for worries about periods) as is the directory.
2. Whenever a cluster is added to a file, the time when it was added is written in the cluster header. During defragmentation, empty clusters are left after files that grow often to lessen fragmentation. Also, the defragmentation utility runs in the background when the system is not busy.

Other features:

1. File associations are set up in a very structured way. When a user selects a file to open without specifying a program, the OS looks up the first program that has requested the file type. The OS then calls the specified procedure the the program's executable and gives the program a short time (a couple of milliseconds at the most) to respond on whether or not it is the correct format. If the program responds with a yes, the OS calls a different procedure in the program's executable that actually opens the file. If the program responds with a no, then the OS looks up the next program "in line" for the extension. It keeps doing this until it finds the right program. If a program is not found, the "open with" style window opens. This should take care of the problem of multiple programs that share the same exension having conflicts. :idea:
2. Full upgradability - nothing set up in a way that prevents changes being made.
3. Way more settings than anyone wants - have you ever noticed one of those little things in an OS that would have been so easy to change for the programmer, but they didn't bother? :sad:

If you have any ideas, criticisms, modifications etc. I would be glad to hear them. I want to plan this thing fully before I start working on it - I don't want to make a windows clone. Thanks in advance for your ideas. :cheesy:

hey i think ur basically some how taking hints from existing os but i donot like it. if ur a very good programmer we can colbrate to have a new os . i have a picturised ideas about the intyelligent and very fast os.
pls reply me on [e-mail]
pls also tell me abt u all
bye
.............waiting for new generation of os..............
rishi

[rishi]

i think u are not basically concentratting on any idea but just try to copy for pre-existing sysytems. i have a new idea of fast comps which i call as ""dsf"
if u are a comp programmer we can colabrate for developing
pls reply me on [e-mail]
---------------wating for new generation of os---------------
rishi

[Toba]

I was considering collaborating with you, but your poor grasp of the english language changed my mind. Sorry.