Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-29 Thread Eric Auer

Hi Mateusz,

In FreeDOS 1.0, most packages were in the same directory
structure of the same main FreeDOS directory. I do like
that approach. Note that it was not extreme in that: For
example Arachne, FBC, Emacs, GS, Lynx OpenXP, Pacific C,
Pegasus Mail and Setedit all had their own directories,
because they are big and have many files. Also for games
it was the case that they all had their own subdirectory
of a single GAMES directory. For the GAMES, there is no
need (imho) to have them reachable in PATH and for thee
other mentioned parts, they sometimes had batch files in
the common freedos BIN directory to start them, which is
also a nice idea.

For the general packaging, I like this structure, all in
subdirectories of the common freedos directory:

- appinfo (one file per package in there: I do NOT like
  having a packages directory with many one-file subdirs)

- bin (one or few files per package, in PATH, and maybe
  drivers, not in path, to keep device drivers separate)

- doc (one directory per package, yet very few files,
  maybe could be NAME.txt w/o dir when onle one file?)

- help (one file per package per language, fixed naming
  scheme, HTMLHELP in a subdirectory or separate place)

- nls (one file per package per language, if available,
  often no file for English when that is a fallback in
  the binary, although good for translations to have it)

- source (one directory per package, only installed for
  those packages where I want to use sources, not all!)

- temp (could also be outside the freedos install tree)

Note that CPI / CPX and translations of ctmouse and the
fortune cookie file (etc.) have their own directories,
so for example BIN does not get clobbered by them. If
many apps had extra files, one could also consider a
tree with VAR name-of-package subdirectories, or SHARE
name-of-package, but it feels too un-DOS to do it often.

Note that this is just about FreeDOS and things which are
part of the distro. I keep my own files in many other dir
trees, e.g. one for arkade games, one for board games, or
one per programming language, with sources, compilers and
compiled projects as subdirectory trees. Other examples
are a directory for batch files, another non-FreeDOS BIN
directory, paint software, info software, audio things...
Even on a separate drive are self-made sources, collected
demos, books, texts, pictures, audio, Windows things...

So far for answering

 'how people store their stuff on FreeDOS'.

for my case :-)

 1. use %DOSDIR% for FreeDOS system, and other variables for other kind 
 of software (eg. %APPSDIR%, %GAMESDIR%, etc). This will require to store 
 an additional flag/marker somewhere to know what the package contains 
 (system stuff, games, or what).

To me it is okay that games end up in dosdir / games, simply being
packaged like that. I can still move them by hand later, of course.

 2. Make the packager scan the filelist of the packages, and make it 
 understand that whenever a file begins with 'games/' it's meaning in 
 fact %GAMESDIR%, whenever it sees 'apps/, it redirects to %APPSDIR%

It could do that, but that is not necessary either. On the distro
(and on the web) you can just keep the ZIP packages for each of
the categories in separate directories, while they can still unzip
into the same places. For example I would NOT want apps with few
files to unzip into separate diretories, I would just want their
binaries in BIN already many other FreeDOS binaries are :-) There
is no need to split them, they all come from one distro and will
all be free and (all?) open source :-)

 2b. To avoid troubles in future, we could say that everything that 
 starts with 'dosdir/' is redirected to %DOSDIR%, and anything else will 
 be caught by the packager that will tell the user it got an unknown 
 kind of package. This however will break FreeDOS 1.0 packages.

I would not do that. If you really are worried about splitting
packages, a very simple answer is to give the user for EACH of
them the chance to manually select another directory to install
to. This is what the user can do by manually unzipping anyway.

The installer could do for example the following: For each of
the CATEGORIES (as per directory where the zips are, NO MATTER
what is inside the zips directory structure wise) the user gets
asked if they should be installed into 1. the dosdir or 2. one
directory chosen by the user or whether 3. the user should get
asked for EACH package in which directory it should be. This
will make it easy to install BASE in dosdir, GAMES in games and
pack one directory for each package for, say, COMPILERS...

 Maybe there are other neat solutions that I am unaware of. Tell me.

