Hacker News Reader

Comment by dblohm7 | Hacker News Reader

On Windows ULONG_PTR is not an unsigned long*, it is a pointer-width unsigned integer.

LONGs and ULONGs are 32-bits on 64-bit Windows, so when porting the API to 64 bits, types that were typedef'd as such on 32-bit, but actually need to be 64-bits wide on 64-bit systems, were replaced with ULONG_PTR.

View on HN

> On Windows ULONG_PTR is not an unsigned long*, it is a pointer-width unsigned integer.

So the equivalent to rust's usize?

Very similar, yes.

I guess they can't use uintptr_t, as that's 'large enough', not 'same size as'.

I think real reason is that ULONG_PTR is older than uintptr_t, which is a fairly new C99/Posix-2001 construct.

ULONG_PTR was introduced with 64-bit Windows (for example, the 32-bit version of USER32 does not have GetWindowLongPtr); the first version of that to be released to users was a separate edition of Windows XP in 2002. At that point C99 was three years old.

(I don’t have it in me right now to track down the first developer releases of 64-bit SDKs or the first C99 draft to have uintptr_t, sorry.)

In principle they could declare an ABI constraint for uintptr_t to have a given width. But note that the Windows headers define both UINT_PTR and ULONG_PTR: the former is {16,32,64} bits on Win{16,32,64}, while the latter is {32,32,64} bits (while a uintptr_t on a sane 16-bit compiler would probably need to be memory-model-dependent, although I haven’t checked). I don’t know why they cared to preserve this distinction, as my impression was that support for Win16 ended before Win64 was released, but maybe the inside timeline was different.

Wasn't amd64 windows available since around xp/vista? While windows 10 ships a 32bit version that still contains ntvdm and win16 support...

There was a small overlap after all, I was a bit off. The first 64-bit version of Windows XP (for the Itanium) was released in October 2001, while the support period for Windows 3.11 ended in December 2001.

At the same time, the existence of those types is not really about application support (which, as you note, you can get even today), it is about toolchain support, and AFAIU the last Microsoft toolchain to be able to target Win16 is VC++ 1.52 as bundled with VC++ 4 (1995). I don’t know at which point you stopped being abls to graft new SDKs onto it. Of course, the Watcom and Digital Mars compilers can still do it, but they maintain their own headers I think.

So the equivalent to rust's usize?

Reply on news.ycombinator.com