During the transition from 16 to 32 bit in the 80s, int was either 16 or 32 bit. Using the current 64 bit transition nomenclature, I understand there was a pretty even spread of ILP32 and LP32 machines. At the time I believe it was understood that int would always follow the register or pointer width for any given architecture and that long would remain 32 bit.
Fast forward 25 years, I see that LP64 is pretty mainstream, but until I encountered 64 bit platforms [my discovery of desktop Linux in 2007 :)], I always expected IP64 to be the next logical step.
- Was this (LP64) the expected evolution for 64bit?
- How does the
char≤short≤int≤longrelationship fit into this emerging scheme of fixing an integer type to each platform we leave behind? - How do these transition schemes relate to the use of (your choice of
{l,u}case)WORD/DWORDon various platforms? - Some areas of Windows still contain
INTforms that are 16bit. Will Windows grow out of LLP64 or is it too late? - Why was
intchosen to be left behind this time, as opposed to during the 32bit transition?
How I see it is that Windows is an oddball in the whole x64 transition. But putting that aside, C or C++ never defined the integral types to be fixed-length. I find the whole
int/long/pointerthing quite understandable, if you look at it this way:int: mostly 32 bits long (Linux, Mac and Windows)long: 64 bits on Mac and Linux, 32 on Windowslong long: 64-bit on Mac, Linux, and Windows x64u)intptr_t: exact length of pointer (32 on 32-bit, 64 on 64-bit systems)WORDandDWORDare ugly, and should be avoided. If the API forces you to use them, replaceDWORDwithDWORD_PTRwhen you’re dealing with… well, pointers. It was never correct to use (D)WORDthere in the first place IMHO.I don’t think Windows will change its decision, ever. Too much trouble already.
Why was
intleft behind? Why does Venus rotate in the opposite direction? The answer to the first question is found here (I believe), the second is a bit more complicated 😉