It's a bit of a dilemma currently which I hope will melt away over time. Unlike the Itanium, AMD designed for backwards compatibility, Intel have seen the impact and heading the same way. As it stands, there are a number of key apps that just won't build from sources on 64-bit without modification. I also don't expect ISV's to be in much of a rush to build 64-bit apps. I discussed 64-bit Crossover Office with codeweaver.com, they said it should be easy, but they haven't tried yet - it may prove more difficult than it looks from this side, like if Windows progs will cooperate as 64-bit doesn't play with 32-bit modules. I'm prepared to play wait and see what happens when the mud settles, happy that my 64-bit laptop leaves the 32-bit boxes behind speed-wise. Regards Sid. Leif Sorensen wrote:

I have to agree with you. It is just not logical to say that backwards compatibility is more important than being prepared for the new technology. Leif

...

From: Örn Hansen To: suse-amd64@suse.com Subject: Re: [suse-amd64] AMD64 and lib64 Date: Thu, 3 Jun 2004 15:14:22 +0200

torsdag 03 juni 2004 01:54 skrev Roy Butler:

...

Örn,

http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64

Read the rationale and you may agree it was the right thing to do.

I understand the rationale, but I hardly agree with it. As of current, 64bit systems require more memory and cpu power, just run the system because of this rationale. You have both 32bit and 64bit libraries loaded and running at the same time. I see this implementation, as a handicap.

Ideally, the system should be able to allow the same program to use either 32bit or 64bit libraries at will. Of course, this isn't so easy to do as you have 64bit values being passed to a program expecting 32bits. If it's a pointer to an int, the problem is solved by the architecture itself (only the lower 32bits would be written by a 32bit program). I understand that this ideal solution, is too hard to implement at this point in time. But on a native 64bit system, my opinion is that 32bit libraries should not be the norm. Regardless of the amount of 32bit programs around. As all programs compiled for the architecture, will be 64bits unless otherwise specified and this "otherwise specified" gives ample room for alternative library locations.

-- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help@suse.com

_________________________________________________________________ MSN 9 Dial-up Internet Access fights spam and pop-ups – now 3 months FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/

-- Sid Boyce .... Hamradio G3VBV and keen Flyer Linux Only Shop.

torsdag 03 juni 2004 16:40 skrev Sid Boyce:

It's a bit of a dilemma currently which I hope will melt away over time. Unlike the Itanium, AMD designed for backwards compatibility, Intel have seen the impact and heading the same way. As it stands, there are a number of key apps that just won't build from sources on 64-bit without modification. I also don't expect ISV's to be in much of a rush to build 64-bit apps. I discussed 64-bit Crossover Office with codeweaver.com, they said it should be easy, but they haven't tried yet - it may prove more difficult than it looks from this side, like if Windows progs will cooperate as 64-bit doesn't play with 32-bit modules. I'm prepared to play wait and see what happens when the mud settles, happy that my 64-bit laptop leaves the 32-bit boxes behind speed-wise. Regards Sid.

Now, there's that too ... but as I see it, providing a special command like "linux32" to run "older and non-compatible" 32bit programs to be more natural. That's the way Windows 64bit is going, you can select to run a program in 32bit (Windows 95/95/Me/Xp) compatibility mode.