I vote for this enhancement, however I also see it as a long-term project.

I have to say, this is not critical. Being in 32 bit mode is annoying, but in-and-of itself, it does not cause loss of inventory or viewer crashing.

I don't think this can be verified. I've seen many instances of freezes and crashes that don't happen on my 32-bit systems at work and my laptops. That is something that is frequently associated with bad pointer translation.

Moving to a 64-bit architecture that was also compatible with residents' 32-bit systems will actually slow down performance. Consider this ... you have a 64 bit system. To be compatible with 32-bit machines, LL makes the choice to specify the maximum size of a word to be compatible with the older machines. So now you are WASTING 32 bits of every word, but you are still having to load it into memory.

That was never in question.

@Sho

I was more specifically referring to how windows in this case handles translation of instructions from 32 to 64-bit, not issues with the pointers themselves. My suggestion to create an autonomous 64-bit viewer does not change, I was hoping that wouldn't get lost in minutae. I never suggested they merely alter the existing sourcebase to support 32 and 64 in the same application. Two seperate distributions would take more time, but would function much better.

That only thing I debated here was whether or not instruction set issues were occuring due to windows having to overthink each part of the process. The stack to run wow64 applications is ridiculous in comparison to simply talking to the win64 api, and it seems more likely that the issue is there, rather than with LL's code, as the problems are not reproducable under 32bit. There are most certainly more people than myself experiencing random crashes and freezes on 64-bit systems. We're on the same page here, just expressing it differently.

Creating a 64-bit viewer would likely be more work than fixing the problem. However, that being said, what if it does turn out to simply be issues with how the operating system is handling the application? In that case, there isn't much you can do ,and the only real option for fixing it without hacking is to write a 64-bit version.

But I'm not sure about Windows and its 3rd party dependencies. For example the last time I checked, Quicktime was still not supported for Windows 64. Not sure about the current situation though.

http://www.byteme.org.uk/secondlife-amd64/apt-get-a-secondlife.html

I would be curious what the numbers are for 64bit users. While I think this is a good idea I imagine we won't see it anytime soon unless there are a large % of users on 64bit and only LL can tell us that type of data.

I think it would simply make it easier to ignore.

http://blogs.zdnet.com/Bott/?p=506&tag=nl.e539

Also, every version of linux and solaris I run are 64-bit, as are my OS X 10.5 installs. The issue here is not need per platform, it's changing hardware. 32-bit is going the way of the dinosaur, and linden labs will only fall further behind by continuing to ignore that.

On a personal note, I see the mountain of complaints that "breaking the issue into seperate issues" cause for the linux and mac viewers, which are largely considered to be undersupported. It seems to me that LL could stand to spend a little more time in QA. Also, QA time doesn't appear to be an issue with the 15 release candidate viewers, I don't see why it would be any different with this.

The answer regarding smoke testing is somewhat disheartening from my perspective. It sounds like you're willing to leave your application on what is fast becoming legacy technology because it will mean more time spent on quality assurance, or I guess in this case simply making sure it doesn't burst into flames when you start it up.

@Drew

While I think this is a valid point, I haven't had a lot of luck with the third party viewers, and really do actually trust linden lab's installs.

@Carjay

As shoshana pointed out, what we seek to avoid with this is people simply recompiling and saying, 'oh look, a 64-bit version.' This causes problems too numerous to list and rarely if ever provides any benefits.

As for quicktime, it's not even neccessary to have it installed to run SL, so, to that end, it doesn't matter what version of quicktime you have installed. I personally won't install it due to outstanding code execution bugs that apple refuses to fix.

see : http://www.frsirt.com/english/advisories/2008/1776/references

Also - please see my comment above. I really can't see this issue going anywhere without calling out and building arguments for specific platforms.

http://jira.secondlife.com/browse/VWR-9087

Requesting 64 bit viewer for Windows Vista and XP.

you're right, the 32bit is going down. But thats the architecture only! It depends which OS you use. I see many new Computersystems with 64bit architecture, but with 32bit OS on it (XP x86, Vista x86), instead of the x64 versions. Why?
Simple, not all programs are supported under a 64bit Windows OS and Windows x64 don't support 16bit programs (i know still some ppl who need such old programs).

I think the best way is, to count the used OS-Versions and not the cpu architecture.

But i agree to all others that it would be nice to have a real 64bit Viewer, maybe without 2gacs (2 gigabyte always continuos swapping, a hint at emacs ).

"64bit is coming, maybe not for windows first but the install.xml file with library links for the prepackaged libs has linux64 links in it now http://svn.secondlife.com/trac/linden/browser/trunk/install.xml But it is already possible to get a 64bit viewer if you build it and all the libraries yourself. "

Update: Created VWR-14181.