Maybe I could give some inspiration :-)

 Another question: how are you storing your files on your FreeDOS 
 systems? As far as I'm concerned, I usually store games in a separate 
 directory, and other stuff under a 'programs' directory. But maybe other 
 categories would be needed? (like 'devel', 'emulator', 

Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-28 Thread userbeitrag
Hi!
Long time no see. I’d like to mention my POV anyways.

Why use a Unix-like structure?

In DOS, everything is where you want to put it.
Configuration files traditionally reside in the same directory where the actual 
program that uses it is located. If not, it has its own structure (like 
complex programs, games).

What I would like:
SYSDRV=C:
APPSDRV=%SYSDRV
GAMESDRV=%SYSDRV
DATADRV=D:
DOSDIR=%SYSDRV%\DOS
GAMESDIR=%GAMESDRV%\GAMES
APPSDIR=%APPSDRV%\APPS

For all the _binaries_ this would result in the following:

In %DOSDIR, everything that comes out-of-the-box with the DOS distribution 
goes, like the system files (FORMAT.EXE, SYS.EXE etc.) – it kind of is, what 
would be in C:\WINDOWS and C:\WINDOWS\SYSTEM[32] on a Windows system and in 
\bin, \sbin (and propably \lib) on a Unix system.

== Thus, all DOS stuff would be in C:\DOS

In %APPSDIR I’d put every optional application in its own directory %pkgname, 
like a word editor, vi, a paint program, even ViewMAX/OpenGEM and the-like.

== Thus, OpenGEM would be in C:\APPS\GEM

The problem is, that there are a lot of small DOS programs, that don’t need 
their own directory. For those, I suggest a “miscellaneous” section that I 
would name %APPSDIR%\BIN.

== Thus, a small (non-FreeDOS distribution) program, like TDE (Thomson Davis 
Editor: TDE.EXE, older version that ran with TDE.CFG and nothing else) would 
be in C:\APPS\BIN.

The games go to %GAMESDIR%\%pkgname.

== Thus, Ultima Underworld II would be in C:\GAMES\UW2.

For (optional) _documentation_ I suggest, where applicable:

DOCDRV=%SYSDRV
DOCDIR=%DOCDRV%\DOC

== Thus, the OpenGEM documentation would be in C:\DOC\GEM.

For (optional) _source files_ I suggest:

SRCDRV=%SYSDRV
SRCDIR=%SRCDRV%\SRC

If needed, the sources of the program would go into %SRCDIR\%pkgname.

Last but not least, _development stuff_ would go into:

DEVDRV=%SYSDRV
DEVDIR=%DEVDRV%\DEV

I would set this to DEVDIR=%DEVDRV, because this would get me Borland Pascal 
into C:\PASCAL, which I appreciate very much. But then, Pascal was the _only_ 
programming language I every /played/ with. But, you get the point.

Some optional system stuff, like DOS4GW and the-like, I’d put into $DOSDIR 
directly.


How is that?
Cheers,
Andreas.

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-28 Thread Rugxulo
Hi guys,

On Fri, Sep 28, 2012 at 1:19 PM,  userbeit...@abwesend.de wrote:

On Thu, Sep 27, 2012 at 1:16 AM, Mateusz Viste mateusz@viste- family.net wrote:

 Another question: how are you storing your files on your
 FreeDOS systems? As far as I'm concerned, I usually store
 games in a separate directory, and other stuff under a
 'programs' directory. But maybe other categories would be
 needed? (like 'devel', 'emulator', etc...?)

I'm not really using a stock FreeDOS install. In fact, I'm sure I ever
did. It was always piecemeal with me, done by hand. So I don't stick
to the normal FreeDOS layout. I don't even have all of BASE
installed, mostly because I don't seem to need it. I just grab what I
need and lump it somewhere.

I'm not saying it's the best way, obviously, but trying to organize
everything is difficult and error-prone.

 Why use a Unix-like structure?

 In DOS, everything is where you want to put it.
 Configuration files traditionally reside in the same directory
 where the actual program that uses it is located. If not, it
 has its own structure (like complex programs, games).

I'm no *nix expert, but I don't think argv[0] is reliable across OSes.
You can't always tell the full path of the program running due to
various reasons, esp. under *nix. So they tend to (apparently) put
everything in $HOME (aka, ~/) either in a hidden .blahcfg file or
.blahdir or some such.

Some DOS programs use %HOME% too, sometimes optionally, sometimes only
if %BLAHHOME% isn't found. But yeah, ideally, all .EXEs files would
look for config files in same dir as they are (ahem, FD EDIT, see my
crappy patch).

 The problem is, that there are a lot of small DOS programs,
 that don’t need their own directory. For those, I suggest a
 “miscellaneous” section that I would name %APPSDIR%\BIN.

I lump all my random stuff (that has no where else to go) that should
be universally available into C:\UTILS (current 272 files).

 == Thus, a small (non-FreeDOS distribution) program, like
 TDE (Thomson Davis Editor: TDE.EXE, older version that ran
 with TDE.CFG and nothing else) would be in C:\APPS\BIN.

I used to use that one but upgraded years ago to Jason Hood's 5.x
version, which switched to text (not binary) config for easier
management (plus syntax highlighting, regex replace, etc). On DOS, it
searched for TDE.SHL and TDE.CFG, both text files, in various places
(%HOME% ?? can't remember), usually found in same dir as TDEP.EXE
(which I renamed T.EXE for speedy access). Under Linux, tde looks
under $HOME, i.e. ~/.tdeshl and ~/.tdecfg.

 I would set this to DEVDIR=%DEVDRV, because this would
 get me Borland Pascal into C:\PASCAL, which I appreciate
 very much. But then, Pascal was the _only_ programming
 language I every /played/ with. But, you get the point.

When testing various compilers, I ended up having too many, so it
cluttered up my root drive. I ended up moving everything (with a few
config tweaks, etc.) into two main dirs, C:\C (for ANSI C stuffs) and
C:\W (Wirth, aka Pascal-y). If you're more sentimental, you could
perhaps name them C:\RITCHIE and C:\WIRTH directly, but I didn't.

A quick count shows 17 subdirs in C:\C and 10 in C:\W (with probably
more to come). Some of that is older versions installed too, for
comparison, but it's nice to have everything (mostly) in one place.

 Some optional system stuff, like DOS4GW and the-like, I’d
 put into $DOSDIR directly.

Sometimes it's useful to test other compatible extenders at random, so
I usually remove all local copies and just put a single copy in
C:\UTILS. In other words, I make sure there aren't erroneously old
versions lying around that are being used behind my back. So I only
have one CWSDPMI.EXE (r7) in C:\UTILS and not older ones in a billion
other places. Similarly for DOS4GW, though OpenWatcom I usually leave
(mostly) intact because it uses some oddball versions (e.g. DOS/32A,
Causeway).

What else did I forget? Oh yeah, you probably can't install DJGPP
proper (GCC) into C:\DEV as it uses /dev/c/somedir and /dev/env/PATH
etc. for special purposes. Not sure if only DJGPP-compiled stuff would
choke on that, doubt it, at least not as badly as the compiler itself.

Otherwise, my layout is fairly boring. C:\ZIPS (and a bunch of
subdirs, e.g. GFX, SOUND, INET, PROGLANG, OTHEROS, LFN, SHELL, EDIT,
I18N, CDROM, DOCUTIL) tries to organize things, esp. for reinstalling
or temporary installs of things I don't need all the time or just
older versions for regression testing or random source code or
whatever. C:\FDOS has some official FreeDOS stuff, but it's all in
there directly, not in C:\FDOS\BIN or \NLS or whatever. Random
projects I'm working on (or plan to) are in C:\WIP. C:\HX gets its own
dir tree. C:\DOCS is random stuff (and even .PDFs, which I hate).
C:\TEMP (formerly C:\TMP) is used for random holding place for things
to keep my attention (though at least one *nix port assumes the later
always exists. BTW, my normal real %TEMP% dir is a RAM disk.). I'm
really 

Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-28 Thread Mark Brown
part of the beauty of FreeDOS is that it's so versatile, so good,
thatyou can do stuff your own way with it - this, i think, is
not going to change, and i, for one, am all for it.

 

eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] FreeDOS packaging rules / paths

2012-09-27 Thread Mateusz Viste
Hi there!

I've discussed this topic with Jim out of the list, and decided to bring 
it onlist, as it has no real 'ultimate answer', and requires to know 
'how people store their stuff on FreeDOS'.

Now, what is it about:
FreeDOS packages are/were used primarily to package the FreeDOS system. 
The principle is simple: just take the zip, unzip it in %DOSDIR%, and 
generate a %DOSDIR%\packages\pkgname.lst file list to keep track of what 
happened.

But the packaging system could be (in fact, is already) also useful to 
package software not strictly related to the FreeDOS core - for example 
games, GNU tools, drivers, media players, whatever. All these have 
historically been unzipped in:
%DOSDIR%\games\pkgname (for games)
%DOSDIR%\pkgname (for everything else)

This is at least what FreeDOS 1.0 does, and what I do myself on FDNPKG 
v0.9 repositories.

Having this much stuff in %DOSDIR% is not really clean - %DOSDIR% should 
probably be used only for OS-specific files. Plus, some people prefer to 
keep their games, applications, etc on an entirely different disks or 
partitions (which is impossible using a single %DOSDIR% path).

Question to you - users of FreeDOS - how would you like software to be 
packaged? I believe stating it once for all and making it a 'standard 
FreeDOS rule' is highly necessary, to avoid any new packaging 
revolutions in the future.

I see two possibilities:

1. use %DOSDIR% for FreeDOS system, and other variables for other kind 
of software (eg. %APPSDIR%, %GAMESDIR%, etc). This will require to store 
an additional flag/marker somewhere to know what the package contains 
(system stuff, games, or what).

2. Make the packager scan the filelist of the packages, and make it 
understand that whenever a file begins with 'games/' it's meaning in 
fact %GAMESDIR%, whenever it sees 'apps/, it redirects to %APPSDIR%, 
etc... otherwise use %DOSDIR%. This is probably much more backward 
compatible.

2b. To avoid troubles in future, we could say that everything that 
starts with 'dosdir/' is redirected to %DOSDIR%, and anything else will 
be catched by the packager that will tell the user it got an unknown 
kind of package. This however will brake FreeDOS 1.0 packages. But on 
the other hand, it provides the 'soft type flag' right into the filename 
path, so no additional field is required. Plus, we could say that the 
first subdirectory is the env variable name to follow, then we don't 
need to make a static list of all possible software types upfront, and 
if/when the packager encounters a future type that doesn't relates to 
any already-existing variable, if would just tell the user, 'hey, this 
package tries to install itself into BOZOSTUFF/, but I lack a 
%BOZOSTUFF% variable!

My preference goes toward 2b, but this is kind of a personal preference, 
therefore I'd like to know how you all feel about it before implementing 
anything in FDNPKG.

Maybe there are other neat solutions that I am unaware of. Tell me.

Another question: how are you storing your files on your FreeDOS 
systems? As far as I'm concerned, I usually store games in a separate 
directory, and other stuff under a 'programs' directory. But maybe other 
categories would be needed? (like 'devel', 'emulator', etc...?)

tschüss,
Mateusz

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] FreeDOS packaging rules / paths

