www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows Header Files!

reply Trevor Parscal <Trevor_member pathlink.com> writes:
I have been working on, and almost have completed, rewriting Cpw
(http://www.mathies.com/cpw) completely in D. However the requirements for
certain windows header functions has cause me to come to a complete hault.

extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);

were all missing from all ports of the windows header files i could find. I was
actually really dissapoined with the Core32 library
(http://dsource.org/projects/core32/) as it had so many problems with it right
off the svn server, i just gave up.

I got a good port (i think it's good) from DedicateD
(http://int19h.tamb.ru/files.html) which worked in all other ways, spare these
functions being missing.

I added the two Set... definitions into the windows.d file I got from DedicateD,
which compiled fine (no undefined symbols anyways) but when I added the two
Get... function definitions, I got undefined symbols. I am compiling the
windows.d and winutil.d files as a lib, than including those files and linking
the lib in another program, and that's where the errors come up. The lib
compiles fine, no complaints.

Perhaps there is something I don't know about what's going on. PLEASE help me!

Another question... Why oh why does every port of the windows headers rename so
many of the functions with an A at the end of the name?

ANY help is wanted and appriciated.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 28 2005
next sibling parent reply bobef <bobef_member pathlink.com> writes:
In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...
I have been working on, and almost have completed, rewriting Cpw
(http://www.mathies.com/cpw) completely in D. However the requirements for
certain windows header functions has cause me to come to a complete hault.

extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);

were all missing from all ports of the windows header files i could find. I was
actually really dissapoined with the Core32 library
(http://dsource.org/projects/core32/) as it had so many problems with it right
off the svn server, i just gave up.

I got a good port (i think it's good) from DedicateD
(http://int19h.tamb.ru/files.html) which worked in all other ways, spare these
functions being missing.

I added the two Set... definitions into the windows.d file I got from DedicateD,
which compiled fine (no undefined symbols anyways) but when I added the two
Get... function definitions, I got undefined symbols. I am compiling the
windows.d and winutil.d files as a lib, than including those files and linking
the lib in another program, and that's where the errors come up. The lib
compiles fine, no complaints.

Perhaps there is something I don't know about what's going on. PLEASE help me!

You have to link with the appropriate library that contains these symbols, I guess user32.lib, but msdn says that there is no such function as SetClassLongPtr, there is without the ptr...
Another question... Why oh why does every port of the windows headers rename so
many of the functions with an A at the end of the name?

Because this is the original name of the functions. There are two versions for all win32 functions dealing with strings- one for ANSI and one for UNICODE. The ANSI one ends with A and UNICODE with W (I think from widechar). Win32 is hiding this with defines and stuff but if you look at the headers you will see...
ANY help is wanted and appriciated.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

May 29 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 29 May 2005 12:41:51 +0000 (UTC), bobef wrote:

 In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...
I have been working on, and almost have completed, rewriting Cpw
(http://www.mathies.com/cpw) completely in D. However the requirements for
certain windows header functions has cause me to come to a complete hault.

extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);

were all missing from all ports of the windows header files i could find. I was
actually really dissapoined with the Core32 library
(http://dsource.org/projects/core32/) as it had so many problems with it right
off the svn server, i just gave up.

I got a good port (i think it's good) from DedicateD
(http://int19h.tamb.ru/files.html) which worked in all other ways, spare these
functions being missing.

I added the two Set... definitions into the windows.d file I got from DedicateD,
which compiled fine (no undefined symbols anyways) but when I added the two
Get... function definitions, I got undefined symbols. I am compiling the
windows.d and winutil.d files as a lib, than including those files and linking
the lib in another program, and that's where the errors come up. The lib
compiles fine, no complaints.

Perhaps there is something I don't know about what's going on. PLEASE help me!

You have to link with the appropriate library that contains these symbols, I guess user32.lib, but msdn says that there is no such function as SetClassLongPtr, there is without the ptr...

Yes there is. I quote from the SDK docs ... SetClassLongPtr Function -------------------------------------------------------------------------------- The SetClassLongPtr function replaces the specified value at the specified offset in the extra class memory or the WNDCLASSEX structure for the class to which the specified window belongs. This function supersedes the SetClassLong function. To write code that is compatible with both 32-bit and 64-bit Microsoft® Windows®, use SetClassLongPtr. Syntax ULONG_PTR SetClassLongPtr( HWND hWnd, int nIndex, LONG_PTR dwNewLong ); Parameters hWnd [in] Handle to the window and, indirectly, the class to which the window belongs. nIndex [in] Specifies the value to replace. To set a value in the extra class memory, specify the positive, zero-based byte offset of the value to be set. Valid values are in the range zero through the number of bytes of extra class memory, minus eight; for example, if you specified 24 or more bytes of extra class memory, a value of 16 would be an index to the third integer. To set a value other than the WNDCLASSEX structure, specify one of the following values. GCL_CBCLSEXTRA Sets the size, in bytes, of the extra memory associated with the class. Setting this value does not change the number of extra bytes already allocated. GCL_CBWNDEXTRA Sets the size, in bytes, of the extra window memory associated with each window in the class. Setting this value does not change the number of extra bytes already allocated. For information on how to access this memory, see SetWindowLongPtr. GCLP_ HBRBACKGROUND Replaces a handle to the background brush associated with the class. GCLP_HCURSOR Replaces a handle to the cursor associated with the class. GCLP_HICON Replaces a handle to the icon associated with the class. GCLP_HICONSM Retrieves a handle to the small icon associated with the class. GCLP_HMODULE Replaces a handle to the module that registered the class. GCLP_MENUNAME Replaces the pointer to the menu name string. The string identifies the menu resource associated with the class. GCL_STYLE Replaces the window-class style bits. GCLP_WNDPROC Replaces the pointer to the window procedure associated with the class. dwNewLong [in] Specifies the replacement value. Return Value If the function succeeds, the return value is the previous value of the specified offset. If this was not previously set, the return value is zero. If the function fails, the return value is zero. To get extended error information, call GetLastError. Remarks If you use the SetClassLongPtr function and the GCLP_WNDPROC index to replace the window procedure, the window procedure must conform to the guidelines specified in the description of the WindowProc callback function. Calling SetClassLongPtr with the GCLP_WNDPROC index creates a subclass of the window class that affects all windows subsequently created with the class. An application can subclass a system class, but should not subclass a window class created by another process. Reserve extra class memory by specifying a nonzero value in the cbClsExtra member of the WNDCLASSEX structure used with the RegisterClassEx function. Use the SetClassLongPtr function with care. For example, it is possible to change the background color for a class by using SetClassLongPtr, but this change does not immediately repaint all windows belonging to the class. Function Information Header Declared in Winuser.h, include Windows.h Import library User32.lib Minimum operating systems Windows 95, Windows NT 3.1 Unicode Implemented as Unicode and ANSI versions on Windows NT, Windows 2000, Windows XP See Also Window Classes Overview, GetClassLongPtr, RegisterClassEx, SetWindowLongPtr, WindowProc, WNDCLASSEX -------------------------------------------------------------------------------- © 2003 Microsoft Corporation. All rights reserved. -------------------------------------------------------------------------------- -- Derek Parnell Melbourne, Australia 29/05/2005 11:15:37 PM
May 29 2005
next sibling parent bobef <bobef_member pathlink.com> writes:
© 2003 Microsoft Corporation. All rights reserved. 

:P:P Just kidding :) Anyway then just link with user32.lib. Just add it to the command line along with you .d sources. If it is supported in win95 it should work. I needed something like GradientFill and it wasn't there. I guess the library is at win95 level...
May 29 2005
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:n8h30rzwkfg$.7luucwmdrm6s$.dlg 40tude.net...
 On Sun, 29 May 2005 12:41:51 +0000 (UTC), bobef wrote:

 In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...
I have been working on, and almost have completed, rewriting Cpw
(http://www.mathies.com/cpw) completely in D. However the requirements 
for
certain windows header functions has cause me to come to a complete 
hault.

extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);

were all missing from all ports of the windows header files i could find. 
I was
actually really dissapoined with the Core32 library
(http://dsource.org/projects/core32/) as it had so many problems with it 
right
off the svn server, i just gave up.

I got a good port (i think it's good) from DedicateD
(http://int19h.tamb.ru/files.html) which worked in all other ways, spare 
these
functions being missing.

I added the two Set... definitions into the windows.d file I got from 
DedicateD,
which compiled fine (no undefined symbols anyways) but when I added the 
two
Get... function definitions, I got undefined symbols. I am compiling the
windows.d and winutil.d files as a lib, than including those files and 
linking
the lib in another program, and that's where the errors come up. The lib
compiles fine, no complaints.

Perhaps there is something I don't know about what's going on. PLEASE 
help me!

You have to link with the appropriate library that contains these symbols, I guess user32.lib, but msdn says that there is no such function as SetClassLongPtr, there is without the ptr...

Yes there is. I quote from the SDK docs ... SetClassLongPtr Function -------------------------------------------------------------------------------- The SetClassLongPtr function replaces the specified value at the specified offset in the extra class memory or the WNDCLASSEX structure for the class to which the specified window belongs. This function supersedes the SetClassLong function. To write code that is compatible with both 32-bit and 64-bit Microsoft® Windows®, use SetClassLongPtr. Syntax ULONG_PTR SetClassLongPtr( HWND hWnd, int nIndex, LONG_PTR dwNewLong );

ULONG_PTR and LONG_PTR are typedefs for C's 'unsigned long' and 'long', respectively. "PTR" signifies a type big enough to hold a pointer, not a pointer itself. So, this would be the declaration in D: extern (Windows) : uint SetClassLongPtrA(HWND hWnd, int nIndex, int dwNewLong); uint SetClassLongPtrW(HWND hWnd, int nIndex, int dwNewLong); Yes, both ANSI and Unicode versions are the same. The Unicode version is intended to be used when passing UTF16 strings. To avoid having to specify which version to call, use an alias: version (Unicode) { alias SetClassLongPtrW SetClassLongPtr; } else { alias SetClassLongPtrA SetClassLongPtr; } Compile with: dmd -version=Unicode I tend to dispense entirely with the ANSI API (on Windows 2000 and above, Unicode is native), so only declare the "W" versions, which obviates the need for the version attribute and compiler option.
 Parameters

 hWnd
 [in] Handle to the window and, indirectly, the class to which the window
 belongs.
 nIndex
 [in] Specifies the value to replace. To set a value in the extra class
 memory, specify the positive, zero-based byte offset of the value to be
 set. Valid values are in the range zero through the number of bytes of
 extra class memory, minus eight; for example, if you specified 24 or more
 bytes of extra class memory, a value of 16 would be an index to the third
 integer. To set a value other than the WNDCLASSEX structure, specify one 
 of
 the following values.
 GCL_CBCLSEXTRA
 Sets the size, in bytes, of the extra memory associated with the class.
 Setting this value does not change the number of extra bytes already
 allocated.
 GCL_CBWNDEXTRA
 Sets the size, in bytes, of the extra window memory associated with each
 window in the class. Setting this value does not change the number of 
 extra
 bytes already allocated. For information on how to access this memory, see
 SetWindowLongPtr.
 GCLP_ HBRBACKGROUND
 Replaces a handle to the background brush associated with the class.
 GCLP_HCURSOR
 Replaces a handle to the cursor associated with the class.
 GCLP_HICON
 Replaces a handle to the icon associated with the class.
 GCLP_HICONSM
 Retrieves a handle to the small icon associated with the class.
 GCLP_HMODULE
 Replaces a handle to the module that registered the class.
 GCLP_MENUNAME
 Replaces the pointer to the menu name string. The string identifies the
 menu resource associated with the class.
 GCL_STYLE
 Replaces the window-class style bits.
 GCLP_WNDPROC
 Replaces the pointer to the window procedure associated with the class.
 dwNewLong
 [in] Specifies the replacement value.
 Return Value

 If the function succeeds, the return value is the previous value of the
 specified offset. If this was not previously set, the return value is 
 zero.

 If the function fails, the return value is zero. To get extended error
 information, call GetLastError.




 Remarks

 If you use the SetClassLongPtr function and the GCLP_WNDPROC index to
 replace the window procedure, the window procedure must conform to the
 guidelines specified in the description of the WindowProc callback
 function.

 Calling SetClassLongPtr with the GCLP_WNDPROC index creates a subclass of
 the window class that affects all windows subsequently created with the
 class. An application can subclass a system class, but should not subclass
 a window class created by another process.

 Reserve extra class memory by specifying a nonzero value in the cbClsExtra
 member of the WNDCLASSEX structure used with the RegisterClassEx function.

 Use the SetClassLongPtr function with care. For example, it is possible to
 change the background color for a class by using SetClassLongPtr, but this
 change does not immediately repaint all windows belonging to the class.

 Function Information

 Header Declared in Winuser.h, include Windows.h
 Import library User32.lib
 Minimum operating systems Windows 95, Windows NT 3.1
 Unicode Implemented as Unicode and ANSI versions on Windows NT, Windows
 2000, Windows XP

 See Also

 Window Classes Overview, GetClassLongPtr, RegisterClassEx,
 SetWindowLongPtr, WindowProc, WNDCLASSEX

 --------------------------------------------------------------------------------

 © 2003 Microsoft Corporation. All rights reserved.
 --------------------------------------------------------------------------------


 -- 
 Derek Parnell
 Melbourne, Australia
 29/05/2005 11:15:37 PM 

May 29 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
John C, Derek Parnell,

Thank you, I will try your advice. Hopefully this library will really help the D
comunity...

I named it Terra.

Thanks Again,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 29 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:d7d4lo$3gl$1 digitaldaemon.com...
 John C, Derek Parnell,

 Thank you, I will try your advice. Hopefully this library will really help 
 the D
 comunity...

I forgot to mention that the user32.lib file distributed with D is out of date and does not import the functions you wanted to use. So you'll need to create a .def file (call it 'user32ex.def') and run it through implib. In 'user32ex.def': LIBRARY user32 EXPORTS _SetClassLongPtrA 12 = SetClassLongPtrA _SetClassLongPtrW 12 = SetClassLongPtrW _SetWindowLongPtrA 12 = SetWindowLongPtrA _SetWindowLongPtrW 12 = SetWindowLongPtrW _GetClassLongPtrA 8 = GetClassLongPtrA _GetClassLongPtrW 8 = GetClassLongPtrW _GetWindowLongPtrA 8 = GetWindowLongPtrA _GetWindowLongPtrW 8 = GetWindowLongPtrW Create an import library as follows: implib user32ex.lib user32ex.def Finally add user32ex.lib to your list of lib files on the dmd command line.
 I named it Terra.

 Thanks Again,
 Trevor Parscal
 www.trevorparscal.com
 trevorparscal hotmail.com 

May 29 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
In article <d7d6u9$5kq$1 digitaldaemon.com>, John C says...
I forgot to mention that the user32.lib file distributed with D is out of 
date and does not import the functions you wanted to use. So you'll need to 
create a .def file (call it 'user32ex.def') and run it through implib.

In 'user32ex.def':

    LIBRARY user32
    EXPORTS
    _SetClassLongPtrA 12 = SetClassLongPtrA
    _SetClassLongPtrW 12 = SetClassLongPtrW
    _SetWindowLongPtrA 12 = SetWindowLongPtrA
    _SetWindowLongPtrW 12 = SetWindowLongPtrW
    _GetClassLongPtrA 8 = GetClassLongPtrA
    _GetClassLongPtrW 8 = GetClassLongPtrW
    _GetWindowLongPtrA 8 = GetWindowLongPtrA
    _GetWindowLongPtrW 8 = GetWindowLongPtrW

Create an import library as follows:

    implib user32ex.lib user32ex.def

Finally add user32ex.lib to your list of lib files on the dmd command line.

It worked, but now, I have a GDIFlush Call, which is the same situation. It takes no arguments, so I thought it should be adeed to the user32ex.def as GDIFlush 0, as the error says it should be... But that's not working. Any ideas? Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com
May 29 2005
next sibling parent Trevor Parscal <Trevor_member pathlink.com> writes:
Please ignore my last post, I was naming it GDIFlush, instead of GdiFlush...
stupid mistake.

The thing compiles fine now.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 29 2005
prev sibling parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
Well, I am now wondering what up with my windows version of user32.dll, cause
it's got none of the functions I was needing...

extern(Windows) WINBOOL GdiFlush(VOID);
extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
extern(Windows) ULONG* GetClassLongPtrW(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrW(HWND, int);

Are all apparently missing from my DLL..

the functions...

extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetClassLongPtrW(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrW(HWND, int, ULONG*);

Are in there, and mapped properly.

Any ideas as to what to do? Work arounds? I am stumped as to why a windows XP
install wouldn't have these functions in the user32.dll library.

I really appriciate this help, it's making a big difference.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 29 2005
parent "John C" <johnch_atms hotmail.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:d7dctv$b2o$1 digitaldaemon.com...
 Well, I am now wondering what up with my windows version of user32.dll, 
 cause
 it's got none of the functions I was needing...

 extern(Windows) WINBOOL GdiFlush(VOID);

GdiFlush is in gdi32.dll. Link in gdi32.lib.
 extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
 extern(Windows) ULONG* GetClassLongPtrW(HWND, int);
 extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);
 extern(Windows) ULONG* GetWindowLongPtrW(HWND, int);

 Are all apparently missing from my DLL..

Ok, it appears these functions don't exist for 32-bit Windows (64-bit only). I've tracked them down in the SDK headers, and they're just aliases for GetWindowLong etc. The equivalent in D is to do this: alias GetWindowLongA GetWindowLongPtrA; alias GetClassLongA GetClassLongPtrA; and so on. They're included for symmetry with the Set*LongPtr functions, which do exist. Also, as I mentioned earlier, they don't return pointers - LONG_PTR is a typedef for C's 'long', which is the same as 'int' in D.
 the functions...

 extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
 extern(Windows) ULONG* SetClassLongPtrW(HWND, int, ULONG*);
 extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
 extern(Windows) ULONG* SetWindowLongPtrW(HWND, int, ULONG*);

 Are in there, and mapped properly.

 Any ideas as to what to do? Work arounds? I am stumped as to why a windows 
 XP
 install wouldn't have these functions in the user32.dll library.

 I really appriciate this help, it's making a big difference.

 Thanks,
 Trevor Parscal
 www.trevorparscal.com
 trevorparscal hotmail.com 

May 29 2005
prev sibling parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...
were all missing from all ports of the windows header files i could find. I was
actually really dissapoined with the Core32 library
(http://dsource.org/projects/core32/) as it had so many problems with it right
off the svn server, i just gave up.

Care to tell me what the problems are so that I might be able to fix them? I just realized that the links in http://www.dsource.org/forums/viewforum.php?f=16 were messed up from the some changes that happened recently with the dsource upgrade. I'm sorry if that wasted your time. It's fixed now. jcc7
May 29 2005
parent reply bobef <bobef_member pathlink.com> writes:
In article <d7dd49$bac$1 digitaldaemon.com>, J C Calvarese says...
In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...
were all missing from all ports of the windows header files i could find. I was
actually really dissapoined with the Core32 library
(http://dsource.org/projects/core32/) as it had so many problems with it right
off the svn server, i just gave up.

Care to tell me what the problems are so that I might be able to fix them?

I can tell you few things I met... First I wanted to have IE in my app and it was OK althought to get a single window I need kilobytes of code but there was no interface (or whatever it is called) for the events so it is useless to me... Most common controls are missing. GradientFill is missing. And the other thing I had problem with was to discover which module contains the functions I need. Maybe naming it like MS would help... then you can just look in msdn amd import core32.windows; or whatever... It is nice project and I can see you've done a LOT of work. But wouldn't it be wiser to extend http://int19h.tamb.ru 's headers instead of rewriting all that...
May 29 2005
parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d7de8s$c8i$1 digitaldaemon.com>, bobef says...
In article <d7dd49$bac$1 digitaldaemon.com>, J C Calvarese says...
In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...
were all missing from all ports of the windows header files i could find. I was
actually really dissapoined with the Core32 library
(http://dsource.org/projects/core32/) as it had so many problems with it right
off the svn server, i just gave up.

Care to tell me what the problems are so that I might be able to fix them?

I can tell you few things I met...

Thanks for your input.
First I wanted to have IE in my app and it was OK althought to get a single
window I need kilobytes of code but there was no interface (or whatever it is
called) for the events so it is useless to me...

Most common controls are missing.

So you're saying that commctrl.d is incomplete. I believe you, but I'm just one person and it's tricky figuring out what is particular needs to be added. I would accepted donated code if it fit with the Core32 style (which is hard to describe). ;)
GradientFill is missing.

I guess it is missing. According to MSDN, it's been around for a while so I can't explain why it's not there. It should be part of wingdi.d. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_8oa4.asp Maybe Core32 is based on a really old version of the Platform SDK. That'd be bad news. :(
And the other thing I had problem with was to discover which module contains 
 the functions I need. Maybe naming it like MS would help... then you can just
> look in msdn amd import core32.windows; or whatever...

I think "import win32.api" was meant to fill this role, but now that I look at it not everything is imported. Hmmm...
It is nice project and I can see you've done a LOT of work. 

Actually, Mike Wynn did most of the work. I've just tried to keep it going when he apparently dropped the project.
But wouldn't it be wiser to extend http://int19h.tamb.ru 's headers instead of
>rewriting all that...

I've been aware of int19h.tamb.ru for years, but it hasn't been updated in a long time. If I were to approach the project from a new angle (and redo everything), I'd base it on the public domain headers (w32api) from http://www.mingw.org/ (and rely heavily on automation). If anyone has another other specific complaints and comments about Core32, we should probably discuss them over at the forum at dsource (http://www.dsource.org/forums/viewforum.php?f=16), so that we don't clutter up this newsgroup. jcc7
May 29 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
GradientFill is missing.

I guess it is missing. According to MSDN, it's been around for a while so I can't explain why it's not there. It should be part of wingdi.d. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_8oa4.asp

GradientFill resides in Msimg32.dll. Msimg32 appeared in WinME - there it is a full implementation. Msimg32.dll on XP is a proxy for correspondent GdiGradientFill, etc. calls from GDI32.dll. Ideally your application should not depend on Msimg32.dll existence so you cannot link it statically. Andrew.
May 29 2005