.Net 2.0 app behavior on 64-bit machine.


G

Guest

Hi,

I have an 1.1 .net app ported to 64-bit 2.0 framework that uses a 3rd party
CAD drawing DLL(natively 32-bit but runs in WOW mode on 64-bit per their
documentation).

There does not seem to be any improvement wrt performance (that is, the .net
app running on 1.1 on a 32-bit machine using their 32 bit DLL). Am I missing
something here?

Or, is the 32-bit 3rd party CAD generating DLL a bottleneck, though they
claim that on 64-bit boxes, their DLL can address the 4GB virtual memory
limit??

TIA
Sriram
 
Ad

Advertisements

C

Chris Mullins

Sriram said:
I have an 1.1 .net app ported to 64-bit 2.0 framework that uses a 3rd
party
CAD drawing DLL(natively 32-bit but runs in WOW mode on 64-bit per their
documentation).

So you have a mixed application at this point. What Build Targets are you
compiling your .Net code to be?
There does not seem to be any improvement wrt performance (that is, the
.net
app running on 1.1 on a 32-bit machine using their 32 bit DLL). Am I
missing
something here?

What kind of performance improvements were you expecting to see?
Or, is the 32-bit 3rd party CAD generating DLL a bottleneck, though they
claim that on 64-bit boxes, their DLL can address the 4GB virtual memory
limit??

I would say it's unlikley their 32 bit dll is addressing 4GB of virtual
memory.

If I remember right, a process is either 32 bit or 64 bit, but not both. So
if you have a 32 bit DLL, your whole process is going to be 32 bit.
 
D

David Browne

Chris Mullins said:
So you have a mixed application at this point. What Build Targets are you
compiling your .Net code to be?


What kind of performance improvements were you expecting to see?


I would say it's unlikley their 32 bit dll is addressing 4GB of virtual
memory.

If I remember right, a process is either 32 bit or 64 bit, but not both.
So if you have a 32 bit DLL, your whole process is going to be 32 bit.


32-bit processes running on 64-bit windows in WOW64 can use the whole 4GB of
addressable memory because there is no reservation of address space for
kernel mode code in WOW64. This will work so long as the executable is
marked as LARGEADDRESSAWARE.

David

Now whether this translates into
 
D

David Browne

David Browne said:
32-bit processes running on 64-bit windows in WOW64 can use the whole 4GB
of addressable memory because there is no reservation of address space for
kernel mode code in WOW64. This will work so long as the executable is
marked as LARGEADDRESSAWARE.

A quick experiment shows that apps compiles for the x64 target are marked as
LARGEADDRESSAWARE, and apps compiled for AnyCPU are not.

David
 
C

Chris Mullins

32-bit processes running on 64-bit windows in WOW64 can use the whole 4GB
of addressable memory because there is no reservation of address space for
kernel mode code in WOW64.

That's interesting. It makes sense, as I think about it.
This will work so long as the executable is marked as LARGEADDRESSAWARE.

This is a VC++ linker setting, which isn't easy to set for C# or VB.Net.

Do you know which piece of the process needs this stamp? Is it the Exe
that's generated by .Net, or the Win32 Dll that's loaded into the address
spaces? My guess would be the initial Exe that loads the process - but
that's nothing more than a guess.
 
W

Willy Denoyette [MVP]

C# Applications compiled with /platform:x64 do not run in WOW64, they run as
full X64 executables, as such they are LARGEADDRESSAWARE by default.

Willy.

message |
| message | >
| > | >>> I have an 1.1 .net app ported to 64-bit 2.0 framework that uses a 3rd
| >>> party
| >>> CAD drawing DLL(natively 32-bit but runs in WOW mode on 64-bit per
their
| >>> documentation).
| >>
| >> So you have a mixed application at this point. What Build Targets are
you
| >> compiling your .Net code to be?
| >>
| >>> There does not seem to be any improvement wrt performance (that is,
the
| >>> .net
| >>> app running on 1.1 on a 32-bit machine using their 32 bit DLL). Am I
| >>> missing
| >>> something here?
| >>
| >> What kind of performance improvements were you expecting to see?
| >>
| >>> Or, is the 32-bit 3rd party CAD generating DLL a bottleneck, though
they
| >>> claim that on 64-bit boxes, their DLL can address the 4GB virtual
memory
| >>> limit??
| >>
| >> I would say it's unlikley their 32 bit dll is addressing 4GB of virtual
| >> memory.
| >>
| >> If I remember right, a process is either 32 bit or 64 bit, but not
both.
| >> So if you have a 32 bit DLL, your whole process is going to be 32 bit.
| >>
| >
| >
| > 32-bit processes running on 64-bit windows in WOW64 can use the whole
4GB
| > of addressable memory because there is no reservation of address space
for
| > kernel mode code in WOW64. This will work so long as the executable is
| > marked as LARGEADDRESSAWARE.
| >
|
| A quick experiment shows that apps compiles for the x64 target are marked
as
| LARGEADDRESSAWARE, and apps compiled for AnyCPU are not.
|
| David
|
|
 
Ad

Advertisements

G

Guest

Should I be re-compiling *all* the DLLs down the tree that my main .exe
consumes as 'LARGEADDRESSAWARE' or just the main exe as 'LARGEADDRESSAWARE'?

How do I know if a DLL/.exe is 'LARGEADDRESSAWARE' - in the PE format? using
ILDASM?? I thought 'AnyCPU' compilation on x64 machines would somehow make
the DLLs/exe's as LARGEADDRESSAWARE.

I am using VB.Net. Any help is appreciated...

TIA
Sriram
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top