WinApi32 declarations archive (x86 & x64): public project

[EwaldP]

There are quite some libraries with Windows API declarations published in the past on the old and new forum and many samples
are created which uses Windows API.

One started public project in the past was to collect all those declarations (dll function definitions) and constants and place them in a downloadable package: WinApi32.zip

This archive contains now many WinAPI functions and constants.

With the new TD UNICODE versions, the archive was updated to include some UNICODE specific functions (W-functions).
But unfortunately, this archive is not maintained many years in a central place.

I would like to start again with collecting all those handy WinAPI functions and constants and try to enhance the current set of declarations.
Many of us have developed applications and used API functionalities which are not present in the public archive and many UNICODE versions are only locally in use.
And to avoid that we all invent the wheel multiple times, it would be better if there is one central place to get a full set of ANSI and UNICODE declarations to be used as reference or directly in your own projects.

I wanted to create one archive with both ANSI and UNICODE declarations and not to split them up in separate ones.
The original old Win32Api archive and the unicode version from SalExtension was the basis for this new archive.
I also integrated declarations from a few samples.

The archive contains these files:

- WinApi32A.apl -> Main library for all ANSI WinApi declarations, it includes all the needed libs
- WinApi32W.apl -> Main library for all UNICODE WinApi declarations, it includes all the needed libs
- WinApi32_Functions_A.apl -> ANSI specific function declarations (A)
- WinApi32_Functions_W.apl -> UNICODE specific function declarations (W)
- WinApi32_Functions_x64.apl -> x64 specific function declarations (for 64 bit TD versions)
- WinApi32_Functions.apl -> Shared function declarations, not specific to ANSI or UNICODE
- WinApi32_Constants.apl -> Shared constants declarations, containing ANSI and UNICODE specific declarations
- WinApi32_CommonCtrlConstants.apl -> Shared common control constant declarations, containing ANSI and UNICODE specific declarations

Every file has it's own version info, so when changes are done it is added as history info in the file
The complete package has main version. When one of the files in the archive is changed, the version of the file but also the version of the package is increased.

To be source-compatible with TD versions starting from TD 1.5.1:
The common and ANSI (A) specific files are saved in TD 1.5.1 text format.
The UNICODE (W) specific files are saved in TD 5.1 text format.
The x64 specific files are saved in TD 7.0 text format.

Functions which are explicitly used for ANSI (A) or UNICODE (W) are saved in their separate libraries.
Many functions are common, so not specific A or W and they are in common libraries.

So when you need only UNICODE declarations (and all the rest not specific for UNICODE) you can use WinApi32W.apl
For ANSI (and the rest not specific for ANSI) you can use WinApi32A.apl.


As a start, the first version of the package is created . The latest and older versions will be placed in the TD Sample Vault here:

https://samples.tdcommunity.net/index ... =WinApi32/


I would like to ask developers here to participate in enhancing the WinApi Declaration archive.
There are probably many used WinApi functionalities out there which are not yet part of this archive.
When this is the case, please send changes/additions to me so I can combine the changes and create a new version of the package.
(probably best to only send me a file with the changed/added declarations so it is clear what to change in the archive.)
All changes will be added to the revision histories. Then the new archive is uploaded to the location mentioned above.

When current declarations are not correct, please report this.

By keeping the package up-to-date we will have a usable set of declarations ready to use in our projects. We all benefit.
It would be great if this combined effort will result in a comprehensive source for reference.

If you have suggestions, please share this here in this thread.

For additions/changes to WinApi32 declaration libraries, please send the file(s) to my personal email address:

daverabelink@xs4all.nl

[TerryP]

Great idea Dave

As with most developers, I've got my own version of a WinApi32.apl library, which I inherited years ago and have modified over the years, as required.

I've recently "converted" it to support the Wide (Unicode) calls for use with the latest TD versions, but only just for testing purposes at the moment.

I'll certainly download your new libraries and let you know if there's anything I've got in my libraries that's not in your new versions.

Cheers,

[H3PO4]

Thank you Dave,

I have downloaded your apls and will check them against my winapi.
Perhaps I can add sth...

Best regards
Henning

[Christof]

Great work Dave,

You will be getting some contributions from me soon!

Greetings
Christof

[markus.essmayr]

Hello Dave,

first of all ... GREAT IDEA!
I thought about that on my own but you were much faster!

What I wanted to do is not only to update the Exported Function declarations, but to additionally add Internal Functions that wrap the External Functions especially for string handling.
There are so many posts in the forums that describe UNICODE issues when calling Win API functions, so many questions about Sal(Str)Set- and -GetBufferLength. So I thought it might be a good way to keep the string-internals away from TD developers if possible as they basically shoulnd't have to worry about that.

So if you agree with my opinion, my contributions will target that area!

Max

[Dave Rabelink]

Max, GREAT IDEA!

You are right that having declarations is only the first step in having the functionality working in TD.
Most functions are 1:1, so calling them is straightforward. But as you said, having all kinds of string stuff could mean setting correct buffers etc etc.

