OSDev.org

I wonder whether anybody has toyed with the idea of writing a multi user OS for the PC. Modern base units ought to be easily capable of supporting at least two users. I am not asking whether there is a demand for such a thing (although it might be cheaper than two complete systems), but just whether it could be done just for the hell of it. Apart from pairing off keyboards with monitors, to form "dumb terminals", I can't see any obvious problems.

Hi,

mathematician wrote:I wonder whether anybody has toyed with the idea of writing a multi user OS for the PC. Modern base units ought to be easily capable of supporting at least two users. I am not asking whether there is a demand for such a thing (although it might be cheaper than two complete systems), but just whether it could be done just for the hell of it. Apart from pairing off keyboards with monitors, to form "dumb terminals", I can't see any obvious problems.

It is entirely possible to have 2 or more users using the same PC at the same time (without virtual machines). I'd also be tempted to say that all the problems are obvious (e.g. video driver/s that allow the OS to support multiple monitors).


Cheers,

Brendan

Brendan wrote:It is entirely possible to have 2 or more users using the same PC at the same time (without virtual machines). I'd also be tempted to say that all the problems are obvious (e.g. video driver/s that allow the OS to support multiple monitors).

My first thought would be to have multiple drivers servicing multiple "terminals", rather than having one driver trying to cope with several terminals.

Just come up with an interesting idea that, while the computer control all the displays and input devices.
Each user would have their own dedicated input and display.

Next, generalize it so that users just works on their own "application window", which can be put on any display.

Now the users would want to communicate, and they may grant access (read-only or rw) of such display/window to other user.

Now generalize this so that users across network could share displays.

Opps you now re-invented VNC

mathematician wrote:My first thought would be to have multiple drivers servicing multiple "terminals", rather than having one driver trying to cope with several terminals.

What do you do when both monitors are connected to the same video card?

Connect a vt52/vt100/vtWhatever to the serial port and run a login shell, or connect a Xterm via the network. It's no different to what you're suggesting, it's a question of which bus is used. At uni in the early nineties there were hundreds of us connected to mainframes this way. These mainframes(?) were Sequent Symmetry machines built with multiple 80386 or 80486 processors and they ran BSD if I'm not mistaken.

bwat wrote:Connect a vt52/vt100/vtWhatever to the serial port and run a login shell, or connect a Xterm via the network. It's no different to what you're suggesting, it's a question of which bus is used. At uni in the early nineties there were hundreds of us connected to mainframes this way. These mainframes(?) were Sequent Symmetry machines built with multiple 80386 or 80486 processors and they ran BSD if I'm not mistaken.

That presupposes that the operating system would only be pushing out text, which is not necessarily so. In any case, I haven't got any ancient terminals available to test it on.

mathematician wrote: That presupposes that the operating system would only be pushing out text, which is not necessarily so.

I'm editing cause I guess you've understood Xterm to be an application and not an X-terminal which was a thin-client thingy that gave you a graphical interface.

bwat wrote:I'm editing cause I guess you've understood Xterm to be an application and not an X-terminal which was a thin-client thingy that gave you a graphical interface.

That's how I'd interpret it. I've only ever heard hardware X-terminals referred to by the full phrase "X-terminal", whereas "xterm" is the name of the standard terminal emulator for X.

Brynet-Inc wrote:http://en.wikipedia.org/wiki/Multiseat_configuration

Quite interesting.

Windows Multipoint Server does this. Servicing different users on each monitor is actually much easier than joining them to form a large desktop, as you don't have to deal with the same window being visible on displays with conflicting color formats and connected to different adapters.

My first thought would be to have multiple drivers servicing multiple "terminals", rather than having one driver trying to cope with several terminals.

Obviously, it's not the user interface's job to manage and load drivers for various devices. A driver will handle any number of devices which it supports, and each of these might in turn cause some number of interfaces to be presented to applications. The UI and the graphics subsystem will probably care about what monitors are connected to the same adapter, but it doesn't matter if different adapters are handled by the same driver or different drivers.

Gigasoft wrote:Windows Multipoint Server does this. Servicing different users on each monitor is actually much easier than joining them to form a large desktop, as you don't have to deal with the same window being visible on displays with conflicting color formats and connected to different adapters.

My first thought would be to have multiple drivers servicing multiple "terminals", rather than having one driver trying to cope with several terminals.

Obviously, it's not the user interface's job to manage and load drivers for various devices. A driver will handle any number of devices which it supports, and each of these might in turn cause some number of interfaces to be presented to applications. The UI and the graphics subsystem will probably care about what monitors are connected to the same adapter, but it doesn't matter if different adapters are handled by the same driver or different drivers.

Well, if you have a single driver trying to manage multiple terminals, you must somehow arrange for it to have multiple copies of its internal static variables. With multiple drivers that problem is solved automatically. If the boot loader was any good at its job, only the static data would be loaded multiple times, and the code only once.

Hi,

Some diagrams!

Single user, single monitor: Single user, multiple monitor, single video card: Single user, multiple monitor, multiple video card: Multiple user, multiple monitor, multiple video card: Multiple user, multiple monitor, single video card: Multiple user, single monitor, single video card (split screen?): Of course more bizarre setups could be possible - e.g. 3 users sharing 4 monitors (with 1.33 monitors each). Mostly; each video card would provide an interface for each (real or virtual) monitor, and you only really need a flexible way to map "monitor interfaces" (and keyboard, mouse, joystick, touchscreen) to virtual consoles.


Cheers,

Brendan

mathematician wrote:Well, if you have a single driver trying to manage multiple terminals, you must somehow arrange for it to have multiple copies of its internal static variables. With multiple drivers that problem is solved automatically. If the boot loader was any good at its job, only the static data would be loaded multiple times, and the code only once.

Except that it doesn't make sense. The OS doesn't even know how many monitor outputs there are, only the video driver knows. Once the video driver "detects" a monitor output, what driver should be loaded and what would be the purpose of such a driver? Should it load more copies of itself? Which one would be responsible for managing VRAM and issuing commands to the card? What would the others be doing?