> Hi, > > > Not being compatible with EFI/GPT is already a problem for the Perl > > variant. > > The relation of both is: > > isohybrid.in/.pl is being left behind. > http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/Makefile > has: > SCRIPT_TARGETS += isohybrid.pl # about to be obsoleted > > isohybrid.c replaces it feature-wise and adds new features. > Only those new features contain the bugs, afaik.I understand that the differences between the 2 variants are related to EFI/GPT/Apple. Whichever they are, the existence of 2 variants is not emphasized enough to common users, much less the differences. The current source of the Perl variant might not have problems when used inside its limitations, but a common user might have no idea of such limitations. Trying to use the Perl variant outside its limitations _is_ a problem _for the user_. I'll go directly to the bottom line: more (user-friendly) documentation is needed.> > > > Add the lack of documentation about the differences, > > ... and the fact that > http://www.syslinux.org/wiki/index.php/Doc/isolinux > still describes the perl script, whereas > http://www.syslinux.org/wiki/index.php/ISOLINUX > says nothing about isohybrid. > > Probably one should consolidate the articles about ISOLINUX. > A chapter about isohybrid could tell about all three ways to > create an isohybrid ISO: isohybrid.c, isohybrid.pl, xorriso.The wiki pages under ".doc/" are based on the respective documentation included in the Syslinux official distribution archives, the others don't, so the latter ones get direct updates in the wiki (it doesn't mean that the wiki documentation is all up-to-date). There are "some" mentions about isohybrid throughout the wiki, but it should probably receive its own page (linked from the ISOLINUX wiki page and from others). Most distros that support/use some variant of isohybrid already include steps to produce isohybrid images, so whatever is added to the Syslinux wiki should really _add_ (not repeat) info. The existence of different variants, their limitations, the requirement for matching the ISOLINUX (e.g. iso*.bin files) version, and the available command line options, are probably relevant points.> > > > 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. > > It would need a maintainer, then.There is a lot to do in Syslinux, and patches are desired / appreciated / welcome. If the Perl variant is "declared" frozen, people that might be tempted to sporadically send patches might refrain from doing so, whereas a "maintainer" might sound as "too much" for them. Therefore, documenting the differences and being open to receive patches sounds to me a more flexible choice (comparing to deleting it, or to "freezing" it, for example).> A good way to enter this job would to learn about the new features > in isohybrid.c, fix the bugs (with my help), and to then port > the features to isohybrid.in. > > > > FWIW, I would not want to "declare" it [isohybrid.in/.pl] frozen, > > It effectively is. And the shape of isohybrid.c is not much better.I am not part of The Syslinux Project Team, but I am anyway using this opportunity to call for developers to send patches (it doesn't have to be regarding isohybrid; there is a lot to do).> > > > 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"). > > Neither perl nor .exe are in my knowledge base. But maybe some > skilled user of MS-Windows can propose a way to create a > widely usable .exe, which must be able to do >= 43 bit byte > addressing in data files.All the "isohybrid.exe" I know of are based on the Perl variant. I don't know what would be needed so to make one based on the C variant. Until someone steps up to the challenge, I think it is worth building one isohybrid.exe from the Perl variant in the official upstream Syslinux (pre-)releases (just as Slitaz does).> > > > Again, The Syslinux Project needs more development-power-time and > > patches are welcome. > > If i fix isohybrid.c then it will stick to me. > After a while it would become the same as the libisofs/xorriso > implementation. (I would read MBRs from the SYSLINUX installation, > would drop the dependency on libuuid, ... perky changes ...)Understandable.> > Have a nice day :) > > Thomas >Just for completeness... The patch sent in http://www.syslinux.org/archives/2014-June/022259.html suggests that the 2 prior bug reports: http://www.syslinux.org/archives/2012-May/017843.html http://www.syslinux.org/archives/2012-May/017871.html might not be the only ones. Regards, Ady.
Hi,> All the "isohybrid.exe" I know of are based on the Perl variant.I just got one from http://www.filewatcher.com/m/isohybrid.exe.39568-0.html Its strings seem not to stem from isohybrid.pl. Digging in slitaz source brought a shell script (that would be variant #5 then): http://hg.slitaz.org/wok/file/313b384e2a06/syslinux/stuff/tools/isohybrid.sh But isohybrid.exe must have a different source. How about this as source of variant #4 (isohybrid.exe): http://cook.slitaz.org/cooker.cgi?stuff=syslinux/stuff/iso2exe/iso2exe.c Despite its name it has: return "Usage: isohybrid.exe file.iso [--forced]\n"; and many of the other strings which i see in "isohybrid.exe".> http://www.syslinux.org/archives/2014-June/022259.html > suggests that the 2 prior bug reports: > http://www.syslinux.org/archives/2012-May/017843.html > http://www.syslinux.org/archives/2012-May/017871.html > might not be the only ones.Yeah. It also has problems with large (image) file support. Already reported in may and diagnosed by hpa: http://www.syslinux.org/archives/2014-May/022041.html:> The right thing to do is compile it with #define _FILE_OFFSET_BITS 64 > and change fseek to fseeko with the appropriate type being off_t.This brings of course the question how to do this on MS-Windows. That's why i asked for a DOS exe that can handle 43 bit file byte addressing (32 bit ISO block count + 11 bits usual block size) Further there is the freshly spotted misnomer "AFP" in the help text of isohybrid.c. It should be "APM". ---------------------------------------------------------------- Known Variants up to now: - isohybrid.in -> isohybrid.pl from SYSLINUX, no EFI/GPT support - isohybrid.c -> isohybrid from SYSLINUX - libisofs/make_isohybrid_mbr.c from libburnia, needs isohdp[fp]x*.bin -> libisofs, xorriso from SYSLINUX - isohybrid.sh from SliTaz, no EFI/GPT support - iso2exe.c -> isohybrid.exe from SliTaz, no EFI/GPT support ---------------------------------------------------------------- If somebody wants to assess the quality, i would propose to inspect the resulting ISOs by xorriso >= 1.3.7 xorriso -indev image.iso \ -report_el_torito plain \ -report_system_area plain It knows El Torito, MBR, GPT, and APM and complains about some known flaws or pitfalls. Have a nice day :) Thomas
> Hi, > > > All the "isohybrid.exe" I know of are based on the Perl variant. > > I just got one from > http://www.filewatcher.com/m/isohybrid.exe.39568-0.html > > Its strings seem not to stem from isohybrid.pl. > > Digging in slitaz source brought a shell script (that would be > variant #5 then): > http://hg.slitaz.org/wok/file/313b384e2a06/syslinux/stuff/tools/isohybrid.sh > > But isohybrid.exe must have a different source. > > How about this as source of variant #4 (isohybrid.exe): > > http://cook.slitaz.org/cooker.cgi?stuff=syslinux/stuff/iso2exe/iso2exe.c > > Despite its name it has: > return "Usage: isohybrid.exe file.iso [--forced]\n"; > and many of the other strings which i see in "isohybrid.exe". >My initial focus was on (finding) documentation. I hope we are not going too much off-topic talking about the isohybrid.exe variant from Slitaz, Anyway... The receipt of the "syslinux-extra" package in Slitaz includes: cp -a $src/isohybrid.sh $fs/usr/bin/isohybrid cp -a $src/iso2exe/iso2exe $fs/usr/bin/iso2exe (Note: I am intentionally not posting the protocol for the following paths.) *_At the time I am writing this email_*, the current receipt is: hg.slitaz.org/wok/file/313b384e2a06/syslinux-extra/receipt An additional relevant receipt is the one for "syslinux-tools": hg.slitaz.org/wok/file/313b384e2a06/syslinux-tools/receipt which is the package that includes isohybrid.exe. Indeed the isohybrid.sh script currently is: hg.slitaz.org/wok/file/313b384e2a06/syslinux/stuff/tools/isohybrid.sh So, using the current isohybrid.in included in official upstream Syslinux, perhaps a similar script and makefile could generate a matching isohybrid.exe in each official (pre-)release. If it could be based on isohybrid.c, even better.> > > http://www.syslinux.org/archives/2014-June/022259.html > > suggests that the 2 prior bug reports: > > http://www.syslinux.org/archives/2012-May/017843.html > > http://www.syslinux.org/archives/2012-May/017871.html > > might not be the only ones. > > Yeah. It also has problems with large (image) file support. > Already reported in may and diagnosed by hpa: > > http://www.syslinux.org/archives/2014-May/022041.html: > > The right thing to do is compile it with #define _FILE_OFFSET_BITS 64 > > and change fseek to fseeko with the appropriate type being off_t.This has been already applied in the Syslinux git (zytor repo).> > This brings of course the question how to do this on MS-Windows. > > That's why i asked for a DOS exe that can handle 43 bit file byte > addressing (32 bit ISO block count + 11 bits usual block size)I don't know about that :(.> > > Further there is the freshly spotted misnomer "AFP" in the help > text of isohybrid.c. It should be "APM". > > > ---------------------------------------------------------------- > Known Variants up to now: > > - isohybrid.in -> isohybrid.pl from SYSLINUX, no EFI/GPT support > > - isohybrid.c -> isohybrid from SYSLINUX > > - libisofs/make_isohybrid_mbr.c from libburnia, needs isohdp[fp]x*.bin > -> libisofs, xorriso from SYSLINUX > > - isohybrid.sh from SliTaz, no EFI/GPT support > > - iso2exe.c -> isohybrid.exe from SliTaz, no EFI/GPT support > > ----------------------------------------------------------------Good _starting_ point for documentation.> > If somebody wants to assess the quality, i would propose to inspect > the resulting ISOs by xorriso >= 1.3.7 > > xorriso -indev image.iso \ > -report_el_torito plain \ > -report_system_area plain > > It knows El Torito, MBR, GPT, and APM and complains about some known > flaws or pitfalls.That's great. Since xorriso is not always an available option for some users (e.g. other OS), I hope for The Syslinux Project to still get help from developers (regarding isohybrid or other matters).> > > Have a nice day :) > > ThomasRegards, Ady.