Azimut Project

[MichaelW]

In his first reply in this thread Greg provided a link to an MSDN article that details the alignment rules used by the Microsoft C/C++ compilers, see the Structure and Union Layout section.

[jdoe]

In his first reply in this thread Greg provided a link to an MSDN article that details the alignment rules used by the Microsoft C/C++ compilers, see the Structure and Union Layout section.

Michael,

My last post end with "Thanks for your clues" and it was not a question. I don't really understand what you mean.

I'm working on a H2INC program so what I need, has to be in the header files as much as possible and knowing the alignment rules may have been of some interests if I had not found the utility of pshpack?.h and poppack.h.

In fact, the "Structure and Union Layout" section and the key words "#pragma pack" is exactly what put to me on the track at second reading. I was a little desperate to have to do the alignment stuff myself. Dealing with the constants in the header files is much more easier but I just realized that I need to be carefull when it comes to structures. I thought it was much simpler.

Thanks again guys and I hope you will be there for my next question. I know what it will be but each thing in its time.

See you later

:U

[jdoe]

are you aware of http://www.japheth.de/Win32Inc.html?

japheth,

Like I said, I am merging all SDK/DDK (Windows 2000 and higher). The result for now is 357 .lib files and around 850 .inc files. I will put the .inc files in a single one (most of them commented though for faster compilation time).

AZIMUT.INC ...

; Azimut Project
; Copyright (c) 2007 Philippe Coulombe
; All rights reserved

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Definition
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

IFNDEF _WIN32_IE
_WIN32_IE EQU 0500h
ENDIF

IFNDEF _WIN32_WINNT
_WIN32_WINNT EQU 05000000h
ENDIF

IFNDEF UNICODE
DBCHAR TYPEDEF BYTE
TCHAR TYPEDEF BYTE
ELSE
DBCHAR TYPEDEF WORD
TCHAR TYPEDEF WORD
ENDIF

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Macro
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

CTL_CODE MACRO DeviceType:REQ, Function:REQ, Method:REQ, Access:REQ
    exitm <((DeviceType shl 16) or (Access shl 14) or (Function shl 2) or Method)>
ENDM

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

HRESULT_FROM_WIN32 MACRO x:REQ
    if ((x eq 0) or (x shr 31))
        exitm <(x)>
    else
        exitm <((x and 0000FFFFh) or (FACILITY_WIN32 shl 16) or 80000000h)>
    endif
ENDM

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

MAKE_HRESULT MACRO sev:REQ, fac:REQ, code:REQ
    exitm <((sev shl 31) or (fac shl 16) or code)>
ENDM

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

MAKE_SCODE MACRO sev:REQ, fac:REQ, code:REQ
    exitm <((sev shl 31) or (fac shl 16) or code)>
ENDM

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Include
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;INCLUDE accctrl.inc
;INCLUDE aclapi.inc
;INCLUDE aclui.inc
;INCLUDE activecf.inc
;INCLUDE activeds.inc
;INCLUDE activscp.inc
;INCLUDE adhoc.inc
;INCLUDE admex.inc
;INCLUDE adoint.inc

But your Win32Inc is a good work.

:thumbu

[drizz]

just be aware of struct alignment bugs!
asm file 1) Internal Assembler Error
asm file 2) Output incorrect
attached.

[attachment deleted by admin]

[jdoe]

just be aware of struct alignment bugs!
asm file 1) Internal Assembler Error
asm file 2) Output incorrect
attached.

drizz,

For asm file 1 bug, I checked in C header (wincon.h) and it is said nowhere that it must be DWORD aligned. When not, it assemble without "Internal error".

For asm file 2 bug, yes the data layout is weird and it seems to come from the use of DUP "2 dup(<>)".

Honestly, I have no choice to rely on the C header files. If there is a bug for few structures with ML, what can I do. It's Microsoft Business, not mine.

Thanks for the information.

:wink

[MichaelW]

For asm file 1 bug, I checked in C header (wincon.h) and it is said nowhere that it must be DWORD aligned. When not, it assemble without "Internal error".

The header file depends on the compiler to align the structure members correctly. If you attempt to use the structure without taking care to align it then the code that uses the structure will not work correctly. There is a thread somewhere here that discusses this exact problem.
The structure as aligned by the C/C++ compiler:

Code Select Expand


sizeof(ir) 20
&ir.EventType 12fed0
&ir.Event.KeyEvent 12fed4

And the unaligned structure in MASM:

Code Select Expand


SIZEOF ir 18
OFFSET ir.EventType 00403000
OFFSET ir.Event.KeyEvent00403002

