Headers update

[donkey]

I have uploaded version 0x021007 that contains some fixes to the problems that have been mentioned here and in other threads. The fixes are mainly to do with COM and the ability to make vTables. Here's the blurb from Windows.h:

This has changed in version 0x021007

IDISPATCH_DEFINED
IUNKNOWN_DEFINED

You no longer must define these two switches in order to avoid
symbol conflicts in COM interfaces. They are defined in windows.h
and the definition can be overridden by the USE_IUNKNOWN switch.
If you do not define them the syntax for COM interfaces changes for
IUnknown and IDispatch implementations of all COM interfaces:

******************
With USE_IUNKNOWN only the following is valid

IInterface.QueryInterface

When setting up your vTable use the following syntax to fill
the IDispatch structure:

vtable IDispatch <<1,2,3>,<4,5,6,7>>

******************
Without USE_IUNKNOWN both of the following are valid (default)

IInterface.IUnknown.QueryInterface
IInterface.QueryInterface

the USE_IUNKNOWN switch will enable the definition of the IUnknown and IDispatch
interfaces. These are needed for COM servers in order to build vtables. They are
not available if the switch is not used. This was done in order to avoid symbol
conflicts and still keep both syntaxes.

As a result of the changes the unknwn.h header has been deprecated and simply loads the BaseCOM.h header, IDispatch and IUnknown are only defined in BaseCOM.h, redundant definitions have been removed from all header files.

Edgar

[Yuri]

Thanks, Edgar! But I wonder why you still divided the alternative IDispatch into two parts? As they are unnamed, what purpose could it serve? After all the recent problems, I think the fewer levels of nesting, the fewer possible bugs (and also fewer brackets at initialization). The simpler, the better. As you have already said, it's not C++.  :wink

[donkey]

Hi Yuri,

I just prefer to separate them even though it makes little difference except in the declaration. Just a personal preference so it is clearer which parameter is which when I scan my code, makes for less counting parameters. No other reason than that and tests have shown that it performs exactly as expected so I saw no reason not to declare it that way.

Would be nice to have the header messages working again though...

Edgar

[donkey]

Uploaded an update to the headers, the current version is GOASMHDRVER = 0x021011, it includes a couple of new header files as well as some corrections. Also the api filter has been expanded to include the native API (ntdll.dll) versioned from Win2K to Win7. With Windows 7 the native API includes ordinal only exports for the first time, these have been included in a new header file called ntdll.h along with a few other undocumented structures and enumerations that might be useful. Still haven't begun work on user32.dll as far as versioning goes but hope to get to it soon as I have downloaded some excellent software that does a great job of comparing DLL exports (DiamondCS DLL Export Compare).

Edgar

[BlackVortex]

Awesome, thanks for your work !   :thumbu

[donkey]

Thanks much to BlackVortex for the files I was missing.

I have uploaded GOASMHDRVER = 0x021012, it contains a fairly complete API filter file comprising 3045 API functions that have been added or deprecated from Win9x to Win7. To use the filter you specify your minimum OS version and define the FILTERAPI switch. Windows.h will set the version numbers for the libraries covered to whatever version was shipped with the OS you specify, you can override the library version by setting its version number directly, see Windows.h and windef.h for examples. In the case of GDI+ and ComCtl32, you will have to set the version number directly if you are using SxS DLLs. I may add libraries to the list in the future (perhaps gdi32) but for now I'm a bit sick of it so I'm taking a break. The following libraries are included:

GDI+
User32
Kernel32
NTDLL (Native API)
Shlwapi
Comctl32
Advapi (only parts of this library are included)
Iphlpapi
Shell32

These should comprise the libraries that have the largest changes from one Windows version to another and should allow fairly accurate versioning when developing applications. The only caveat is that I did not bother to do any versioning below Win2K, that is that all of the Windows 9x versions have been lumped together and there is no distinction made between them. However if you specify any 9x version it will filter functions that are only available to Win2K+.

Edgar

[donkey]

