ASM Community

I have started this thread to pick up any additions that need to made to the WINDOWS.INC file.

What I am after is any corrections and additions up to and including win98se/winNT4 to try and get a stable WINDOWS.INC

Material specific to win2k/XP needs to be added to a seperate INC file so that the current one can become stable.

It is important that the material submitted is tested and reliable as there is no point adding it if its not. There are minor naming variations in the existing file that will not be changed as it would break a lot of existing code but omissions or errors in messages, structures and the like will be added to make the existing file more complete.

Regards,

hutch@movsd.com

Yes you are right, the win32.hlp file has "hDC" instead of "hdc" but the problem is that to change it would break existing code for no purpose as it works correctly using "hdc".

This is not really a problem as there are numerous conflicts with MASM reserve words and registers so the WINDOWS.INC file cannot fully conform to the C++/C naming conventions.

Regards,

hutch@movsd.com

Maybe it's time to think how to make some sort of precompiled headers for MASM?

There are some PE format related structures that use
<Name1> as field name.
Since the keyword <Name> is not used in MASM as it mentioned in its reference (6.15) maybe it's time to disable this keyword in widows.inc and use real "Name"s in structures!

In windows.inc 1.25a the ACCEL structure is wrong.

It should be:

ACCEL STRUCT

  fVirt	BYTE ?

  dummy	BYTE ?	;<--- add this line

  key	WORD ?

  cmd	WORD ?

ACCEL ENDS

KetilO

Hi hutch--

Look here

KetilO

tagACCEL defined in Winuser.h like this:

typedef struct tagACCEL {

#ifndef _MAC

    BYTE   fVirt;               /* Also called the flags field */

    WORD   key;

    WORD   cmd;

#else

    WORD   fVirt;               /* Also called the flags field */

    WORD   key;

    DWORD  cmd;

#endif

} ACCEL, *LPACCEL;

_MAC System Variable
Compiling this snippet with msvc6.0,

acl.fVirt = FVIRTKEY ;

acl.key = 'A' ;

acl.cmd = 0 ;

assembles to this:

.text:004011B5   mov  byte ptr [ebp-180], 1

.text:004011BC   mov  word ptr [ebp-178], 41h

.text:004011C5   mov  word ptr [ebp-176], 0

So, it's byte padding.

I would like to see if there are more konstants included that are related too common controls. Maybe you've read the thread From where do I get these konstant values? in Main forum.
For example such as Re-/ToolBar-notification-messages, structures, and more.

:rolleyes: Marwin

There is no dw2ah func in masm32.lib
And proto in masm32.inc also not present.
But it's described in \MASM32\HELP\Masmlib.hlp:
"dw2ah converts DWORD size data to a hexadecimal ascii string."

The listview NMITEMACTIVATE structure:

typedef struct tagNMITEMACTIVATE{

    NMHDR   hdr;

    int     iItem;

    int     iSubItem;

    UINT    uNewState;

    UINT    uOldState;

    UINT    uChanged;

    POINT   ptAction;

    LPARAM  lParam;

    UINT    uKeyFlags;

} NMITEMACTIVATE, *LPNMITEMACTIVATE;

This must be a recent addition from MS as it is stated "Version 4.71 and later of Comctl32.dll".

However this NM_LISTVIEW struct is already defined as follows:

NM_LISTVIEW STRUCT

  hdr           NMHDR      <>

  iItem         DWORD      ?

  iSubItem      DWORD      ?

  uNewState     DWORD      ?

  uOldState     DWORD      ?

  uChanged      DWORD      ?

  ptAction      POINT      <>

  lParam        DWORD      ?

NM_LISTVIEW ENDS

So maybe to retain compatibility:

NM_LISTVIEW STRUCT

  hdr           NMHDR      <>

  iItem         DWORD      ?

  iSubItem      DWORD      ?

  uNewState     DWORD      ?

  uOldState     DWORD      ?

  uChanged      DWORD      ?

  ptAction      POINT      <>

  lParam        DWORD      ?

 uKeyFlags DWORD ?

NM_LISTVIEW ENDS



NMLISTVIEW  equ  <NM_LISTVIEW>

NMITEMACTIVATE  equ  <NM_LISTVIEW> 

Cheers!