On Thu, Sep 27, 2012 at 4:25 PM, Mateusz Viste <mate...@viste-family.net> wrote:
> Marcos, Dennis - thanks for your valuable input. I see with only two
> answers that we already have two very different point of view (Marcos
> using a more 'classic' DOS-ish directory structure, while Dennis prefer
> to unixify his environnement).
Every user will have a preferred organization. One size will not fit all.
I did the unixification back when on my original MS-DOS machine (which
is sitting on a shelf). I had a Unix machine (an AT&T 3B1) before I
got a DOS PC, and I wanted the DOS box to resemble the Unix machine
where possible. I ran a commercial package called the MKS Toolkit,
that provided DOS versions of most Unix utilities that made sense in a
single user, single taking environment. The selling point was a very
complete DOS version of the Unix Korn shell, that had everything save
asynchronous background processes (because DOS mostly didn't *do*
The Toolkit offered a highest Unix compatibility mode. Run it that
way, and COMMAND.COM was replaced as your boot shell in CONFIG.SYS by
the MKS INIT.EXE program. Boot the system, INIT would load, and print
Login: on the screen. Enter and ID and optional password, and INIT
would call LOGIN, which checked the ID against an /etc/passwd file.
If it found the ID, it changed to the directory specified as that ID's
home directory, and loaded whatever was specified as that ID's shell.
I had IDs that ran the MKS Korn shell, vanilla COMMAND.COM, 4DOS, and
DesqView. When I wanted to switch environments, I logged out of the
current shell, control returned to INIT, Login: got printed, and I
logged back in under a new ID. I could switch environments without
rebooting, and when I was up under the Korn shell, you had to dig a
bit to tell it *wasn't* an honest-to-Gos Unix box.
* The exception to background processes was the DOS PRINT command,
which installed a resident extension that time sliced and allowed you
to print in the background. I used Korn shell aliases and functions
to implement a version of the Unix LP command built on top of PRINT.
When Win 3.1 joined the family, I modified the technique. Windows 3.1
still had the concept of the user's shell, which defaulted to Program
Manager, but there were a variety of alternatives and you could
specify which you preferred in SYSTEM.INI. I used MKS IDs that
diddled the SYSTEM.INI file to specifiy the desired shell, then ran
Win3.1 with that spec.
> This makes me think that we definitely must have some flexibility in
> handling packages, and make installation paths configurable as much as
> possible (with some 'standard' default configuration for users that
> don't care about where their software is installed on disk).
My preference, if doable, is making where things get put user
specified, with a default if an alternate choice is not given.
> I'm also wondering about what to do with configuration files of
> applications... In FreeDOS 1.0, configuration files for the few system
> tools that require them are stored right in %DOSDIR%\BIN. I really don't
> like this (am I alone?). I'd prefer to have a dedicated directory for
> system tools configurations... let's say something like %DOSDIR%\cfg\ ?
> What do you think?
This is a subset of the issue above. If I choose a non-standard
location to install something, the config file that something uses
needs to be modified as part of the install to reflect that.
> I do know that this is not as easy as it sounds, because it would
> require to modify these tools to make them look at this specific
> directory, but this doesn't seem unrealistic, does it?
I'm opposed to that sort of config directory. To the extent it makes
sense, that should be user specifiable, too. Most apps under FreeDOS
will have app specific configs that won't live in a global config
directory, and will usually be found in the same directory where the
app is installed.
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Freedos-user mailing list