A small interim update before the weekend, I have completed the advapi32 versioning. Added a new type (ENUM) and will soon begin to update all the headers to reflect the new type, I think that it will make it clearer when reading a structure and trying to find the type of data that it requires (all enums are defined using name=value while constants use #define name value). Added a few structures to some files and added some new headers (security related).

EDIT: Just realized I forgot to merge the GDI32 api filters into the main distribution, I have just uploaded again with the updated API_Filter.h file that includes GDI32 filters up to Vista, since my laptop is out of commission for a while and it was the only Win7 box I had I don't have a copy of GDI32 for Windows 7 and couldn't version that DLL.

Edgar

[donkey]

GOASMHDRVER = 0x021014 has been uploaded, it contains the complete DirectShow headers along with DirectSound and a few updates to some other headers. Also added are the external device headers for controlling things like VCR's and DVD's as well as the headers for WPC (Windows Parental Controls), Windows Event Tracing and the MacIntosh Win32 code porting header. The only note for the added headers is for strmif.h:

NOTE:

The VMRGUID structure has the following change:

The member VMRGUID.GUID has been changed to VMRGUID.guid to resolve a conflict with the GUID structure

Also available are the internal GDI direct draw functions which are exported as GdiEntry(x), the headers will translate them to the documented names automatically (i.e. DdCreateDirectDrawObject). Usage for the functions is available here, the following functions are supported:

Code Select Expand

DdCreateDirectDrawObject
DdQueryDirectDrawObject
DdDeleteDirectDrawObject
DdCreateSurfaceObject
DdDeleteSurfaceObject
DdResetVisrgn
DdGetDC
DdReleaseDC
DdCreateDIBSection
DdReenableDirectDrawObject
DdAttachSurface
DdUnattachSurface
DdQueryDisplaySettingsUniqueness
DdGetDxHandle
DdSetGammaRamp
DdSwapTextureHandles
DdChangeSurfacePointer << undocumented

Edgar

MILESTONE: The header project has now passed 5 MB, consisting of 395 files.

[donkey]

I have uploaded version 0x021016 to my website, it contains the following changes:

PROPVARIANT structure added to propidl.h
Correction to the VARIANT structure for Win64, bstrVal is now defined as a PTR
Filter api added
Structured Query api added
Windows Desktop Search api added
Corrections to various structures (note that I may not have caught them all)
Corrections to Win64 DLL names (this problem was due to some tests I was running and was uploaded in error)
macros.a has been removed from the distribution (this file has been deprecated for some time)

It should also be noted that the error in the structures only occurs when the DUP operator is used, see E^cube's post for further information.

Note that as of this version macros.a is no longer in the distribution, use macros.h instead.

Edgar

[Dharam]

After a long gap from Assembly Language programming, I made a long visit to "Donkey's Stable".  I was very impressed with what I saw.

Thanks.

[donkey]

After a long gap from Assembly Language programming, I made a long visit to "Donkey's Stable".  I was very impressed with what I saw.

Thanks.

Well thank you very much Dharam, I'm glad you like the code and hope you might find some useful or at least helpful.

Edgar

[Yuri]

Hi, Edgar

For APIs like DialogBox that are actually macros, I thought it might be useful if they resolved into something like DialogBox_IsMacro. Or even, for more clarity, DialogBox_IsMacroForDialogBoxParam?  :lol

These are in winuser.h:

DialogBox —> DialogBoxParam
DialogBoxIndirect —> DialogBoxIndirectParam
CreateDialog —> CreateDialogParam
CreateDialogIndirect —> CreateDialogIndirectParam

[donkey]

Hi Yuri,

We have discussed incorporating these types of macros in the past...

http://www.masm32.com/board/index.php?topic=11130.msg91477#msg91477

I will consider adding them but I tend to leave these types of macros for each person to write and use themselves, that way they have control over any code generation and can more easily track down bugs.

Edgar

[Yuri]

Hi, Edgar

No, I didn't mean writing any macros, only clarifying the situation. When GoLink could not find DialogBox, it took me some time to figure out that DialogBox isn't actually a function and isn't exported by any Windows DLL.

I meant the same as what is done by API_Filter.h:

Code Select Expand


FlatSB_EnableScrollBar_NotAvailable

If someone tried to call DialogBox in his code, I think it would be good if he saw something like:

Code Select Expand


Error!
The following symbol was not defined in the object file or files:-
DialogBox_IsMacroForDialogBoxParam


That would help him understand what is wrong and what to do.

Although I'm not sure, maybe DialogBox and the other three were real functions on some previous Windows (I am using XP)?

[donkey]

Hi Yuri,

This could easily be done through the API filter header, if you will submit a list of the API's you want warnings for I will add them to the next update.

Edgar