I will dedicate my time now to developing a new FreeDOS installer, one which
will be easy, fully functional, and not necessarily make everybody happy - that
is just impossible here, but it will be good to go. I will keep you all
updated as progress commences.
Joe
-------------- Original message --------------
From: Eric Auer <[EMAIL PROTECTED]>
>
> Hi and merry xmas to everybody :-)
>
> I have been trying to understand the installer batch
> files, but they turned out to be too complex... What
> I did find out is that there are many variables:
>
> Autoexec: DEBUG NLSPATH dircmd lang config PATH cputype
> ... plus runs GETARGS > temp bat and then calls that.
>
> Others: CD DIRECTORY OS destdrv autofile cfgfile GUI_inst kernel
> cddrv destdsk choice cdrom color instparm rd currdir isofile dest
> locmsg dosdir xms msg mkisoexe BASEDIR temp fdosroot lang usemse
> header INSTDAT INSTMAX INSTMIN instmode kblayout keybrest menu2_nr
> menu1_nr params2 path os CFGFILE FC display frmterr hello basedir
> keybfile line1 oldnls AUTOFILE TEXTMENU loadcd oldlang opt DISTRO
> KEY VM oemcmd pqbackup pqpart initrd cputype fdosdir nlspath key
>
> Generic: %%x %%X %%D %1 %2 ... PATH errorlevel _CWD comspec
> path config dircmd NLSPATH ... those all have special meanings.
>
> First suggestion: Reduce the number of used variables a lot, and
> use consistent upper / lower case for easier reading. I think it
> would be nice to always use UPPER CASE for variable names. Some
> variables seem to be unused, while in other cases there are a
> number of variables which all hold the same value.
>
> Examples of removable variables: autofile cfgfile (use fixed
> fdconfig, fdauto on %destdsk%) GUI_inst (always use textinst)
> kernel (always use fat32 386+ kernel) color (always use color)
> cputype (always use 386) mkisoexe (just put exe in same dir as
> the makeiso batch file) usemse (used as pbatch option but is
> never set? seems to be for enabling the mouse?) ... There are
> several variables for "cdrom drive", "destination drive" and
> "ramdisk drive", but it would be easier to use fixed letters.
>
> DISTRO / VM is used but never set, and there is no XOSL - all
> probably old "forgotten to remove" hooks from beta8 or beta9.
> The hooks for drive img / part magic / oem should be removed:
> oemcmd, pqbackup, pqpart variables are leftovers of those.
> Note that support for pre-386 / mono can be given on diskette
> distros if wanted. You cannot boot from CD on pre-386 anyway.
> By the way, what actually creates the postinst / config...?
>
>
>
> Next part: Who calls whom during install? First, you have the
> fdconfig and fdauto files on the diskette image. Because the
> image only contains 240k of data, it would be very nice to
> have a zip with a copy of the files in the isolinux directory,
> to make it easy for users to access them (actually there is
> a tool called "extract" on the CD to read from the gzipped
> diskette image but UNZIP is easier to figure out ;-)). This
> diskimage contains himem, emm386, cdrom drivers, caches and
> devload. There is a basic freedos system and a few helpers:
> getargs, xmssize, iniadd, oscheck, append, localize, choice
> and sys. Those should also be in the "odin" directory on the
> CDROM, so people can use the cdrom after booting from ANY
> dos diskette, not only after booting a 1.0 installer disk.
>
> The autoexec / fdauto sets: DEBUG (unused!?) NLSPATH dircmd
> (no problem) lang (always EN) config PATH and cputype (to
> 80286 or 80386). Initial PATH is "freedos" and "driver" on
> A: and the ODIN directory on X: ... This step also takes
> care to read ISOLINUX options with GETARGS and makes sure
> that the CDROM (or ISO) is mounted on drive letter X: ...
> Then it loads ctmouse (mouse driver) and runs setup :-).
>
> So... If you put copies of the boot disk image contents in
> an easy to access zip and write a short readme like "you
> have to make the CD contents available on X:, set PATH and
> NLSPATH and then run SETUP", it will be easier to run the
> SETUP from an existing previous DOS version. As long as the
> tools like LOCALIZE and OSCHECK are added to the ODIN dir
> on the cdrom, of course. I think config / lang / cputype as
> set by the boot diskimage should not be required by SETUP.
>
>
>
> Next step is SETUP: It loads shsurdrv (ramdisk) and checks
> if the ODIN dir is there and SET /E work. The cddrv variable
> is set to the current drive, so I guess there is no need to
> always use X: with this version of setup. The nlspath, path
> and lang are updated and fdosroot is set... A language menu
> with 10 choices is shown: EN DE FR PL NL IT SV PT ES RU.
> The 11th choice is "other", showing a much bigger menu...
> The choice is then passed to the REGIONAL batch. This can
> load a font and a keyboard layout. It does not add those
> settings to the target config, though.
>
> Next, a list of drives is generated. If more than one dest
> drive candidate exists, the user is asked to pick one. Now
> setup tries to CDD to that drive, and shows a FDISK menu
> if that fails. Options here: Xfdisk, abort, warmboot, and
> make bootdisk... Note that there is a separate BOOTDISK
> batch file which can do multi-system boot disks which is
> probably a bit overkill. The "get drives" thing is in a
> separate batch file, why that?
>
> Now the target drive is checked by making a test directory
> and by running oscheck (why not other way round?). Depending
> on the result, the metakern boot menu is installed, the user
> is asked whether he wants to run format /q, sys is run. The
> latter depends on the freedos boot diskimage, it would be
> better to explicitly use a kernel / shell from ODIN the dir.
> Finally the ramdisk is removed.
>
>
>
> Third step is AUTORUN: This contains two main menus, which
> both consist of several files including a batch file each.
> I think this should be simplified a lot, for example with
> inlined localize or pbatch calls, the former being the
> preferred option as this allows to inline English default
> messages. This would be useful for both -reading- the bat
> and for -using- it if you forget to set NLSPATH. Because
> if you forget that, all non-inlined messages vanish and
> you are expected to answer questions without seeing what
> the question is. For some reason, there is also code to
> set color to Mono or Color depending on cpu type if the
> key or lang variables are not set...??
>
> Menu 1 items are: "install" (leads to menu 2), "bootdisk"
> (duplicates code discussed in SETUP), "quit", "readme",
> "reboot", "xfdisk", "spfdisk", "fdisk", "format". If you
> ask me, setup and autorun should be merged into one file
> to avoid duplicating the language selection (see below)
> and bootdisk and fdisk menu areas.
>
> Menu 2 items are: "quit", "keyboard" (language selection,
> duplicates code from SETUP), "install" (runs TEXTMENU and
> POSTINST), "return to English", "screen" (color or mono, a
> superfluous menu item imho), "mode". The latter is a non-
> intuitive name for a sub menu, choices: full, mini, maxi?
>
> TEXTMENU choices depend on whether games (non-base) and/
> or sources (of games or of base) are available. I think
> there should NOT be a pre-made choice "install all the
> sources". No Linux distro would include such a choice.
>
> For some reason, TEXTMENU also seems to iniadd DOS to
> WinNT/WinXP boot.ini - which would only work if those
> are installed on FAT drives. Also does metakern again??
>
> Users can always use the package mgr to install sources
> of single packages at any time. Installing all sources
> of fdfullws might consume 100s of megabytes. Remember
> that this includes "source of openwatcom" etc ;-). I do
> think that there should be a choice "install everything
> which can be installed without INTERNET connection":
>
> Many people got stuck during install because the WGET
> which tried to download additional files got stuck at
> some point sooner or later :-(.
>
>
>
> Before POSTINST is run, the TEXTMENU calls TEXTINST
> which is the tool which actually unzips everything
> and which asks you which packages to install, based
> on default sets selected by textmenu. Problem with
> TEXTINST is that it flickers a lot. By using a black
> background and by NOT using shadow effects, the tool
> can be made simpler, flicker can be eliminated and
> the mono / color decision can be removed :-).
>
>
>
> I guess something also creates the target config
> and autoexec, but I cannot find this. But I know
> that it needs some repairs: The trailing space
> after the LANG setting in (fd)config, the missing
> 4?ECHO no drivers in (fd)config, the missing load
> disk cache line, the complexity of fdauto. For the
> latter, I recommend to add at some point:
> if "%config%"=="4" goto nodrivers (...)
> ... instead of having many if-config lines.
>
> I myself load fdapm apmdos for all other choices,
> as shsucdhd (mount ISO file as virtual CDROM) and
> my fm801 drivers. I made loading DISPLAY, SHARE and
> DOSLFN conditional as those use a lot of RAM. Note
> that you should NOT use LH with MODE (yet another
> small flaw in 1.0) or MOUSE. The latter because
> CTMOUSE LHs itself anyway. For the CTMOUSE 2.1b3
> driver, please use the /O /Y options to suppress
> wheel (QEMU bug) and Mouse Systems / Genius mouse
> mode (can get triggered by non-mouse devices).
>
> The path can be shortened - faster DOS - by using
> wrappers for emacs, setedit, vim, fbc, dog and the
> pacific c compiler. The latter 2 have several exes
> so it is probably okay to keep them in PATH. Other
> variables set in autoexec: dosdir, PATH, NLSPATH,
> HELPPATH, temp, tmp, BLASTER, CFGFILE, WATTCP.CFG
> and VIM. The LANG and dircmd variables are already
> set in (fd)config sys.
>
>
>
> This summary hopefully helps some people to understand
> more about the FreeDOS 1.0 installer and helps others
> to make the FreeDOS 1.1 installer a lot simpler (!).
>
> Have a nice day :-) Eric
>
>
>
> PS: See fd-doc.sourceforge.net/wiki/index.php?n=FdDocEn.FdInstall
> for other known problems in FreeDOS 1.0 / install ...
>
>
>
> -------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
