OSDev.org

hmm. Aren't you picking stuff the wrong way ? i mean, is it really necessary for a remote-control program to be able to send 'ALT+TAB' or do you just need a 'window_manager::cycle_active_window()" function call ?

Sending keyboard events means that you can also send 'CTRL+ALT+DEL' or any unwished sequence, including fake passwords or e-mails, etc.

So how would you go about doing it?

I need to have the up button on the remote control execute the keyboard up so I can play tetris from my couch. The tetris program is another program. I need a way for program A to press button up on Program B (tetris).

I would have the window manager accept input from either the keyboard driver or the remote access layer, and sent graphical output to both the video card and the remote access layer. User applications would not (and should not) notice any difference.

I would probably have two copies of the window manager, though: once connected to the keyboard/mouse/video card, and one connected to the remote access device. Each window manager would have its own set of client apps, so each users' apps wouldn't interfere with each other.

yup. Tim sounds right... Let your GUI toggle between device://keyboard or device://remote-control or even device://virtual-keyboard (which could be some speech-to-text, handwriting recognition or whatever) ...

When one input is available, the GUI takes it, otherwise, it tries to stick to the next one...

Well, I'm a relative newbie on the actual implementation side of things (plus I haven't had time and motivation co-inciding for a while), but I have a few higher-level ideas that hopefully will be interesting.

First off, I thought the concept of "filters" might be useful. Many UNIX programs can be chained together with pipes, so that the output of program X gets fed into the input of program Y. Well, it might be a good idea to formalize and expand on this idea. So you have a bunch of filter applets, each taking a certain number of input streams and producing another number of output streams. So these could be used for such things as compression, spell-checking, all that fun stuff. But since they can do more than one input and output at once, they're more flexible, for instance you might want to use one as an automatic sound-mixer. And they'd all be arrangable in a nice drag-n-drop interface with pop-up config boxes, instead of remembering zillions of command-line switches.

I have a few other thoughts, but I gotta run, so I'll post 'em later.

nice to see i'm not the only one to dream about such a silly thing. The way i envisionned the GUI to control that kind of stuff (creating complex filters) was looking like a jigsaw.

You initially insert "stream producers" that will for instance come from some application's data plug and then you can pick filters (like grep, etc). from drop lists (or contextual menus based on the "type" of the data provided by a filter/producer). Right-clicking on a component would allow you to setup its options through a dialog (which could be auto-generated by inspecting the "--help" data plug of the filter).

Finally, you should be able to name your own new filter and define which arguments it could receive and how arguments are transmitted to sub-components ...


okay, i must admit this is massively inspired from MIT's gui to program LEGO MindStorms ... but who cares

It would be great if there was an os that used a search engine instead of folders and stuff.

It should also have an options that automaticly fixe your problem. I know its just a computer but their should be a way to just say turn on the sound and it automaticly turns off all options that disable sound.

It should also let programs just run like video games.

I've started to rewrite my operating system in C++ with a new modular design. It is going to be designed as a workstation os rather than something you would want to run on a server.

Design Specs
Microkernel
Modular design
Realtime scheduler
Posix libraries
Support for WDM and other popular device driver models

Microkernel is cool.

It *requires* modular design.

I for my part don't fiddle with *real time* scheduling. I am happy with three or more queues, one of them being the round robin queue for the user processes in which a priority-sorting is done.

For now, I 've also got the beginning of a service-naming system, with which the system services register/unregister at start-up: they just indicate their system-wide name and their process number to a kind of list. User processes or other services can query this list to obtain the service' process number (which is needed to send a message to it). First service which registers at the moment is the windowing service.

Mac OS X (panther) seems to follow that approach. No need to say that it's much the kind of stuff i want for Clicker too ...

However, one should keep in mind that documents are not the sole files that the OS stores, but that it also needs configuration files, preferences, temporary items, libraries, etc. So under the graphical presentation (which could be augmented by a powerful search engine), there will always be a need for files & folders.

