Why is it so difficult to make 64-bit versions of software?

Question

All aspects should be considered when developing your software in a 64-bit environment, and why will the same code not work as 32-bit and 64-bit (when it comes to applications)?

Drivers, obviously, are another animal, missing 64-bit drivers are a notorious problem for almost all hardware. What is so different in this area that it is almost impossible to find drivers?

Why is it so difficult to create 64-bit versions of software?

Edit: Forget about the basic flaws of the old, buggy software with magic numbers, etc. and think that you yourself will create software to be compatible with both. What aspects do you need to consider, and is there something you simply cannot overcome with the current compiler design? All the missing 64-bit software cannot be simply because people like code with magic numbers ?! :)

Conclusion Apparently, this all applies to laziness and the historical causes of man, and not to technical reasons.

Answer 1

One of the specific reasons why this can be difficult is that the sizes of the pointers will be different. Instead of a pointer occupying 32 bits, the pointer will now occupy 64 bits.

This is a problem if in software somewhere shoehorns a pointer to an int via reinterpret_cast in C ++ (which can happen at some really low level of code), and this happened because the size of the int and the pointer were the same size. Basically, the code assumed a certain size for the pointer.

Another way that can bite is a code crammed with magic numbers, for example 4 instead of sizeof(void*) , or 0xffffffff instead of INT_MAX or something like that.

There may not be a 64-bit version of the software if it depends on a library or feature that is not available in 64 bits. You cannot have an application that is part of 32 bits and 64 bits. For example, on Windows there is a function called SetWindowLong , which can only accept 32-bit data, so it is not very useful for 64-bit if the pointer should be passed to the function. That's why there is a function called SetWindowLongPtr , which can handle up to 64 bits in 64-bit programs and 32-bit in 32-bit programs.

Please note that Internet Explorer runs at 32 bits by default even in 64-bit windows, because a huge number of plug-ins for it are available only in 32-bit windows. A great example of this is the Adobe Flash Player , which is only available in 32-bit versions. Thus, apparently, even for a large company such as Adobe, porting to 64-bit may not always be trivial.

Bit change operations may be affected. For example, the bit offset 0x80000 remaining 10 times in 32 bits gives you 0x0 , but the bit offset 0x80000 remaining 10 times in 64 bits gives you 0x200000000 .

All that is said, there is no real technical reason why it is too difficult to port the application to 64-bit if the code was well written. The best scenario is a simple reconfiguration of the project and a complete overhaul - that's all you need.

The cynical side of me says that companies use this as a way to implement the planned obsolescence - to force or encourage people to update or buy the latest products!

Answer 2

The nutshell version: in the most popular language family - C and its children - the size and structure of data types are very important and implementation-defined. In fact, C has a lot of implementation-specific functions. This means it's easy to write non-portable code. It is impossible to write code that does not make assumptions about the underlying architecture, but it is very easy to depend on the behavior typical of x86 without realizing what you have done until you try to run the code in a different environment.

These are mainly low-level functions that make the architecture independent. In higher-level languages ​​such as Python and C #, this is much simpler.

Answer 3

Reasonably written software is usually very easy to port to another architecture. Just look at NetBSD, Debian, or other great free OS ... many open source programs run on more than two architectures.

The problem is that a lot of software has been written with good practice in mind. Creating "his" work is usually the only thing a typical programmer thinks about, not paying attention to further problems. Typical explanation: why worry about good practice if the client does not see the code and it works? Why spend more time on what is already working?

The drivers here are slightly different. Different architectures can handle low-level things differently. x86 and amd64 on Windows there is another problem: Microsoft has set stricter standards for amd64 drivers - hardware manufacturers haven’t bothered to create drivers for old equipment that meets more stringent requirements (again: why bother? buys new equipment with new 64- bit boxes, and if he does not, we will make sure that he still does not provide drivers). Again, open source drivers often work on both amd64 and x86 .

I have a sound card that works well on x86 and amd64 systems on Linux, but does not work with amd64 Windows precisely because of this problem. Therefore, it was impossible to write a driver for amd64 for it; the hardware company just didn't want to.

So, the final answer to your question: money.