[syslinux] Interaction with Windows bootloader

Ady Ady ady-sf at hotmail.com
Sun Jan 6 09:55:32 PST 2019


> 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.




More information about the Syslinux mailing list