So wrappers would be very nice which takes care of that.
Maybe new wrapper apl which includes the winapi libraries to contain all kinds of needed wrappers?

[MSchmidt]

wonderful idea

and lot of work.

so thanks advance.

M.Schmidt

[Dave Rabelink]

I have uploaded a new version with additional declarations, v1.01

https://samples.tdcommunity.net/index ... =WinApi32/

[Dave Rabelink]

I have uploaded a new version: WinApi_Declarations_v102.zip

Many thanks to Christof Helm for his contributions.

https://samples.tdcommunity.net/index ... =WinApi32/

[Dave Rabelink]

I have uploaded a new version with additional declarations, v1.04

https://samples.tdcommunity.net/index ... =WinApi32/

[Dave Rabelink]

When compiling the WinApi archive you might get compile errors.
Those are mainly caused by differences between Windows versions or different versions of the dll's.
Some functions or dll's are introduced in Win Vista or Windows 7 and are added to the archive.

Compiling on Windows XP or lower will get you compile errors on those functions or dll's.

Comment them out to fix this. If you want to use those dll's functions on the system WIndows OS which has compile errors actually mean you can not
use those features.

Here some examples:

GetFinalPathNameByHandleA and GetFinalPathNameByHandleW -> available starting from Windows Vista
dwmapi.dll -> available starting from Windows Vista. Probably is installed on older systems for specific Windows SP's

Compile errors on MSVCRT.DLL: this is a redistributable file (Microsoft runtime library) which exists in several versions depending on installed software, PATH settings etc.
When having compile errors, probably an older version of this dll is installed/found.

When having compile errors, you can check MSDN to see if a specific function or dll is present on the installed Windows OS you are using.

Example:
Information on GetFinalPathNameByHandle on MSDN in this link:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

WinApi_Info.png

There it states on which Windows OS version the function is supported.

Beware that when you use windows API functions in projects, the userbase of you application determines if the function works or not.
So building applications calling specific API functions introduced in Windows 7 on you development system will fail when it is installed and used on a Windows XP system for instance.
Always check the availability of those API functions at client side, by determining which Windows OS systems they use.

[Jeff Luther]

FYI, the compile errors Dave R. is writing about happen for me running WinXP. Here's a summary of what needs to be commented out if you will be running Dave's code (thanks from me too, Dave!) on WinXP:

File: WinApi32_Functions.apl
comment out:
* Library name: DWMAPI.DLL
* in ext. library MSVCRT.DLL comment out: Function: _localtime32

File: WinApi32_Functions_W.apl
comment out:
* in ext. library KERNEL32.DLL comment out: Function: GetFinalPathNameByHandleW

With these commented out WinApi32W.apl now compiles in TD v5.2. I only checked the "W" versions of his APLs, BTW.

[TerryP]

Hi Dave,

I was doing some work with UTC/Local time conversion in TD 4.1 last weekend, and needed to use the SystemTimeTzSpecificLocalTime and related functions from KERNEL32.DLL, but couldn't get them working correctly with the current Struct definitions (for uSYSTEMTIME) from library version 1.04.

After quite a struggle, I worked out that the individual date/time components (year, month, day, etc.) needed to be defined as WORD rather than as INT, and after that everything seemed to work okay. Thought you might like to check this out for yourself, and if necessary update the relevant function definitions in the next version.

I haven't checked out all the other functions that use uSYSTEMTIME, but the Get/SetTimeZoneInformation definitions also use INT instead of WORD. Interestingly, the FileTimeToSystemTime and TzSpecificLocalTimeToSystemTime function definitions already use WORD for the individual date/time components of their uSYSTEMTIME parameters.

Wouldn't it be great if the Structs could be defined separately, then just referenced in each external function definition, without having to re-define them each time!

Cheers,

[Dave Rabelink]

Hi Terry,

Yes, seems you are right. I have checked MSDN and looked at some other functions using SYSTEMTIME and how they are defined in the WinApi libs.

For now I could find these functions having the params defined as INT instead of WORD, as you said :

GetLocalTime, GetSystemTime, SetSystemTime, SystemTimeToTzSpecificLocalTime,
SetTimeZoneInformation, GetTimeZoneInformation

(but could be more)

I will change them in V1.05 !

Thanks for pointing to this.

PS
There is a nice sample showing the use of (local)time(zone) for files and system time:

https://samples.tdcommunity.net/index ... leTime.zip

But as you can see, the external function definitions are different here in some cases compared to the WinApi archive.
Instead of using a defined struct it uses a buffer and using cstruct functions on the buffer.

The suggestion from Max to supply also a library with wrapper functions (calling the WinApi) is definitely a good one.

As for the structs, yes it would be nice to be able to define structs and reuse them. I will post this as an enhancement request.

[Dave Rabelink]

I have uploaded a new version with some additional declarations and the fixes on functions using SYSTEMTIME, v1.05

https://samples.tdcommunity.net/index ... =WinApi32/