Note that most "good" shells integrate the search box within the display ... Imho, what it most lacks is a good content indexing technique (so that i can look for all the "documents" (.doc, .tex, .ps, .pdf, etc) that have the words 'ELF format' in them without needing to open all files ...
Another nice feature would be to allow searching both the local filesystem and the web in a single operation. Or that the local filesystem remembers of which remote file has already been downloaded and which wasn't, so that if i'm trying to re-download the 30-MB Intel manuals for the 4th time, the system could be able to tell me that it's locally available in documents://manuals/intel-p4.pdf, or that it has been saved on my Backup CD labelled "OS stuff" ...

I've had many of the same thoughts about content indexing and search engines.

It wouldn't be hard to create a SearchEngine class and some decendents (like GoogleSearch, FilesystemSearch, LocalLibrarySearch, etc). Then you could create a MultiSearch class that queries one or more SearchEngines whenever a search is performed, collating the results. You could also create filters of type SearchEngine. It is not hard to extend this idea. A small list of possible classes:

SearchEngine
MultiSearch
SearchEngineFilter
AdultContentFilter
RepeatedContentFilter
GoogleSearch
FilesystemSearch
LocalLibrarySearch
StreamPipe
StreamTee
Grep
Sort
Uniq
StreamProvider
FileStreamProvider
TcpStreamProvider
ChatClientStreamProvider
StreamConsumer
FileStreamConsumer
TcpStreamConsumer
ChatClientStreamConsumer
ChatClientProtocol
AolInstantMessengerClientProtocol
YahooMessengerClientProtocol
IrcClientProtocol
Trigger
TimedTrigger
DataAvailableTrigger

The shell could allow you to combine classes to create powerful tools without doing any real programming. This could be done graphically or through some sort of text interface.

One concept I've been thinking about for my os, and in particular my file system, was having multiple virtual filesystems on one physical one.

The idea exactly would be a new structure, the file system entry point list, defining a list of names and associated inodes, including the quota for those partitions. This would allow a sysadmin to give every user his own virtual "home disk" called home, without actually partitioning off 50MB for that user. It would allow dynamic resizing of virtual partitions, a system partition only the system itself could modify (and the user could modify only indirectly) and, one idea I liked a lot, a separate partition where all the files for a specific application are stored, together with its dependencies on other applications. This would allow you to make an application that uses a number of dynamic libraries for the application in specific, and a number of libraries for general use, and put them in two different locations altogether, thereby fully avoiding any mix of files, any sort of chaos (look in windows/system32 or /lib to see what I mean) and a number of lingering directories, save files and things like that (your program files or /usr directory).

A second idea would be to give each user on his or her own home site a configurable view on the computer disks. The user can set how he / she wishes to view the system, and what things should be used.

This allows the system to have a different directory structure for each user.

One of the final ideas I like a lot is the option to have the home site not on the harddisk of the user, but on an internet server somewhere. This would allow all users to make adjustments to their environment, and would allow them to work at any computer running my OS, with their own files and settings (limited as by the physical computer they're using).

And, because I'm not one of the "good guys", I'm not planning on giving my OS away for free, the space rental is a point of profit, as is the user usage limit. A user would buy for instance the 2-month right to use the OS on his/her computer with a specified set of programs, for which he/she would not pay the full quotum, but only the small portion he/she actually uses. This allows all users to test all applications you want to test (you buy the use for 2 hours / 1 day / 3 years, you decide), be as up to date as you want to be (within bounds, 1980 software might not be available anymore) and to use any computer you might find as your own. The downside would be that each user would have to pay at a fixed rate for a single service, that other providers offer for lower tariffs.

HTH, and if you are one of the good guys, ignore that last bit

on a marketting point of view, i'd drop for "OS rental" approach you propose. I admit that it make sense for professionnal applications (i.e. i cannot afford PSP6 and i *reaally* need it to work on 2 or 3 photos, so i can get a time-limited version of it) ...

But what good would a time-limited demo of an OS be ?? what would happen to all your preciousss data you stored in it ? The OS is what makes the machine run! if RentAnOs is all i installed and it's no longer usable because my credit went away, what do i use to pay another month of RentAnOS ??

In exactly that idea. If you want to test the OS you can buy a number of days to use it, and you can always enlarge the day count you have. Look at it like a prepaid phone on the current mobile phone circuits, if you buy some credit each 6 months your phone remains usable, if you don't, you lose your phone number. Transforming that to the OS & data world, you can use the OS if you have usage credit (based on usage or time), and if you have no credit and you don't add some in a (fill in time unit here) you will lose your data stored on the hired space. Your own computer data is not lost.


Well, this is quite the pitfall though... If I may link back to the mobile phone idea, they allow you to call only one number in order to up your mobile phone credit, and in this world that would be starting the OS in a guest-tour mode in which you can only create an account or add money to an account, or do a guided tour (say, a simple tour with half an hour of playtime in a limited demo).

Just wondering, what do you think of the other side of my original post?

well, i find the idea pretty interresting and i planned to do something alike for my own system too: having something like "docs://" as a file space for user documents (organized as the user like them to be) and other separate spaces for applications settings, preferencies, etc. I'm not conviced at all by the "one Single Tree" approach of Unix (though you could tease my and say "but what about /docs or /apps?")

I think that a given application should only be able to see what it has to see: its configuration/preference files, its internal files (plugins, data and resources, etc), and the files that the user allowed it to view for this session.

here come a bit more of my thoughts about it, if you're interrested...