Hi all,
for extra fun, I traced through the installer batch
files in the new fdbasecd (1.0 preview 2 cdrom iso)
tonight... The new ISOLINUX 3.11 still did not like
me (hangs on boot), but I could again use the special
boot diskette... The cdrom driver liked my dvd drive
better this time, no crc errors etc :-)
However, the singlestepping showed a few annoying
FreeCOM issues in single step mode: If you do any-
thing with redirection, the "some command [YES=Enter
No=Esc] ?" message are prepended to the redirected
data. So "echo hello > foo,bat" will write something
like to foo,bat like:
"echo hello > foo.bat [YES=Enter No=Esc] ?
hello " (also note the space after "hello").
The YES/NO etc prompt should be sent to STDERR or
to CON even if redirection is active.
This problem breaks the "push output of GETARGS
into a batch file" step to some part when you
are in single step mode, but what is worse is
that it completely breaks the config / autoexec
generation batch script.
The next issue is that FreeCOM freaks out if you
do CTTY NUL in single step mode, probably because
it wants to read the Enter or Esc from NUL then.
In either case, it only beeps, and when you hit
Ctrl-C to abort the batch, you cannot type an
answer to the abort prompt either, as that would
have to be typed from NUL as well.
This is a NUL specific case: A solution would
be to CTTY only output of FreeCOM for the NUL
case, but to do bidirectional redirection for
other devices like AUX.
I notice that the installer diskette would
NORMALLY load an 1.5 MB diskette-only cache
and TICKLE. Why is that disabled at the moment?
The installer diskette also has many "if file XYZ
is present then..." things - it would be better
if those tests were omitted. Either you have the
installer diskette or you do not have it.
About drivers: both the CDROM driver and SHSUCDX
(and the CDRCACHE as well, 1.25 MB of it...) are
DEVLOADed /H to UMB. Unless the installer really
needs a lot of RAM, it would be a lot safer not
to use UMBs for such drivers.
There also is a check for c:/fdbootcd.iso, but
no message about it (which could inspire people
to put the ISO there, I mean)...
It is probably intentional that validsrc is set
to " X:\FREEDOS" (note the space)? The diskette
searches for either /setup/batch/autorun... or
for x:/freedos/setup/batch/autorun... okay...
For some reason, the diskette looks for up to 6
cdrom drivers. That can probably be simplified.
The PATH contains the ODIN and INSTALL directories
at some point: On disks with livecd, the ODIN
stuff does not have to be duplicated in the
livecd. Or, the other way round, you could omit
ODIN on such disks, as long as the PATH is
automatically adjusted to point to the livecd
instead there.
At some point, the installer has to decide whether
it should add a:\freedos to the PATH. It decides
not to, and that breaks several things. I had to
fix that manually to be able to continue properly.
An alternative would be to have all files from
a:/freedos and a:/driver also in the ODIN or INSTALL
directory on the cdrom. Then the second step of the
install would not have to access the diskette that
much... Of course with a MEMDISK, it is better to
try the virtual diskette before the cdrom (faster).
The first PATH problem are menu1 and menu2 dot bat:
Those need LOCALIZE and CHOICE (and one also wants
to use CD2ISO86 to copy the whole cdrom to a file
on C:, probably depending on a choice which I would
have with CHOICE in the PATH...). Problem here is
that no default messages are present, so the batch
files are almost unreadable ("show message 1.2, then
ask question x.y..."). Would be very nice to have
default messages here.
The installer should probably check if the selected
size (install.min, install.dat, install.max, for
binary, binary+sources, ask per package) is possible
with the current cdrom (by checking for the file).
The screen mode selection should be removed: It is
"mono/text" versus "ega/vga", but we do not use the
VGA/486dx installer at the moment anyway. One sub
menu removed :-).
When the actual install starts, it first TYPEs beta9.txt
and then displays inst.txt with PG. But PG is not in the
PATH. The user will not see the inst.txt file.
If the installer would find c:/nul missing or would
find an OSCHECK errorlevel of at least 64, it would
FORMAT C:, suppressing all user interaction. Very
bad! Solution: Remove the /Z:SERIOUSLY. The user can
easily wait for a short while until the format c:
step is reached. After that, he can walk away, the
rest can be less interactive.
At some point, the installer tries to use CPULEVEL,
but that is not in the PATH. In addition, GETARGS
provides the relevant hints about what CPU you have
anyway. Plus it is highly unlikely that people do
a cdrom install on a pre-386...
LOCALIZE is used a lot, but you should make sure
to have default messages everywhere, for sake of
readability of batch files. You could even use
something like IF EXIST ... SET LOC=LOCALIZE
ELSE SET LOC=ECHO ..., then the default messages
would even be displayed if both localize.de (in
DE language case) and localize.com are gone :-).
Some components have been updated: deltree,
command, edit, fdisk, kernel. The kernel some-
times shows extra messages (when creating files),
my fault. EDIT is not UPXed yet but at least it
is 0.7d :-). And typing umlauts and backslashes
works for me, with KEYB and EDIT. Not sure what
went wrong for the one for whom it did not.
There even is some automatic XMS size check,
to set the cache sizes, but there is no disk free
space check yet. Still nice.
The installer checks for various OSes, for
existing config files, for metakern... And it
repeatedly creates boot sector dumps on c:/
and a:/ and deletes them again. Could probably
be optimized. Note that I did not test if the
installer works at all if a: is read-only.
TEXTINST / FDPKG works quite nice now :-)
However, if you have no DOSDIR variable set,
it will not even show the /? help screen. Bad.
What do the /O:&D /N /F:I /G options mean when
the installer tries to locate postinst? Postinst
is what creates the config and autoexec. See
above. Could not really singlestep those...
What I did notice is that both LOCALIZE and
the LOCALIZE.* text files are not where they
should be on the installed system! So POSTINST,
which is run from harddisk for some reason,
shows no messages at all... Or maybe this
went wrong because I singlestepped it. Because
I used a German codepage, the box and checkmark
ASCII arts did not look right. Maybe use some
more conservative plain ASCII instead...
Talking about those, the /bin/sleep tool is
missing as well. And, even though the list-
of-steps display is fancy, it would be better
to just SEE the output. As said, CTTY NUL is a
really bad idea.
One of the POSTINST steps is to copy a CMD-*
for the selected language into the default
command.com - that fails because DE is not
the same as de :-p
Plus there are TWO command.com, one in %DOSDIR%
and one in %DOSDIR%/BIN, which is not good. One
of them is older than the other, you can easily
get the older one by accident. For extra fun,
I copied two different languages to both dirs,
to see which one is used when.
Bug in REGIONAL,bat: There is no END label and
the ODIN/CPI/EGA.CPX filename points into the
void, so "German" font only happens when the
installed DOS boots, not during install...
In general, the installer looks a lot better
now than the early beta9 ones. I hope the
remaining issues can be fixed before 1.0 :-).
Some of them make the installer somewhat use-
less to less-insider users at the moment, but
most bugs are still easy to pinpoint and fix.
Thanks :-).
Eric
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
