RE: [rt.cpan.org #55660] [PATCH] Partial win64 support for Win32::API
[email protected] ("Stephen Bennett via RT")
| Newsgroups | perl.libwin32 |
|---|---|
| Message-ID | <[email protected]> |
Mon Jul 12 11:52:56 2010: Request 55660 was acted upon. Transaction: Correspondence added by [email protected] Queue: Win32-API Subject: RE: [rt.cpan.org #55660] [PATCH] Partial win64 support for Win32::API Broken in: (no value) Severity: (no value) Owner: COSIMO Requestors: [email protected] Status: open Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=55660 > Ah yes, I'd forgotten about those. However, I'd suggest they can probably just use the _P name as DWORD_PTR does -- MSDN lists them all as being equivalent either to a HANDLE (hence PVOID) or a *_PTR type (hence pointer sized)[1]. The argument in favour of having separate _P and _L size markers would be future-proofing, but experience suggests there's absolutely no telling what the Win32 API will look like for any possible future architecture, so I'd rather handle the current possibilities in the simplest manner possible. So yes, they're not technically pointers but are all defined as being the same size as a pointer. [1]: http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx Accelrys Limited (http://accelrys.com) Registered office: 334 Cambridge Science Park, Cambridge, CB4 0WN, UK Registered in England: 2326316