x86 vs x64

[Guest]

Hi all,

We are considering migrating some of our production web and application
servers to 64-bit platform. My question is do I need to re-compile my code
on a x64 machine running a x64 version of Windows and x64 version of .net?
Or will the same code run on the new x64 environment without recompilation
needed.

TIA!

 

[Cowboy \(Gregory A. Beamer\)]

You can set to compile for x64 on a 32-bit machine and end up with a
"binary" (.NEt si actually byte code) that runs only on 64-bit machines
(optimized for 64-bit). If you leave at default (any platform), it will not
be as optimized, but will run on both x86 and x64.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************************************************
Think outside of the box!
*************************************************

 

[Michael Nemtsev]

Hello Cowboy (Gregory A. Beamer),

C> If you leave at default (any platform), it will not be as optimized,

Could you point where u get this?

AFAIK, the /platform compiler option only set the desired PE header - PE32
or PE32+ and emit desired architecture into header.
There is nothing relating to the compilation, that btw take place only when
u start app, not compile it


---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Phil Wilson]

The issue to watch out for with "some of our production" is a mixture of
related 32-bit apps and 64-bit apps both running on the same system. If you
have (say) 64-bit apps that write registry entries for 32-bit apps to see
then they're potentially going to fail when the 64-bit app writes to the
registry and the 32-bit app reads from the 32-bit view of the registry.
There's potential for COM misconnects too, if you're using COM. So if you do
convert some apps to run 64-bit and not others, this is something to watch
out for.

 

[Guest]

So that should be for my dlls. What about the .aspx pages? Doesnt the
framework compile those? Any special setting?

 

[Kevin Yu [MSFT]]

Hi,

You don't need to care about the .aspx file. The .aspx pages are rendered
at runtime. The .NET framework will do that according to the platform.

In this case, what you need to care about is the file directory and
registry writing and COM interoping in your app. You can just select Any
CPU from configuration manager to make your .NET app platform independent.

If anything is unclear, please feel free to let me know.

Kevin Yu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================

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

 

[Guest]

Why do I need to be careful about registry writing and file writing? Some of
my current code that runs on x86 does read from the registry and does
read/write files to disk.

TIA

 

[Kevin Yu [MSFT]]

Hi,

Because if a 32bit app is running on a 64bit windows, it is using Windows
on Windows 64(WOW64). Some of the registrys and System32 directory will be
mapped to other places. For example, System32 will be mapped to Syswow64.
Program Files folder is mapped to Program Files (x86). In this case, you
have to be careful if you need to read from these registry keys and
folders. You will find more from the following links:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog64/w
inprog64/registry_redirector.asp
http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx
http://msdn.microsoft.com/isv/technology/64bitwindows/x64faq/developmentfaq/
default.aspx

Kevin Yu
Microsoft Online Community Support
==================================================

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

 

[Guest]

My apps write to none of the folders you have outlined below. They write to
specified folders like d:\myapp etc.

They also read/write to the following registry keys:-

EventLog - using the .net EventLog classes
HKLM\MyCompany\Software - custom key

 

[Chris Mullins]

Be warned then, that Vista will likley consider your App to be broken, and
it won't run.

You need to be writing data to specific locations on the file system, not
just "D:\myapp\".

 

[Kevin Yu [MSFT]]

Hi,

There is no problem writing to that specified folder like d:\myapp and
registry like (I think it has to be) HKLM\Software \MyCompany. When your
.net app is running on a 64bit windows, it will be working as a 64 bit
process, so there will be no problem.

What I mean is that if your app is reading a registry key that a 32bit app
has left, we have to take care of the redirection. In WOW64 modde, the
HKLM\Software will be redirected to HKLM\Software\WOW6432node. Under
WOW6432node all the nodes under HKLM\Software will be reflected. A 32bit
app running on WOW64 which is writing to HKLM\Software will actually be
writing to HKLM\Software\WOW6432node.

Since your app is reading/writing to its own keys in completely 64bit mode,
you don't need to worry about it.

Kevin Yu
Microsoft Online Community Support
==================================================

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