1. What're the major benefits of migrating an app from 32-bit to 64-bit,
besides running fast?

2. Can an 64-bit app run on a 32-bit processor/Windows version platform?

3. What're the major concerns when developing a 64-bit app?

Re: Migrate app to 64-bit by Igor

Igor
Sat Jul 26 15:31:58 CDT 2008

"micro" <micro090909@yahoo.com> wrote in message
news:u5OuyD17IHA.3696@TK2MSFTNGP04.phx.gbl
> 1. What're the major benefits of migrating an app from 32-bit to
> 64-bit, besides running fast?

64-bit app is unlikely to run faster than an equivalent 32-bit app,
unless it belongs to a rare class of applications that benefit from huge
amounts of accessible RAM. If your application can efficiently use more
than 2GB of RAM, there's a benefit to switching to 64 bit. Otherwise,
there are only downsides.

> 2. Can an 64-bit app run on a 32-bit processor/Windows version
> platform?

No.

> 3. What're the major concerns when developing a 64-bit app?

Whether you need one in the first place. What kind of application are
you thinking of?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925



Re: Migrate app to 64-bit by Giovanni

Giovanni
Sat Jul 26 18:20:30 CDT 2008

Adding to Igor's post:

[micro]

> 3. What're the major concerns when developing a 64-bit app?

I've never written a 64-bit apps, however I think that if you have
pointer-intensive data structures, your compiled code will be "bloated",
because the size of your pointers will be doubled (from 32 bits to 64 bits).

However, I don't know if in 64-bit environment it is possible to define
"large" 64-bit pointers and "small" 32-bit pointers...

Giovanni



Re: Migrate app to 64-bit by Tim

Tim
Sat Jul 26 22:09:38 CDT 2008

"Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it> wrote:
>
>I've never written a 64-bit apps, however I think that if you have
>pointer-intensive data structures, your compiled code will be "bloated",
>because the size of your pointers will be doubled (from 32 bits to 64 bits).

Actually, there are relatively few full absolute pointers in the typical
program. Passing pointers around in registers doesn't cost any more in 64
than is does in 32.

However, that doesn't change the fact that 64-bit code IS larger than
32-bit.

>However, I don't know if in 64-bit environment it is possible to define
>"large" 64-bit pointers and "small" 32-bit pointers...

No. How could you? You don't have any guarantee that your virtual
addresses will fit in 32 bits.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Re: Migrate app to 64-bit by Ben

Ben
Sat Jul 26 22:25:26 CDT 2008



"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:OS0wq617IHA.2060@TK2MSFTNGP02.phx.gbl...
> "micro" <micro090909@yahoo.com> wrote in message
> news:u5OuyD17IHA.3696@TK2MSFTNGP04.phx.gbl
>> 1. What're the major benefits of migrating an app from 32-bit to
>> 64-bit, besides running fast?
>
> 64-bit app is unlikely to run faster than an equivalent 32-bit app, unless
> it belongs to a rare class of applications that benefit from huge amounts
> of accessible RAM. If your application can efficiently use more than 2GB
> of RAM, there's a benefit to switching to 64 bit. Otherwise, there are
> only downsides.

More registers, mustn't forget the extra registers. Again, this is only
going to overcome the disadvantages for a few apps, but I suspect in most
cases it comes pretty close to cancelling them out.

>
>> 2. Can an 64-bit app run on a 32-bit processor/Windows version
>> platform?
>
> No.
>
>> 3. What're the major concerns when developing a 64-bit app?
>
> Whether you need one in the first place. What kind of application are you
> thinking of?
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>

Re: Migrate app to 64-bit by karpov2007

karpov2007
Sun Jul 27 11:18:07 CDT 2008

If you are interested in questions of 64-bit migration then come on a
site www.Viva64.com.

On this site you can get acquainted with articles:

20 issues of porting C++ code on the 64-bit platform
http://www.viva64.com/articles/20_issues_of_porting_C++_code_on_the_64-bit_platform.html

