similar to: [syslinux:master] isohybrid: Function to write UTF-16LE strings

The worst sin of isohybrid.c was to compose GPT partition names by 8-bit characters and to memcpy() them as if they were 16 bit wide. GPT names are encoded as UTF-16LE. It is trivial to create this encoding from 7-bit ASCII. This change introduces two byte arrays with the desired UTF-16LE names which replace the string constants "ISOHybrid ISO" and "ISOHybrid". ---

EFI systems typically don't support booting off ISO 9660 filesystems, even if written to USB sticks. This patch adds support for generating a GPT that covers the stick as well, with an additional partition entry pointing purely at the secondary El Torito image. When burned to CD the secondary El Torito will be used as an EFI boot image, and when written to a USB stick the GPT partition

Hi, following will be 6 patch proposals for isohybrid.c 1: Encode GPT partition names as UTF-16LE 2: Correct blocking factor in APM partition block counts 3: Correct end block address of first GPT partition 4: Write GPT backup to the very end of the image 5: Change all fseek(3) to fseeko(3) 6: Introduce option --mbr and make isohybrid.c compilable standalone If the form needs adjustments,

The GPT partition 1 covers the whole ISO filesystem size. GPT specs demand that the partition end block number shall be the last valid block in the partition. isohybrid.c rather wrote the number of the first block after the partition end. This change reduces the number by 1. --- utils/isohybrid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/isohybrid.c

Hi, i am currently exploring the boot data of Matthew Garret's Fedora LiveCD. For that i read utils/isohybrid.c from git resp. 4.05. (I assume Matthew used options --efi --mac --type 0 .) Some stumblestones showed up: ----------------------------------------------------------------------- In initialise_gpt() i see unhealthy usage of string constants. Like: memcpy(part->name,

On 06/23/2014 09:19 PM, Geert Stappers wrote: >> diff --git a/utils/isohybrid.c b/utils/isohybrid.c >> index 0011b78..e308a82 100644 >> --- a/utils/isohybrid.c >> +++ b/utils/isohybrid.c >> @@ -593,7 +593,7 @@ read_mbr_template(char *path, uint8_t *mbr) >> err(1, "could not open MBR template file `%s'", path); >> clearerr(fp);

The GPT backup header block should start 512 bytes before the end of the image file (resp. end of the disk device). This block and the backup GPT array were wrongly written 512 bytes too early. This change brings the backup GPT at its correct position. --- utils/isohybrid.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/utils/isohybrid.c b/utils/isohybrid.c index

Hi, Duncan Elliot wrote: > As far as I can see, this essentially trims off the first 3 bytes of the > custom isohybrid MBR image before applying it to the ISO. You probably mean this line: memcpy(mbr, &isohdpfx[hd0 + 3 * partok], MBRSIZE); The indize do not apply to bytes but to byte arrays of size MBRSIZE. extern unsigned char isohdpfx[][MBRSIZE]; (hd0 + 3 * partok)

Hi, I have been attempting to set up a multi-boot USB stick (i.e. multiple bootable ISO images on the one stick) I have had good success by: - processing ISO with isohybrid (with "partok" flag) - dd'ing ISO to primary partitions on the USB stick (e.g /dev/sdc2, /dev/sdc3, /dev/sdc4) - installing grub to USB stick and configuring to chainload to these partitions To remove the limit

Dear list, I have been trying to debug a build failure for a while in the utils directory on isohybrid which seems to be distro specific. On Fedora 17 64bit the build completes without problems, but under both Ubuntu 32/64bit 11.10 and 12.04 I get the following: tim at oxygen:/usr/src/git/syslinux/utils$ make gcc -O2 -luuid -o isohybrid isohybrid.o isohdpfx.o isohybrid.o: In function

It seems unwise to offer future programmers fseek(3) calls for copy+paste. They are simply insufficient for large image files. This change switches all calls of fseek(3) to fseeko(3) and takes care that the offset value if of type off_t. --- utils/isohybrid.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/utils/isohybrid.c b/utils/isohybrid.c index

Various EFI systems insist that there be no active flag in the pMBR in order to parse the GPT. The only way around this is to also generate a valid MBR - the firmware will then pick that up and use the system partition provided there. In order to deal with other EFI "sanity" checks, the partition type for the non-EFI partitions is set to 0 to skip the firmware bailing because of

Thanks for the clarification Thomas. Thomas Schmitt wrote: > (Did you already tell which partitions exist and in which one do you want > to put your ISO ?) I've tried a number of different structures, but the results are consistent (boots fine from primary partitions, not from logical partitions). For example for a disk partitioned like below: Disk /dev/sdc: 3.8 GiB, 4007657472

??? Hi, Recently it was brought to notice by Mr Steffen(snwint at suse.de) that ---- > syslinux 4 comes with a C-rewrite of isohybrid. Unfortunately the option > parsing has changed: it no longer accepts hex numbers (0x...). Was this > intentional or can we have the old behaviour back (say, changing > sscanf(%u) -> sscanf(%i))? > I've made the changes to the current git

* Richard W.M. Jones: >> - nk->name_len = htole16 (strlen (name)); >> - strcpy (nk->name, name); >> + nk->name_len = htole16 (recoded_name_len); >> + memcpy (nk->name, recoded_name, recoded_name_len); >> + free(recoded_name); > > Please put spaces after function names! It improves readability: Sorry, I'll fix those. I also forgot to add a

--- lib/hivex-internal.h | 1 + lib/utf16.c | 10 ++++++++++ 2 files changed, 11 insertions(+) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index 6bc8638..7f4cc3c 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -277,6 +277,7 @@ extern char * _hivex_recode (const char *input_encoding, _hivex_recode ("LATIN1", _input, _len, "UTF-8",

Dear R-help, I am having trouble reading a UTF-16LE formatted file. The issue appears to be a byte order mark at the beginning of the file. I have tried readLines(file, encoding='utf-16LE') but got me [1]"\xff\xfe1" "" "" "" "" "" Regards, Tim

Dear R-help, I am having trouble reading a UTF-16LE formatted file. The issue appears to be a byte order mark at the beginning of the file. I have tried readLines(file, encoding='utf-16LE') but that got me [1]"\xff\xfe1" "" "" "" "" "" This is a tab delimited text file, despite the ANA extension. It is created by a custom

The earlier post had an attached text file that did not go through. I hope this link works. I tested it with a coworker, but that is no guarantee. https://uflorida-my.sharepoint.com/:u:/g/personal/tebert_ufl_edu/EXf5u_CtTwJCrhdfTBIPr7wBefZHx4P_suj4wAWb8i8HFA?e=iQawhh Regards, Tim

Try this: > x <- file("C:\\Users\\Jim\\Downloads\\PV2-ch2 - R_Help.ANA",+ encoding = "UTF-16")> y <- readLines(x)> head(y)[1] "1\t36,74\t0" "2\t269,02\t-44" "1\t326,62\t29" "2\t354,52\t24" [5] "8\t390,75\t1838" "2\t395,11\t-1053"> > Thanks Jim Holtman *Data Munger Guru*