The MASM Forum Archive 2004 to 2012

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

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

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

// 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.

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

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

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:

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

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.

That's interesting maybe you can do


TestLocal FRAME
LOCAL hEdit:$HANDLE

mov [hEdit],eax

RET
ENDF


$ 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.

Quote from: GoAsm manual$ - means the position at the point of use in memory in the executable as loaded by Windows

Quote from: GoAsm manualyou 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

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

Quote from: BlackVortex on March 31, 2009, 06:21:07 PM
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 (http://msdn.microsoft.com/en-us/library/ms683231(VS.85).aspx)

Header: Winbase.h (include Windows.h)

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

thanks

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 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 (http://www.masm32.com/board/index.php?action=dlattach;topic=11142.0;id=6048) 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.

Quote from: donkey on March 31, 2009, 09:51:29 PM
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.

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

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?

Hi E^cube,

Well, one of the original goals, way back when wjr and I were discussing this project was that I separate the defines to allow for reduced assembly times and less stress on GoAsm's symbol engine. Through switches and not loading every definition it allows us to have any number of definitions without having too adverse an effect on the size of symbol table GoAsm has to build and manage. In reality the standard set of definitions as they stand now are only a few MBs but I am hoping that as more users are attracted they may begin to translate other headers as they need them and grow the project. The first 300 or so I did pretty much alone, but there are around 1200 header files representing some 60MB (C++, probably around 15MB for GoAsm) in all. Though I have no objection to an "includeall.h" type file, I think that windows.h should remain as is for a stripped down set of headers that follow the docs at MSDN. One feature of the headers I was shooting for was that if you read an entry at MSDN and it says include Windows.h then that is all you have to do, if it says (as is the case for say TASKDIALOGCONFIG) to include commctrl.h then that's what you do, simple and directly in step with the documentation we all use.

For the most part the design goals of the header project were set up in discussions before the first header was translated, some of them may seem a bit irrelevant now that the project is more mature and I am always willing to listen to suggestions or at least explain the rationale behind the way it is structured. The idea of a specific set of goals was something that I wanted from the get go and Wayne (wjr) and I discussed it at length, this was to avoid what I perceived as a mess in windows.inc for MASM32 and for GoAsm (which was translated from Hutch's file).

I will make an includeall.h file for the next release, it will replace windows.h for those who want to avoid tracking down specific header files. There are some compatibility issues that have to be worked out but they are minor and shouldn't require much head scratching.

Edgar

sounds great, yeah I like the modulation of how you did things, do you think it would be easier/possible to add a switch in the windows.h that allows including all? Or even really just include the most common? vs's a whole new .h

#DEFINE INCLUDEALL

#DEFINE INCLUDECOMMON

or something of that nature?

Hi E^cube,

Yup, I like your idea better, I will implement it in the update. For INCLUDEALL it's a no brainer, for INCLUDECOMMON we will need a consensus on what should be included.

Edgar

Hello,
well user32,kernel32,advapi32 are used in most programs, but perhaps ws2_32,msvcrt,wininet can be added, or not, you're right in it being somewhat tricky to decide what goes in that or not, if you don't want to add that one or want to add different ones thats fine, but the includeall would be fantastic!

INCLUDEALL is almost complete, lots of typing to eliminate duplicate files but it will be done tomorrow. Actually it helped find 3 errors in some pretty obscure files that I would never have caught otherwise except by testing in such a high load environment so it has already paid for itself :)

Outstanding! looking forward to it :) i've been working on a nice GoASM SDK, That includes everything I wish masm32 did,along with your great headers, etc... am releasing tommorow and should really highlight the power that is GoASM. I'm converting the masm32.inc right now my approach is automated but is going to be something like

MASM32 = C:\GoAsm\Lib\masm32.lib
szLower = MASM32:szLower

so they can just invoke szLower after including the header. what do you think?

Great idea E^cube,

There are however some functions which I have problems with in MASM32, mostly those that use a spinlock for checking whether an application has terminated as opposed to the wait functions. I have had this debate with Hutch numerous times and have pretty much given up arguing about it. I think for now a patch allowing GoAsm user to access the functions in MASM32 is fine, however I think you should look into building a separate library that contains better written and more robust functions. I have not looked into my libs for quite a long time, if you like you can use them as a starting point, they would have to be converted to work with the headers and brought up to date but the functions are robust and more closely follow the caveats at Microsoft.

In the final analysis GoAsm code for GoAsm users is always the best approach.

Yeah I didn't see a point in converting the lib right now as it's for 32bit only, and is easy to use if you just precompile. I know when I and others start converting it to GoASM the code should be both 32bit and 64bit compadible(which will be pretty much transparent using some of the neat stuff from your headers) but that'll still take time as they're quite a bit of functions. Right now I think getting this SDK out is more important as it gives newcomers a great place to start, like they have with MASM32.You did a fantastic job with your headers, Jeremy did a fantastic job at his documentation, and his tools ofcourse but his example are kinda lacking, and aren't as "pretty" nor complete as one can hope for. Nor is all of his or your great up to date work combined anywhere besides in a minalmist way. This is where I come in :)

and thanks for your permission in being able to include your libraries code. I used some of your other code and macros in examples aswell(full credit ofcourse)

New upload (GOASMHDRVER = 0x020004)

Still having some issues with INCLUDEALL but there were a few critical issues that needed fixing so there is an interim upload. I ham having problems with the #dynamiclinkfile directive when using the INCLUDEALL switch, I keep getting errors indicating that the filenames are not good but they definitely are (kernel32.dll is obviously alright). I am trying to find out the circumstances under which it occurs in order to report the bug to Jeremy but it is not consistent. However, there are many corrections to the headers and I have included the http headers though I am still working on the supporting files the headers were already incorporated into my own so rather than remove them I decided to leave them in, the ones I am working on are not included in the archive.

Edgar

Very nice,
i've been swamped at work, but if I don't get the preprocessor code done within next few days i'll go ahead and reupload the SDK with your new headers and some new examples i've written. If you get the includeall working after Jeremy takes a look at the DLL's that'd be fantastic. Users can just add that switch and not worry about non-standard includes, GoASM is so incredibly fast I don't forsee any noticeable performance hit you suggested from the extra parsing/interpreting. I was thinking of adding some support to the preprocessor that are based off your header switches, so for instant if the preprocessor sees #Define WIN64 in the source it'll automatically have GoASM assemble as 64bit. #Define Console or similar assemble as console etc...unless otherwise specified in the build.bat passed options. This way users can use the same build.bat for everything and have it assemble correctly. But that's just a minor thing.

Uploaded headers version 0x020006

A few minor corrections, added a couple of header files. Nothing really major in this release just thought I would make sure that everything was up to date since Jeremy and E^cube also had updates. The only major difference is that the non-standard headers must now be explicitly included, previous versions required that they be explicitly excluded. The NODONKEY, NOZLIB and NORADASM switches are deprecated and replaced by INC_DONKEY, INC_ZLIB and INC_RADASM respectively, there may be a few cases where code needs to be modified to accommodate the change. This change reduces the standard include directives to :

#DEFINE LINKFILES
#DEFINE WIN32_LEAN_AND_MEAN
#include "WINDOWS.H"

Which will assemble and run most Windows applications. The INCLUDEALL switch should now be functional with the new version of GoAsm. The example files on my website have had their headers modified to reflect the change, no point in downloading them just for that as the older switches have no effect now anyway and they don't use the new ones. I have added the zLibstat.lib file to the headers since I think the header file I have for it is version specific and I want to make sure the lib used is the one it has been tested for. If anyone has a copy of zilbstat 1.2.3 I would appreciate a copy the best I can find is 1.2.1.

Edgar

Thanks Edgar, the effort is appreciated.

GOASMHDRVER = 0x020008

Ramon Sala pointed out that the mmsystem.h file did not switch some structures to unicode when the unicode switch was used, this is fixed in the current version.

Edgar

 :U
perfect!

I just got the 2.0 headers since ive been using the older version, but am I not supposet o use IncludeA anymore for the windows.inc? And not include windows.h? Because if I try to use windows.h it errors everytime saying error including baseCOM.h and some line on 75 of winnt.h

Now I tried just using this


#DEFINE LINKFILES
#DEFINE WIN32_LEAN_AND_MEAN
#include "WINDOWS.H"

and now goasm gives me a error saying "Error no data or code in the assembly file found" or something along those lines.

Guess ill just stick to the old headers.. :'(

This is a GoASM issue, not the headers, GoASM needs a entry point, by default it assumes it's start so do

#DEFINE LINKFILES
#DEFINE WIN32_LEAN_AND_MEAN
#include "WINDOWS.H"

CODE SECTION
START:
;your code

invoke ExitProcess,0 ;optional clean exit


If you want to get started with GoASM I recommend you checkout the older SDK I put together at http://www.masm32.com/board/index.php?topic=11180.0
it has quite a few 32bit/64bit examples that come with build.bat's.

Yeah, I have exactly that. I can make any other program with the old headers but as soon as I change the includes to what you have there  I get there error. So I dont know what it is :\

try building with

build.bat

set INCLUDE=C:\GoAsm\include

\GoAsm\bin\GoAsm /x86 sourcename.asm
\GoAsm\bin\GoLink sourcename.obj
pause


Worked perfect! Thank you! Finally something works now lol  :dance:

Hi travism et al,

Sorry I didn't have a chance to answer I am quite busy at work right now, glad you got it worked out.

GOASMHDRVER = 0x020009

Added CHOOSECOLOR structure to unicode switches (Thanks Ramon). Added a WIN64_LEAN_AND_MEAN switch that functions exactly like WIN32_LEAN_AND_MEAN except it turns on 64 bit support. WIN32_LEAN_AND_MEAN will now disable 64 bit switches if any.

Edgar

Thanks Edgar, your support is appreciated.

Curious, this from the RadASM templates, is no longer needed, correct?

// NOTE: INCLUDE Environment variable must be set to headers path
// Kludge for goasm bug
#DEFINE IDISPATCH_DEFINED
#DEFINE IUNKNOWN_DEFINED


Not actually a bug in GoAsm, though I originally treated it as such, the new templates have "symbol conflict" instead of "bug". It is only needed if you are going to use any COM headers since IUnknown and IDispatch are both actual interfaces but are used as structure member names in all COM headers as well. Once you define those two symbols the raw IUnknown and IDispatch interface structures are no longer available but it allows for IPersistFile.IUnknown.Release syntax which I decided was a fair trade-off. I generally include them in all my programs since I make extensive use of COM.

Oh, I didn't see there was a separate section for RadASM support downloads. :bg I need glasses, really.

Since the above is statically defined in Windows.h it is redundant to redefine it. I'm experimenting with something like this as a template header:

// Headers by Donkey http://www.quickersoft.com/donkey/index.html
// NOTE: the INCLUDE environment variable must be set to headers path

#DEFINE WIN32_LEAN_AND_MEAN // Include minimal set of common defs only

#DEFINE LINKFILES // Passes the appropriate DLLs to GoLink
//#DEFINE LINKVCRT // Include MSVCRT.DLL in functions list
//#DEFINE C99HDRS  // Include the C99 hdrs, use with LINKVCRT
//#DEFINE CCUSEORDINALS // Access common controls by ordinal
//#DEFINE ODBC_STD // Standard ODBC definitions
//#DEFINE X86USEUNDOC // Use undocumented opcodes

#DEFINE NOCARD  // No SmartCard Subsystem definitions
//#DEFINE NOCON // No Console subsystem definitions
#DEFINE NOCRYPT  // No Cryptographic API definitions
#DEFINE NOGDI // No GDI Module definitions
#DEFINE NOGDIPLUS // No GDI Plus definitions
#DEFINE NOIME // No Input Method Manager definitions
#DEFINE NOMCX // No MCX API definitions
#DEFINE NONETWORK // No Network definitions
#DEFINE NONLS // No NLS component definitions
#DEFINE NOOLE // No Linking and Embedding API definitions
#DEFINE NOREG // No Registry API definitions
#DEFINE NOSERVICE // No Service Control Manager definitions
#DEFINE NOTV // No TV definitions
//#DEFINE NOUSER  // No User Module definitions
#DEFINE NOVER // No version management definitions

#DEFINE NODONKEY // No Donkeylib definitions
#DEFINE NORADASM // No RadAsm plugin definitions
#DEFINE NOZLIB  // No Zlib static library definitions

#include "WINDOWS.H" // Main Windows definitions
#include "Commctrl.h" // Common Controls definitions


Edit: Also, somehow "@$B\GFL.txt" seems to have persevered throughout some of the RadASM template command-lines. I'm working on cleaning those up.

Sounds good Mark, yes, a few things slip by even though I try to get them all.

For the header, NODONKEY, NORADASM and NOZLIB are deprecated and no longer necessary, I neglected to remove them from the comments section. You're right I had not noticed that I defined them in windows.h, that one got past me...

Here are the template masters that I use...

[attachment deleted by admin]

Thanks.

I just thought about "porting" any additions I had made to my RadASM's masm .API files to the GoASM versions, and discovered several hundred discrepancies. For instance:

(http://img223.imageshack.us/img223/6274/goasmsapisradasm.th.png) (http://img223.imageshack.us/img223/6274/goasmsapisradasm.png)

Here is a tiny part of a comparison between the two. Looking up "WriteClassStg" in Win32.hlp for instance,

QuoteWriteClassStg: Stores the specified CLSID in a storage object.

HRESULT WriteClassStg(

    IStorage * pStg,    //Points to the storage object
    REFCLSID rclsid   //Specifies the CLSID to be stored in the storage object
   );

Here "rclsid" is missing from the GoASM API entry definition but not MASM's. There are hundreds of these, all missing the final value...

That would be a great idea, I had noticed this too but was preoccupied with the header project and didn't do anything about it. It should just be a renaming of the api file as far as I can remember. The big task is to rebuild the struct file which has many incompatible structures in it since the header project follows MSDN member names and not the MASM ones (ie struct.cx instead of struct.lx). I had planned on doing it one day but never seem to get the energy to tackle it, perhaps an automated approach would be best for that particular file.

Attached is what I came up with quickly merging the MASM and GoASM .API files. They additionally contain defs for GDI, GDIPLUS, OpenGL, sDraw, and a line or two of SDL (all these entries are at the end so can be accessed easily.) I also renamed and included the "masmType.api", although it is unclear if this is even utilized. As usual, there is a significant probability for bugs. :toothy

I think you're right about the structure definitions, an automated approach is needed. One readily visible difference is anything with a "mask" element---MASM always defines them as "imask" or "_mask" or similar (to avoid a conflict assumedly) while GoASM does not seem to have that limitation.

[attachment deleted by admin]

Hi Mark,

Automating the struct file is the only way I can see to get it complete and correct. It is a difficult task however since there are some pretty complex structures in the headers, far too much for me to take on during the busy time at work. If some-one can take it on and build a decent file (hopefully with the COM structures as well) then I will upload it to my site and we can ask Ketil to include it in the distribution of RadASM.

Yeah that's a little above me also. Been rebuilding my box after a drive failure. Good news is, finally installed 64-bit XP. Things are mostly working, so if everything goes well, hopefully I can come up with some 64-bit templates. Should be fun... wish me luck. :bg

I'm still working on the updated templates, and have ran into a quandary. For 32-bit applications on a 32-bit OS, OllyDbg seems to be a good contender as a blanket "$E" RadASM (GoASM.ini) definition. However, OllyDbg will not run on a 64-bit OS, so it therefore cannot be used as "$E" in all cases. Trying to make the templates 64-bit compatible, this is proving to be an issue.

I cannot see a good solution to this in terms of a template, because each template defines the command explicitly and statically. I considered if "$E\Debug.exe,5" were used instead, and the user renamed their 32 or 64-bit debugger executable to "Debug.exe", but this still does not address the issue that RadASM does not know if the user is on a 64-bit OS or not, and does not know that only certain debuggers will work in 64-bits.

Perhaps what is needed is an additional debugger definition in RadASM, "$64" lets say, which points to the 64-bit debugger. Also, define (under [Paths] in GoAsm.ini) "$E" and "$64" to include the filename, i.e. "$E=\Coding\OllyDbg\OllyDbg.exe". Then, for an added touch, have RadASM determine upon startup, if the user is running on a 64-bit OS, and define "$debugger" as either "$64" or "$E"... therefore, "$debugger,5" will work in all templates, for all users, and they must only define the paths to their debuggers in GoAsm.ini.

Does this sound like a good proposition to ask KetilO to consider?

Quote from: Mark Jones on May 28, 2009, 02:58:18 PMHowever, OllyDbg will not run on a 64-bit OS,

It does so on Vista64 at least. Of course not for x64 processes, but for x86 ones.
Sry I don't know about XP64, but in any case you would need this olly plugin:
http://www.tuts4you.com/download.php?view.2425

cheers

For the next few months I have to set the headers project aside while I concentrate on work. I will still be sure to correct any errors brought to my attention but new header files are pretty much out the question for a while. If anyone wants to contribute to the project I will add their headers to the main project once they are posted here and vetted by the group. The rules are simple, follow the naming conventions at MSDN as closely as possible and also the conventions already established in the header project. This is mainly so we don't end up with a mish-mosh of different naming standards and file names. If you are uncertain as to how to implement a certain header just post your questions and ideas here for group discussion. Since the header project is now the "de-facto" standard for GoAsm includes I am turning its design and goals over to the group though I hope to be able to contribute more headers once my busy time is over. As for answering questions I will still try to do at least that but I am not always near a computer or internet access so I may not get to them right away, Mark Jones, E^cube and a few others know as much as I do about the headers and their usage so they will probably be better placed to give prompt answers than I.

There are a few headers that I think should be translated, they are IMO important to make the header collection complete but I never got around to either starting them or finishing them. Though I don't have the time myself it would be helpful if someone could tackle the following header files:

SAPI - sapi.h and sapi51.h
DirectX - all current versions (including Direct3d, DirectSound and DirectPlay)
msxml2.h and msxml6.h

These are generally COM headers and would require a working knowledge of COM.

Also, this project respects copyrights, any translation should have the original copyright notice in the file or be covered by one of the blanket notices in Windows.h. Under no circumstances should you include a personal copyright notice in a translated file as I believe it attempts to abrogate the rights of the original author, if you add content to a header you can include a "portions of this file copyright..." notice.

Well, I'm back home for a couple of days and looked through my emails and to my disappointment did not find any volunteers for translating the header files. I am really hoping that some-one will step up and do a couple of them.

i saw a program that converts .h into .inc
let me see if i can find it...

here it is on Wayne's site.....

http://www.magma.ca/~wjr/xlatHinc.zip

even if it doesn't do a 100% job, it should save a lot of work

What about japheth's h2incx ?
http://www.japheth.de/

Donkey decided to go against automatic translation because it seems to lose something, and possibly miss some things. He also has a format that he follows and has outlined earlier. I would try and help translate headers myself but my times consumed as is, and my priority first is to get the new SDK out. I really hope someone steps forward though, and helps donkey out, he's given countless hours i'm sure with the existing headers, it'd be nice if he got something back.

still, for larger files, i would think you could use one of the translator porgrams, then do clean-up
i suppose another approach would be to write a new translator
certainly, the time spent would pay for itself
you might even be able to get the source from Wayne or Japeth so you don't have to re-invent the wheel

Because of some issues I have with the existing translation programs, mainly the inability to modify naming conventions and in the case of MASM targeted ones some incompatibilities that are sometimes difficult to find and edit out I had decided against the automated approach. I had planned to look at Dacorbi Pattern Search (http://download.cnet.com/Dacorbi-Pattern-Search/3000-2248_4-10920798.html) and have obtained permission from the author to use it for free to translate the headers but time ran out and my busy season started before I could get started. I am sure that with Dacorbi a conforming translator could be written since it is scripatble. That said, as long as the conditions above are met anything you use would be OK with me.

PS I am sorry if my responses sometimes seem out of sync with the current discussion but I am out of town very often now (I have only been home 9 days in the last 2 months) and I rarely have much in the way of internet access except a cell connection which is far too expensive to use for browsing the forum...

Edgar, there are two structures in WinCon.h that probably use too small types (should be DW):

COORD STRUCT
X DB
Y DB
ENDS

SMALL_RECT STRUCT
Left DB
Top DB
Right DB
Bottom DB
ENDS

From MS's wincon.h:

typedef struct _COORD {
    SHORT X;
    SHORT Y;
} COORD, *PCOORD;

typedef struct _SMALL_RECT {
    SHORT Left;
    SHORT Top;
    SHORT Right;
    SHORT Bottom;
} SMALL_RECT, *PSMALL_RECT;


Thanks Yuri,

The correction has been made in version 0x020010 and has been uploaded.

COORD STRUCT
X SHORT
Y SHORT
ENDS

SMALL_RECT STRUCT
Left SHORT
Top SHORT
Right SHORT
Bottom SHORT
ENDS

LVITEM & LVCOLUMN structures are wrong in x64,
padding missing.

LV__COLUMN STRUCT
  mask      dd
  fmt      dd
  cx      dd
     dd ; PADDING !
  pszText    dq
  cchTextMax dd
  iSubItem   dd
ENDS

LV__ITEM STRUCT
  mask      dd
  iItem      dd
  iSubItem   dd
  state      dd
  stateMask  dd
     dd ; PADDING !
  pszText    dq
  cchTextMax dd
  iImage     dd
  lParam     dd
  iIndent    dd
ENDS



It is not necessary to explicitly define this padding with GoAsm. Due to stricter Win64 alignment requirements, GoAsm automatically handles this padding for proper alignment (also making 32/64-bit structure definitions easier to maintain).

I wouldn't be sure about that.
It took me whole day to figure out
what was wrong with my code
until I finally found the padding issue..
And how the hell Goasm could know where to add padding bits  ::)
maybe it aligns the end of the structure or something...

It's not that hard to calculate padding, so that quadwords are aligned. Is it ?

oh yeah.. I wasn't looking what type follows  :green
but what previous type was
..so it seems Goasm doesn't align as it claims  :lol

later> OK I assumed no-one will believe me, so here is "the issue exposed..& attached below"

[attachment deleted by admin]

Hi All,

I just had time to look at the discussion, I was at stampede most of the weekend. I think that regardless of whether the structure is automatically aligned by GoAsm or not, this is an error in the header and should be addressed. I will correct it tomorrow and upload the new file. I don't think that the header project should ever rely on the behavior of the assembler in cases like these since it can be removed or modified at any time and the edit to the header will guarantee permanent compatibility.

BTW still no takers on translating some of the headers ?

Unless the original header definition had explicit padding thrown in, probably best to let GoAsm handle the alignment (if you make that change, then there are around a dozen others in that file alone). Another issue with explicitly adding padding occurs when initializing the structure in data - the padding introduces another field ex. <1,2,3,0,4> which looks awkward (and a bit messy for possible 32/64-bit switchable code).

GoAsm handles the padding for proper alignment, the bug here (which seems somewhat familiar, thought there was a fix for this earlier) is in the symbol table which should point to the adjusted field, not the padding...

So I guess we need a consensus as to whether to let GoAsm handle the alignment or not. As a rule of thumb I generally follow Wayne's advice so I am leaning towards no padding. Unfortunately I still haven't gotten around to installing Windows 7 on my 64 bit laptop yet, I'm probably going to buy Vista 64 bit instead as all the drivers are available as well as the preinstalled software. I'm a bit reticent about installing 7 because of driver availability, Acer hasn't gotten back to me on the driver issue, its been a couple of weeks since I emailed them. Hope to get around to installing Vista 64 this weekend then I can run some of these tests myself.

QuoteGoAsm handles the padding for proper alignment, the bug here (which seems somewhat familiar, thought there was a fix for this earlier) is in the symbol table which should point to the adjusted field, not the padding...

Yes, this is a bug (which occurs in 64-bit local data defined by structure only), which I am working on at the moment.

This has now been fixed in the latest version of GoAsm, version 0.56.7 available from here (http://www.jorgon.freeserve.co.uk/Goasm.zip).

Hi Edgar,

There is a little problem with calling CreateWindow. Winuser.h resolves it to CreateWindowA or CreateWindowW, but there are no such functions in modern Windows if I get it right. I thought about something like

#define CreateWindowA CreateWindowExA, 0
#define CreateWindowW CreateWindowExW, 0

Is there any sense in that? ::) Probably this must depend on the Windows version.

I've also noticed that STARTUPINFO is not defined in winbase.h, only STARTUPINFOA and STARTUPINFOW.

Hi Yuri,

Sorry it took so long to get to this post, I am quite busy right now.

The CreateWindowA/W functions were included "as-is" in the GoAsm headers. The problem with just redefining it as CreateWindowEx is that the CreateWindow function does not have the same parameters (missing dwExStyle) and may lead to confusion and bugs that are hard to track down as the headers are doing a hidden replacement of the API. In my opinion it is better to let it terminate in error or remove it completely. Even better perhaps someone can create a macro for the function that wraps the CreateWindowEx function and add it to macros.a

For STARTUPINFO it will be corrected in the next upload.

In fact, the missing dwExStyle is present in the definition itself, as zero. But upon consideration, yes, you are right, such tricks may lead to confusion. I see at least one ugly consequence of my proposal — "call CreateWindow" will resolve to "call CreateWindowExA, 0", which is invalid. I am mostly using invoke, so I forgot about push + call. :)

Uploaded GOASMHDRVER = 0x020011, it contains the fix to STARTUPINFO as well as the DCM structure. There are a few additions to winioctl.h, npptypes.h, and ntddstor.h. A few minor technical corrections were made to some structures, they will not affect the usage of the structures or break any code, the corrections only involved data types. Added fileextd.h, which is used with the Vista+ only file id extensions, they can also be built for XP using static libraries available from Microsoft, this file does not need to be explicitly included, it is loaded through winbase.h (just include Windows.h). To use the file id extensions with XP simply place the lib file in your build folder and use the functions normally, you must set WINVER to NTDDI_WINXP in order to use the lib versions, setting WINVER to NTDDI_VISTA or above will cause the OS resident versions to be used and the program will not function or build under XP.

Win32 FileID API Library (http://www.microsoft.com/downloads/details.aspx?FamilyId=1DECC547-AB00-4963-A360-E4130EC079B8&displaylang=en)

Edgar

Oh, darn, I've run into a problem while assembling, GoAsm can't find windows.h file.
In my source I use just :  #include windows.h

Well, I had this problem when I had XP, but I think I decided to put the Include folder in my Path environment variable. But this doesn't work now on win7 64bit, any help ?

I tried using the full path of windows.h at the include line, but I get errors about the other files (as expected). I'm using the latest Headers package.

Hi,

Path issues are really the domain of GoAsm and not the headers, I don't have Windows 7 installed so I haven't confronted the issue but I am sure others here have and should be able to figure it out.

for masm, and most ms compilers like c, INCLUDE is a seperate environment variable
this picture does not show the PATH variable, but c:\masm32\bin is in the PATH
older versions of MASM had a variable named MASM instead of MASMDIR
(http://img504.imageshack.us/img504/6871/environment.jpg)

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

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

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.

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 ?

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.

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

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 ?

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