The forgotten problems of 64-bit programs development
http://www.viva64.com/articles/Forgotten_problems.html

Development of Resource-intensive Applications in Visual C++
http://www.viva64.com/articles/Resource_intensive_applications.html

Driver Development for Windows 64-bit
http://www.viva64.com/articles/Driver_Development_for_Windows_64-bit.html

Static code analysis for verification of the 64-bit applications.
http://www.viva64.com/articles/Verification_of_the_64-bit_Applications.html

64 bits, Wp64, Visual Studio 2008, Viva64 and all the rest...
http://www.viva64.com/articles/Wp64_VS.html

and many other things

Re: Migrate app to 64-bit by Giovanni

Giovanni
Sun Jul 27 11:26:36 CDT 2008


"Tim Roberts" <timr@probo.com> ha scritto nel messaggio
news:3dpn84hq66d3753p6naa9mks1hv4ob6rnc@4ax.com...
> "Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it> wrote:
>[...]
>>However, I don't know if in 64-bit environment it is possible to define
>>"large" 64-bit pointers and "small" 32-bit pointers...
>
> No. How could you? You don't have any guarantee that your virtual
> addresses will fit in 32 bits.

Reading Windows Platform SDK headers, I found lots of NEAR and FAR (which
seems to be #define'd as nothing...).
I don't know about Windows programming in 16-bit, I started learning Windows
programming with Windows 95/98 (32-bit), but I used to think that in the
16-bit age, there were 16-bit pointers and 32-bit pointers (the NEAR being
16-bit, and the FAR being 32-bit).

So, I thought: is it possible to have similar distinction, i.e. having both
32-bit pointers ("near") and 64-bit pointers ("far") in a 64-bit Windows
environment?

Giovanni



Re: Migrate app to 64-bit by Doug

Doug
Sun Jul 27 12:33:19 CDT 2008

On Sun, 27 Jul 2008 18:26:36 +0200, "Giovanni Dicanio"
<gdicanio@_NOSPAM_email_DOT_it> wrote:

>Reading Windows Platform SDK headers, I found lots of NEAR and FAR (which
>seems to be #define'd as nothing...).
>I don't know about Windows programming in 16-bit, I started learning Windows
>programming with Windows 95/98 (32-bit), but I used to think that in the
>16-bit age, there were 16-bit pointers and 32-bit pointers (the NEAR being
>16-bit, and the FAR being 32-bit).
>
>So, I thought: is it possible to have similar distinction, i.e. having both
>32-bit pointers ("near") and 64-bit pointers ("far") in a 64-bit Windows
>environment?

I sure hope not. :)

--
Doug Harrison
Visual C++ MVP

Re: Migrate app to 64-bit by David

David
Mon Jul 28 09:30:59 CDT 2008

"Doug Harrison [MVP]" <dsh@mvps.org> wrote in
news:k5cp8497pfu6rjoig492r9162tdaq7br03@4ax.com:

> On Sun, 27 Jul 2008 18:26:36 +0200, "Giovanni Dicanio"
> <gdicanio@_NOSPAM_email_DOT_it> wrote:
>
>>Reading Windows Platform SDK headers, I found lots of NEAR and FAR
>>(which seems to be #define'd as nothing...).
>>I don't know about Windows programming in 16-bit, I started learning
>>Windows programming with Windows 95/98 (32-bit), but I used to think
>>that in the 16-bit age, there were 16-bit pointers and 32-bit pointers
>>(the NEAR being 16-bit, and the FAR being 32-bit).
>>
>>So, I thought: is it possible to have similar distinction, i.e. having
>>both 32-bit pointers ("near") and 64-bit pointers ("far") in a 64-bit
>>Windows environment?
>
> I sure hope not. :)
>

DITTO!!!

I started on programming on Windows 3.1. NEAR/FAR was set based on the
memory model you chose for your program. Oh, the joys of segmented memory.
I was SO GLAD when we moved to 32 bit. Though we had to transition thru
Win32s. And thunks to the 16bit COM api. (shiver)

Dave Connet

Re: Migrate app to 64-bit by Ben

Ben
Mon Jul 28 17:53:27 CDT 2008

Giovanni Dicanio wrote:
> "Tim Roberts" <timr@probo.com> ha scritto nel messaggio
> news:3dpn84hq66d3753p6naa9mks1hv4ob6rnc@4ax.com...
>> "Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it> wrote:
>> [...]
>>> However, I don't know if in 64-bit environment it is possible to
>>> define "large" 64-bit pointers and "small" 32-bit pointers...
>>
>> No. How could you? You don't have any guarantee that your virtual
>> addresses will fit in 32 bits.
>
> Reading Windows Platform SDK headers, I found lots of NEAR and FAR
> (which seems to be #define'd as nothing...).
> I don't know about Windows programming in 16-bit, I started learning
> Windows programming with Windows 95/98 (32-bit), but I used to think
> that in the 16-bit age, there were 16-bit pointers and 32-bit
> pointers (the NEAR being 16-bit, and the FAR being 32-bit).
>
> So, I thought: is it possible to have similar distinction, i.e.
> having both 32-bit pointers ("near") and 64-bit pointers ("far") in a
> 64-bit Windows environment?

Well, given the existence of __based, you'd think such an idea makes sense.
Of course if you want to avoid increasing the size of structures, you can
store the index into a rather large array and subscript the basis pointer
yourself, the index could then remain 32 bit.

>
> Giovanni



Re: Migrate app to 64-bit by Ondrej

Ondrej
Wed Jul 30 01:59:12 CDT 2008

Igor Tandetnik napsal(a):
> "micro" <micro090909@yahoo.com> wrote in message
> news:u5OuyD17IHA.3696@TK2MSFTNGP04.phx.gbl
>> 1. What're the major benefits of migrating an app from 32-bit to
>> 64-bit, besides running fast?
>
> 64-bit app is unlikely to run faster than an equivalent 32-bit app,
> unless it belongs to a rare class of applications that benefit from huge
> amounts of accessible RAM. If your application can efficiently use more
> than 2GB of RAM, there's a benefit to switching to 64 bit. Otherwise,
> there are only downsides.

There is one more case where 64b may be handy, and that is when you are
running out of virtual space. This commonly happens with games, which
use the address space not only to access RAM, but also video card
drivers map significant portions in the virtual address space for their
own purposes. Our experience is we can allocate only about 1 GB RAM
before hitting the virtual space limit - and once we hit the limit, all
kinds of bad start to happen, because video card driver programmers seem
not count with a possibility of failed virtual memory allocations.

There might be cases other than games where 64b address space may help
you, because you no longer need to care about address space limits or
fragmentation, which opens door to some interesting techniques (like
growing arrays with huge virtual address space reserved which is
committed later as needed, avoiding the copy on resize)

> 3. What're the major concerns when developing a 64-bit app?

The performance and memory hit for being 64b can be significant - memory
hit depending on how much pointers do you data structures contain (my
guess is for our applications it is something like 5-15 % of data).

Concerns vary depending on what exactly do you intend to do. My concerns
would be:

* Some tools or libraries may be unavailable or badly tested in 64b
environment,
* If you programmed in 32b a lot, you need to take a lot of care to get
rid of habit of pointer-int(32b) conversions and arithmetic, and make
sure you always use proper sized 64b types.

Cheers
Ondrej

(Resending, sent to Igor only by mistake, sorry for that)

>
>> 2. Can an 64-bit app run on a 32-bit processor/Windows version
>> platform?
>
> No.
>
>> 3. What're the major concerns when developing a 64-bit app?
>
> Whether you need one in the first place. What kind of application are
> you thinking of?