News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Headers 2.0

Started by donkey, March 30, 2009, 02:14:02 AM

Previous topic - Next topic

BlackVortex

AHA !

You are correct, I had to create an INCLUDE variable and give it the value of the include path. The PATH variable wasn't the right one. All fine now ! Thanks !

P.S.: I didn't really *need* a screenshot to understand your point   :toothy

dedndave

lol
i put a pic up, because some people try to set them at the command line, which only lasts until you close the console

donkey

Finally got around to downloading and installing the Windows 7 SDK today along with a whole new set of header files. This is going to take a while but I hope to have something usable before the projected release date of Oct 22 (I think). Hopefully this time we'll be all set up and ready to run with it by the time it becomes generally available. I am once again going to post a few files for the group to translate once I am finished looking through them.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

BlackVortex

Up until now, I'm just using this line in my sources :
#include windows.h

Is there any reason to specify a platform ? I don't really get it. I mean, I am on win7 64bit, and I'm assembling 32bit programs.

I see the defines for different OSes, but how do I really "select" one ? Is it best to just do nothing and let the XP ones be active by default ? I don't care for pre-XP compatibility.

What other options do I have ?

ecube

win7 has a few new functions I believe aren't present on vista, so some addition struct defines etc are needed but other than that I don't see any benefit for trying to replicate all the new .H's. 64bit versions ofcourse, as that's the future.

donkey

Hi,

Well, there areĀ  a few instances where defining WINVER can be important. For example when using the GetFileInformationByHandleEx function, not specifying a Windows version will result in the default value of NTDDI_WINXP being used and the headers will redirect the API to a static library, using NTDDI_VISTA will cause the OS resident DLL version to be used. Beyond that many structures are expanded dynamically based on the WINVER value, take the following example from shellapi.h;

NOTIFYICONDATAA STRUCT
cbSize DD
hWnd HANDLE
uID DD
uFlags DD
uCallbackMessage DD
hIcon HANDLE
#IF WINVER < NTDDI_WIN2K
szTip DB 64 DUP
#ENDIF
#IF WINVER >= NTDDI_WIN2K
szTip DB 128 DUP
dwState DD
dwStateMask DD
szInfo DB 256 DUP
UNION
uTimeout DD
uVersion DD
ENDUNION
szInfoTitle DB 64 DUP
dwInfoFlags DD
#ENDIF
#IF WINVER >= NTDDI_WINXP
guidItem GUID
#ENDIF
#IF WINVER >= NTDDI_VISTA
hBalloonIcon HANDLE
#ENDIF
ENDS


The structure changes radically and even szTip's size changes based on which Windows version is specified. For this (and a couple of things that will eventually be added to the headers) I recommend that WINVER is always specified. Eventually Microsoft plans to retire certain API functions, especially the legacy functions, the headers will accommodate this change by making them unavailable based on Windows version as follows:

#IF WINVER >= NTDDI_WIN7
#define lstrcpyA deprecated_lstrcpyA
#define lstrcpyW deprecated_lstrcpyW
#ENDIF

#IFDEF UNICODE
#define lstrcpy lstrcpyW
#ELSE
#define lstrcpy lstrcpyA
#ENDIF


Ofcourse lstrcpy is not likely to be retired but many API functions will be and the headers should be capable of catching them.

For the Windows 7 headers, I am concentrating on the headers that are loaded by Windows.h, the others can come a bit more slowly,

Edgar
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

BlackVortex

Hehe, I understand that MS changes some structures as the APIs evolve, but are they backwards-compatible ?

In other words, do I set the WINVER as my current OS, or as my minimum target OS (xp) ?

And if I were to use it, would it be like this ?
#define WINVER NTDDI_WIN7

Also, what's the deal with NTDDI_WIN7ALL ? Does it contain both 32 and 62 definitions, for use in 32/64 goasm code ?

donkey

Quote from: BlackVortex on September 21, 2009, 01:30:16 AM
Hehe, I understand that MS changes some structures as the APIs evolve, but are they backwards-compatible ?

In other words, do I set the WINVER as my current OS, or as my minimum target OS (xp) ?

And if I were to use it, would it be like this ?
#define WINVER NTDDI_WIN7

Also, what's the deal with NTDDI_WIN7ALL ? Does it contain both 32 and 62 definitions, for use in 32/64 goasm code ?

WINVER will default to NTDDI_WINXP if none is specified so there is no need to explicitly set it if that is your target OS. Most structures are backwards compatible however newer functionality will not be available. All of the NTDDI_ constants are defined in windef.h, to use Windows 7 specifically you would as you mentioned use

#define WINVER NTDDI_WIN7

The NTDDI_xxxALL definitions are used to include every version of the OS defined (for example all service packs) though they are not used by my headers and I wouldn't recommend using them. The WINVER switch has no affect at all on whether 32 or 64 bit versions are used, that is handled by the WIN64 switch:

#define WINVER NTDDI_WIN7 ; Minimum OS version is Windows 7
#define WIN64 ; Use 64 bit structures and definitions
#include Windows.h


I should note that the headers can't be designed for a single coder to use, there are many many features in them that I don't use and have no intention of using but include because they would be incomplete without them. In the final analysis the headers must meet all reasonable demands put on them and so that's my goal.

Edgar
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable