2GB Boundary

[Alex Ionescu]

Hi,

Anyone against switching ROS to be compiled by default on the 2GB 
boundary? (This can always be locally changed by /3GB = 1)

For the sake of consistency and perhaps better driver support, as has 
been found in the past.
Then we can start working on a real freeldr PE loader...

Best regards,
Alex Ionescu

"Alex Ionescu" [e-mail] wrote:
> Anyone against switching ROS to be compiled by default on the 2GB
> boundary? (This can always be locally changed by /3GB = 1)

I agree! But I think we should move the ntoskrnl base address to 0x80100000
and map the first MB of physical memory to 0x80000000 - 0x800FFFFF in order
to simplify BIOS calls.

Regards,
Eric

[Alex Ionescu]

Eric Kohl wrote:
> "Alex Ionescu" [e-mail] wrote:
> > Anyone against switching ROS to be compiled by default on the 2GB
> > boundary? (This can always be locally changed by /3GB = 1)
>
> I agree! But I think we should move the ntoskrnl base address to 0x80100000
> and map the first MB of physical memory to 0x80000000 - 0x800FFFFF in order
> to simplify BIOS calls.
>
> Regards,
> Eric
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

Hi Eric,

Good point you make there...but won't that work only if the BIOS is set 
to Save itself in Physical Memory?

But you're absolutely right about 0x8x0000000, because it wouldn't be 
good to stick it right on the boundary for a couple of reasons.

Best regards,
Alex Ionescu

[Aliberti Emanuele]

Hi Eric!
> I agree! But I think we should move the ntoskrnl base address to 0x80100000
> and map the first MB of physical memory to 0x80000000 - 0x800FFFFF in order
> to simplify BIOS calls.

Does that conflict with the statement I read in some books about 
completely skipping the low 64k physical address range for ease of 
detecting NULL pointers?

Emanuele

"Aliberti Emanuele" [e-mail] wrote:
> > I agree! But I think we should move the ntoskrnl base address to

0x80100000
> > and map the first MB of physical memory to 0x80000000 - 0x800FFFFF in

order
> > to simplify BIOS calls.
>
> Does that conflict with the statement I read in some books about
> completely skipping the low 64k physical address range for ease of
> detecting NULL pointers?

This is not 100% correct. The lowest 64k of the process _virtual_ address
space is is reserved and protected in order to detect NULL pointer access.

Regards,
Eric

[Alex Ionescu]

Eric Kohl wrote:
> "Aliberti Emanuele" [e-mail] wrote:
> > > I agree! But I think we should move the ntoskrnl base address to
>
> 0x80100000
> > > and map the first MB of physical memory to 0x80000000 - 0x800FFFFF in
>
> order
> > > to simplify BIOS calls.
> >
> > Does that conflict with the statement I read in some books about
> > completely skipping the low 64k physical address range for ease of
> > detecting NULL pointers?
>
> This is not 100% correct. The lowest 64k of the process _virtual_ address
> space is is reserved and protected in order to detect NULL pointer access.
>
> Regards,
> Eric

Getting back to what Eric suggested, we should also perhaps do like NT 
does, and cache the GDT and IDT somewhere between 0x80000000 and the 
kernel base as well.

Best regards,
Alex Ionescu

[Barubary]

> This is not 100% correct. The lowest 64k of the process _virtual_ address
> space is is reserved and protected in order to detect NULL pointer access.

Do you know how NTVDM in NT/2000/XP/2003 gets around this?  NTVDM allocates 
this area somehow for creation of the V86 IDT.

Melissa

[Steven Edwards]

--- Barubary [e-mail] wrote:
> Do you know how NTVDM in NT/2000/XP/2003 gets around this?  NTVDM
> allocates 
> this area somehow for creation of the V86 IDT.

On the Alpha the NTVDM is a true emulator. I dont know about x86.....

Thanks
Steven

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

[Alex Ionescu]

Barubary wrote:
> > This is not 100% correct. The lowest 64k of the process _virtual_ 
> > address
> > space is is reserved and protected in order to detect NULL pointer 
> > access.
>
> Do you know how NTVDM in NT/2000/XP/2003 gets around this?  NTVDM 
> allocates this area somehow for creation of the V86 IDT.
>
> Melissa
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

Are you sure about that?

In any case, NTVDM is a completely separate subsystem that actually 
"Boots up" with its own ROM/BIOS and has its own memory handlers, ivt, 
idt, gdt, ldt, etc. It emulates everything it can, but sometimes it 
can't and it raises exceptions (which is why many DOS apps won't work). 
So, by being an emulator, it has full control over its internal virtual 
memory. However, I'm still not convinced that the actual ntvdm.exe 
process allocates, in Windows, the first 0x10000 bytes.

Best regards,
Alex Ionescu

[Robert Köpferl]

