.Net 2.0 app behavior on 64-bit machine.

  • Thread starter Thread starter Guest
  • Start date Start date
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
 
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).
Click to expand...

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?
Click to expand...

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??
Click to expand...

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.
 
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.
Click to expand...


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
 
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.
Click to expand...

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

David
 
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.
Click to expand...

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

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.
 
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
|
|
 
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
 
Back
Top