> On Sat, Jan 5, 2019 at 3:17 PM Ady Ady via Syslinux <syslinux at
zytor.com> wrote:
>
> > > syslinux[64].exe -i -f c: bootsecfile.bss
> > >
> > > This should have been the form for your desire as specifying the
> > > filename should have told it to create the BSS instead of writing
it
> > > to the VBR. Being the "fixed" HDD instead of a
removable drive like a
> > > USB stick, "-f" is necessary.
>
> > Hmm, instead? Could this syntax be some kind of unintended oversight?
>
> Unintended oversight, unanticipated use, etc. that at least was on the
> side of caution. The check for fixed HDD instead of removable like
> floppy or USB stick was put in place first. Then the part about
> specifying a .bss output instead of writing the VBR was added in 2004.
>
> > Are you saying that a command such as:
> >
> > syslinux.exe -i a: bootsecfile.bss
> >
> > is not supposed to change the VBR of a:, whereas a command such as:
> >
> > syslinux.exe -i a:
> >
> > performs the change of the VBR?
>
> Correct on both points.
>
> > I see several inconsistencies here.
> >
> > In theory, at least either --install or --Update are supposed to be
> > required for the VBR to be modified by the installer. But for this
> > case, since the VBR is not supposed to be modified, the --install
> > option should not be required (for consistency with its
> > meaning/intention).
>
> > Therefore, for consistency:
> >
> > _ A command such as:
> >
> > syslinux.exe -i a: bootsecfile.bss
> >
> > should had meant performing both actions: writing to the VBR of a:
(and
> > copying the ldlinux.{sys,c32} files to the root of a:) _and_ writing
> > (creating) the bss file; _not_ one action _instead_ of the other.
>
> Unintended changes of past behavior could have negative impacts and
> should have been the case when the -i/-U flags were started.
>
> > _ A command such as:
> >
> > syslinux.exe a: bootsecfile.bss
> >
> > should had meant writing (creating) the bss file, and copying
> > ldlinux.{sys,c32} to the root of a:, but without writing to the VBR of
> > a:.
>
> This behavior would have been preferable.
>
> > An additional matter, also regarding consistency, is that for the exe
> > and com installers, the usage of --install is not yet congruent with
> > the equivalent usage for the Linux-based installers (i.e. with and
> > without "-i" has currently the same result for the case
presented in
> > this email thread).
>
> I saw this too.
>
> > I haven't tested the Linux-based installers with the bootsecfile
> > option; for the exe and com installers, this syntax (that currently
> > seems to mean "instead") is confusing and
inconsistent/incongruous with
> > the expected usage/goal of --install.
>
> It won't work on Linux as the saving .bss behavior is DOS/Windows only.
>
> > Independently of the matter of the "-f" option, isn't
the above a more
> > consistent / logical behavior (for the Windows- and DOS-based
> > installers, at least, if not for all of them)?
>
> It would be preferable to have all congruent but if certain behaviors
> are changed, it could impact someone's scripts with some potentially
> negative impacts like breaking a system.
>
> I think the only safe option would be to simultaneously evaluate for
> other changes for safety, move the .bss save to a proper option
> (instead of being an optional extra argument) and enforce using -i/-U
> for DOS/Windows.
>
> --
> -Gene
Now I'm confused.
If the "-i/-U" options are not yet enforced for the exe and com
installers, and we are discussing a case in which it should not be
enforced, then we could choose for a different improvement: instead of
enforcing the "-i/-U" for exe and com installers (which is currently
not enforced), we could enforce the following combination of cases:
A_ use "-i" to install to VBR; (or)
B_ use "-U" to update the VBR (i.e. when the VBR is already using
SYSLINUX); (or)
C_ use the bootsecfile(.bss) option to create the bss file (and copy
ldlinux.{sys,c32}), without touching the VBR;
D_ combine either "A+C" or "B+C".
IOW, a command with no "-i/-U" options and simultaneously with no bss
file, would not be accepted, but specifying either:
_"-i";
_"-U";
_ the bss file;
_ "-i" and the bss file;
_ "-U" and the bss file;
should all be possible, each of them with the respective coherent
meaning/behavior.
Moreover, since the bss file is not available for the Linux-based
installers, then this proposal should not have any "generic" backward
compatibility problem (since the assumed enforcement of "-i/-U" has
not
yet been implemented for Win/DOS).
The only potential problem would be someone that has been using the
"-i" already from Win/DOS while simultaneously using the
bootsecfile(.bss) file option, and still doesn't want to actually
install the code to the VBR. Could we assume that such case would be
very uncommon, and that any changes (i.e. improvements) would be
clearly listed in the changelog anyway?
Other than that "little" (corner?) case, where exactly the backward
compatibility break would be happening? Am I missing / misinterpreting
something?
As a reminder, in the past there have been other changes in the options
for the installers (e.g. --offset, "unix/linux", location of
installers
within the official archives...) and those were much more problematic
than the case presented here. And if we go beyond the installers, we
can find multiple backward compatibility breaks, through the history of
Syslinux, with more impact than this one (e.g. chain.c32, multiple
times).
Could this proposal please be considered / discussed?
Regards,
Ady.