Prev: BSOD, mismanaging system PTEs, x64/WinServer2003?
Next: VSS problem on an Windows 2003 Enterprise R2 SP2 Server
From: InputIO on 4 Jan 2008 10:04
Sorry but i still to don't understand.... :-(

1 case : 32 bit application on windows server x64

in this case it's mandatory compile my application with the flag
/LARGEADDRESSAWAR for see >2 Gb of memory or not ?


2 case: 64 bit aplication on windows server x64

in this case i need make anything on my server or my application for use
more than 2GB ?



3 case : 23 bit application on window server 32 bit

in this case after set the /3GB flag in boot.ini i nedd make anything on my
server or application for use more than 2GB ?


Thanks in advance.

bye :)



"jorgen" <na(a)invalid> ha scritto nel messaggio
news:ee$4$1jTIHA.4696(a)TK2MSFTNGP05.phx.gbl...
> Charlie Russel - MVP wrote:
>> clearly you did.
>>
>> The problem is that we're talking about two different things here. And
>> neither of them is RAM.
>
> We are actually talking about the same thing. And I do differentiate
> between RAM, physical address space, virtual address space, between user
> space and kernel space etc.
>
> I just thought you said, that every 32-bit application automatically was
> able to grow to 4GB in 64-bit Windows - even without the flag in the image
> header. Nothing more than that :)

From: Bo Persson on 4 Jan 2008 11:52
InputIO wrote:
:: Sorry but i still to don't understand.... :-(
::
:: 1 case : 32 bit application on windows server x64
::
:: in this case it's mandatory compile my application with the flag
:: /LARGEADDRESSAWAR for see >2 Gb of memory or not ?

Yes.

::
::
:: 2 case: 64 bit aplication on windows server x64
::
:: in this case i need make anything on my server or my application
:: for use more than 2GB ?

No.

::
::
::
:: 3 case : 23 bit application on window server 32 bit
::
:: in this case after set the /3GB flag in boot.ini i nedd make
:: anything on my server or application for use more than 2GB ?

You still need the /LARGEADDRESSAWARE flag, for the application to
even attempt to use > 2GB.


Bo Persson


From: Chuck Walbourn [MSFT] on 4 Jan 2008 15:12
There's a bit of confusion in this thread, although the technical details
came out fine in the end.

To sum up:

- 32-bit applications can opt-in to use >2 GB of virtual address space by
using /LARGEADDRESSAWARE when they are built by the developer. There are
some compataiblity implications that the developer must handle correctly to
support this, which is why by default 32-bit applications never get more
than 2 GB in the first place. Just forcing this on by using editbin could
easily result in corruptions, crashes, or other major failures.

- Such applications will only actually be able to allocate >2 GB if the OS
they are running on is also configured to support this. For 32-bit versions
of Windows, this requires special boot modes and even then can never get
more than a total of 3 GB. For 64-bit versions of Windows, there is NO
special boot mode required and can grow to a full 4 GB. Standard 32-bit
applications (i.e., those without /LARGEADDRESSAWARE) will still never get
>2 GB no matter how the OS is configured.

- 64-bit applications always have access to at least 8 TB of virtual address
space.

How much physical RAM an application uses is a slightly different matter,
but as an approximiation you need as much Virtual Address Space as you have
physical memory allocated at a given time plus some more for other things
like memory-mapped files, Direct3D devices, EXE and DLL size, etc.

There's a nice summary of this in the DirectX SDK article "64-bit
programming for Game Developers"
http://msdn2.microsoft.com/en-us/library/bb147385.aspx ,as well information
in many of the whitepapers Charlie pointed to on MSDN's websites.

--
Chuck Walbourn
SDE, XNA Developer Connection

This posting is provided "AS IS" with no warranties, and confers no rights.


From: Charlie Russel - MVP on 4 Jan 2008 16:03
correct. ;)

--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"Chuck Walbourn [MSFT]" <chuckw(a)online.microsoft.com> wrote in message
news:OnDDZ4wTIHA.1168(a)TK2MSFTNGP02.phx.gbl...
> There's a bit of confusion in this thread, although the technical details
> came out fine in the end.
>
> To sum up:
>
> - 32-bit applications can opt-in to use >2 GB of virtual address space by
> using /LARGEADDRESSAWARE when they are built by the developer. There are
> some compataiblity implications that the developer must handle correctly
> to support this, which is why by default 32-bit applications never get
> more than 2 GB in the first place. Just forcing this on by using editbin
> could easily result in corruptions, crashes, or other major failures.
>
> - Such applications will only actually be able to allocate >2 GB if the OS
> they are running on is also configured to support this. For 32-bit
> versions of Windows, this requires special boot modes and even then can
> never get more than a total of 3 GB. For 64-bit versions of Windows, there
> is NO special boot mode required and can grow to a full 4 GB. Standard
> 32-bit applications (i.e., those without /LARGEADDRESSAWARE) will still
> never get
> >2 GB no matter how the OS is configured.
>
> - 64-bit applications always have access to at least 8 TB of virtual
> address space.
>
> How much physical RAM an application uses is a slightly different matter,
> but as an approximiation you need as much Virtual Address Space as you
> have physical memory allocated at a given time plus some more for other
> things like memory-mapped files, Direct3D devices, EXE and DLL size, etc.
>
> There's a nice summary of this in the DirectX SDK article "64-bit
> programming for Game Developers"
> http://msdn2.microsoft.com/en-us/library/bb147385.aspx ,as well
> information in many of the whitepapers Charlie pointed to on MSDN's
> websites.
>
> --
> Chuck Walbourn
> SDE, XNA Developer Connection
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

First  |  Prev  | 
Pages: 1 2 3 4
Prev: BSOD, mismanaging system PTEs, x64/WinServer2003?
Next: VSS problem on an Windows 2003 Enterprise R2 SP2 Server