This is the new two(2) file version. Use windows.inc as normal and do not include the second file as it is done in the tail end of windows.inc. The combined files are about half a megabyte larger mainly due to equates from Windows Vista.
it is an external link because the zip file is too large to attach.
www.masm32.com/download/winc14r.zip
Hi hutch,
the CY definition is not correct, he is a UNION. -> http://www.masm32.com/board/index.php?topic=7139.15 you forgot? :wink
Can you change the LARGE_INTEGER definition in your version?
LARGE_INTEGER UNION
STRUCT
LowPart DWORD ?
HighPart DWORD ?
ENDS
QuadPart QWORD ?
LARGE_INTEGER ENDS
LPLARGE_INTEGER typedef ptr LARGE_INTEGER
I missed 4 Winsock consts, please add the in your version.
FD_QOS equ 040h
FD_GROUP_QOS equ 080h
FD_ROUTING_INTERFACE_CHANGE equ 100h
FD_ADDRESS_LIST_CHANGE equ 200h
Regards
Obi
Obi,
Thanks for the report but I did need it BEFORE I released this version, thats what the questions have been about for the last week or so.
Tis is the form I have just put it into WINDOWS.INC.
LARGE_INTEGER UNION
STRUCT
LowPart DWORD ?
HighPart DWORD ?
ENDS
QuadPart QWORD ?
LARGE_INTEGER ENDS
Tolerate me at the moment, I still have some massive amount of work to do building a new version.
I had not done the latest winsock2.h file.
Here are the ones I can find.
SO_PROTOCOL_INFOA equ 2004h
SO_PROTOCOL_INFOW equ 2005h
SO_PROTOCOL_INFO equ SO_PROTOCOL_INFOW
PF_BTH equ AF_BTH
MSG_WAITALL equ 8h
XP1_SAN_SUPPORT_SDP equ 00080000h
WSA_FLAG_ACCESS_SYSTEM_SECURITY equ 40h
NS_BTH equ 16
NS_EMAIL equ 37
NS_PNRPNAME equ 38
NS_PNRPCLOUD equ 39
LUP_NON_AUTHORITATIVE equ 4000h
LUP_SECURE equ 8000h
LUP_RETURN_PREFERRED_NAMES equ 10000h
LUP_ADDRCONFIG equ 00100000h
LUP_DUAL_ADDR equ 00200000h
POLLRDNORM equ 0100h
POLLRDBAND equ 0200h
POLLIN equ POLLRDNORM or POLLRDBAND
POLLPRI equ 0400h
POLLWRNORM equ 0010h
POLLOUT equ POLLWRNORM
POLLWRBAND equ 0020h
POLLERR equ 0001h
POLLHUP equ 0002h
POLLNVAL equ 0004h
Here is the correct assembler notation for the 4 equates converted from the C notation using <<.
FD_QOS equ (1 SHL FD_QOS_BIT)
FD_GROUP_QOS equ (1 SHL FD_GROUP_QOS_BIT)
FD_ROUTING_INTERFACE_CHANGE equ (1 SHL FD_ROUTING_INTERFACE_CHANGE_BIT)
FD_ADDRESS_LIST_CHANGE equ (1 SHL FD_ADDRESS_LIST_CHANGE_BIT)
Quote from: hutch-- on July 28, 2007, 11:15:51 AM
Tis is the form I have just put it into WINDOWS.INC.
LARGE_INTEGER UNION
STRUCT
LowPart DWORD ?
HighPart DWORD ?
ENDS
QuadPart QWORD ?
LARGE_INTEGER ENDS
Hutch, do you mean this is the form that will appear in an update? Because on checking it in the 1.4 version I just downloaded from the site link, it shows this, clearly incorrect:
LARGE_INTEGER STRUCT
QuadPart QWORD ?
LARGE_INTEGER ENDS
Ian,
No, its as I said, the suggestion was made after I released the later version so i added a corrected version of the structure plus the listed equates and corrected SHL equates.
I have always had this problem in that when i need useful information little is forthcoming and when I release a file of this tpe I get whinged at for not including something.
Hutch, I understand. I was just trying to clarify what you meant by "added". You mean you have added it into your master reference copy, but not into the public release. That makes a large amount of difference, since we still all need to correct the windows.inc/winextra.inc file we have downloaded so that use of this particular structure works in all cases.
Ian,
That will be solved reasonably soon so it will no longer be a problem. For obvious reasons I am not going to do release versions on short notice after every correction. What I needed while I was asking for suggestions was suggestions. I added about 400k to the master fiel, found it was too long for older versions of ML so I split it into 2 files so it would run correctly on all versions of ML from 6.14 to 8.0.
Hi Hutch,
Do you have any plans to update the other version of windows.inc designed for Poasm?
Erol,
Yes, the current version I have here at the moment works with POASM fine. I tracked down the last couple of things that clashed with POASM and they can now share the same version. It will be released reasonably soon.
I assembled a file just the other day with POASM, using the latest WINDOWS.INC (1.4) because I didn't have the POASM version handy, and it worked just fine. I was pleasantly surprised. :thumbu
Hi Hutch,
Many thanks :U
Thank you Hutch for all your hard work.
Unfortunately, unlike Greg, I still get the same recurrent error when using POASM with windows.inc 1.4 or prior versions, ie 'Redefinition of symbol GUID'.
The relevant make.bat line is '...\POASM.EXE Easter.asm'. (The Easter program simply calculates the exact date of Easter Day for any future year).
Any thoughts on the error, or should I just wait until you release the new POASM compatible version?
Many thanks for your help.
t the moment just delete the duplication. It happens because POASM is not duplicate tolerant like MASM. POASM reports the line where the error is so you should be able to go to that line and delete it witout much problem.
Hutch
I tried your suggestion and commented out the 'IID equ <GUID>' in windows.inc but this gave 'undefined IID' and '<' errors.
However, when I also moved the IID struct definition from winextra.inc to windows.inc everything assembled normally.
Thank you for the nudge in the right direction.
Added the file hutch posted to my mirror.
I have a small remark about the union in structure in :
D:\MASM\INCLUDE\winextra.inc(3312) : error A2008:syntax error : tab
Give me the name of the structure as the original file has been modified since the version you are using was released.
Here's :
NOTIFICATION STRUCT
...
union info
...
tab TABLE_NOTIFICATION <>
The problem is that "tab" is not a reserve word in MASM 6.14. Are you using a later version ? I just tested it with ML.EXE version 8.0 and its still not a problem.
Here is the test piece.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
.data?
value dd ?
.data
tab dd 0
.code
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
call main
exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
main proc
mov eax, OFFSET tab
ret
main endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start
This is the structure in the windows.inc extra file.
NOTIFICATION STRUCT
ulEventType dd ?
ulAlignPad dd ?
union info
err ERROR_NOTIFICATION <>
newmail NEWMAIL_NOTIFICATION <>
obj OBJECT_NOTIFICATION <>
tab TABLE_NOTIFICATION <>
ext EXTENDED_NOTIFICATION <>
statobj STATUS_OBJECT_NOTIFICATION <>
ends
NOTIFICATION ENDS
It is equate :
ht equ 09H ; ^I
tab equ 09h ; ^I tabulation
lf equ 0AH ; ^J
It is not an equate in any win32 system and that equate is not in the windows.inc or extra file.
This equate could be in any program, because to often used name, when that's overlading by one field in union of system include file it's nou useful.
The names match the names from the Microsoft structure definitions in MAPIDefS.h and WabDefs.h:
typedef struct _NOTIFICATION
{
ULONG ulEventType; /* notification type, i.e. fnevSomething */
ULONG ulAlignPad; /* Force to 8-byte boundary */
union
{
ERROR_NOTIFICATION err;
NEWMAIL_NOTIFICATION newmail;
OBJECT_NOTIFICATION obj;
TABLE_NOTIFICATION tab;
EXTENDED_NOTIFICATION ext;
STATUS_OBJECT_NOTIFICATION statobj;
} info;
} NOTIFICATION, FAR * LPNOTIFICATION;
Keeping include files as close to documented naming conventions is simply more important than private equates in a single application. Reporting this as an error is simply mistaken, the error is in your own application for duplicating the name with an equate instead of using a naming scheme that is compatible with the documented structure scheme names.
It has managed to waste a reasonable amount of time debugging your application when I have a workload with this project that rivals writing Encyclopaedia Brittanica so please keep error reporting to documented problems allowing that MASM deviated in some reserve word names.
Is it not mistake in assembler that equate intersect with union fields. Especially if to use h2inc versions of include files iI think, t's need to discard.- EQU it's not TEXTEQU and nowhow link to fields.
The DLGTEMPLATE structure in windows.inc is incorrectly declared:
DLGTEMPLATE STRUCT DWORD
style DWORD ?
dwExtendedStyle DWORD ?
cdit WORD ?
x WORD ?
y WORD ?
lx WORD ?
ly WORD ?
DLGTEMPLATE ENDS
The DWORD alignment is forcing the length to 20 bytes by adding two zero bytes at the end, to meet the requirement that the size be a multiple of the alignment. The length should be 18, as verified with this code:
#include <windows.h>
int main(void)
{
printf("%d\n",sizeof(DLGTEMPLATE));
getch();
return 0;
}
Gratsie,
Its fixed in the reference build version and will be available with the next beta or release.
I think it was one of Iczelion's leftovers, I have never DWORD aligned a win32 structure.