Windows.inc Database Application

[zcoder]

Vortex,
Take the win32api.txt  and try to assemble
in asm with it, it won't work it's in a diffrent
format then what assemblers need. so if you
change the format of what is in the file you
have made something new.

Infact, Microsoft wants you or I or anyone to
do so. Example if I made up a new language
Microsoft would love it if I made their file
compatible to my new Language and
assembler or compiler.

An old saying is, the more support for
a OS the more users will use it.

whis is why Unix or Red hat is not
what everyone is using as the #1
OS, not mush software out their
that runs in it.

If you think about it you should be
able to see why MS does not care
what form you put their win32api.txt
file into as long as you realize that they
retain rights on the contents.

Zcoder....

[zcoder]

Randall Hyde,

Oh, your idea is right and good.

I thought about this idea for about 6 months now. Infact I wrote a simple php script that lets me add( in groups)
the equates, structs, and API's in raw form from the VC++ h files.

Then I wrote a small script to parse some of these out to file in MASM form and it looks promising. So I have been adding to the
database and playing with adding more parsing to the PHP script in hopes of being able to make a windows.inc.

In PHP I can even do string testing easy to tell when an Item should appear in the file. Example is you have to make sure a
Structure, is not placeed in the file before an item in that structure is defined. PHP is good for this.

So I agree that this idea is good for this type of operation. Data base's are good for sorting, and everything like that.

Lets just say I have done this in ASM and C++ trying to sort, convert ect and I get more error's here and there.
but what I have done so far in PHP the output file had been error free and DUP free, so I have been working
harder on this but doing this alone building the database up is slow at best.

Right now I have been making a script to take a H file explode it and place it into the database each struct, equate ect.
I am also storing them all in groups as to what file they had came from as I want INC files in this same structre.
I want all API's, Structures, and Equates in a Found H file to be in a INC file, so I don't have to have a LARGE Windows.inc file.

I am suprised to see that someone had came up with the same idea or at least the idea to use a database to help sort the junk out.


Zcoder....

[Shantanu Gadgil]

I am also storing them all in groups as to what file they had came from as I want INC files in this same structre.
I want all API's, Structures, and Equates in a Found H file to be in a INC file, so I don't have to have a LARGE Windows.inc file.

Yes..yes, I agree and I definitely want to be a part of this one !!!  :green

I am suprised to see that someone had came up with the same idea or at least the idea to use a database to help sort the junk out.

Not a "database" idea...but atleast the grouping thing !!!
(My previous post (and the responses :P to it) http://www.masmforum.com/simple/index.php?topic=98 )

[hutch--]

Most of these suggestions come to grief when it comes to the format of the PLATFORMSDK header files which are a genuine bundle to parse and each successive version gets more complex. Much of the content will not convert to either MASM or POASM format and there are many other complex problems to solve to get much of it to run with an assembler.

Microsoft have long ago given up on H2INC so i suggest there is no simple way to get the data and this is after spending 8 years on the current version. Contrast this with getting the API prototype data from the libraries as its needed by the linker and apart from using a non proprietry method to scan for names that does not get broken each time Microsoft change the library format internally, it has produced super reliable include files for years where each include matches the library it is to be used with.

The current windows.inc is about 1.2 meg which is hardly a problem on modern machines. Include files of that size worked fine on my mid 90s P166 so its not as if its a machine capacity problem.

With the introduction of POASM, it became another problem in that POASM loads a complete symbol table and stops with an error with a duplicate that MASM would tolerate if it did not find the duplicate so I wrote a hash table based duplicate checking app just to solve this problem which either displays the duplicates to the console or automatically removes them depending on the option selected.

What most people don't understand is the massive tme it takes to get this stuff right and every time I have shared this file with someone else, I have had to spend days to weeks to fix it so the version I distribute with the masm32 and poasm projects will not be a collective version as I don't need the extra work.

If the only gain is to be able to ape the problems in using Microsoft C headers where there is no published correlation between the include file you use and the library you use, I just don't want it as the existing method is proven reliable.

[Vortex]

zcoder,

All what I wanted to know was the copyright status of that txt file. Everything is fine for me, now, I know that you can use that file for your own purposes. It's OK for me.

[moldy]

To show you what I meant.

From your windows.inc file
CHOOSEFONTA STRUCT
  lStructSize     DWORD      ?
  hwndOwner       DWORD      ?
  hDC             DWORD      ?
  lpLogFont       DWORD      ?
  iPointSize      DWORD      ?
  Flags           DWORD      ?
  rgbColors       DWORD      ?
  lCustData       DWORD      ?
  lpfnHook        DWORD      ?
  lpTemplateName  DWORD      ?
  hInstance       DWORD      ?
  lpszStyle       DWORD      ?
  nFontType        WORD      ?
  Alignment        WORD      ?
  nSizeMin        DWORD      ?
  nSizeMax        DWORD      ?
CHOOSEFONTA ENDS

CHOOSEFONT  equ  <CHOOSEFONTA>

Now from the vb6 files
Type CHOOSEFONT
        lStructSize As Long
        hwndOwner As Long          '  caller's window handle
        hdc As Long                '  printer DC/IC or NULL
        lpLogFont As Long
        iPointSize As Long         '  10 * size in points of selected font
        flags As Long              '  enum. type flags
        rgbColors As Long          '  returned text color
        lCustData As Long          '  data passed to hook fn.
        lpfnHook As Long           '  ptr. to hook function
        lpTemplateName As String     '  custom template name
        hInstance As Long          '  instance handle of.EXE that
                                       '    contains cust. dlg. template
        lpszStyle As String          '  return the style field here
                                       '  must be LF_FACESIZE or bigger
        nFontType As Integer          '  same value reported to the EnumFonts
                                       '    call back with the extra FONTTYPE_
                                       '    bits added
        MISSING_ALIGNMENT As Integer
        nSizeMin As Long           '  minimum pt size allowed &
        nSizeMax As Long           '  max pt size allowed if
                                       '    CF_LIMITSIZE is used
End Type

All of the definitions in the apiload directory are in this format. Is it not straightforward to extract this into a database (as the original app did) and just copy paste the relevant structures/constants etc into your programs as you design them? (again as the original app did)

As i mentioned in my first post. The vb files are trivial to parse into an ASM format. (as you would expect from such a basic language...whoops bad pun)

Comments and relevant defined values for structures could easily be copy/pasted at the same time.
This would breakdown the incompatabilities between various assemblers and possibly remove the burdon of constantly updating certain include files.

Maybe you could freeze the original includes and recommend using the new include/copy/paste/db to avoid breaking older code.

Again, I hope I am on the same train of thought of you peeps.  :U

[hutch--]

moldy,

The VB file is only a small part of the complete header set from the platformsdk. Basic is very easy to parse where the C++ include files are just about impossible without detailed knowledge of the guts of CL.EXE. The problem is keeping up with the additions every time a newer Windows version is released.