2012-09-27 Thread Marcos Favero Florence de Barros
Mateusz Viste on 27 Sep 2012 08:16:47 +0200:
 Another question: how are you storing your files on your FreeDOS
 systems? As far as I'm concerned, I usually store games in a separate
 directory, and other stuff under a 'programs' directory. But maybe other
 categories would be needed? (like 'devel', 'emulator', etc...?)

I don't have any games but if I had, they would be in
'c:\games'.

Programs are in 'c:\prog' directory, with subdirectories such as
databases, editors, image viewers, LaTeX, sound, spreadsheets,
text viewers, etc.

The above is for files in use. As to the compressed files, they
are in a 'd:' partition, subdivided in dozens of categories.

Marcos


--
Marcos Fávero Florence de Barros
Campinas, Brazil




--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-27 Thread dmccunney
On Thu, Sep 27, 2012 at 2:16 AM, Mateusz Viste mate...@viste-family.net wrote:
 Another question: how are you storing your files on your FreeDOS
 systems? As far as I'm concerned, I usually store games in a separate
 directory, and other stuff under a 'programs' directory. But maybe other
 categories would be needed? (like 'devel', 'emulator', etc...?)

My approach is hybrid.

The originally FreeDOS structure created by installing from CD is
intact, but there are additions.

I'm an old Unix guy, so part of the file system emulates unix.
There's a \bin directory with DOS versions of common unix uitilities.
Device drivers live in \dev.  Config information lives in \etc.
There's a \home\dennis directory, and a \usr directory, with a
\usr\bin directory below that. Various user installed applications
live under \opt, like aseasy, word, TDE and wpshell.

