Hello devs,
Few users at spanish ReactOS blog ( http://reactos.wordpress.com ) are
asking about having both Windows and ReactOS installed in different
partitions at the same time...
And i wanted you to answer, rather than me... :P
What would you say? Is it currently possible?
Hi,
while working on GPT handling for ReactOS, one thing appeared: Microsoft (at least in Windows 2003 SP1) is using hardcoded partition entry size, ie it assumes that every partition entry in GPT will be 128 bytes big. Even if that assertion is largely right, it might exist cases where it's wrong. That's even why there's a field in GPT header that contains such size. Furthermore, reading Apple technical note(1) about GPT precise one more thing: "Do not hardwire the current size of the partition entry (128 bytes).".
As we have no commercial issues with Apple, perhaps could we drop a bit compatibility with Windows 2003 and fix something obvious? In most cases, users won't see any difference. Only difference would be that ReactOS could properly handle GPT with exotic partition entry size when Windows can't.
Any opinion on that subject?
Best regards,
P. Schweitzer
(1): http://developer.apple.com/library/mac/#technotes/tn2006/tn2166.html
Hello,
eVb checked in one of his final patches yesterday from his development machine in China, where we worked on a final pass on the driver. Unfortunately, my last two (unrelated) check ins were done from his machine (as most of you know, I was in China for the past month), and he was not used to SVN caching the credentials of the last user. Revision 48748 was a checkin from eVb, and his "goodbye" was in reference to my departure. Since it used my cached credentials from the same machine, it must've caused a lot of confusion.
Many apologies and thanks for understanding.
-r
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sat Sep 11 09:20:26 2010
> New Revision: 48745
>
...
> /* Save EFlags */
> + Esp -= 4;
> + *(PULONG)(Esp - 2) = V86EFlags;
>
This looks wrong to me. The (Esp - 2) I mean.
> + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32)
> + {
> + /* Read EFlags */
> + EFlags = *(PULONG)Esp;
> + Esp += 4;
> + }
> + else
> + {
> + /* Read EFlags */
> + EFlags = *(PUSHORT)Esp;
> + Esp += 2;
> /* Read correct flags and use correct stack address */
> - Esp -= 2;
> EFlags &= 0xFFFF;
>
Here the comment got broken a bit.
> /* Set new ESP */
> - TrapFrame->HardwareEsp = Esp;
> + TrapFrame->HardwareEsp = (USHORT)Esp;
>
This is not correct. We earlier calculated the flat Esp from Ss and Sp.
Example:
HardwareSegSs = 0x10, HardwareEsp = 0x10 -> flat Esp = 0x110, then you
substract 4, and get 0x10C. But this is not the value of the new
HardwareEsp. TrapFrame->HardwareEsp needs to be either modified in
parallel to the flat Esp or calculated like (USHORT)(Esp -
(TrapFrame->HardwareSegSs << 4)).
Regards,
Timo
Hi!
I just found a severe bug in hardware detection code of Freeldr. It uses
two configuration nodes in the hardware tree to pass information about
detected hard-disks to ntoskrnl.exe and disk.sys.
First, hard-disk information is passed as a DiskPeripheral node attached
to a DiskController node.
Second, hard-disk information is passed as an array of
CM_INT13_DRIVE_PARAMETER entries in a special system configuration node,
if the disks were detected by the BIOS.
As part of the boot process, the special system configuration node is
used by disk.sys to determine the disk geometry used by the BIOS.
Unfortunately, this configuration node did not use the extended disk
geometry (LBA geometry) but the old CHS geometry even if the LBA
geometry was available.
I already fixed this bug in my local source tree and suddenly Freeldr,
disk.sys and usetup.exe report exactly the same disk geometry as gparted
(http://gparted.sourceforge.net/download.php). Unfortunately, using this
patch breaks the 2nd stage setup.
I will provide a patch that fixes the Freeldr issue as soon as I have
cleaned up the source tree.
Please help me find the remaining bug or workaround that keeps ReactOS
from booting into 2nd stage setup! I guess it is either part of usetup
or somewhere in the partition management routines.
Regards,
Eric
Hi,
why reimplementing an unsecure IoReadPartitionTable version? It even looks like IoReadPartitionTableEx() which may arrive soon in ReactOS ;).
Best regards,
P. Schweitzer
Hi,
What You say makes sense of course.
I can't find time to dig into the code, but it sounds like you acted
correctly.
We can of course improve the setup behavior as time goes and we learn how
to do it right with various boot managers, no need to take after
Microsoft here,
but there will always be cases when we don't know how to wedge the boot in.
We can always, as long as there is a free partition or free space to
create one, get as far
as installing the OS and it's partition boot, but may be unable to
install a master boot,
if the user has an unknown boot manager we don't recognize
One way to deal with it would be to chain the master boot.
That is, we save the original master boot to a file, and implement a query
in our own master boot, whether the user want to boot ROS, or continue
with the original master boot. It would be a small matter to load the
original
master boot and giving control over to it if need be.
Sure, it's one more pit-stop on the way to OS, but it would take care
of all the cases we cannot know, or cannot handle.
Best Regards
L from Hell
Eric Kohl <eric.kohl(a)t-online.de> wrote:
> Hi!
>
> Being cooperative was my intention when I wrote this part of usetup.
> The bad thing about this approach is that usetup needs to deal with
> all kinds of different situations that developers cannot even think
> about. The only proper way to fix this situation was: "Don't touch it
> if you don't know how to deal with it!" The result was that usetup
> could only handle empty harddisks and Windows boot managers correctly.
> Except for these two cases there are lots of different situations that
> a setup application cannot deal with. That's where the user must fix
> things. That's why usetup enables users to save the bootsector to a
> floppy disk. This enables them to fix the unknown situations
> themselves. Unfortunately this means that newbies might not be able to
> install the bootcode properly. But I thought it was better not to
> overwrite a bootsector that to unintentionally damage a system.
>
> The question how to handle this correctly is a difficult one.
> Microsoft chose the easy way as they behave like they are the owner of
> the system and overwrite everything as they see fit. But implementing
> this part of the setup in a way that fits everyones needs is a very
> difficult task. Just think about the different filesystems and
> different versions of LILO and GRUB and what about other third-party
> boot-managers...
>
> Regards,
> Eric
Hi!
Please test this with GRUB and LILO, since I use LILO on my main
hardware test. I do not have access to it for the moment. During the
installation of the boot CD, I do not overwrite the MBR. I just hope
it works when I get back to work with the project.
Thanks,
James