#2226 Missing Win API functions (GetDynamicTimeZoneInformation)

[Thund]

Hi together, I have found that there is, at least, 1 missing Windows API function declaration in the Windows SDK that comes with MinGW 4.8.1; concretely GetDynamicTimeZoneInformation (and the type DYNAMIC_TIME_ZONE_INFORMATION), in WinBase.h. The function exists in the static library (libkernel32.a) so I have declared it in my code (besides the mentioned struct) and it works.
Just in case it's useful for you, I am using Windows 7 64 bits (although compiling to 32 bits) and CodeLite 6.0.1, with the mentioned version of MinGW 4.8.1 (without changes).

Are you planning to add these declarations in the header file?

Thanks in advance for all your work, and sorry for may bad classification of this ticket, it is the first time I use this ticket system.

Regards.

[Keith Marshall]

Are you planning to add these declarations in the header file?

Not in the short term, but we will certainly consider it if you care to submit a patch. If you do so, please ensure that you support it with references to appropriate MSDN documentation, (but not to any Microsoft SDK sources, from which you must not copy, nor abstract any information).

The function exists in the static library (libkernel32.a) ...

That is not a static library; it may have been better named as libkernel32.dll.a, but it is an import library for kernel32.dll

[Thund]

...submit a patch...

I will try to send it, it seems to be a very simple piece of code.

...you support it with references to appropriate MSDN documentation...

You mean writing the references along with the patch or in the code's documentation?

That is not a static library...

Yes, I know, thanks for the clarification anyway.

Thanks for your responses.

[Keith Marshall]

...you support it with references to appropriate MSDN documentation...

You mean writing the references along with the patch or in the code's documentation?

Listing all that apply, on this ticket, is sufficient, although including them in the ChangeLog entry, which you write to support your patch, would also be useful. If you are writing a separate implementation file for a specific feature, then it's also good to include the references, in the form of comments within it, but in the case of header files covering multiple API features, adding references for everything creates too much clutter, so better just leave it in ChangeLog, or on the ticket.

When you do write the ChangeLog entry, be sure to include a reference to the ticket. This needn't be a full URL; the ticket number will suffice.

[Christopher Yeleighton]

And InitializeCriticalSectionEx; this breaks nspr build.
If we are not allowed to use information Microsoft headers, how do we go about telling what the definition of CRITICAL_SECTION_NO_DEBUG_INFO should be? It is undocumented, but neither is the definition of SP_SERIALCOMM which you define nevertheless.