Near final windows.inc 1.4c beta

[hutch--]

This one should be very close to release, I have added about 400k of equates, mainly from Vista includes so it should be reasonably up to date.

What would be useful is some testing across a range of software to make sure nothing clashes when building normal files. I have tested it with a range of my own stuff and I cannot find any problems. I have used a new method of duplicate and redefinition checking that ensures that with each set of additions remain unique so the file should be reliable.

Any testng would be appreciated.

The zip file is now to big to attach to the forum so I have it at the URL below.
www.masm32.com/download/14cbeta.zip

[Biterider]

Hi Hutch
My first test shows the following error
C:\Masm32\Include\Windows.inc(32767) : fatal error A1019: invalid debug and browser data; file exceeds line limit
It seems that the 32767 lines limit per file for ML 6.14 was reached!

Regards,

Biterider

[hutch--]

Biterider,

Thanks for the info but I don't understand the problem, I run it here on any version of ML and I don't get any error. What are you running to get the error ?

[Biterider]

Hi Hutch
The problem arises when you try to compile using the debug options. A release compilation completes without problem.
I used a modified batch file of the C:\Masm32\examples\advanced\msort example of the last MASM32 installation. Attached is the test file.

Regards,

Biterider

[attachment deleted by admin]

[hutch--]

Biterider,

Thanks for the batch file, I can reproduce it with no problems at all. It effects ML versions 6.14 and 6.15, versions above can handle the higher line count.

The only solution seems to be to have a smaller file for debugging. have you tested the file split into parts so no single file exceeds the 32k limit ?

Now this leaves me with a dilemma, there are many equates that almost no-one ever uses but I have tried to supply more than less as I have kept hearing people complaining about missing items.

There are a couple of approaches I can take, use an equate to exclude the less used equates that can be grouped towards the end of the file to keep the line count below 32k or split the file into parts to achieve the same result.

Let me know what you think here.

[Mark Jones]

Hi, as an aside, I wonder if POASM has a similar limitation? It seems our support for Pelle's assembler has been slow to nil lately.

[Biterider]

Hi Hutch
In my opinion there is a simple and pragmatic solution. The Windows.inc file has to be split, but the big question is where.
My suggestion is to organize it the following way:

• at the beginning all typedefs and necessary macros
• then, the most common equs
• finally a series of include files

The last include file series are the translations of the single C header files.
Making it this way, the 32K line limit is only relevant for the included files (which will not be reached in the near future :bg).
Another important benefit is that if you are writing a big project, you can easily create a custom Windows.inc file from the master file by copying it and commenting out the includes you don't need, achieving an important compilation performance boost.

Regards,

Biterider

[hutch--]

have a look at the 2 file solution I have posted in a later topic. They test fine with your debug batch file and don't lose any equates and or structures so it has the advantage of being more complete without the problems of too igh a line count.

[Biterider]

Hi Hutch
Before I made my last post, I tested the 2 file solution to be sure that it works. It seems to be only a per file limitation, so I can confirm that the solution is OK. Nevertheless, you should consider a way to reduce the ML symbol database load.

Regards,

Biterider

[hutch--]

Biterider,

Thanks for confirming that the two file solution is compatible with your own work. I am not particularly worried about the symbol load with ML as the two file solution with the extra symbol count is only in the range of about 40000 which is not a high figure in terms of memory usage for a tool like an assembler. ML uses a tree structure which within boundaries does not have an easily found top limit.

Just with the duplicate checking I use a hash table that for convenience sake is 8 times the line count of the original unsplit file. The technique I am using to build the current pair allows me to stack the order reasonably easily so it was no big deal to set up the most frequently used equates near the front and the long lists of error code and the like towards the end of the second file.

The include / includelib technique that has been used in masm32 since it was first built is more a linker friendly method in reducing the number of files to be searched in the linker phase.