Hacker News new | past | comments | ask | show | jobs | submit login

> In fact, for many software on Windows, the 64 bit port is considered beta versions.

That's probably due to Microsoft's choice of keeping both "int" and "long" as 32 bits while pointers increased to 64 bits, unlike everyone else which kept "int" as 32 bits and increased "long" to 64 bits. If any part of your program stored a pointer in a "long", it would break when the memory allocator gave you an address above 4G. You have to carefully comb your code to change the relevant variables to things like LONG_PTR (which isn't a "long" on 64-bit Windows) instead.

Storing a pointer in a long is probably common in 32-bit Windows, since window messages have a pair of parameters, WPARAM (which, despite its name, was an "int") and LPARAM (which was a "long"); pointers are often passed in LPARAM.




Most Windows apps don't deal directly with things line LONG_PTR and window procs - they just use a framework, and frameworks have been updated to do this all correctly a long time ago (this migration started in early 00s, when Windows on IA-64 appeared).

The main reason these days is that there's simply no strong incentive to go 64-bit for most desktop software. The 2Gb memory limit is a non-issue for most scenarios, and other than that, why bother? If you compile and test for 32-bit, it works for anyone who is still on 32-bit Windows and it works for 64-bit. And recompiling for 64-bit is usually easy, but it doubles your test matrix - so "here's a build, but there's no official support" is not an unpopular approach.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: