Headers 2.0

[ramguru]

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

[BlackVortex]

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

[ramguru]

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]

[donkey]

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 ?

[wjr]

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

[donkey]

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.

[jorgon]

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

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

[jorgon]

This has now been fixed in the latest version of GoAsm, version 0.56.7 available from here.

[Yuri]

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.

[donkey]

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.

[Yuri]

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. :)

[donkey]

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

Edgar

[BlackVortex]

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.

[donkey]

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.

[dedndave]

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