www.hammick.com/hcs/WINDOW_S.ZIP 136 KB I'm working on a solution of the problem of long, numerous, and intricate header files (or include files for ASM). The above zip will suggest the possibilities. It contains a re-do of windows.inc from iczelion & hutch. I would happy to hear suggestions, or, of course, bug reports. (It does contain a few symbols which were undefined in the original and which I haven't been able to track down.) Thx.
Why not use conditionals include ? For example, OpenGl constants could be defined only if the INCLUDEGL flag is set, like this IFDEF INCLUDEGL // open gl definitions ENDIF There is a set of flags defined in windows.h : * NOGDICAPMASKS - CC_*, LC_*, PC_*, CP_*, TC_*, RC_ * NOVIRTUALKEYCODES - VK_* * NOWINMESSAGES - WM_*, EM_*, LB_*, CB_* * NOWINSTYLES - WS_*, CS_*, ES_*, LBS_*, SBS_*, CBS_* * NOSYSMETRICS - SM_* * NOMENUS - MF_* * NOICONS - IDI_* * NOKEYSTATES - MK_* * NOSYSCOMMANDS - SC_* * NORASTEROPS - Binary and Tertiary raster ops * NOSHOWWINDOW - SW_* * OEMRESOURCE - OEM Resource values * NOATOM - Atom Manager routines * NOCLIPBOARD - Clipboard routines * NOCOLOR - Screen colors * NOCTLMGR - Control and Dialog routines * NODRAWTEXT - DrawText() and DT_* * NOGDI - All GDI defines and routines * NOKERNEL - All KERNEL defines and routines * NOUSER - All USER defines and routines * NONLS - All NLS defines and routines * NOMB - MB_* and MessageBox() * NOMEMMGR - GMEM_*, LMEM_*, GHND, LHND, associated routines * NOMETAFILE - typedef METAFILEPICT * NOMINMAX - Macros min(a,b) and max(a,b) * NOMSG - typedef MSG and associated routines * NOOPENFILE - OpenFile(), OemToAnsi, AnsiToOem, and OF_* * NOSCROLL - SB_* and scrolling routines * NOSERVICE - All Service Controller routines, SERVICE_ equates, etc. * NOSOUND - Sound driver routines * NOTEXTMETRIC - typedef TEXTMETRIC and associated routines * NOWH - SetWindowsHook and WH_* * NOWINOFFSETS - GWL_*, GCL_*, associated routines * NOCOMM - COMM driver routines * NOKANJI - Kanji support stuff. * NOHELP - Help engine interface. * NOPROFILER - Profiler interface. * NODEFERWINDOWPOS - DeferWindowPos routines * NOMCX - Modem Configuration Extensions Maybe the same flags could be defined in windows.inc This message was edited by karim, on 6/13/2001 5:26:55 AM
Whaaoooo!!!!!!...... Gona check this this afternoon. Great work. betov.
Larry, I am not sure what you are trying to do with the windows.inc file, there is a utility in the INCLUDE directory that compacts the file size by removing repeat sequences spaces called "hcompact.exe" which drops the size by about 200k but it usually does not effect the build time much, MASM is fast enough not to bother about it. Problem is with removing the formatting is that the file is nearly impossible to edit properly, thats the reason why it is supplied in its normal form with a compressor if someone wants it. Be interested to see what you have in mind. Regards, firstname.lastname@example.org
Since I'm a frequent grumbler about windows.inc... The file as Icz has it now is an attempt to make it the ONE SINGLE file needed for any constant anywhere in the Windows universe. hutch may not notice it's compilation time, but I have. In one large library project I did, I expressly did not use windows.inc but pulled out just what constants I actually used. The built time droped from several minuits to a few secconds. Conditional compilation as karim suggests would probably also compile faster, but has the same programmer overhead of having to define which pieces one needs. Either way, each major library or such would need it's own seperate block or file. They partially exist in MSM32, but include files for a library just contain the function protos, the constants have all been dumped into windows.inc. Everything is a trade-off.
Why not define a .inc file for each .h files in the plateform sdk, with the same conditional flags (like LEAN_AND_MEAN)?
Check done. I have updated SpAsm integrated tables in a couple of minutes with it (what was impossible with the last version). Details problems related... Really, very good work. Hold on. Thanks.
Why not put the constants for a function in the kernel32.inc file. Like if MessageBox is in Kernel32.inc, put the constants for it in there. And if CreateDialogParam is in gdi32.inc, put the constants in there. I dont know if this will work, but i thought id suggest it.
instead of having just one large file such as the windows.inc i think it would be best just to keep all the information where its really suppose to be. everything in the kernel32.h would be in the kernel32.inc and so on. this way it should be much easier to maintain and also reduce assemble time some people are having problems with. smurf This message was edited by smurf, on 6/13/2001 1:45:37 PM
I just said that.
I think the Windows.inc should be kept the way it is and maintained the way it has been, because it's a standard for a lot of us. Everyone has the option of building their own I, used to, but it was not consistent with the Windows.inc file. To Ernie: What's the size of the programs that would take a few minutes to build? I have some fairly large programs and my worst case is about 3 seconds. Ewayne
It's a long story. I'm aiming for one giant database containing all the H material. Once we have that, dumping an H or INC file containing any desired subset will be easy. The programmer will just run an applet which reads a script such as produce thisjob.inc include kernel32 include gdi32 ... and then the file thisjob.inc will contain what he needs, but with no fields that need to be calculated at build time, and with no formatting other than what the assembler requires. The "new windows.inc" (I should not have called it that -- it is really only a demo and testbed) does not demonstrate this; but all it needs is one more field in the database. A little more on selective compilation: Flags such as Karim suggested are a good step, as far as they go. GimmeSound equ TRUE GimmeGDI equ FALSE ... .if GimmeSound .fi .if GimmeGDI ... But then the compiler still has to digest the unused portions of file (at least partly) because if-blocks may be nested. There are at least three other issues. Ease of editing and debugging: The "new windows.inc" would be impossible to edit or debug as text. But that's not the intention. The inc file is just a report dumped out of a database. The database itself is much easier to edit than the original, or any big H file or other stuctured script. The table immediately exposed more than 500 duplicated lines in the original, for instance. Notice too that the assembler does not do a great job of detecting bugs in include files. Even undefined constants are not reported until you try to use them in your source. The same goes for: myint equ 3L (clipped from a H file). You get no build error unless myint is used, in which case you get "missing operator in expression". Standardization: This is vital, as Ewayne says. But the real standards are the H files from which our INC files derive. I laid hands on a massive set of H's from lcc-win32. These are ANSI-compliant and have had a lot of use, and therefore probably don't contain many problems. I plan to use these for the all-in-one data table. Parsing big H's will still need considerable work. I found one line 1043 characters long! And these standards are not just an aid to communication between programmers; they aim to support several OS's and machines. Integer constants may be 32 bits on one machine and 64 or 16 on another, which is one reason for formulas in the H's: mysym equ symbol1 | symbol2 | symbol3. As yet all the integers in my table are all 32 bits+sign. I will therefore need to make adjustments for the coming 64-bit Intel cpu, but that won't be difficult. Compilation time: It seems sensible to calculate things like mysym just once for one job, rather than force the assembler to do the same calculation on every build. The "new windows.inc demonstrates that this is possible. This message was edited by Larry Hammick, on 6/13/2001 7:54:21 PM
These are the problems as I see them, the source for the prototypes, structures and equates are generally the platformsdk C/C++ header files and these almost defy conversion to the INCLUDE format required by MASM. I think the only way to automate the conversion of the SDK header files is to write a C compiler front end and process them in order writing the same structure of files as includse files. MASM32 was possible because there was a trick from the libraries having the names of the API functions as "decorated names" which provided the parameter information for the automatically generated include files that MASM32 uses. This gives a matching include file for each library but it does not handle the equates, structures, unions and records required to write wide ranging windows code. I manually produced the first WINDOWS.INC file for MASM32 and Iczelion has done the bulk of the WinNT/Win2k material to produce the current version that is available. Now as you can imagine, collectively the WINDOWS.INC file has had many hours dedicated to it so far and it is certainly the best available at the moment but it has become a large file, currently just short of 1 meg. The suggestions of conditional directives and local equates and structures in each include file for each library would in fact work well but it is a task measured in man years to do which renders it impractical. In hindsite I would have liked to have seen the WinNT/Win2k stuff put in a different file and have kept the specific Win32 meterial in the WINDOWS.INC file but it is too late to change it now. I am not sure of the exact drift of Larry's idea but if I have it right, the idea is to maintain a database so you can dial up the range of include files you need and produce a local INCLUDE file for the project that you are working on. It looks like an interesting idea and if the problems can be sorted out with it, it may be a practical solution to slightly longer assembly time that some have mentioned. I personally have no problems with the existing system, it saves the old TASM style problem of endlessly looking for equates and structures and by using a matching library to include file, you always have the correct prototype for the functions that you call. Regards, email@example.com
I have been working on a similar effort for my code-completion data. The basis for my data is the DLLs themselves. You select which DLLs you want to depend on and the interfaces for that code are imported into a tree structure. I do take into account the type of data that each function needs, but you can override this (like type casting). I'm building a different type of assembler. I'm aiming to have this working by 2004. ;) I'd give more details but I wouldn't want to spoil the surprise. I'm not writing it in assembly because I wouldn't finish in my lifetime! :P
Yes hutch, the idea is generate an include file for use by one job; when the job is done that file can be discarded, but a short script will need to be archived. Conditional assembly will need attention but it won't be a big problem when all the headers are in one database. The dependancy of one symbol on another can be built in to the database (like a calculated field in a spreadsheet). But there will be a few special cases, such as UNICODE: #ifdef UNICODE #define mysym SomethingW #else #define mysym SomethingA #endif This comes up a lot, but the generated inc file won't contain the constant UNICODE (unless the user wants it). The current windows.inc, and my demo version, assume that unicode is not in use. Compile time might not matter much, but even 3 seconds times a thousand builds is fifty minutes, after all. The main attraction will be ease of maintenance. There are lots of easy ways to put consistency checks in a database, particularly against the simplest and commonest errors: typos.
www.hammick.com/hcs/WINDOW_T.ZIP contains a second version, this one retaining calculated fields like "mysym OR sym2 OR sym3". Everything appears in the same order as in icz's, except that duplications have been omitted and a few missing constants have been inserted. Some structures were omitted from WINDOW_S.ZIP because of a fault in my dumping program. I will have a fixed version up shortly. (Edit) I forgot to mention that this WINDOW_T file has hex numbers where appropriate. It still has a problem in equates to negative numbers -- will fix shortly. This message was edited by Larry Hammick, on 6/15/2001 7:20:12 AM
An idea for someone like Betov is to add into the assembler an option that would build the unique project inc on the fly. So it'll start empty, and any equates that cannot be found are fetched from a central source. Kind of like caching it :), subsequent builds would be faster as long as no new equates are needed! Obviously this is only an option if you can modify the appropriate pass of the assembler. Just an idea really Mirno
I agree, Mirno. Eventually it will be possible to fetch equates and structures as-needed. And it is possible to do without include files at all. (Edit) Okay, WINDOW_S.ZIP and WINDOW_T.ZIP are both up. In my haste I might have committed a blunder or two. Anyway, WINDOW_T.ZIP contains the tidy version in the style of icz's. I'm sure this board can make at least some use of it. This message was edited by Larry Hammick, on 6/15/2001 8:43:26 AM
Ernie, I have 1G PIII and 512MB RAM... perhaps you could buid your project here and see if it still takes few inutes :P Everyone else, I like the idea. The idea of real-time inc generation before the assembly. That's cool. But for code completion programs, it needs a pre-defined .inc file. Since many don't use them, it's prolly not an issue. _shawn