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
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
When i compiled a file I encountered an error, i had used the hDC member of the DRAWITEMSTRUCT. The compiler insisted on that there was no "hDC" member of the struct, but the Win32 Programmer's Reference version of the struct contains this var.
When I dug in the Windows.inc I found that the member were named "hdc" (small letters), where in the Win32 Programmer's Reference it was written "hDC", i use (and prefer) the later one.
The verion of Windows.inc I use is 1.25a (dated 22 Oct. 2001), if there is a newer one please let me know.
I haven't checked the rest of the stucts in the file, so there might be more of such details in the file.
When I dug in the Windows.inc I found that the member were named "hdc" (small letters), where in the Win32 Programmer's Reference it was written "hDC", i use (and prefer) the later one.
The verion of Windows.inc I use is 1.25a (dated 22 Oct. 2001), if there is a newer one please let me know.
I haven't checked the rest of the stucts in the file, so there might be more of such details in the file.
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
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
Do you plan to release the version of windows.inc with
UNICODE macro support?
UNICODE macro support?
Maybe it's time to think how to make some sort of precompiled headers for MASM?
Hutch,
There are some undocumented features I know of in NT4, do you want the prototypes for them?
umbongo
There are some undocumented features I know of in NT4, do you want the prototypes for them?
umbongo
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!
<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!
All these difined:
EVENT_ALL_ACCESS
SEMAPHORE_ALL_ACCESS
TIMER_ALL_ACCESS
But what about MUTEX_ALL_ACCESS ?
MUTEX_ALL_ACCESS EQU MUTANT_ALL_ACCESS
EVENT_ALL_ACCESS
SEMAPHORE_ALL_ACCESS
TIMER_ALL_ACCESS
But what about MUTEX_ALL_ACCESS ?
MUTEX_ALL_ACCESS EQU MUTANT_ALL_ACCESS
In windows.inc 1.25a the ACCEL structure is wrong.
It should be:
KetilO
It should be:
ACCEL STRUCT
fVirt BYTE ?
dummy BYTE ? ;<--- add this line
key WORD ?
cmd WORD ?
ACCEL ENDS
KetilO
Ketil,
Thanks for the suggestion but the win32.hlp file documents it as,
typedef struct tagACCEL { // accl
BYTE fVirt;
WORD key;
WORD cmd;
} ACCEL;
It was in windows.inc as,
ACCEL STRUCT
fVirt BYTE ?
key WORD ?
cmd WORD ?
ACCEL ENDS
Now I wonder if it should be WORD aligned as you suggestion seems to be doing that anyway. I would be interested to see what the problems you had with it were.
Regards,
hutch@movsd.com
Thanks for the suggestion but the win32.hlp file documents it as,
typedef struct tagACCEL { // accl
BYTE fVirt;
WORD key;
WORD cmd;
} ACCEL;
It was in windows.inc as,
ACCEL STRUCT
fVirt BYTE ?
key WORD ?
cmd WORD ?
ACCEL ENDS
Now I wonder if it should be WORD aligned as you suggestion seems to be doing that anyway. I would be interested to see what the problems you had with it were.
Regards,
hutch@movsd.com
MASM shouldn't word align unless you do:
ACCEL STRUCT 2
fVirt BYTE ?
key WORD ?
cmd WORD ?
ACCEL ENDS
IMHO, I don't think that the byte should be given a name - this would prevent future problems. And you can defined the structure like:ACCEL STRUCT
fVirt BYTE ?
BYTE ?
key WORD ?
cmd WORD ?
ACCEL ENDS
If verbosity is preferred.tagACCEL defined in Winuser.h like this:
_MAC System Variable
Compiling this snippet with msvc6.0,
assembles to this:
So, it's byte padding.
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 found WHEEL_PAGESCROLL definition in WINDOWS.INC:
WHEEL_PAGESCROLL equ UINT_MAX
But UINT_MAX is defined nowhere!
Should be:
UINT_MAX equ MAXDWORD ; maximum unsigned int value
or
UINT_MAX equ 0FFFFFFFFh ; maximum unsigned int value
WHEEL_PAGESCROLL equ UINT_MAX
But UINT_MAX is defined nowhere!
Should be:
UINT_MAX equ MAXDWORD ; maximum unsigned int value
or
UINT_MAX equ 0FFFFFFFFh ; maximum unsigned int value
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
For example such as Re-/ToolBar-notification-messages, structures, and more.
:rolleyes: Marwin
Among EXCEPTION_ACCESS_VIOLATION, EXCEPTION_BREAKPOINT etc,
should also be:
And may be it's good idea to complite exception code list, but not sure.
should also be:
EXCEPTION_STACK_OVERFLOW [B]equ[/B] STATUS_STACK_OVERFLOW
EXCEPTION_NONCONTINUABLE_EXCEPTION [B]equ[/B] STATUS_NONCONTINUABLE_EXCEPTION
And may be it's good idea to complite exception code list, but not sure.
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."
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."
If dwValue == 0 proc exits without pop edi!
[size=12].text:00000000 push ebp
.text:00000001 mov ebp, esp
.text:00000003 push ebx
.text:00000004 push esi
.text:00000005 push edi
.text:00000006 mov eax, [ebp+arg_0]
.text:00000009 [COLOR=red][B]mov edi, [ebp+arg_4][/B][/COLOR]
.text:0000000C or eax, eax
.text:0000000E jnz short loc_19
.text:00000010 mov word ptr [edi], '0'
.text:00000015 leave
.text:00000016 retn 8 ; [COLOR=red][B]Exits without restoring edi!!![/B][/COLOR]
...................
.text:00000055 pop edi
.text:00000056 pop esi
.text:00000057 pop ebx
.text:00000058 leave
.text:00000059 retn 8[/SIZE]
The listview NMITEMACTIVATE structure:
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:
So maybe to retain compatibility:
Cheers!
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!
If dwValue == 0 proc exits without pop edi!
One of the benifits of using USES ESI EDI EBX is that this will not happen :)