I have uploaded a preliminary test of the new 32/64 header files. The original 32 bit ones are still the current version available from the website however the following link is for the new set..
http://www.quickersoft.com/donkey/headers/headers2.zip
They feature switchable 32 bit and 64 bit definitions for structures and COM interfaces.
A new windef.h file that sets new data types (PTR, HANDLE, LPARAM etc...)
A lot of bugs were found and corrected
Better handling of unnamed nested structures and unions
A few new switches, most notably WIN64
Separation of the UNICODE and STRINGS UNICODE switches to match GoAsm documentation
A new VISTA switch that will add hundreds of new VISTA only definitions and expand structures for VISTA
There are bound to be quite a few missed definitions and badly defined structures, for that reason it is only in alpha release. All bug reports should be posted in this thread.
Note GoAsm version 5605c is required for this release. It is available in this thread (http://www.masm32.com/board/index.php?topic=11016.0)
Please no MASM posts !!
Help2 Viewer v0.6.3.9
GoAsm v0.56.5c
----------------------
C:\GoASM\Bin\GoAsm.EXE /d UNICODE "Help2 Viewer.asm"
GoAsm.Exe Version 0.56.5c - Copyright Jeremy Gordon 2001/9 - JG@JGnet.co.uk
Warning .......................
Line 13 of the include file msxml.h:-
Include file referred to more than once and therefore ignored:-
#include "unknwn.h"
Output file: Help2 Viewer.obj
Make finished.
--------------------
Just report this.
Quote from: UtillMasm on March 22, 2009, 04:19:55 AM
great!
Hi UtilMasm,
Still a long way to go, the expansion required nearly 200K of new definitions and over 100 new structures as well as a lot of interfaces. Almost every aspect of the header project has been affected in what amounts to nearly 3 months of editing so there are going to be a lot of errors but I have built in more flexibility this time by using data types so corrections should be easier. For now Vista support is limited to the core files, that is all files in windows.h and their derivatives but that encompasses almost all programming needs except for a few very esoteric applications. For Win64 the same applies except that all COM interfaces have been upgraded as well as many of the non-core files. For things like IA64 and AMD64 the internal and low level structures (ie CONTEXT) are done but need some testing.
I have seen that warning, I have a typo in the MSXML.H file, the following line
#IFNDEF UNKNOWN_H
should be
#IFNDEF UNKNWN_H
New upload, took care of the bug above as well as a problem with including GDIPlus, it would reset the IUnknown interface to 32 bit affecting all COM interfaces.
Thanks for the hard work Donkey. 700+kb, wheeeew that's a lot of static data.
Quote from: Mark Jones on March 23, 2009, 06:00:40 AM
Thanks for the hard work Donkey. 700+kb, wheeeew that's a lot of static data.
Hi Mark,
I have some 2 MB that will be added in the next couple of weeks, mshtml.h alone will be over a meg and now stands at around 20% complete. In all I am hoping to keep the entire project under 3MB zipped and it looks like it might come in just under the wire, this compared to the 62MB of headers with MSDN that I use as my data source. Aggressive switching is meant to cut down the amount of data GoAsm has to process but it is possible to selectively skip header files by defining them as loaded, for example if you use commdlg.h but don't need the property sheet header file you can use
#define PRSHT_H and prsht.h will be skipped. In all headers the name of the file (with an underscore to replace the dot) is used as a flag to indicate whether it has been loaded or not, looking for unused #includes is always a good strategy to make your source a little leaner.
Edgar
Great work! Thanks.
Thanks Ramon.
On a side note:
I don't think I ever mentioned it but since the beginning of the project windows.h has been accumulating notes and useful information, it is always a good idea to read it if you have an issue. In some cases the problem has been foreseen in advance and both the solution and an explanation is available. This has nothing to do specifically with this release but I got an email today with a problem that had been covered in the compatibility notes of windows.h (changes to GUID structure) and it would have saved the user quite a lot of time had he checked the file.
Edgar
Hi All,
New upload to the link above.
Many many many fixes and more files processed. Major changes include imagehlp.h and DbgHelp.h. A major addition is the mshtml.h file and all supporting headers. The original mshtmlc.h file was 3 MB !!! it shrunk to 175 KB after all of the editing (it took nearly a week). Since my 64 bit machine is not available for use in development (work only), I hope to get around to buying a second one next week and should be able to begin testing these files myself. For now any bug reports or omissions would be appreciated...
Edgar
great! :U
Quote from: UtillMasm on March 27, 2009, 02:35:14 PM
great! :U
Thanks, hoping you change your name to UtilGoAsm soon :bg
Thanks Donkey. Hmm curious, can VMWare "run" a 64-bit image on a 32-bit OS?
VMWare can run 64bit windows as guest on 32bit windows host IIF (if and only if) your processor is 64bit.
My dev machine has been reduced to my AMD Sempron 3000+, a 32 bit machine, ever since my P4 died. For security reasons I can't use my AMD Athlon64 box for anything but work but I am planning to buy a second one just for development, the sempron is a good processor but I need more horse power and 64 bit is becoming essential in order to test the headers.
By the way, I am thinking about completely dropping support for Windows 9x and Windows NT4, existing entries will not be changed but any new structs etc.. will not have any switches for these OS versions. This will especially affect structures with cbSize where the size for Win9x/NT4 would not be calculated properly with the SIZEOF operator, it would have to be entered manually. Is there any reason to continue supporting these OS versions ?
As an example of the compleixity of continued Win9x/NT4 support the NOTIFYICONDATA structure provides enlightenment...
NOTIFYICONDATAA STRUCT
cbSize DD
hWnd HANDLE
uID DD
uFlags DD
uCallbackMessage DD
hIcon HANDLE
#IFDEF WIN9X
szTip DB 64 DUP
#ELSE
#IFDEF WINNT4
szTip DB 64 DUP
#ELSE
// WIN2K +
szTip DB 128 DUP
dwState DD
dwStateMask DD
szInfo DB 256 DUP
UNION
uTimeout DD
uVersion DD
ENDUNION
szInfoTitle DB 64 DUP
dwInfoFlags DD
#IFDEF WINXP
guidItem GUID <>
#ENDIF
#IFDEF VISTA
guidItem GUID <>
hBalloonIcon HANDLE
#ENDIF
#ENDIF
#ENDIF
ENDS
Ahh, the damn NOTIFYICONDATA ! Took me 2 hours to show a system tray balloon tip properly, I got totally lost, and MASM32's header is wrong, had to fix it.
Thanks for your work by the way, keep at it.
Some words of my experience of the problem.
There is litlle differences between the header's of the sdk XP and the sdk Vista , the structure NOTIFYICONDATAA is just a sample of this little differences.
That i have tested is compiled a program (XP) with the sdk vista and then the sdk XP.
The SDK VISTA don't work for XP,it is strange but it is like that.Without compilation errors a certain numbers of controls don't work's.
Here is the two forms of the structure
XP
Quote
NOTIFYICONDATAA STRUCT
cbSize DWORD ?
hWnd DWORD ?
uID DWORD ?
uFlags DWORD ?
uCallbackMessage DWORD ?
hIcon DWORD ?
IF COMPARE(_WIN32_IE,LT,00500h)
szTip BYTE 64 dup (?)
ELSE
szTip BYTE 128 dup (?)
ENDIF
IF COMPARE(_WIN32_IE,GE,00500h)
dwState DWORD ?
dwStateMask DWORD ?
szInfo BYTE 256 dup (?)
union DUMMYUNIONNAME
uTimeout DWORD ?
uVersion DWORD ?
ENDS
szInfoTitle BYTE 64 dup (?)
dwInfoFlags DWORD ?
ENDIF
IF COMPARE(_WIN32_IE,GE,0600h)
guidItem GUID <>
ENDIF
NOTIFYICONDATAA ENDS
Vista
Quote
NOTIFYICONDATAA STRUCT
cbSize DWORD ?
hWnd DWORD ?
uID DWORD ?
uFlags DWORD ?
uCallbackMessage DWORD ?
hIcon DWORD ?
IF COMPARE (NTDDI_VERSION,LT,NTDDI_WIN2K)
szTip BYTE 64 dup (?)
ENDIF
IF COMPARE (NTDDI_VERSION,GE,NTDDI_WIN2K)
szTip BYTE 128 dup (?)
dwState DWORD ?
dwStateMask DWORD ?
szInfo BYTE 256 dup (?)
union DUMMYUNIONNAME
uTimeout DWORD ?
uVersion DWORD ? ; used with NIM_SETVERSION, values 0, 3 and 4
ENDS
szInfoTitle BYTE 64 dup (?)
dwInfoFlags DWORD ?
ENDIF
IF COMPARE (NTDDI_VERSION,GE,NTDDI_WINXP)
guidItem GUID <>
ENDIF
IF COMPARE (NTDDI_VERSION,GE,NTDDI_VISTA)
hBalloonIcon DWORD ?
ENDIF
NOTIFYICONDATAA ENDS
What answer To give I don't know
Hi BlackVortex,
Yeah that one was a bit much, but I am currently working on the beta release of Headers2.0 and it will manage structures like that much easier to define than in the alpha version. I have decided to go with the NTDDI defines to determine Windows version, which was the reason I originally planned on dropping NT4 and 9X support (no NTDDI equates for those) but I have decided to add a few...
#define NTDDI_WINCE 0x02000000
#define NTDDI_WIN9X 0x03000000
#define NTDDI_WINNT4 0x04000000
That way I can continue to support the OS versions but have a standard ID scheme, the Microsoft headers are all over the place using 3 or 4 different OS id schemes sometimes in the same file. It was getting a bit discouraging to try to figure it all out. Replacing the whole lot with one standard scheme seems to make life easier. It also allows for a quantitative check (ie >=) so no more complex #IFNDEF blocks, the only caveat is that checks have to be done from highest to lowest because of the way GoAsm processes equates. No allowance for IE versions will be made unless it is greater than 6 and there is a structure size member, otherwise all members will be included without switching.
I am targeting the beta release for Tuesday but it may be sooner than that (depending on the weather).
Edgar
The final alpha (hopefully) has been uploaded, unfortunately I found the conditional assembly bug (http://www.masm32.com/board/index.php?topic=11121.0) after the upload so the conditional assemblies have a problem but I hope that it gets fixed fairly soon so the project can continue without my having to rewrite each of those structures. At any rate it should only affect a very small amount of code so I am leaving them as is for now. All files have now been completed and the change over to WINVER = NTDDI_xxx is complete.
Headers 2.0 is now in Beta release, it has replaced the main headers file at the website, the link in this thread is no longer valid. I finished SHObj.h ahead of schedule, we had quite a bit of snow here ruining my plans for the day. I have tested the headers as best I can in 32 bit mode with some applications I have. Here are some notes:
You should always set the target Windows platform, the headers will default to Windows XP SP0 if none is set. The definitions for versions is found in windef.h
example : WINVER = NTDDI_WIN2K
The Windows version must be set before windows.h or any header file is included.
Win32 is default, to switch all structures and definitions to 64 bit define the WIN64 switch:
#DEFINE WIN64
WIN64 must be set before windows.h or any header file is included.
Many structures have been updated to include resizing based on the Windows version, if you do not specify a version number your application may fail on some OS versions due to the cbSize member. Specifying a version number too low will result in any members for higher versions being unavailable and will throw an error if referenced.
Attempting to use WIN64 with an OS version that does not have 64 bit support will show a warning message, for example using NTDDI_WIN9X with WIN64.
GoAsm.Exe Version 0.56.5c or greater is required
GoLink.Exe Version 0.26.10 beta3 or greater is required
Edgar
EDIT:
One small change to windef.h, I had been working under the assumption that I could chain typedefs, that is not working properly. The following change has to be made
replace the typedefs for LPARAM and WPARAM with the following:
#IFDEF WIN64
#DEFINE LPARAM DQ
#DEFINE WPARAM DQ
#ELSE
#DEFINE LPARAM DD
#DEFINE WPARAM DD
#ENDIF