Editbin /LARGEADDRESSAWARE

My .NET 2.0 app may be deployed on both 32-bit and 64-bit systems.
Are there any side effects to running Editbin /LARGEADDRESSAWARE against
the EXE and then deploying it on a 64-bit system?

The reason I ask is that there is just one setup and the .EXE will be
converted to be LARGEADDRESSAWARE at setup creation time.

Thanks.

re: Editbin /LARGEADDRESSAWARE

Hello,

So far, I didn't see any reported problem caused by "Editbin
/LARGEADDRESSAWARE" against an .NET assembly. It will indicate that the
assembly can handle addresses larger than 2 gigabytes and this is required
on a 64-bit system. Anyway, since your application will be deploy on both
32-bit and 64-bit system, there may be some potential issues. You need to
perform complete test on these two platform including the setup process.

Sincerely,

Luke Zhang

Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

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

re: Editbin /LARGEADDRESSAWARE

Luke Zhang [MSFT] wrote:Wow, this makes no sense. You are saying that a .NET 2.0 compiled
executable won't be able to access more than 2 GB of RAM on a 64-bit OS,
unless it's been tweaked with 'Editbin /LARGEADDRESSAWARE'???

My understanding is that out of the box .NET 2.0 compiled EXEs can
access 1TB of RAM (or some such ridiculous number) on a 64-bit OS.

But to be able to access 3GB on a 32-bit OS, you had to run the EXE
through 'Editbin /LARGEADDRESSAWARE'.

Is this not the case?

re: Editbin /LARGEADDRESSAWARE

"Frank Rizzo" <none@none.comwrote in message news:em6aVWENHHA.3552@TK2MSFTNGP03.phx.gbl...
Question is - why do you 'flag' this application to be LARGEADDRESSAWARE?
Does the application really needs more than the default 2GB VAS?
What target platform (AnyCPU, x86, x64) did you specify while compiling?
Following illustrates the effect of the target platform and the LAA flag on the VAS:

AnyCpu (default)
32 bit OS VAS = 2GB (default)
32 bit OS LAA VAS = 3GB
64 bit OS VAS = xTB (default)
x86
32 bit OS VAS = 2GB (default)
32 bit OS LAA VAS = 3GB
64 bit OS VAS = 2GB (default)
64 bit OS LAA VAS = 4GB
x64
64 bit OS VAS = xTB

LAA = LARGEADDRESSAWARE
x = 6 or 7 TB

It's clear that you need to know your specific VAS requirements before you can decide to
apply the LAA flag.
It's obvious that your application will need to restrict it's VAS requirements to < 3GB,
otherwise it won't run on 32Bit. However, if you apply the LAA on an AnyCpu target, nothing
stops it from consuming more than 3GB on 64 bit, that's why I would never compile with the
AnyCpu flag if I have very specific memory requirements.

Willy.

re: Editbin /LARGEADDRESSAWARE

Willy Denoyette [MVP] wrote:Willy, thank you for your reply. It's informative as always. In
answers to questions you posed:

1. Yes, the application does need more than 2GB of RAM for some of my
larger customers. Usually the application consumes 2.1-2.3GB at the
most. Typically, the customers have multi-proc boxes with around 6-8 GB
of RAM. However, some of these customers have 32-bit boxes, others have
64-bit. And I don't know who has what, so I need to cover all the
bases. Thus I specify AnyCPU.

2. So I need to make sure, that if customer has a 32-bit box, they can
access more than 2GB of RAM.

3. So I figured that if I marked an AnyCPU executable with LAA, then
I'll be covering all bases. If the user installed the app on a 32-bit
box, they would be able to use 3GB of RAM. If the app was installed on
the 64-bit box, they would use xTB of RAM.

Am I wrong?

Regards

re: Editbin /LARGEADDRESSAWARE

One more unrelated question. When deploying a 32-bit LAA enabled EXE to
the 64-bit OS, does the machine need the /3GB flag in order to access
4GB of RAM?

Regards


Willy Denoyette [MVP] wrote:

re: Editbin /LARGEADDRESSAWARE

"Frank Rizzo" <none@none.comwrote in message
news:%23iVrpYONHHA.3944@TK2MSFTNGP06.phx.gbl...Nope.

Willy.

re: Editbin /LARGEADDRESSAWARE

"Frank Rizzo" <none@none.comwrote in message news:uPu5dQONHHA.320@TK2MSFTNGP06.phx.gbl...If you never need more than 4GB, you better specify X86 as target. On a 32 bit OS you will
get up to 3GB while on 64 bit you'll get up to 4GB VAS.
This requires the/3GB boot.ini switch.
Right, but if you memory requirements are < 3GB (as they are), so you don't need the address
extention feature of the 64bit platform (HW and OS) anyway.
That's why I said you better target x86, that way you are sure that both run the exact same
code (both use the JIT32), both have the same memory footprint, that is the same workingset,
virtual bytes, stack requirements etc. and both use the same framework code on both 32 and
64 bit.

Willy.

re: Editbin /LARGEADDRESSAWARE

Willy Denoyette [MVP] wrote:
Ah, understood. I couldn't grok previously why you were recommending a
specific flag. Now it makes sense.

Regards