Discussion Locked

64 Bit Computing

0 helpful
8 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
The ancient old relic that has served me well for the last 7 years has finally been replaced and I have a brand new machine at work. It is a bit more "state of the art" than old "reliable" who served me well, though to be fair, many years ago it would have been considered "state of the art" once. Along with the new machine comes a step into the 64 bit world with XP 64 bit edition. A few months ago I also upgraded my primary home machine which is running 64 bit Fedora 8. Hardware wise 64 bit machines are not new, but there seems to be a lagging in the take up of 64 bit computing. Basically software and applications across the board have not kept up with the machines. As I know squat about the software and development of applications I have no idea why this is. With my limited knowledge of these things, with Linux going from a 32bit to 64bit, would mainly consist of re-compiling source for 64bit. What needs to happen to move things forward. To me 32 bit seems a bit last century when compared with the 64 bit option.

8 replies

by jaqui

since with true 64 bit hardware there are more available ram addresses, variable sizes are changed, and a number of other basic changes on that low level.

The complete rewrite of the programming language to support the changes, and the compilers to support them was / is needed.

Why is software lagging behind os in 64 bit support? Most applications that are commonly used don't even begin to make use of the capacity of 32 bit systems, porting them to 64 bit is not a high priority until there are no more active 32 bit systems.

Once the last 32 bit systems are no longer being sold, then they will start to worry about supporting 64 bit. Until then, it is a very rare situation where you will not have multilib systems, with support for both 32 and 64 bit software.

by jaqui

that is the same old penguin avatar I was using for a month, with the background made non transparent and scaled to fit TR's size.

by mjrunion

I support several x64 systems and perhaps I have an explanation. It seems that there is a catch 22 situation with x64 software. People do not use x64 because there are few applications that truly take advantage of the x64 capability (read as high end scientific, data crunching and graphics). Because people do not use the platform on a regular basis, driver development, and software development are not cost effective on a mass market basis. If it is not cost effective no software is written for the x64 platform, meaning there are few users. As far as the scientific community (particularly those who run GIS or LIDAR processing) x64 is pretty standard and the software used is all x64.

by tony hopkinson

I've had Win64 bit compliance as a thing to do in for nearly two years, it's still there....

Not just out software of course, had to wait for drivers, SQL2005 on 64 bit...

I'm only aware of one of our customers who bought it, made the installer hiccup when it tried to put SQL 2005 32bit version on.

I'm hummmh and hahing about getting it for myself, but don't know as I need the hassle.

I have done some work on it and you can get some strange stuff happening even in 32 bit mode. GDI API calls are something to look at if relevant, handle size will be wrong and you can get some weird effects. Mine was a tab sheet with blank captions.

by j-mart

most of the apps in use are 32 bit and it had broken my drawing management software that was written with Borland Builder 3 ( win 95-98 era) which did work on win 2000. I can see one of our NC cutting programs from the same era not working when we get around to installing it. We are well overdue for upgrading this application but in the past never bothered because the old one really worked well and got the job done quickly. Though a new system with decent hardware and a fresh windows install always runs well.

This discussion is closed to new replies.