Thread overview
Where can get the Windows 64-bit API for GUI_Libraries?
Nov 19, 2014
FrankLike
Nov 19, 2014
Frank Like
Nov 21, 2014
Marco Leise
November 19, 2014
Now,GUI_Libraries should be migrated from 32-bit to 64 bit,but some info is based on WindowsAPI,so WindowsAPI should be a standard for 64-bit GUI_Libraries.Where can get it?
Thank you all.
November 19, 2014
On Wednesday, 19 November 2014 at 06:28:20 UTC, FrankLike wrote:
> Now,GUI_Libraries should be migrated from 32-bit to 64 bit,but some info is based on WindowsAPI,so WindowsAPI should be a standard for 64-bit GUI_Libraries.Where can get it?
> Thank you all.

if you compile the dfl Library to 64 bit,you will find error:

core.sys.windows.windows.WaitForMultipleObjects(uint
nCount,void** lpHandles,....) is not callable using argument
types(ulong,void**,...)

the 'WaitForMultipleObjects' Function is in
dmd2/src/druntime/src/core/sys/windows/windows.d

the argument of first is dfl's value ,it come from a 'length'
,it's type is size_t,now it is 'ulong' on 64 bit.

So druntime must keep the same as  phobos for size_t.
November 21, 2014
Am Wed, 19 Nov 2014 09:08:07 +0000
schrieb "Frank Like" <1150015857@qq.com>:

> On Wednesday, 19 November 2014 at 06:28:20 UTC, FrankLike wrote:
> > Now,GUI_Libraries should be migrated from 32-bit to 64 bit,but
> > some info is based on WindowsAPI,so WindowsAPI should be a
> > standard for 64-bit GUI_Libraries.Where can get it?
> > Thank you all.
> 
> if you compile the dfl Library to 64 bit,you will find error:
> 
> core.sys.windows.windows.WaitForMultipleObjects(uint
> nCount,void** lpHandles,....) is not callable using argument
> types(ulong,void**,...)
> 
> the 'WaitForMultipleObjects' Function is in dmd2/src/druntime/src/core/sys/windows/windows.d
> 
> the argument of first is dfl's value ,it come from a 'length' ,it's type is size_t,now it is 'ulong' on 64 bit.
> 
> So druntime must keep the same as  phobos for size_t.

Of course it does. Using uint or int would just be inconsistent. My opinion is that the compiler should treat size_t as a different type from both uint and ulong, so it can warn about portability issues when switching between 32-bit and 64-bit. I know some who say "But it is easy with dmd to test both 32-bit and 64-bit", but in reality we see these size_t doesn't match uint bugs way too often.

Anyway did you report a bug to dfl or did you just want to
make another point about how int is better for lengths?
(No, it is not going to happen. :) )

-- 
Marco