on x86 NTVDM is a VDM = Virtual Machine int that it virtualizes the processor 
and the memory. In contrast to simulate or emulate the whole thing.
Since it is a "normal" process it mustn't access physical memory as all others. 
It however can enable the VM-Bit to enable v86-mode. This and some registered 
HW-Exceptoion-handlers enables NTVDM to emulate privileged instructions. Such 
instr in usermode (v86 is usermode) raises an exception. NTVDM then can manage 
it's own GDT, LDT and map pages around to finnish up the missing part of a 
x86-processor inside NT.
NTVDM as its pendant in OS/2 can boot a DOS. At least in OS/2 it was possible 
to start a "DOS-Box" from a floppy in A: ...
The Bios is specially made for such a "realmode"-Box. It invokes system calls 
instead to access HW.

Asking me, I'd ignore all this fascinating but difficult stuff which was good 
at 386's times and use the project DOS-Box on nowerdays machines.

Alex Ionescu schrieb:
> Barubary wrote:
> > > This is not 100% correct. The lowest 64k of the process _virtual_ 
> > > address
> > > space is is reserved and protected in order to detect NULL pointer 
> > > access.
> >
> > Do you know how NTVDM in NT/2000/XP/2003 gets around this?  NTVDM 
> > allocates this area somehow for creation of the V86 IDT.
> >
> > Melissa
> > _______________________________________________
> > Ros-dev mailing list
> > [e-mail]
> > http://reactos.com:8080/mailman/listinfo/ros-dev
>
> Are you sure about that?
>
> In any case, NTVDM is a completely separate subsystem that actually 
> "Boots up" with its own ROM/BIOS and has its own memory handlers, ivt, 
> idt, gdt, ldt, etc. It emulates everything it can, but sometimes it 
> can't and it raises exceptions (which is why many DOS apps won't work). 
> So, by being an emulator, it has full control over its internal virtual 
> memory. However, I'm still not convinced that the actual ntvdm.exe 
> process allocates, in Windows, the first 0x10000 bytes.
>
> Best regards,
> Alex Ionescu
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Barubary]

> In any case, NTVDM is a completely separate subsystem that actually "Boots 
> up" with its own ROM/BIOS and has its own memory handlers, ivt, idt, gdt, 
> ldt, etc. It emulates everything it can, but sometimes it can't and it 
> raises exceptions (which is why many DOS apps won't work). So, by being an 
> emulator, it has full control over its internal virtual memory. However, 
> I'm still not convinced that the actual ntvdm.exe process allocates, in 
> Windows, the first 0x10000 bytes.

NTVDM is a user-mode application.  You can put a thread into V86 mode in 
your own process using NtSetContextThread()'s EFLAGS value (V86 isn't 
masked).  NTVDM seems almost identical to a standard Win32 application 
except for the slightly different exception handling methods.  The "VDD" 
documentation in the DDK kinda shows how this mechanism works, letting you 
load a DLL into NTVDM's process space.

Melissa

[Alex Ionescu]

NTVDM is not only an application, but also a subsystem. Many parts of 
the NT Kernel themselves are dedicated to supporting certain NTVDM 
operations.

Best regards,
Alex Ionescu

Barubary wrote:
> > In any case, NTVDM is a completely separate subsystem that actually 
> > "Boots up" with its own ROM/BIOS and has its own memory handlers, 
> > ivt, idt, gdt, ldt, etc. It emulates everything it can, but sometimes 
> > it can't and it raises exceptions (which is why many DOS apps won't 
> > work). So, by being an emulator, it has full control over its 
> > internal virtual memory. However, I'm still not convinced that the 
> > actual ntvdm.exe process allocates, in Windows, the first 0x10000 bytes.
>
> NTVDM is a user-mode application.  You can put a thread into V86 mode 
> in your own process using NtSetContextThread()'s EFLAGS value (V86 
> isn't masked).  NTVDM seems almost identical to a standard Win32 
> application except for the slightly different exception handling 
> methods.  The "VDD" documentation in the DDK kinda shows how this 
> mechanism works, letting you load a DLL into NTVDM's process space.
>
> Melissa
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Hartmut Birr]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eric Kohl
> Sent: Sunday, October 10, 2004 10:52 AM
> To: ReactOS Development List
> Subject: Re: [ros-dev] 2GB Boundary
>
> This is not 100% correct. The lowest 64k of the process 
> _virtual_ address
> space is is reserved and protected in order to detect NULL 
> pointer access.

That is not correct. The lowest 64k are not reserved. The allocation of
memory starts at 64k if there was no base address given. With a base address
it is possible to allocate memory in the lowest 64k.

- Hartmut

[KJK::Hyperion]

At 00.42 11/10/2004, you wrote:
> That is not correct. The lowest 64k are not reserved. The allocation of 
> memory starts at 64k if there was no base address given. With a base 
> address it is possible to allocate memory in the lowest 64k.

True. The Device Path Exerciser tool in the DDK maps the lowest page to 
detect drivers that don't check for NULL pointers. And anyway NTVDM 
allocates a code segment for the virtual machine (NtSetLdtEntries), so 
that's a non-issue