Prev: Application priveleges on Win 7 and Win Vista
Next: tooltip for controls on a dialog application
From: JY on 21 Jan 2010 06:59
Hi,

I'm developing an app which has to run on 32 and 64 bit versions of Win
Vista/ Win 7 and XP. Are there any special considerations that I need to take
care of when developing for 64-bit?

TIA,
JY
From: David Wilkinson on 21 Jan 2010 08:42
JY wrote:
> Hi,
>
> I'm developing an app which has to run on 32 and 64 bit versions of Win
> Vista/ Win 7 and XP. Are there any special considerations that I need to take
> care of when developing for 64-bit?

Why not just run the 32 bit version on all platforms? That's what most
applications (including Visual Studio itself) do.

If you are already doing that, the main thing is just to make sure that you are
not using hard-coded paths like C:\Program Files\, because 32 bit applications
are actually installed in Program Files (x86).

I have did not have any problems with my applications on Win64 platforms (once I
had gotten rid of my old 16-bit installer).

--
David Wilkinson
Visual C++ MVP
From: Giovanni Dicanio on 21 Jan 2010 09:52
"JY" <sd(a)nospamgroup.com> ha scritto nel messaggio
news:A4B720AC-8D8E-4C87-8925-B53A45C41FAC(a)microsoft.com...

> I'm developing an app which has to run on 32 and 64 bit versions of Win
> Vista/ Win 7 and XP. Are there any special considerations that I need to
> take
> care of when developing for 64-bit?

I've never written a 64-bit app (as David already wrote, you could write
32-bit apps and run them on 64-bit Windows thanks to WOW64 technology).

To add to David's post, a special note that you may want to consider is that
64-bit (actually, AMD64 or x86-64) has only one kind of calling convention
(so, no more __stdcall vs. __cdecl, etc.).
More details can be found here:

http://blogs.msdn.com/oldnewthing/archive/2004/01/14/58579.aspx

Moreover, of course, when you build for 64-bit, your pointer size doubles
(from 32 bits they grow to 64 bits). So you should pay attention to the fact
that if you store a pointer in a DWORD in 32-bit app, then you can't do it
in 64-bit, because the pointer would be truncated.

....Enjoy the new 256 TB virtual address space available for your app on
x86-64 :)

Giovanni


From: Tom Serface on 21 Jan 2010 10:15
We had this same issue when we went from 16 bit to 32 bit Windows and, for a
while, people just continued to write 16 bit applications. Eventually,
there was an interface that allowed the 32 bit programs to run on 16 bit ,
but it didn't work very well so eventually we just gave up on it and moved
to supporting 32 bit only (at that time there were even different compilers
so it meant going to a new paradigm in that regard as well).

I'd do what the others have suggested and just write the app for 32 bit for
now. Our experiments with 64 bit having proven it to have any advantages
and in many cases the programs we recompiled have actually run slower than
their 32 bit equivalents.

Unless you're writing a device driver for that platform or something like
that I'd just use the lowest common denominator for now.

Tom

"JY" <sd(a)nospamgroup.com> wrote in message
news:A4B720AC-8D8E-4C87-8925-B53A45C41FAC(a)microsoft.com...
> Hi,
>
> I'm developing an app which has to run on 32 and 64 bit versions of Win
> Vista/ Win 7 and XP. Are there any special considerations that I need to
> take
> care of when developing for 64-bit?
>
> TIA,
> JY

From: Joseph M. Newcomer on 21 Jan 2010 12:31
Never cast a pointer or handle to an int, DWORD, etc. Never cast a WPARAM or LPARAM to an
int or DWORD if they can hold more than 32 bits of data (WPARAM, LPARAM, and LRESULT are
all 64-bit types in Win64).

Compile at /W4. Be prepared to deal with some of the casting issues that arise,
particularly when using the size operations, e.g.,

CArray<whatever> x;

for(int i = 0; i < x.GetSize(); i++)

will give a warning; the correct code is

for(INT_PTR i = 0; i < x.GetSize(); i++)

after a day or so of weeding out such warnings, there's a good chance it will run. I've
written a fair number of 64-bit apps at this point, and converted several 32-bit apps to
64-bit apps, without any problems. However, I have been programming "64-bit aware" for
about six or seven years.

Note that one of the arguments for using 64-bit native apps over 32-bit native apps is the
address space issue. But the other one, I discovered, was when I started comparing the
times of compute-bound apps. The computations, on several different apps, ran in 64-bit
mode in about 0.75 the time of the same app, on the same data, in 32-bit mode. And I was
measuring only the compute-bound part (no I/O or other APIs in the loops).
joe

On Thu, 21 Jan 2010 03:59:02 -0800, JY <sd(a)nospamgroup.com> wrote:

>Hi,
>
>I'm developing an app which has to run on 32 and 64 bit versions of Win
>Vista/ Win 7 and XP. Are there any special considerations that I need to take
>care of when developing for 64-bit?
>
>TIA,
>JY
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Application priveleges on Win 7 and Win Vista
Next: tooltip for controls on a dialog application