extend of native apps

aresoftware manufacturers ever going tocome out with native 64 bit versions?

It seems that they are all thinking , we can rely on the 32 bit emaultion
environment so why bother.

Gerard

Vanguard
Sun Dec 25 14:43:36 CST 2005

"ged" <ged@discussions.microsoft.com> wrote in message
news:6BE08F56-52FA-44CD-9183-B9C1655BA97F@microsoft.com...
> aresoftware manufacturers ever going tocome out with native 64 bit
> versions?
>
> It seems that they are all thinking , we can rely on the 32 bit emaultion
> environment so why bother.


Are you going to pay them for their research and refund them any loss should
not enough users feel the need to replace a fully functional 32-bit version
with a 64-bit version that provides absolutely no additional functionality
and is insigificantly faster?

Why ask us what software authors will do? Go ask the software authors if
they see a need.

--
__________________________________________________
Post replies to the newsgroup - Share with others.
E-mail: Remove "NIX" and append "#VC811" to Subject.
__________________________________________________

Ernst
Mon Dec 26 03:00:02 CST 2005

Software that isn't flexible enough to be ported cheap and fast on other
operation systems will die out in short-term. It is a question of â??secureâ??
capital investment to buy software that is usable in the future (especially
for organizations). Emulation is only a temporary workaround, because you
"buy" this compatibility with stability, security, and resource
disadvantages. 64Bit software isn't temporary and also no permanent
occurrence (there is 128bit on the way). Therefore it is the best idea to
port your software as fast as possible to managed code. If this is not
possible try to write clean C++. There is software you can port to any new
system in few days.(Including complete automatic tests.)

"Vanguard" wrote:

> "ged" <ged@discussions.microsoft.com> wrote in message
> news:6BE08F56-52FA-44CD-9183-B9C1655BA97F@microsoft.com...
> > aresoftware manufacturers ever going tocome out with native 64 bit
> > versions?
> >
> > It seems that they are all thinking , we can rely on the 32 bit emaultion
> > environment so why bother.
>
>
> Are you going to pay them for their research and refund them any loss should
> not enough users feel the need to replace a fully functional 32-bit version
> with a 64-bit version that provides absolutely no additional functionality
> and is insigificantly faster?
>
> Why ask us what software authors will do? Go ask the software authors if
> they see a need.
>
> --
> __________________________________________________
> Post replies to the newsgroup - Share with others.
> E-mail: Remove "NIX" and append "#VC811" to Subject.
> __________________________________________________
>
>

Vanguard
Mon Dec 26 09:47:04 CST 2005

"Ernst" <Ernst@discussions.microsoft.com> wrote in message
news:E2318FD7-76BD-440F-A7AC-80548ECE311F@microsoft.com...
> Software that isn't flexible enough to be ported cheap and fast on other
> operation systems will die out in short-term. It is a question of
> â??secureâ??
> capital investment to buy software that is usable in the future
> (especially
> for organizations). Emulation is only a temporary workaround, because you
> "buy" this compatibility with stability, security, and resource
> disadvantages. 64Bit software isn't temporary and also no permanent
> occurrence (there is 128bit on the way). Therefore it is the best idea to
> port your software as fast as possible to managed code. If this is not
> possible try to write clean C++. There is software you can port to any
> new
> system in few days.(Including complete automatic tests.)

And we are now into how many YEARS of supporting 16-bit apps on Windows?
Developers have limited resources, so if they are working on new
functionality, fixing bugs, or working on other projects, then the developer
has to wait until they can schedule their programmers to rewrite a 32-bit
app to be a native 64-bit app. If no functionality is added and if the
32-bit app is already working on the 64-bit platform then the developer sees
NO immediate need for conversion regardless of how easy it is.

--
__________________________________________________
Post replies to the newsgroup - Share with others.
E-mail: Remove "NIX" and append "#VC811" to Subject.
__________________________________________________