similar to: com32 module compatibility between 5.x versions

On 2013.08.10 01:55, H. Peter Anvin wrote: >> I assume it's not possible to store a copy of the LDLINUX.SYS binary at >> the end or inside of either ISOLINUX.BIN > > Not really. ldlinux.sys isn't just an ordinary file, it really needs to > be installed with the Syslinux installer. My application already its own version of the Syslinux installer [1], and simply

On 2013.08.10 04:07, H. Peter Anvin wrote: >> My application already its own version of the Syslinux installer [1], >> and simply requires the relevant ldlinux.sys file to be provided. > > But that, too, is version-specific. I think there may be a misunderstanding here. Are you saying that when installing ldlinux.sys + ldlinux.bss v5.01 on a FAT filesystem, the installer needs

On 08/10/2013 08:02 AM, Pete Batard wrote: > On 2013.08.10 04:07, H. Peter Anvin wrote: >>> My application already its own version of the Syslinux installer [1], >>> and simply requires the relevant ldlinux.sys file to be provided. >> >> But that, too, is version-specific. > > I think there may be a misunderstanding here. > > Are you saying that when

The following boot entries: # COM32 chain.c32 APPEND fs ntldr=/bootmgr # or: # COM32 chain.c32 APPEND hd0,1 ntldr=/bootmgr # might result in the following error: # Insane primary (MBR) partition. Can't find myself on the drive I booted from. # when using chain.c32 v4.07. I have seen similar error reports when using chain.c32 v4.06 too. It works correctly with chain.c32 v4.05, even when

Hi Shao, You're right, "a=b=<immediate value>;" wasn't the actual issue. On 2016.03.06 20:34, Shao Miller via Syslinux wrote: > If this change is simply due to a mental note about an incident where a > compiler once complained about this type of thing The problem was due to the following warning when compiling for 64-bit using using the latest WDK (7600.16385.1),

Hi, As I am embedding part of the Syslinux code in Rufus [1], I have encountered various issues that I would like to see addressed, so that I can keep most of my code in sync with the official mainline. Some of these fixes have to do with being more friendly with MSVC compilation, and other are fixes for actual Syslinux issues, that Rufus users have encountered. For convenience, the

Hi there, ----- Original Message ----- From: koxudaxi at gmail.com To: syslinux at zytor.com Date: 01.04.2013 10:00:27 Subject: Re: [syslinux] Problem with pxelinux 5.0 and memtest > On 04/01/2013 09:28 AM, H. Peter Anvin wrote: >> On 03/31/2013 05:26 PM, Koudai Aono wrote: >>> I ran the test on a x86 emulator is called Oracle VirtualBox. >>> I think it might not be

On 2016.03.03 04:37, H. Peter Anvin via Syslinux wrote: > I don't think that is an issue. Well, I didn't really want to mention it, because it's going to be more of a rant that anything else, but since this is being brought up, versioning detection and handling has very much been an issue for me in Rufus. As I mentioned in the summary of the patches I submitted recently, 6.03

Here are some thoughts: 1. Customized Syslinux could be customized such that it refuses to boot from USB. No amount of version-matching nor downloading from the same source can help with that scenario. A different Syslinux would be needed, by definition (of the customizer) 2. Slightly less bad is where an ISO or CD/DVD is made with a key piece of non-ISOLINUX Syslinux missing

[disclaimer: I am the author of Rufus] Hi, On 2014.01.15 10:10, Thomas Schmitt wrote: > As producer of MBRs i wonder where that LBA-flag is located. > In bit 0 to bit 6 of byte 446 (where bit 7 means active/bootable) ? I haven't looked at what GParted does, so I may be off mark, but I have a strong suspicion that this LBA "flag" is a fake flag that simply indicates if a

On 3/8/2016 14:26, Pete Batard via Syslinux wrote: > [...] > But in essence, yes, that's pretty much it. So then some thoughts: 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

H. Peter Anvin schreef op 9-8-2013 7:37: > Sorry. If you are substituting any files you should substitute them all. I assume it's not possible to store a copy of the LDLINUX.SYS binary at the end or inside of either ISOLINUX.BIN or LDLINUX.C32 then? Then at least it could be extracted, for those distributions not having LDLINUX.SYS / SYSLINUX(64).EXE present on their CD. Having

i`ve found a bug in chain.c32 in v4.06. When i use isolinux it does not run windows7 installation, chainloading bootmgr. the error is: Can't find myself on the drive I booted from. chain.c32 from syslinux 3.xx works like a charm! chain.c32 from syslinux 5 shous tat this is not a com32 app

On 2016.02.26 15:32, Ady via Syslinux wrote: > Regarding the "+1", when talking about the math (not the computer code > to achieve a result as accurate as it can be) Well, sorry, but I will not dissociate the context of application from the formula itself. I thought this was implied into what I wrote, which was in the context of fixing a computation algorithm bug. The sole

On Thu, Feb 25, 2016 at 7:59 PM, Pete Batard via Syslinux <syslinux at zytor.com> wrote: > Hi Ady, > > Your insightful post prompted me to to a little bit more digging as to how > the Ridgecrop algorithm computed its FAT size, with the result of my > investigations presented below. > > NB: For those who don't want to go through this whole part, there's a TL;DR

Pete Batard via Syslinux <syslinux at zytor.com> writes: > One solution to avoid that would be to embed in Rufus all possible > .c32 modules from Syslinux, alongside with the 'ldlinux.sys' version > we have, and replace them on the USB. Why not install instead an arbitrary version of Syslinux and replace all .c32 files with the modules of the installed version? --

Pete Batard <pete at akeo.ie> wrote: > On 2013.08.09 16:24, Bernd Blaauw wrote: > >> Sorry. If you are substituting any files you should substitute them all. > > > From where I stand, the idea that someone using an ISO will only ever > use it in optical media mode (either real or emulated) is a thing of > the past. > > These days, you can be almost certain

On Tue, 8 Mar 2016, Pete Batard via Syslinux wrote: > would. As I mentioned, I've seen reports of ISOHybrids that didn't boot in DD > mode, but that seemed to work using the Rufus process. And you will always be > limited by what the "automated process" that is the ISOHybrid algorithm can > do (which can of course be modified by a developer, but so can Rufus'

On 3/6/2016 17:03, Pete Batard via Syslinux wrote: > The problem was due to the following warning when compiling for 64-bit > using using the latest WDK (7600.16385.1), with warning level 3 (/W3): > > 1>c:\rufus\src\syslinux\libinstaller\syslxmod.c(44) : warning C4242: > '=' : conversion from 'sector_t' to 'unsigned int', possible loss of data Then your

On Sun, Mar 6, 2016 at 8:21 PM, Shao Miller via Syslinux <syslinux at zytor.com> wrote: > On 3/6/2016 17:03, Pete Batard via Syslinux wrote: >> >> The problem was due to the following warning when compiling for 64-bit >> using using the latest WDK (7600.16385.1), with warning level 3 (/W3): >> >> 1>c:\rufus\src\syslinux\libinstaller\syslxmod.c(44) :