Idea for the next version of WINDOWS.INC

[Shantanu Gadgil]

Hi everybody...
The explanation could be a bit long...do read on :)

Firstly...the problem scenario...
1. WINDOWS.INC growing in size to a *wee* bit difficult-to-mange size
2. Missing stuff like equates, structures, etc which everybody wants

Then...the accolades...
thanks to _all_ those who have contributed in making the WINDOWS.INC as it is today.

Accolades out of the way...:) the problem still remains...right ?

How about if we (all the users who are on the forum) decide to contribute in making the next INCLUDE folder for masm32 ?

Waiiit !!! What am I saying, "the whole INCLUDE folder" ??? YES !!!

Easy to say...how to actually do it ? It could be done as...
One person takes care of one .H file from the actual Platform SDK!
One person gets assigned one .H file from the Platform SDK and submits it at a common "repository" (or whatever) which will overseen by the moderators !!!

How does this "assigned" thing happen???

Well like beta testers sign up for software testing, members will sign-up !!!

People from all over the world contributing and the conversion should be done quite speedily :)

While doing this what we could also do is...keep the version/#ifdef checking in the .INC files...the WINVER, UNICODE, _WIN32_WINNT, _WIN32_IE, etc, etc. Nothing should be missed !?!

Before all this can actually get off the ground...something that might need to be done on the moderators' part.

Some ground rules...
1. Some definite software to use to convert the files (say thINC, etc).
2. if there is a naming conflict...like the "cx" member of some structures, it becomes either "_cx" or "lx". (Thats already been done for listviews,etc , anyway)
3. A general FAQ for any more doubts that might come up during making the .INC file from the .H file


Obvious incentives for the contributors...:)
1. Their name appears in the list of contributors, corresponding to the .H file which they did the work !!! (So everyone knows who to blame ;) ;) if something is wrong in that file)

Looking at the rough idea so far...one definite advantage would be that the WINDOWS.INC would reduce in size !!!

Problems...
break in existing code...but better maintainability for the future ! Right?

Anyway...this is a rough idea of what can be done...Any thoughts ?

[Vortex]

Hi Shantanu,

Hutch takes care of the windows.inc file as it's the major part of the masm project. You can report Hutch the missing equates, plus there are tools to generate include files from import libraries.

[Shantanu Gadgil]

that I know...:)

What I am saying is distributed work will give better results !!!

For now...I don't have any requirements wrt the missing equates and stuff...but from time to time they (missing things) are needed :)

Again...the point was about everybody contributing to reduce hutch's workload :)

[rea]

I guess the best will be have a parser that can suport from C.

typedef, struct, union, enum, #include, #define, #undef, #ifdef #endif

By the way, you normally to C compilers can say that you only whant preprocessing.

You can get in that way:

the struct defined, the unions defined, the enumerations defined, the definitions done per file following #include directives I guess in that way should not be a project, you can take the includes of x SDK (OpenGL, DX, Win32, DDK) pass the initial file, the tool do his work, make a output in a directory called asmincludes and tada, you have each include file defined.


The question is what more you need to know from a include file from C???? is there other important directive to the preprocessor to take care of it???

[hutch--]

While I would like to be able to delegate the workload on WINDOWS.INC, it is a genuine PIG of a file to edit then test and if you get it slightly wrong it will break a lot of code and dump screens of junk with failed builds. There are a large number of people who use it so it MUST remain reliable for ALL of the code that depends on it. The problem with spreading it around is synchronisation of what is added where and this is almost impossible to achieve.

I have plans to create a later main include file that works on XP and later so that WINDOWS.INC can be finalised as this would save a lot of headaches and place all of the newer stuff in the later file. This allows all existing code to work but if you need later version specific stuff, you set an equate and it will be included.

[rea]

Why not use the automatic way?

Eg, get the SDK for windows, then you have two options, run a C compiler indicating taht you whant the preprocessed file or the more interesting I think, the parser that only take care of the anterior ones c keywords (and pheraphs another things?), and this will automatically  convert include files to include files for asm?

For example: Windows include N files, then in the asmincludes directory, aparte of the windows.inc you will have the other N files (if the preprocessing get them), also you can list what files in the current dir where not touched or translated by the tool, I supose, dont know will not be dificult, because you only need take care of the defines, typedefs (for size) structs, unions and enumerations, all the other (codes can be ignored)... except some macros for the C preprocessor that are defined with the same keyword #define they should be a problem... altough not at all, because normally a macro have arguments () and you can identificate, and put a warning for a manual translataion of such macro....


What other thing should be taked from the C grammar/sintaxis?????, by the way, if the tool is sufcient configurable, then can be used for allmost all the assembler (only retarget the output), for example, members wit cx replaced with X thing that need masm for compatibility....

By the way, you can provide the include file warning that pheraphs is not compatible with anterior ones?



I have watched at the include files of diferent compilers (ok only gcc and lcc) they are both diferent, but I guess they try emulate the definition of SDK... I guess youknow best than I the licensing..., there is a licensing or some that stop me ... ok stop the tool for process this file and output a translation of the header to the X language that I whant?

[hutch--]

I already have fully automated software that uses CLEXE to extract all of the structures, convert them to MASM and then check for duplicates. Then you have to test for reserve words that the SDK header files use that MASM cannot and manually chance all of them and this is while ensuring that backwards compatibility is retained.

[rea]

The duplicates you are referencing, how they are produced?? I guess is because there no exist a like emulation of #define??? or what?



I only have a final question, from where the "diferences" come? (dont know how to explain)... from where the parts (structures that are uncorrect) come?, is because include files dosent include it? or from where they come, I dont fully understand this part of support :S?

[Vortex]

I already have fully automated software that uses CLEXE to extract all of the structures, convert them to MASM and then check for duplicates.

Hi Hutch,

Do you intend to release your tool to public?

[hutch--]

Vortex,

Tools plural and they are bad mannered, hard to use and dedicated to the task written in multiple languages splattered around my machines. The documentation would have to be written and this would be a bigger task than the software.

[Shantanu Gadgil]

to hutch...
agree to the part where it has become a sort of PIG :)

In the current INCLUDE folder, the .inc files except the WINDOWS.INC contain only PROTOs, no structures or defines. The filesizes are a bit skewed aren't they ? the other INC files are teeny as compared to the WINDOWS.INC, which is as you said it, a PIG !

Almost feel sorry for the other files :)

The idea of emulating (trying to be like :) ) the actual MS Platform SDK popped into my mind when I was _*browsing*_ the platform SDK .H files, hunting for some stuff.

I see some of the problems...I agree that it will break a lot of code...but aren't the advantages much more ? :)

The distibuted thing...one person one file...converting a .H to .INC could be tried as a separate *mini-project* when you get time to make plans as to how it would be managed on your end (managing uploads, etc)

[hutch--]

shantanu,

The process of having one include for each library has been very reliable so there is no real reason to change it as you can only lose reliability doing it. It also allows you to dial in the include you need for each library so you don't end up including the lot through include nesting. The other factor is this system has been in place since the MASM32 project started and changing it would break a mountain of code so there is no point to doing it.

The problem has ended up that WINDOWS.INC is very hard to safely edit so the model I have in mind is not to keep adding to it but to finalise it and have a second include file with equates and structures in it that has the later info from XP and server 2003 in it. I favour a file name like "nt5.inc" and have it included by setting an equate so that it is called in the correct order from WINDOWS.INC.