From: Gary R. Schmidt on
shrink4g wrote:
[SNIP]
> Sorry for replying late... due to issue i have with the PC.
>
> Since the OS is 64bit, I would like to have programs run in their native
> environment to avoid incompatibility issue. Wouldn't you think this is a
> good starting point? Anyhow someone here did say 32bit FF can work
> perfectly well with 64bit OS. So I did give it a try, and to be honest I
> had not run in any problem so far. To your questions concerning the
> browser, agree 32bit would do the job. I am not so sure that your
> argument would well fit other programs.

I'm talking mainly about x86/x64/AMD64 and EMT64 CPUs here, but this
also applies to 32- and 64-bit SPARC, MIPS, and PowerPC CPUs.

In the AMD64/EMT64 world, there is no difference in the execution of
32-bit instructions to that which takes place on a 32-bit x86 CPU
(modulo the CPU actually supporting those instructions, see SSE and others).

So, what you really have to worry about here is whether the 64-bit OS
will support the 32-bit program.

This is where Microsoft fall down very badly.

Up at the start I mentioned SPARC, MIPS, and PowerPC CPUs, all of have
been through 32- to 64-bit evolutions, and have had the various
Operating Systems that run on them evolve from 32- to 64-bit[1].

I have written code for them since they were 32-bit which *still* works
on the 64-bit evolutions.

Of course, I have also written a lot of code for the x86 family of CPUs
that still works under 64-bit Operating Systems - but only where the
Operating Systems are UNIX or Linux.

There have been some funny things happen with 32-bit programs I have
written when they are run on 64-bit Windows - but I write what are
considered "Systems Level" programs, they tend to do a lot of grovelling
around inside places, not like User Applications which tend to just add
numbers together :-) - so it is not that surprising.

Of course, since MS decided to make porting 32-bit programs to 64-bit a
*real pain in the fundament*, don't hold your breath waiting for them.

And what did MS do? Well, a "long" variable in the 32-bit world is
(generally) 32-bits, in the 64-bit world, a "long" variable is 64-bits -
except in MS' 64-bit world, there, a "long" variable is only 32-bits,
which means the code just can't be simply re-compiled. Sigh. I think
about 95% of the non-assembler code I've written (in the last 20 years)
will compile and run cleanly in a 64-bit *NIX environment - the 90
programs (about 10000 lines of code) in my home utilities directory
(some of which have been with me since 1986, which means they survived
going from a 32-bit environment *back* to a 16-bit environment then
*back* to a 32-bit environment) compile and run happily as 64-bit
programs - but that's my *NIX utilities, not my Windows utilities, they
are all still 32-bit only.

So, what this all boils down to is - there is no need to rush out and
put 64-bit applications on 64-bit Windows, 32-bit applications will run
fine.

And, you should be aware that 64-bit apps are often twice as large as
the equivalent 32-bit app, and consume about twice as much memory. They
usually, but not always, run faster, some can run a *lot* slower.

Cheers,
Gary B-)

1 - Okay, what Operating Systems did they use?
SPARC - Sun Solaris, ICL UNIX System V
MIPS - Sinix, IRIX
PowerPC - AIX
From: Craig on
On 01/04/2010 06:47 AM, Gary R. Schmidt wrote:
> 1 - Okay, what Operating Systems did they use?
> SPARC - Sun Solaris, ICL UNIX System V
> MIPS - Sinix, IRIX
> PowerPC - AIX

What? No Xenix?

--
-Craig
From: Gary R. Schmidt on
Craig wrote:
> On 01/04/2010 06:47 AM, Gary R. Schmidt wrote:
>> 1 - Okay, what Operating Systems did they use?
>> SPARC - Sun Solaris, ICL UNIX System V
>> MIPS - Sinix, IRIX
>> PowerPC - AIX
>
> What? No Xenix?
>
Well, that'd just confuse things - Xenix on the PDP-11 was 16-bit, as it
was on the 80286, then 32-bit on the 80386, but it never made it to
64-bits. (Yes, I worked with Xenix on all 3 platforms.)

Cheers,
Gary B-)