Syslinux - Jun 2014 - isohybrid has 2 variants

>Although there are some "isohybrid.exe" around, there is no
official support for them and they are also outdated.
>The Syslinux mailing list already includes several emails about issues in
the included isohybrid variants. I think that deleting either of them would be a
mistake. At least users such as Ian might benefit from both being included.
>Ideally, the Perl variant should get updated at least with the patches that
the C variant already includes, and then solve the remaining known problems. Any
takers?






While I did know the .exe variant was not official / untrusted, I didn't
know the official Perl and binary versions were out of sync in terms of
features/bugfixes. If the Perl version cannot be maintained alongside the binary
version (sadly I don't know any Perl to help with this), I agree with Geert
that it should be removed or the differences clearly documented.


--Ian

Hi,

Ady:
> Since both included variants are currently different, and both 
> variants have problems
I am not aware of problems of the perl version. It is just lacking
the newer features which support EFI/GPT and Mac/APM.
The known bugs of isohybrid.c are with those newer features.
  http://www.syslinux.org/archives/2012-May/017843.html
  http://www.syslinux.org/archives/2012-May/017871.html

> Ideally, the Perl variant should get updated at least with the 
> patches that the C variant already includes
As a programmer who knows the task, i'd say that C is the right
language to implement isohybrid. It introduces the least
dependencies and is well suited for the necessary byte operations.
Of course the build system of SYSLINUX would have to produce
a suitable executable from isohybrid.c.

The executable has hardcoded MBR templates. I once got instructed
by hpa, not to mix MBR from one SYSLINUX version with the
isolinux.bin boot images from other versions.
This applies to the executable from isohybrid.c and to isohybrid.pl.

So my proposal would be to fix isohybrid.c and to declare
isohybrid.pl frozen and deprecated.
(As long as isohybrid.in exists it will be able to adapt to
 the MBR templates of new SYSLINUX versiosn.)


Ian Bannerman:
> While I did know the .exe variant was not official / untrusted,
Is there a special reason for this ? (Except the known bugs which
affect Linux binaries, too.)


Have a nice day :)

Thomas

> 
> >Although there are some "isohybrid.exe" around, there is no
official
> support for them and they are also outdated.
> 
> >The Syslinux mailing list already includes several emails about 
> issues in the included isohybrid variants. I think that deleting 
> either of them would be a mistake. At least users such as Ian might 
> benefit from both being included.
> 
> >Ideally, the Perl variant should get updated at least with the 
> patches that the C variant already includes, and then solve the 
> remaining known problems. Any takers?
> 
> 
> While I did know the .exe variant was not official / untrusted, I 
> didn't know the official Perl and binary versions were out of sync in 
> terms of features/bugfixes. If the Perl version cannot be maintained 
> alongside the binary version (sadly I don't know any Perl to help 
> with this), I agree with Geert that it should be removed or the 
> differences clearly documented.
> 
> --Ian
Your wording seems to (unintentionally, I'm sure) slightly misquote 
prior statements.

Geert is suggesting the deletion of the Perl variant (which means you 
have had no choice when you had problems with the C variant).

I am, _on the other hand_, suggesting adding documentation (leaving 
the option to at least try the Perl alternative when the other one 
doesn't fit user's needs or fails for whichever reason). FWIW, I am 
against deleting the Perl variant.

FWIW (not that my opinion has any special value), I would agree to 
its deletion if the C variant would serve users in each and every 
single case. Your example shows this is not the case.

Let me put it this way: IMHO, the possibility that the Perl variant 
might not achieve its goal in certain cases is not reason enough to 
delete it. Remember that the C variant included in Syslinux has 
limitations too.

The known issues should be an encouragement to improve them, both.

Regards,
Ady.

> Hi,
> 
> Ady:
> > Since both included variants are currently different, and both 
> > variants have problems
> 
> I am not aware of problems of the perl version. It is just lacking
> the newer features which support EFI/GPT and Mac/APM.
> The known bugs of isohybrid.c are with those newer features.
>   http://www.syslinux.org/archives/2012-May/017843.html
>   http://www.syslinux.org/archives/2012-May/017871.html
> 
 
Not being compatible with EFI/GPT is already a problem for the Perl 
variant. The cases were the C variant might fail are also a problem, 
as common users don't know that different variants (including these 
two, the xorriso ones, and possibly others) might have different 
results. Add the lack of documentation about the differences, and you 
will get (sooner or later) reports about "isohybrid not working". To 
such reports we already answer with "which version of Syslinux?",
"is
your ISO image publicly available?", and "which tool was used to 
build the ISO image?".

Without documentation (variants, versions, capabilities, limitations, 
requirements, OS...), how many detailed questions a common user would 
need to answer just to try to overcome (perhaps) the problem? How 
about the time to be invested just to (repeatedly) ask those 
questions?

Updating the Perl variant would reduce the need for initial 
questions/details (which is frequently not something common users are 
in conditions to answer/provide). Since I am aware that such 
potential update to the Perl variant requires someone stepping up (I 
am sure patches are welcome), I was previously asking for some 
initial direction regarding the potential existence of some public 
reference about the different variants and their respective different 
behaviors (so to add documentation to the wiki, for example).

 
> 
> > Ideally, the Perl variant should get updated at least with the 
> > patches that the C variant already includes
> 
> As a programmer who knows the task, i'd say that C is the right
> language to implement isohybrid. It introduces the least
> dependencies and is well suited for the necessary byte operations.
> Of course the build system of SYSLINUX would have to produce
> a suitable executable from isohybrid.c.
 
As you might have read already in prior emails, the Perl variant 
might be helpful under some circumstances, e.g. if we consider the OS 
itself a dependency.
 
> 
> The executable has hardcoded MBR templates. I once got instructed
> by hpa, not to mix MBR from one SYSLINUX version with the
> isolinux.bin boot images from other versions.
> This applies to the executable from isohybrid.c and to isohybrid.pl.
> 
> So my proposal would be to fix isohybrid.c and to declare
> isohybrid.pl frozen and deprecated.
> (As long as isohybrid.in exists it will be able to adapt to
>  the MBR templates of new SYSLINUX versiosn.)
 
Although I hope someone can still update the Perl variant, at least 
it should not be deleted and the differences / limitations should be 
documented. FWIW, I would not want to "declare" it frozen, as it 
would stop any potential contributions attempting to improve the Perl 
variant.
 
> 
> 
> Ian Bannerman:
> > While I did know the .exe variant was not official / untrusted,
> 
> Is there a special reason for this ? (Except the known bugs which
> affect Linux binaries, too.)
 
I am not sure I understand you question. I don't know whether those 
"isohybrid.exe" are "untrusted", but they are not an
official part of
The Syslinux Project (read as "not distributed in official upstream 
archives"). Moreover, lack of documentation for them would also be a 
problem, and common users might not know the respective Syslinux 
versions they are based upon (common users frequently don't know they 
should match the Syslinux version at all).

If one distro is already producing one "isohybrid.exe" (v.4.06 last 
time I checked), I would tend to think it is also possible for The 
Syslinux Project to generate such executable for Windows common users 
(who can't use the C variant without knowing how to build it under 
cygwin or equivalent, nor can use xorriso's method either). Although 
not a replacement for the Perl variant (for example under other OS), 
I would tend to think it would be welcome.

Again, The Syslinux Project needs more development-power-time and 
patches are welcome.
 
> 
> Have a nice day :)
> 
> Thomas
> 
 
Regards,
Ady.