Headers 2.0

[donkey]

Headers 2.0 is now in beta.

I have completed the first round of translation and correction, this concludes the more or less automated part and the manually combing through the header files. I have tested the headers with some of my older 32 bit software and no code is broken so I am releasing the headers as the beta. It now replaces the older 32bit only version of the headers. Major changes from the last alpha release include wingdi.h and shobj.h which underwent extensive editing, there were also changes to winuser and commctrl. I went through a lot of structures to make sure they adhere to the new types defined in windef.h and would transparently change over to 64 bit when the WIN64 flag is specified. I am currently a little bug eyed from staring at header files day after day for the last couple of months so I am relying on the GoAsm community to find a few bugs while I take a break.

The current version on the website is 0x020000, it will start to increment with this version.

Notes from the alpha thread (which is closed)

You should always set the target Windows platform, the headers will default to Windows XP SP0 if none is set. The definitions for versions is found in windef.h

example : WINVER = NTDDI_WIN2K

The Windows version must be set before windows.h or any header file is included.

Win32 is default, to switch all structures and definitions to 64 bit define the WIN64 switch:

#DEFINE WIN64

WIN64 must be set before windows.h or any header file is included.
Attempting to use WIN64 with an OS version that does not have 64 bit support will show a warning message, for example attempting to build 64 bit code for Windows 9x, 64 bit support begins with Windows XP.

Many structures have been updated to include resizing based on the Windows version, if you do not specify a version number your application may fail on some OS versions due to the cbSize member. Specifying a version number too low will result in any members for higher versions being unavailable and will throw an error if referenced. This is by design in order that the SIZEOF operator will return the correct cbSize for the specific OS version.

GoAsm.Exe Version 0.56.5c or greater is required
GoLink.Exe Version 0.26.10 beta3 or greater is required

Edgar

[ecube]

fantastic! do you have a link somewhere? and can you sticky it.

[donkey]

Hi E^cube,

The headers project on my website, the main headers.zip is now version 2.0, the older headers are no longer available from the website.

http://www.quickersoft.com/donkey/index.html

I should also note that it is a good idea to include the following in your code after windows.h

Code Select Expand

// Minimum header version
#IF GOASMHDRVER < 0x020000
GOASM_ECHO This program requires headers version 2.00.00 or greater
GOASM_EXIT
#ENDIF

That way if anyone tries to build it with an older version of the headers it will fail with an error message.

[donkey]

Version 0x020001

This is an incredibly minor update, I cleaned up the Shell32 and CommCtrl32 versioning for imports by ordinal, windef.h now has the version numbers supported, see windows.h for usage. Also moved the definitions for Unknown and Dispatch to their own file and included it with the COM interface definitions, this was primarily to make it easier to modify later but also saves a few KB. Finally there were a few OS version checks in commctrl.h that were still using the old scheme, they have been updated.

A small note about data types:

Since the start of version 2 I have employed data types in order to make the switch to WIN64 possible. You can use these data types in your data section but not as LOCALs. I find they can make code much more readable, for example

Code Select Expand

DATA SECTION
test0 TCHAR 40 DUP (?) // define a text character DW for unicode DB for ANSI
test1 DOUBLE 1.1 // Define a DOUBLE (DQ)
test2 FLOAT 0.1 // Define a FLOAT (DD)
test3 LPARAM 1 // Define an LPARAM, DD for WIN32, DQ for WIN64
test4 HANDLE ? // Define a HANDLE, DD for WIN32, DQ for WIN64

Using these data types will allow switching apps to WIN64 to be a little smoother and require less editing. For example if you use LPARAM in your WIN32 application and later decide to build it as a 64 bit version no editing of the DATA SECTION will be necessary.

Edgar

[donkey]

I've been thinking about a way to allow LOCALs to be typedef'ed in order to have the size of the LOCAL change dynamically based on the WIN64 switch. It is possible to declare them as structures and use them in a procedure as normal variables. For example:

Code Select Expand

#IFDEF WIN64
%HANDLE STRUCT
DQ
ENDS
#ELSE
%HANDLE STRUCT
DD
ENDS
#ENDIF

Code Select Expand

TestLocal FRAME
LOCAL hEdit:%HANDLE

mov [hEdit],eax

RET
ENDF

Works but since I am not interested in enclosing data in the data section in braces (<>) I will not give up the existing type defs. However, if everyone is comfortable with using the % prefix when declaring local variables I will include it in the next update. Or if there is another suggestion post it here.

[ecube]

That's interesting maybe you can do

Code Select Expand


TestLocal FRAME
LOCAL hEdit:$HANDLE

mov [hEdit],eax

RET
ENDF


[donkey]

$ is already used in GoAsm for the location counter and also for ordering sections (CODE SECTION 'Asm$b'), I did not want to cause any confusion so I chose % which I already use for macro locals and arguments anyway.

$ - means the position at the point of use in memory in the executable as loaded by Windows

you can instruct the linker to order the individual raw data components in a certain way by using a $ suffix in the name of the section

[BlackVortex]

Is STD_OUTPUT_HANDLE defined somewhere ? I did a search and didn't find it in any of the files.

[donkey]

Is STD_OUTPUT_HANDLE defined somewhere ? I did a search and didn't find it in any of the files.

It is defined in winbase.h, that file is included as one of the minimum requirements so you should have it available for use if you include windows.h

The docs at MSDN are all you need with my headers. From GetStdHandle

Header: Winbase.h (include Windows.h)

[BlackVortex]

Yes, I got it working now (with #include winbase.h)

thanks

[donkey]

Hi BlackVortex,

Is there a reason you did not want to include Windows.H ? It does not add any code so there is no bloating problem, though it can slow down assembly time marginally (~2 seconds more on average). Also you should always include windef.h, the headers rely on it being loaded in order to make sense of the type defs in structures.

Edgar

[donkey]

I have uploaded version 0x020002

Mostly fixes to obscure structures in headers no one ever uses. However, I have included the %type's for local declarations, there were no objections (only one suggestion) so I am making them a permanent part of the project. To test the usage I redid Help2 Viewer as I said above and using GoAsm.Exe Version 0.56.5h which has the bug fix for repeating structures in locals, I assembled and ran it without a problem. It works as demonstrated in the post above, the advantage is that when doing a dual version (32 and 64 bit) you can have all global and locals sized dynamically based on the WIN64 switch.

[BlackVortex]

Hi BlackVortex,

Is there a reason you did not want to include Windows.H ? It does not add any code so there is no bloating problem, though it can slow down assembly time marginally (~2 seconds more on average). Also you should always include windef.h, the headers rely on it being loaded in order to make sense of the type defs in structures.

Edgar

I'm just at a total loss with goasm, that's why   :lol

Now I use :
#include windef.h
#include windows.h

Is that correct ? And I have added the folder with your header files to the INCLUDE environment variable, so now it assembles fine.

[donkey]

HI BlackVortex.

windef.h is always loaded as part of windows.h since along with winbase.h it comprises the minimum includes allowable. It will probably result in a duplicate warning message from GoAsm if you include yourself it though it won't hurt anything since conditional assembly will not allow it to be processed more than once. There is a lot of information regarding usage in the windows.h file, reading it will solve a lot of problems before they arise.

Edgar

[ecube]

Donkey,
nice work, when testing a ProcessIDtoName function I wrote it complained about the toolsnapshot stuff not being defined, which I fixed by including a addition .h. Do you think it would be more practical to just all .h's included  in the windows.h so developers just need that one line? i'm assuming GoAsm doesn't add into your pe file anything not actually used, so is there any downsides to including everything?