MultiDesk User Guide

From OS2World.com Wiki
Jump to: navigation, search

[[Image:]]


Contents

General Warning

This is a beta release, so the usual disclaimers apply. Also please note that this program messes with your desktop and INI files, so PLEASE make a backup before installing/using it. Even if I tested thoroughly the program and found no dangerous situations, it's always better to be safe than sorry.


Quick Introduction

µDesk (stands for MultiDesk) is a program that will let you have multiple desktops on OS/2.

Actually, it does something more: it presents you with a login screen at boot time, and when a user is recognized it can:

  • setup environment variables (e.g. HOME, USER, etc)
  • lock some files so that users won't touch them
  • run a customizable rexx script before and after login
  • start a customized desktop
  • keep track of logins (user name, time, failed logins..)


NOTE: MultiDesk offers some mild security features. While this features will probably improve in the future, don't expect too much from this: every user with enoguh skills and knowledge of OS/2 can bypass it. I'm not going to use SES (at least for now) because it is too buggy at this stage.

The µDesk package includes two programs: µDesk itself, which manage logins, and µAdmin, which manage user/desktop pairs.

µDesk is very easily configured through a simple text file, with few options. A sample configuration file is included, with tons of comments.

µAdmin don't need any configuration, and will instead help you (the administrator) to create/manage the users and their desktops.

Here are the contents of the folder as created by the installation package:

[[Image:]]

Sample Configuration File

# -- MuDesk configuration file --   

#   

# !!!! Don't put spaces around the "=" sign !!!!   

#   

#-----------------------------------------------------------------------------   

# The system will automatically login this user after default_user_timeout   

# seconds, if this variable is set. You can comment it out, or leave it blank   

# to disable automatic login.   

# Note that setting the timeout to 0 will also disable auto-login.   

#   

default_user=cris   

default_user_timeout=20   

#   

#-----------------------------------------------------------------------------   

# The root user is the user that has access to all the log files, the   

# config files, etc. Here you tell how the root user is named. Default is   

# 'root'.   

#         !! IT IS NOT POSSIBLE TO SET DEFAULT_USER = ROOT_USER !!   

#   

root_user=root   

#   

#-----------------------------------------------------------------------------   

# If this is set to YES, then MuDesk will NOT ask to enter a password. Also,   

# this enables starting the default_user by simply pressing "ENTER" when the   

# login prompt shows. Default is NO.   

# Note however that log files, config files, etc are still locked to everyone   

# but the root_user (which will always require a password).   

#   

relaxed_security=NO   

#   

#-----------------------------------------------------------------------------   

# After ssaver_timeout seconds without user interaction, the screen will be   

# blanked. Note that screen blanking is never disabled. If you do not specify   

# it, it will be set to the default of 120 seconds.   

#   

ssaver_timeout=60   

#   

#-----------------------------------------------------------------------------   

# If this is set to YES, all logins will be logged to the log_users_file file.   

# Note that this file will be readable only by the root user.   

#   

log_users=YES   

log_users_file=E:\SysBoot.Log   

#   

#-----------------------------------------------------------------------------   

# This is where the users tree is created by default. This is only used by   

# administration program.   

# You can override this setting on a one-by-one basis, by using the   

# administration program.   

#   

users_tree=E:\Users   

#   

# -- end of cfg file --

MultiDesk Administrator

[[Image:]]

Save button: saves all informations about users.

Revert button: reverts to the last saved status. NOTE that it simply re-reads the user information from disk: it will NOT undo desktop creations and such.

New user: start creation of a new user.

Delete user: start removal of a user.

Move: moves the window around. Click on it, and then use arrow keys to position the window. Press any other key when done (you will see the icon change).


N.B. To change user settings, you can use in-place editing.

New User Creation

First of all, you're asked the name of the new user. Don't use names already entered.

After that, you're asked if you want to create a standard tree for the user. This will create a user directory under the main user tree (look in mudesk.cfg) and place there some precompiled configuration files, the user and system INI files, the "desktop" tree, the "nowhere" directory, etc.

[[Image:]]

You can choose not to create a standard tree (for example because you want to put the files somewhere else, or because you're assigning a user to the standard OS/2 configuration with INI files in \OS2). In this case you'll have to complete the fields manually after the creation ends, and eventually create all the files that are needed and not already present.

Then you're asked if you want to customize the INI files.

In this step you're allowed to copy some predefined groups of INI entries from another user's INI files. There are one group for printers, one for display, one for sounds, etc.. You can choose all the groups that apply. Of course, you have to select the source INI files using the drop-down box.

Here the program will take care of copying all that is necessary for a group (e.g. it will copy about a dozen INI entries for the "Printers" group).


Clicking on the "more..." button, you're presented with the complete list of entries in the INI files of the source user. This is for expert users that know what they are doing. You can choose the entries that you want to be copied to the new user's INI files.

You can repeat the steps above, to copy some of the settings from a user, then another few settings from another user, and so on.

[[Image:]]

Things that you may have Missed

The mudesk.bnr file is a banner that you can customize. It is displayed just before the login request upon boot.

The <user>.env file contains entries that are added to the main environment. You can use variable substitution here. For example, if you want to add the e:\apps\dummy directory to the path, you can add a line resembling the following:

PATH=%PATH%;e:\apps\dummy;   

The mudesk.lck file is initially a 0-byte file. But if you enter one (or more) fully-qualified pathname(s) here, they'll be locked on next reboot. You can enter as many lines as you want, one pathname for each line. Remember that those locked files are always accessible to the root user.

The mdstart.cmd file in MultiDesk's directory is the pre-login rexx script. It is customizable by the administrator. Look in the source to see which parameters are passed by the login program.

The mdstart.cmd file in each user directory is the post-login rexx script. It is executed when the user is recognized after login, and is customizable by every user. Look in the source to see which parameters are passed by the login program.

The mdstart.usr file in MultiDesk's directory is the template used to create the post-login rexx script for each user. The administrator may adapt it, to make common changes that he wants for every new user created.


Who needs it?

  • Developers who want a fast, light desktop, with only the tools needed to

develop their applications and no fancy (and crashy) things. Also they can experiment with WPS programming without touching their 'real' desktop.

  • Home users who want to share their PC with their wife/husband/son(s).
  • Users who like to fiddle with their WPS, or like to experiment new (and risky)

software.

  • Users who have an instable desktop: they can crate a new, fresh one, use a

product to do a 'portable' backup of their old desktop (e.g. with Object Desktop, WPTools, UniMaint), and then restore it on the newly created desktop. They will have a copy of the desktop without all the instabilities due to installing/removing/reinstalling of objects/classes. And they can test it to see if it fits their needs before removing the old one!!


A Few notes about MultiDesk

Why

It started out as a way to let my wife use my OS/2 partition, 'cause she always had problems with her Win95 one. Then, I went ambitious :-)

Why anohter multi-user-desktop software

I tested all commercial/shareware/free packages I could get. Noone satisfied me. I wanted to be able to have separate user_ini *AND* separate system_ini, so that I could use different desktop enhancers on different desktops (e.g. Object Desktop 2.x on one desktop, and XWorkplace on another). All tested programs had problems (nearly all were very old), most were no more supported, none was flexible enough. For a few months I did beta-testing for 'Secure Desktop', but at some point it was clear it wasn't going anywhere fast (due to the problems with SES). It has now been abandoned. So I sat down...

Why the different Approach

All above packages use the dreaded PrfReset() API, to change the INIs on the fly. While this seems a good approach, since it allows changing desktop without a reboot, it brings so many problems and limitations that after a few experiments I decided to take another route. So I opted for the most compatible and documented way: changing the USER_INI and SYSTEM_INI variables in the config.sys before the WPS loads.

Which are the problems and limitation with PrfReset

First of all, PrfReset cannot change the system_ini, so this is a show-stopper, if you want to be able to have different registered classes on different desktops.

Also, PrfReset broadcasts the 'PL_ALTERED' message to all message queues to indicate that applications should re-read their settings from the new set of INI files.. but there are nearly no applications that intercept this message. Well, applications could be closed upon a desktop switch, so that on restart they would pick up the changes... but not all applications can be restarted. For example, if you have a desktop enhancer (Object Desktop, CandyBarZ, Styler/2, XWorkplace, etc..) you can't unload it, because of the way it gets loaded upon (or before) WPS start (I won't go into details here, but if you want to know more you can write me).

PM itself won't pick up some changes on desktop switch (e.g. change of system fonts in which the standard message boxes are displayed).

In short, after changing the desktop just once, you end up with a mess of the previous desktop settings and the actual ones (at least if you don't have a super-simple desktop setup).

Which are the bonuses and downsides you get with MultiDesk's approach?

The only downside is that you have to reboot to change desktop (at least for now.. see Help Me!!). Given all the bonuses of this approach, I felt it was a small fee to pay. Also, nowadays' PCs boot so fast that it isn't a real problem, other than resetting your uptime counter ;-)

The bonuses are many (also see Who Needs It?):

  • Have different user_ini *and* system_ini files for each user.
  • Have different screen resolutions on different desktops/users.
  • Have different WPS enhancers on different desktops/users.
  • Have different WarpCenter configurations on different desktops/users.
  • Have different environment settings based on the user.
  • Have users who don't use the WPS for their desktop (e.g. PC/2, CMD.EXE, etc.)
  • Protect some files from other users (mild security)

All the above things are simply not possible with the PrfReset approach, or are completely new achievements made possible by the fact that µDesk loads before the PROTSHELL.


Using uDesk without Rebooting?

Well, in principle it would be possible to use µDesk without rebooting: since it loads before the PROTSHELL, that is before PM and the WPS, it could shut down both this programs when asked to switch desktop. BTW, while it is fairly simple to shut down and restart the WPS, I've found absolutely NO way to do the same with PM.

That is: if you try to kill the first instance of PMSHELL (which initializes the PM environment), the system will lock up solid. This happens even if the first instance is a child of µDesk, and has been spawned by it.

The real problem is that PM has been written without thinking about the possibility of stopping it. Even on shutdown, the system is locked so that you can't do anything anymore, but PM is still there and functional.

So, if anyone knows anything more about PM internal structure, or knows a way to kill and restart it without locking the system, please let me know!!

Another approach that comes to mind would be a fast-reboot feature. I remember a third-party DOS memory manager that had such a feature: it did not reboot the whole system, but only made some sort of tweaking to let DOS reload completely. I don't know how it was done, and don't know if it is possible under a protected operating system like OS/2, but if someone has ideas...


The Author


Disclaimer

Copyright (C) 2000-2001 Cristiano Guadagnino.

This program is free software; you can redistribute it, provided you don't ask a fee for it.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.