Hi Mateusz,
>> I only see one possible reason: SvarCOM and FreeCOM files are named
>> command.com both.
>> Just name SvarCOM file SVARCOM.COM and set SHELL=C:\SVARDOS\BIN\SVARCOM.COM.
>
> ...or rename FreeCOM to be FREECOM.COM :)
Exactly.
> But yes, overall this is an option, I just wasn't sure if there wouldn't
> be some side effects if the shell is not specifically named C:\COMMAND.COM.
There might be side effects, if any stupid software relies on
C:\COMMAND.COM for shelling out.
>> It looks for COMMAND.COM on the "source drive".
>> If it doesn't exist, query %COMSPEC% environment variable and copy the
>> file specified instead.
>
> Good, I didn't know that. That makes things indeed simpler, means that
> there is no need for a C:\COMMAND.COM at all.
See above.
>> Um. What does "pkg update ..." do in the background?
>> Does it do "pkg remove" followed by "pkg install"?
>
> Yes. With an extra pre-install check for already-existing files to avoid
> uninstalling a package and not being able to install the updated one.
I don't understand.
If a file from a package already exists on C:, how could removing this
file make installation of the new package version fail?
> Which means that updating svarcom (or any COMMAND.COM) should be
> perfectly doable.
If you say it.
>> 2. "pkg remove command"
>> -> All files but C:\COMMAND.COM (!) were removed and I was returned to
>> the DOS prompt.
>
> This is expected, it's a COMMAND.COM that was placed there by SYS during
> install time, so it is a "wild" file that is not part of any package. I
> guess this could be deleted after installation. Would make things cleaner.
Sure. It was not a bug report. ;-)
As we are talking about "cleaner"... The LINK/LN approach looks cleaner
to me. :-D
>> So, it isn't a problem, because:
>> 1) After removing the package, a copy of COMMAND.COM is still present in
>> memory,
>
> That works with FreeCOM, but won't work with SvarCOM. SvarCOM is not
> kept in memory, it leaves there only a minimalist stub of about 2K and
> that stub desperately needs to be able to reload COMMAND.COM from disk
> after the last command exits.
I see. Then it should, if not already there, noted in the SvarCOM docs,
that this results in additional disk reads, which might be slow on
floppy-only or really low-end systems. (SvarDOS has no disk caching
driver, AFAIK.)
> But pkg update will work, so it's all fine - it will remove the old
> command.com, install the new one and exit. And then SvarCOM will hang,
> but that's not a problem, user will only have to reboot and everything
> will work again.
Why will SvarCOM hang?
Why can it not just reload the new SvarCOM binary from disk?
Will the 2K stub of SvarCOM then display a message to the user, e.g.,
"SvarCOM: Unable to load transient part from disk. Please reboot your
system by pressing Ctrl+Alt+Del."?
Cheers,
Robert
--
+++ BTTR Software +++
Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/
_______________________________________________
Svardos-users mailing list
Svardos-users@lists.osdn.me
https://lists.osdn.me/mailman/listinfo/svardos-users
