C
Charlie Russel - MVP
Guest
Re: About "LARGEADDRESSAWARE" option in W2K3 SP2 x64
correct.
--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel
"Chuck Walbourn [MSFT]" <chuckw@online.microsoft.com> wrote in message
news:OnDDZ4wTIHA.1168@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.
>
correct.
--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel
"Chuck Walbourn [MSFT]" <chuckw@online.microsoft.com> wrote in message
news:OnDDZ4wTIHA.1168@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.
>