similar to: Problems with booting ReactOS over network using pxelinux

Correct the "seg=" value(s) corresponding to the "reactos=" option for chain.c32. The correct segment parameter should be "seg=0x0F80", instead of the incorrect / failing ones "seg=0:0x8000:0x8100". References: https://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/notes.txt?revision=73859&view=markup&pathrev=73859#l24

(snip) > > It's a bit more complex. At the time of writing, the data was perfect. > > https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/boot/freeldr/freeldr/include/arch/pc/x86common.h;hb=28e58e6d01892c1f2f0e1d323745e6463cb9e6c9 > dated 2011-06-14 > >

> On Wed, Jun 15, 2016 at 1:02 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > > >> On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > >> > > >> >> > kernel.c:new_linux_kernel() to load_linux.c:bios_boot_linux() because > >> >> > there is no convenient way in new_linux_kernel() to

On Mon, Feb 20, 2017 at 2:17 PM, Ady Ady via Syslinux <syslinux at zytor.com> wrote: > Correct the "seg=" value(s) corresponding to the "reactos=" option > for chain.c32. > > The correct segment parameter should be "seg=0x0F80", > instead of the incorrect / failing ones "seg=0:0x8000:0x8100". > > References: >

> > kernel.c:new_linux_kernel() to load_linux.c:bios_boot_linux() because > > there is no convenient way in new_linux_kernel() to control the boot > > flags value. > > This is the part that has me questioning things and trying to recall > if any other KERNEL-like directives ever utilize keeppxe. > @Gene, Not being a developer myself, I don't understand this

> On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > > >> > kernel.c:new_linux_kernel() to load_linux.c:bios_boot_linux() because > >> > there is no convenient way in new_linux_kernel() to control the boot > >> > flags value. > >> > >> This is the part that has me questioning things and trying

On Thu, Jun 16, 2016 at 06:20:31PM +0300, Ady via Syslinux wrote: > the main idea: if the LINUX directive would be capable of using / > parsing "keeppxe", then it might make sense to have the same capability > in linux.c32 (in addition to mboot.c32 and chain.c32). AFAICT, the following modules lead to the syslinux_boot_linux code path: ldlinux.c32 lua.c32 (for boot_linux and

Two commits available at: http://git.zytor.com/?p=users/sha0/syslinux.git;a=shortlog;h=refs/heads/chain_freeldr --- Author: Shao Miller <shao.miller at yrdsb.edu.on.ca> Date: Sun May 1 13:49:43 2011 -0400 chain: Support loading ReactOS' FreeLdr Use something like: LABEL freeldr COM32 chain.c32 APPEND freeldr=freeldr.sys Signed-off-by: Shao

PXELINUX has stopped recognizing the keeppxe option on the kernel command line. Here is a patch to make it work again. With COM32, it is no longer possible to use preprocessor directives to determine the SYSLINUX variant. The code inside the #if will never be compiled. So, I changed it to use syslinux_filesystem() to determine the variant. Also, I moved the relevant code from

I'm currently trying to integrate ReactOS's bootloader into my concept bootdisk with standard layout. It uses Syslinux 4.10pre15. This is failing on two parts: 1) bootsector method only works if specifying huge cluster size (16KB) 2) Multiboot method fails due to opening bootloader's configuration file from harddisk instead of bootdisk.

Fwiw, I think a ReactOS port would be very useful to both projects. One thing I think xen could do with (if it isn''t there already) is some sort of virtual framebuffer like with disk and network. Dom0 could provide the backend of the virtual framebuffer (on virtual consoles or inside X windows or whatever), and the other domains could make use of the exported framebuffers. It

On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > >> > kernel.c:new_linux_kernel() to load_linux.c:bios_boot_linux() because >> > there is no convenient way in new_linux_kernel() to control the boot >> > flags value. >> >> This is the part that has me questioning things and trying to recall >> if any other

When booting windows I currently have to use an extracted boot sector to chain-load the OS, is there any merit to creating a method to execute NTLDR directly using a /reverse engineered/ version of the boot sector?

> On 2014-12-07, at 14:57, jay at m5.chicago.il.us wrote: > > >> >> If you want a stand alone Wine, you are looking at React OS, >> which is awful .... >> > > I have noticed that also. Does anyone here know anything about the > ReactOS project? Is it ever going to be a respectable free non-Unix > operating system, like Haiku or Plan 9? Yes. To

After adding /reactos as windows systemroot, virt-inspector identified OS as windows with product name ReactOS. Fixes RHBZ#709326. Related bug RHBZ#709327 seems to be already fixed in ReactOS 0.4. Maros Zatko (1): inspector: add /reactos as systemroot src/inspect-fs-windows.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.3

Hi Everyone, For those of you who don't know, Reactos (www.reactos.com) is an open source (GPL) attempt to write an NT compatible operating system. By the end of the year the kernel should be developed enough to support a GUI. My first thought was to grab the xfree86 source code and use the bitmaps, etc. from there and program my own USER32.DLL. However, if WINE can be altered to run on

today the reactos web site is down http://www.reactos.org/en/index.html what's happened? it's really dead? [Crying or Very sad] [Crying or Very sad]

I have read just the comment from Mark Wielaard, the leader of GNU Classpath: http://gnu.wildebeest.org/diary/index.php?p=129 And after that I have a question, if somethinl like Mauve exists also for WINE/ReactOS? GNU Classpath is a OpenSource-Version of the Java Standard Edition Classes. And Mauve are testclasses, which test, that the OpenSource JVMs with GNU Classpath are still working

Hi, I've got a question regarding pxelinux: It seems that there is a buck in syslinux 3.86 (or still is in the current build) in the reset_pxe function. If I call "syslinux_local_boot(0)" (in a COM32 binary) the KeepPXE variable is always 1 which resets the PXE stack instead of unloading it: local_boot: push cs pop ds mov [LocalBootType],ax call vgaclearmode mov

Changes in 4.05: * HDT updated, and now supports uploading data to a TFTP server. * ISOLINUX: remove the .img file support; it has been broken on virtually all systems since the beginning, and has been totally broken since 4.00 at least. Use MEMDISK instead. * chain.c32: Support chaining ReactOS' FreeLdr (Shao Miller) * isohybrid: