Re: Feedback needed on BOOTING, CACHING and some HELPER TOOL

Hi all,
thanks for the feedback so far!

To Arkady: Yes, I know that DOS reads < 1 cluster sometimes, but I got the
impression that this would not harm LBAcache performance that much (I mean,
with respect to my idea to have a cache element size of roughly the cluster
size and so on).
Your idea to use a magic to allow the KERNEL to find back the boot partition
for the "harddisk but not C:" case sounds nice. However, I do not think this
is an urgent issue. At least in the MetaKern case, the boot code itself may
not be part of the magic/serial number/stamp system, as MetaKern patches the
boot code when chaining on to the actual kernel. I think the classic SERIAL
NUMBER (part of the boot sector) would be the right "stamp" here. When the
number is not found, the KERNEL can still fall back to C: itself...

To Steffen: Thanks for fixing BOTH the XMS_SWAP issue and adding _CWD. The
variable contains the current drive as well, so it is more _ABSPATH than
_CWD, to be a bit of a nitpicker :-). Should be mentioned in the documentation
as well. Here a sample of its use:
D:\FOO>type c:\test.bat
@echo %%ERRORLEVEL%% is %ERRORLEVEL%
@echo %%_CWD%% is %_CWD%
D:\FOO>c:\test

%ERRORLEVEL% is 0

%_CWD% is D:\FOO


This will simplify the requested "THINGY" tool: Now you can use
THINGY %_CWD%\
instead of
CD | THINGY
very nice...

To Bart: So both "boot A:" and "boot B:" could be useful menu entries
for MetaKern, as far as I understand your comments on boot sector and
kernel flexibility? FreeCOM flexibiltiy is limited by kernel flexibility
here, kind of. By the way, I digged up an old MS DOS 6.22 kernel
(yeah, FreeDOS-or-MS-DOS selection with MetaKern works :-)), and when
I rename command.com (or command.com exits, for example due to an error),
it says:

Falsche(r) oder fehlende(r) Befehlsinterpreter
Geben Sie den korrekten Namen des Befehlsinterpreters ein. (z.B. C:\COMMAND.COM)

A>



To all: Thanks for the feedback so far, but I still need some opinions and/or
benchmarks regarding my LBAcache suggestions. And opinions whether the "boot A:"
and "boot B:" menu entries are an useful addition to MetaKern. To tell a bit
on LBAcache: The next version will have 2-digit size selection,
what UNIT would you want? Current version allows 1 digit, unit is
1k sectors (512k bytes), so the current version is limited to 4.5 MB
per instance. The next version will probably use 4k element size (current
is 2k), making the TSR size smaller - depends on your element size feedback
and benchmarks. The next version will also detect LBA capability per drive
and allow 8 harddisks (current: detected once for all harddisks, at most 4).
The next version will probably NOT contain better support for changeable
media and dynamic geometry yet. So you will still NOT be able to cache
floppy disks of other size than 1.44 MB (trying to do so anyway will damage
the data copied to/from the floppy!) and you may have to flush the cache
manually when using changeable harddisks or similar special media ("flush"
meaning "forget cached data" not "write back cached date" here, so you would
do it before inserting the new medium, not before removing the old medium).
Feel free to tell me your thoughts about my plans for the next LBAcache
release. By the way, size will stay limited to < 64 MB, I do not plan to
support the XXMS API. However, using FDXXMS you will be able to install
several LBAcache instances (do not use more than one per drive, this will
not improve performance!) up to a TOTAL of more than 64 MB anyway.

Bonus task: Anybody volunteering to combine my Memory FAQ (which driver
can do what), the follow-up Memory Acronym Clarifications (by several
people) and the follow-up Memory HOWTO (by Tom or Bart, I think: which
driver to use for which computer) into a single document for the FreeDOS
homepage? Should be mostly cut and paste. Thanks! Otherwise please kick me
virtually to force me doing it myself.

Reminder: THINGY is yet another one of those "please contribute or tell me
that I have to do it myself" type tasks. I am needing it to write a few
batch files to ease using UNDELETE as a "MIRROR" or "TREE-MIRROR" tool.
For using UNDELETE in a "unerase x:\y\zzz*.txt d:" way that would first
dirsave x:\y\ to d:dirsave.txt and d:dirsave.bin and then parse the dirsave,
showing all entries marked as "undeleteable" and matching "zzz*.txt" and
allowing the user to undelete them to d:zzz*.txt (or skip them, prompting for
each file), I fear BATCH files cannot contain enough "cleverness". If you
happen to be an AWK wizard that can prove the opposite, please tell me...
If you are a friendly programmer who can write UNERASE as described here
(which is only a shell that starts undelete several times with appropriate
arguments), thanks a lot for doing so!

--------- UNDELETE details: -----------
I think I can write the MIRROR and TREE-MIRROR tools (not the UNERASE one)
or wrappers without THINGY, given the following:
- FreeCOM now has %_CWD%
- I can use dir / zipinfo (unzip -1) along with find and errorlevel to
  do both "if exist" (which would be easier :-)) and "if exists in zip".
- MIRROR and TREE-MIRROR do not need the name/extension parsing of THINGY,
  and do not need to have separate drive/path parsing either (reason: I
  can use CDD which is part of FreeCOM as well :-)).
- The only tool still left on the requirement list for MIRROR / TREE-MIRROR
  would be COUNT. Count reads the variable %COUNT% and replaces it by a new
  value that is numerically 1 more and string-wise of the same length. This
  can be used like this:
  set COUNT=0000
  :next
  if not exist mirr%COUNT%.bin goto here
  count
  goto next
  :here
  move mirror.bin mirr%COUNT%.bin

I think people can use COUNT for many other things in BATCH files :-).
The only way to count without count is to do:
  set COUNT=x
  :next
  do something
  set COUNT=%COUNT%x
  if not %COUNT%=xxxxx goto next
Which is obviously not THAT comfortable ;).

(sorry, typo, must be if not %COUNT%==xxxxx goto next)