Outside of the unix-like structure, there are directories for 4DOS,
docs, games, batch files, and a few other things.

 Mateusz
__
Dennis
https://plus.google.com/u/0/105128793974319004519

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-27 Thread Mateusz Viste
Hello,

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).
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).

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?

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?

cheers,
Mateusz





On 09/27/2012 06:32 PM, dmccunney wrote:
 On Thu, Sep 27, 2012 at 2:16 AM, Mateusz Viste mate...@viste-family.net 
 wrote:
 Another question: how are you storing your files on your FreeDOS
 systems? As far as I'm concerned, I usually store games in a separate
 directory, and other stuff under a 'programs' directory. But maybe other
 categories would be needed? (like 'devel', 'emulator', etc...?)

 My approach is hybrid.

 The originally FreeDOS structure created by installing from CD is
 intact, but there are additions.

 I'm an old Unix guy, so part of the file system emulates unix.
 There's a \bin directory with DOS versions of common unix uitilities.
 Device drivers live in \dev.  Config information lives in \etc.
 There's a \home\dennis directory, and a \usr directory, with a
 \usr\bin directory below that. Various user installed applications
 live under \opt, like aseasy, word, TDE and wpshell.

 Outside of the unix-like structure, there are directories for 4DOS,
 docs, games, batch files, and a few other things.

 Mateusz
 __
 Dennis
 https://plus.google.com/u/0/105128793974319004519

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://ad.doubleclick.net/clk;258768047;13503038;j?
 http://info.appdynamics.com/FreeJavaPerformanceDownload.html
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-27 Thread dmccunney
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 ATT 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*
background processes.*)

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.

 cheers,
 Mateusz
__
Dennis
https://plus.google.com/u/0/105128793974319004519

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS packaging rules / paths

2012-09-27 Thread Mateusz Viste
On 09/27/2012 10:50 PM, dmccunney wrote:
 Every user will have a preferred organization.  One size will not fit all.

Yes indeed. That's why I believe the way to go will be using so,e env 
variables to store installation paths to software (dosdir, gamesdir, 
appsdir, develdir for starters, other might follow...)

 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.

In fact, I was thinking about only FreeDOS core tools (that is, these 
that would go install themselves into %DOSDIR%). The vast majority of 
3rd party software will have to be installed in their own directories 
anyway, with all files together (binaries, data, configs, etc) - because 
that's the way DOS software were usually designed to work. But FreeDOS 
core tools could be an exception here - in fact, FreeDOS already uses 
several directories for different purposes: %DOSDIR%\bin for binaries, 
%DOSDIR%\nls for translations, %DOSDIR%\help for man files, etc... some 
kind of %DOSDIR%\cfg directory would just extend that idea a little further.

bye,
Mateusz


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user