In FreeDOS 1.1 (or whatever) once the directories are finalized, a system
variable can be declared in the OS (at the master environment level) like in
Windows NT/2000/XP called SYSTEMROOT. On my Windows machine it's C:\WINDOWS.
For FreeDOS it can be C:\FDOS. Then the other directories (with the exception
of \APPS and \SOURCE) could but placed under there.
Are there plans in the works to standardize the install process? Some sort of
API of routines, or skeletal installer that would use these directory rules.
With all this discussion, it would probably be easier to put together an
installer API for FreeDOS that can process a script to install apps to make
this setup work better.
-T
> Date: Sun, 6 Jan 2008 12:08:00 -0600
> From: [EMAIL PROTECTED]
> To: freedos-devel@lists.sourceforge.net
> Subject: Re: [Freedos-devel] FreeDOS directory standard (1.1?)
>
> On 1/5/08, Eric Auer <[EMAIL PROTECTED]> wrote:
> >
> > Hi!
> >
> > > LIB for libraries. We never really defined a "lib" before because
> > > FreeDOS doesn't support the shared-library model...
> >
> > I would put those in BIN if dynamic and in SOURCE if used to compile
>
> I don't think under BIN if dynamic is a good idea. It mixes too much
> non-user-executable stuff in BIN. BIN needs to be for user programs
> only. If there is ever a dynamic lib concept, it should be in its own
> LIB.
>
> But yes, looking back at the discussion, if the libraries are used to
> compile, they should go under the package name in SOURCE (same as
> normal practices.)
>
> >
> > > INCLUDE would be a good place for any *.h files that are associated
> > > with the libraries in LIB. But I don't think I'd put them under LIB.
> > > This should be a top-level directory.
> >
> > I would put those in SOURCE
> >
> > Actually I would not even use SOURCE but the subdirectory
> > of SOURCE used by this package. After all, dependencies
> > should know on which package they depend...
>
> As above, if used to compile, they should go under the package name in
> SOURCE (same as normal practices.)
>
>
>
> To modify my original post with the above:
>
>
> BIN
> Binaries, such as exe and com files. And if a program is made
> of of a bat file, then that goes in BIN too. Programs only.
>
> DOC
> Package documentation, with each package having its own directory such
> as DOC\INSTALL or DOC\4DOS, etc. This allows a complicated package
> such as a compiler or programmable editor to include more than just a
> readme (perhaps sample code for the compiler, technical notes or other
> references, etc.)
>
> HELP
> The help files. I think the original FD directory structure was
> based on a UNIX-like directory tree, and the HELP directory was
> originally going to have subdirectories a-la UNIX 'man' sections:
> HELP\1, HELP\2, ... But that didn't make much sense in the end, so
> only the top-level HELP directory stuck. Later, we added an html-based
> Help program, so that needs its own directory for html files. I don't
> use the htmlHelp program, but it looks like the top directory for its
> files is in HELP\EN (i.e. the language.) That makes sense, I suppose.
>
> SOURCE
> For source code (when installed) with each package having its
> own directory. (Source package [spkg] only.)
>
> LIB
> If there is ever a dynamic lib concept, it should be in its own LIB.
> (future concept)
>
>
>
>
> -jh
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
_________________________________________________________________
Make distant family not so distant with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
