> 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. > > -- > -GeneNow 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.
On Sun, Jan 6, 2019 at 12:58 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > > > 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.Hopefully this helps.> 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".At this time "-U" is an unimplemented option for DOS/Windows.> 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)."-i" works for DOS/Windows but its use isn't enforced.> 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?I'd say the opposite is true. You're unlikely to want the VBR touched if specifying bootsecfile.> Other than that "little" (corner?) case, where exactly the backward > compatibility break would be happening? Am I missing / misinterpreting > something?That's precisely the issue.> 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?To be clear, unless overridden by HPA, a proposal to change "syslinux.exe -i a: bootsec.bss" from one that does NOT install the VBR to one that does _will_be_rejected_. It's going from a safe behavior to a potentially dangerous one. If some script or program already uses this syntax, changing its behavior risks the stability of a system. I see the use case for exporting the boot sector to a file instead of the VBR as demonstrated in this discussion. However, IF there's an actual use case for installing the VBR AND writing it to a file at the same time, the only _safe_ method to implement this is with a new syntax. "syslinux.exe -i a: bootsec.bss" would either only create the bootsecfile OR become a rejected syntax. "syslinux.exe -i --bss bootsec.bss a:" could be a new syntax that creates the bootsecfile and installs the VBR. While implementing such a new syntax, the options should be examined for any other possible changes and we should consider rejecting syntax "syslinux.exe a:" as a no-action syntax suggesting using "-i" to install. -- -Gene
> On Sun, Jan 6, 2019 at 12:58 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > > > > > 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. > > Hopefully this helps. > > > 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". > > At this time "-U" is an unimplemented option for DOS/Windows. > > > 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). > > "-i" works for DOS/Windows but its use isn't enforced. > > > 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? > > I'd say the opposite is true. You're unlikely to want the VBR touched > if specifying bootsecfile. > > > Other than that "little" (corner?) case, where exactly the backward > > compatibility break would be happening? Am I missing / misinterpreting > > something? > > That's precisely the issue. > > > 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? > > To be clear, unless overridden by HPA, a proposal to change > "syslinux.exe -i a: bootsec.bss" from one that does NOT install the > VBR to one that does _will_be_rejected_. It's going from a safe > behavior to a potentially dangerous one. If some script or program > already uses this syntax, changing its behavior risks the stability of > a system. I see the use case for exporting the boot sector to a file > instead of the VBR as demonstrated in this discussion. > > However, IF there's an actual use case for installing the VBR AND > writing it to a file at the same time, the only _safe_ method to > implement this is with a new syntax. > > "syslinux.exe -i a: bootsec.bss" would either only create the > bootsecfile OR become a rejected syntax. > > "syslinux.exe -i --bss bootsec.bss a:" could be a new syntax that > creates the bootsecfile and installs the VBR. While implementing such > a new syntax, the options should be examined for any other possible > changes and we should consider rejecting syntax "syslinux.exe a:" as a > no-action syntax suggesting using "-i" to install. > > -- > -GeneOK, to sum-up: _ Instead of the "bootsecfile" parameter for the exe/com installers, we could have (something like): --bss file.bss meaning: --bss: long option file.bss: the (path and) file name to be created (to be provided by the user) (optionally, we could also have an equivalent short option, like "-b", but that's not critical and perhaps even not really recommended). _ For the exe and com installers, the new --bss option would replace (and enhance) the current "bootsecfile" parameter usage; the latter possibility shall cease to exist (in order to stop, not just reduce, the current unwanted oversight behavior). The behavior with [--help] (i.e. messages) could be improved too (accordingly). _ At least one of the options: "-i", "-U", or "-bss" should be required in order to "install" SYSLINUX, either to VBR (-i/-U) and/or to file.bss, in a similar way as the Linux-based installers. _ Other command-line options should not be impacted. IIRC, the Windows- and DOS-based installers don't have these options implemented (yet?). The options "-f" and "-s" should not assume any other option, so they should demand either "-i", "-U", "--bss" or a combination of these, in addition to specifying "-f" and/or "-s". _ The command-line options that are specific to the exe and com installers ("-am") should not require any enforcement of additional options (but allow the combination with them). IOW, the enforcement of -i/-U/--bss is only relevant when the SYSLINUX code would be "installed" (or updated/modified) somewhere, either to/in the VBR (or equivalent) area, or to/in a bss file, or both; other use-cases of the command line should not demand -i/-U/--bss. (BTW, what about the other options, like those that modify the ADV, or --offset or -r?) _ So: A_ use "-i" to install to VBR (or equivalent area); (or) B_ use "-U" to update the VBR (i.e. when the VBR is already using SYSLINUX, otherwise do not touch the VBR); (or) C_ use the --bss option to create a bss file (and copy ldlinux.{sys,c32}), without touching the VBR; D_ combine either "A+C" or "B+C". (I'm not sure what should be the behavior when using "B+C" and the "B" part finds that the VBR is not using SYSLINUX yet; "B" should not touch the VBR then, but what about "C" in such case?) E_ other command-line options should be kept with no changes in their required conditions, the same as for the Linux-based installers (which, for the most part, currently don't really work for the exe and com installers, AFAICR). The "-a" and "-m" options should also not demand enforcement of anything else, but allow the possible combinations. The options "-f" and "-s" should demand either "-i", "-U", "--bss file", "-i --bss file" or "-U --bss file". F_ older scripts that are still using the current (old) "syslinux[64].exe" or "syslinux.com" syntax, i.e. without using "-i" (while the intention is to "install" SYSLINUX to the VBR) will not work after these proposed changes are in place. The same goes to scripts using the current "bootsecfile" parameter. The old syntax would not be accepted, and the (new) result (of using old syntax) should be some kind of "warning" or "info" or "help" message (i.e. not just silently fail). One small detail: is the .bss file name extension also a requirement? I think it used to be (because of the BSS KERNEL-like directive?) , but I don't know whether that requirement is still in effect. If "-U" and other options are not yet implemented for the exe and com installers, let's at least reduce the current inconsistencies. Beware: older scripts will break, so some (perhaps many) users won't see this as an improvement. As a way to ease the pain (but still improve consistency), the exe and com installers could potentially leave the basic "syslinux[64].{exe,com} <device>" syntax as equivalent to using "-i", meaning "no option at all except for <device> (e.g. "a:")" would still mean "-i" (which is what happens right now, IIRC). IOW, we could focus on changing (aka patch) the "bootsecfile" syntax alone (for now) to the proposed "--bss file(.bss)" so it allows consistency and opens more possibilities, while deferring the rest for a later time/version. I am hopping this sum-up reflects an acceptable proposal (and that it is clear enough). Is it? Comments/thoughts/feedback/oversight/whatever? Regards, Ady.