You can avoid the bug and achieve the necessary alignment by padding the structure:

Code Select Expand


INPUT_RECORD struct
  EventType WORD ?
  WORD ?
  union Event
    KeyEvent KEY_EVENT_RECORD <>
    MouseEvent MOUSE_EVENT_RECORD <>
    WindowBufferSizeEvent WINDOW_BUFFER_SIZE_RECORD <>
    MenuEvent MENU_EVENT_RECORD <>
    FocusEvent FOCUS_EVENT_RECORD <>
  ends
INPUT_RECORD ends


[jdoe]

Michael,

So, it is not the opposite... the compiler needs the header files to align structures ?
What are "#pragma pack" and "#pragma pop" for then ?
I thought I understood something. Thanks for the disillusion  :P

So the INPUT_RECORD structure is known to be a buggy one. Is there some more like that, you can remember ?
I will take care of them manually.

[MichaelW]

AFAIK the #PRAGMA PACK directive is used to control packing alignment for special cases.

http://msdn2.microsoft.com/en-us/library/d9x1s805(VS.71).aspx
http://msdn2.microsoft.com/en-us/library/ms856729.aspx

Perhaps my statement should have been:

The header file depends on the default behavior of the compiler to align the structure members correctly.

Obviously you can use #PRAGMA PACK or /Zp to force alignments that will not work with the Windows API.

In addition to INPUT_RECORD, japheth mentioned OAIDL (OLE automation).

Another that I recall is PDH_FMT_COUNTERVALUE. It's not in Windows.inc, but IIRC to implement it in MASM you must add padding to properly align the union within the structure.

[jdoe]

Obviously you can use #PRAGMA PACK...

It is my best option for now and I am confident that it will be sufficient.

[jdoe]

Hi,

I would like to know what is the difference between these (in header files)...

#if _AMD64
#if _M_IA64
#if _WIN64

Does they're all condition for Win64 or (_AMD64 and _M_IA64) makes a specific difference between AMD and Itanium processors ?

Thanks

[jdoe]

#if _AMD64
#if _M_IA64
#if _WIN64

Does they're all condition for Win64 or (_AMD64 and _M_IA64) makes a specific difference between AMD and Itanium processors ?

I found that if I want to make my include files compatible with Win64, I must exclude all the _M_IA64 stuff from the header files because it is not really Win64 or I should say yes it is but not for ML64.EXE.

But I still don't know what to do with _AMD64. I thought that AMD64 was the same as the 64bits processor of Intel but it seems not because specific structure member use it.

Code Select Expand


KWAIT_BLOCK STRUCT
    WaitListEntry LIST_ENTRY <?>
    Thread DWORD ?
    Object DWORD ?
    NextWaitBlock DWORD ?
    WaitKey WORD ?
    WaitType BYTE ?
    SpareByte BYTE ?
IFDEF _AMD64_
    SpareLong DWORD ?
ENDIF
KWAIT_BLOCK ENDS


From that example, do I have to include SpareLong member only for AMD processor or for all WIN64 stuff.

:'(

[GregL]

jdoe,

Looks like you figured it out, _M_IA64 is for Itanium.

[Vortex]

Hi jdoe,

How is going the work with your project?

[jdoe]

Hi jdoe,

How is going the work with your project?

Vortex,

Lately, after reading many header files, I decided that it would be more judicious to make my include files compatible with WIN64 stuff by adding the _WIN64 definition. The Windows 64 programming will get more and more popular so instead of doing another package later, I doing it once for 32 and 64 bits Windows.

I know I'm not very fast to come up with something but my living job takes a lot of my time right now because of many projects at the same time. My free time suffer of that.

I put all my other personal projects on the side, so what is sure, Azimut is gonna see the day before the end of 2007... I hope.

[jdoe]

Hi,

For now, the includes *.lib and *.inc are completed for WIN32 (and CONSTANTS almost completed) but I had a look at WIN64 *.lib and they all looks like C import libraries. I read on the net that WIN64 use FASTCALL calling convention (first 4 parameters on registers and the rest on the stack) but the function name decoration don't fit the usual @function@4 name seen for WIN32. It seem to be no way to know on much parameter a function use like it is for C (:VARARG).

My questions are...

1) Is there any needs for PROTOs or only something like EXTERNDEF ExitProcess:PROC (or should I wrote EXTRN) ?
2) I didn't found examples using INVOKE so does this internal macro still exist or only CALL is used.
3) Does WIN64 APIs restore the stack before returning like it was for FASTCALL on WIN32 (I don't think so) ?
4) Does the WIN64 APIs have all the same parameters count as for WIN32 ?

Thanks for your enlightment.