[syslinux] Merging isolinux.bin and ldlinux.bin for Rufus

[Pete Batard]

On 2016.03.08 20:11, Shao Miller via Syslinux wrote:
> 1. Did you mean a truly "merged" file, where the very same file could
>     be used for ISOLINUX and for disk-based Syslinux?  Or did you mean
>     "tacked on," where ldlinux.bin would be appended to isolinux.bin so
>     that you could later split them apart?

The way I'd prefer (mostly because of the cool factor, and also because 
it would reduce the size for people who care about it... which I do as I 
also embed a 6.x ldlinux.sys in Rufus), is if the same file could be 
used for both ISOLINUX and disk-based Syslinux. Otherwise, I'd expect 
there would be some duplication. Part of me is also slightly worried 
about distro maintainers deciding to modify the source to remove a 
recent change that seems to increase the size of a file and duplicate 
content for no apparent reason, which would be more difficult to revert 
with the dual-executable model, but not that much...

The way I currently envision it is like some  busybox executable, where 
the behaviour of the executable changes according to its name. Although, 
in this instance, checking for the name might be difficult considering 
that there isn't really an underlying OS to report it back.

This being said, if appending ldlinux to isolinux is easier or less 
risky for the project, I can most certainly work with that in Rufus!

> 2. What about people who are too stupid to anticipate their ISOs being
>     converted to PXELINUX?  Do we tack on PXELINUX stuff to
>     isolinux.bin?

I will leave that up to other people on this list to decide.

I personally think that might make sense, as it sounds fair to try to do 
the same for PXE, if there's a chance it can help people dealing with 
ISO -> PXE conversion. But I don't have a strong opinion on that one.

> 3. In your experience, are people picky about which .c32 modules they
>     include, or do they just dump the whole lot in?

Let me pick what I hope can be a representative cross section of some 
ISOs I have, to try to provide a verifiable picture here (Syslinux 
version in parenthesis):

- archlinux-2016.01.01-dual.iso (sl 6.03)      -> only ldlinux.c32
- CentOS-7.0-1406-x86_64-Minimal.iso (sl 4.05) -> only vesamenu.c32
- clonezilla-live-2.1.2-24-i686-pae.iso (sl 5.10) -> about 6-7 .c32's
- debian-8.3.0-amd64-DVD-1.iso (sl 6.03)       -> 4 .c32's
- elementaryos-freya-amd64.20150411.iso (sl 4.05) -> 3 .c32's
- Fedora-Live-Cinnamon-x86_64-23-10.iso (sl 6.03) -> 4 .c32's
- gparted-live-0.23.0-1-i586.iso (sl 6.03)     -> 6 .c32's
- linuxmint-17.1-xfce-64bit.iso (sl 4.05)      -> only vesamenu.c32
- lubuntu-12.10-desktop-i386.iso (sl 4.05)     -> 3 .c32's
- nixos-graphical-16.03pre73316.93d8671-x86_64-linux.iso (sl 6.04) -> 
Looks like all of them!
- rhel-server-7.0-x86_64-dvd.iso (sl 4.05)     -> only vesamenu.c32
- slackware64-14.1-install-dvd.iso (sl 4.06)   -> no .c32
- tails-i386-2.0.1.iso (sl 6.03)               -> 5 .c32's
- ubuntu-15.10-desktop-amd64.iso (sl 6.03)     -> 5-6 .c32's

So the overwhelming majority of this sample base appears to cherry-pick 
modules.

>     I ask because
>     perhaps we could sneak ldlinux.bin into a .c32 module, which would
>     [thankfully] leave isolinux.bin alone.  Such a module could be a
>     trivial xtrafile.c32 program that simply lists the names of its
>     embedded files, for example.

That's not a bad line of thought.

Sadly it looks like some distros, such as Arch, are really going for the 
bare minimum in terms of modules they include...

> 4. If is was tremendously easy to find a disk-based Syslinux to work
>     with .c32s you find in an ISO, would you still advocate merging
>     isolinux.bin and ldlinux.bin, or is that the only reason to care
>     about having an ldlinux.bin?

If there an ldlinux.bin I can fetch on the ISO, I'm good. It doesn't 
really matter where it resides. As I said, I think the dual binary would 
be "cooler", as it would avoid duplication, but as long as I'm a beggar, 
I'll be happy with whatever you guys deem best. However, I can't promise 
that I'm not going to look into the dual (or triple if we add PXE) 
executable thing myself, and submit a patch for review, if I feel that 
such a solution isn't going to be shut down at the concept phase.

Also, just to confirm my eyes are not deceiving me:
ldlinux.bss + ldlinux.sys = lbdlinux.bin, right?

In which case you are correct to talk about ldlinux.bin and not 
ldlinux.sys as I was doing earlier, as I'll need the full set.

> P. S. I hope you've observed another Rufus-specific e-mail regarding
> Rufus and Syslinux version concerns. :)

+1 on trying to make the goal of this new discussion more explicit.

Regards.

/Pete