MASM32 include files out of date: what to do?

[NoCforMe]

I realize I'm broaching a somewhat sensitive subject here. The problem is this: the set of include files that all of us who use the MASM32 package are out of date, some of them very badly so, and that causes problems for anyone who relies on them for programming.

The problem is simple; unfortunately, the solution isn't.

I'm proposing a solution that might work. Let me outline it and then let the discussion begin.

Since so many people rely on the existing set of include files, it would be very difficult to upgrade them in any orderly way. Therefore we should consider them "sacred", to be left alone, in their final state.

What we can do instead is to create additional include files that have all the items missing from the existing ones. I've created a (primitive) tool that could be used to do this.

What I've done for myself is to create a file called NotInWindowsInc.inc, and every time I find something I need that's missing from the MASM32 files I add it to this file. Works well for me.

The tool (attached here) is just a simple .asm program that uses the assembler to find any items not in any of the MASM32 include files and output those items. It's then easy to put them into the auxiliary include file. This .asm program has the items to be checked (EQU statements) coded into it. Primitive, I know: I'm sure someone could come up with a much better tool here. This is just for demonstration purposes.

Some details about the include file problem:

There are three types of items which may be missing from the include file set:

• Symbolic constants (EQUs)
• Structures or structure members
• Windows API functions

Regarding the last, my suggestion is to ignore that for this project. Including missing functions is a much, much more difficult problem to deal with, as it must include code libraries as well as just the include files. So let's leave that out of the equation for now.

My tool can really only deal with missing EQUs. Structures and structure members must be added by hand. Maybe there's a way to at least semi-automate this, or maybe not. In any case, structures need to be brought up to date as well.

So here's my proposed solution and a demo tool. If anyone has any better ideas, let's hear them. I'm not at all attached to my ideas here.

Regarding this project, another thing needed is someone to take charge of this. Whoever leads this project is going to also have to do some testing to verify the new include files. That person won't be me. Sorry, but I'm just not interested in taking on that responsibility. So if anyone wants to take this on ...

Note:: You need to give the name of the .asm file to the batch file, minus the extension:

Code Select Expand

e:> notinwindowsinc NotInWindowsInc


[jj2007]

I agree with your approach. Fumbling the Masm32 SDK would be a nightmare - I have several thousand sources that rely on it. So adding what's missing in a separate file is the only serious option IMHO.

What I usually do is adding structures and interfaces into the source I am working on. If it appears that they could be useful for other kinds of code, I add them to my library.

Structures and structure members must be added by hand.

See e.g. the COM Interface plugin. That is a RichMasm plugin, so not that accessible for most of you

In contrast, the attached CStruct2Asm is a standalone tool.

[daydreamer]

I used approach of backup previous windows. Inc and added lots of d3d includes before

Other approach I used is an extra. Inc files containing things I want to add and keep out of main. Asm file
For example Winapi change screen resolution, needs a big structure filled in, before invoke

[jj2007]

I used approach of backup previous windows. Inc and added lots of d3d includes before

Which makes your code incompatible with the rest of the forum.

Other approach I used is an extra. Inc files containing things I want to add and keep out of main. Asm file
For example Winapi change screen resolution, needs a big structure filled in, before invoke

This is what NoCforme proposes, and I agree.

[_japheth]

This thread belongs to the Masm32 sub-forum. It's neither of general interest nor does it cover a "Windows API" problem.

So please move it!

[stoo23]

Gee, is that a Request? or a Demand ??

I think I'll refer that 'Action' to the OP and other members who have 'engaged' in the discussion prior to moving it.

Thank you for your ..... 'input'.

[jj2007]

I think I'll refer that 'Action' to the OP and other members who have 'engaged' in the discussion prior to moving it.

There is a perfect place for discussing an updated Windows.inc, and it's here in the Windows API section

[_japheth]

Gee, is that a Request? or a Demand ??

Hm - what's the difference between those? ... I guess it was an ordre du mufti

Thank you for your ..... 'input'.

My pleasure.

[stoo23]

Hm - what's the difference between those?

What ?? Really ??
Request
an act of asking politely or formally for something.
Demand
an insistent and peremptory request, made as of right.

I guess it was an ordre du mufti

Whilst I did study German way back in high school, I'd suggest a more appropriate communication could be made Without the use of esoteric German idioms.

Regarding:

It's neither of general interest

Well, with reference of other senior members;
The Windows.inc is an essential part of the Masm32 project, so it cannot be of no interest.

nor does it cover a "Windows API"

Perhaps you are correct

This thread belongs to the Masm32 sub-forum

Once again, perhaps Technically, you are correct ....

But as you appear to enjoy being pedantic,...
Belongs to is generally possessive:
Belongs in indicates that something should be in a certain position:

Just as I imagine, would be the case with yourself, perhaps a friendlier, less confrontational, more 'conversational' and Polite Suggestion of possible Action, may have been met with greater 'consideration'. Few people actually Like 'Being TOLD'.
As stated, I will consider taking whatever 'suitable' action is deemed to be appropriate, based on both the OP's wishes for Where the 'thread' should reside as well as those 'actively' involved in the discussion.

Considering the 'Mess' many other sections of this forum Were (and in many cases,) still are Plus the fact (as stated by yourself) it is of No Interest, (and there I am unsure whether you mean't merely to yourself or to anyone in general), then (with the greatest of respect), I do not understand Why it should be of any concern to yourself.

I have taken your concerns and 'Suggestion' on board and have stated my intended course of action. I will leave it to 'NoCforMe' and others to reply further to your concerns.

[HSE]

 

Indeed is more related to "The MASM Forum► Projects► MASM32► WINDOWS.INC Project"

But is mostly irrelevant where 

The only really "curated" section must be The campus, others sections from time to time 

[jj2007]

esoteric German idioms

The odd thing here is that it is "French German", i.e. French words used exclusively by Germans.

Examples:

"And yet, disregarding the student majority vote could be dangerous for tuition fees as a whole: Because the more often decisions are pushed through par ordre du mufti, the more the already low acceptance of the campus toll dwindles in view of anti-social student loan models."[2]
[1] "Without asking the parliamentary group, the two were dumped par ordre du mufti in a backroom manner: Both received offers they could not refuse."

The English Wiktionary explains "mufti" and says explicitly that it's "German", i.e. not Arabic (but of course, of Arabic origin).

Normally, I think we should stick to English, but from time to time an excursion into other idioms can be fun. For example, see how DeepL.com translates Japheth's signature "Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht":

Stupidity paired with audacity - a terrible power

Can't we all agree on that?

But is mostly irrelevant where 

Agreed

Keep up the good work, Stewart

[NoCforMe]

OK, simmer down now.

I had forgotten about the WINDOWS.INC Project forum. Maybe that would be a more appropriate place for this thread. Interested to hear what you think, JJ.

I don't really care; I just want this problem attended to.

[NoCforMe]

Further thoughts:

How to harvest all the missing items?

Rather than have the person in charge of this project find all the missing stuff by themself, better to have members submit items they've found to be missing. There are far too many potential missing items for one person to be able to find them all.

Other thoughts:

• Name of file: my name (NotInWindowInc.inc) is no good. Something like WinMissing.inc or WinAux.inc would be better.
• One file should be sufficient; there won't be anywhere near the number of items in windows.inc.
• File should contain some kind of date/version info. in a header at the top.
• File should use tabs, not spaces! Please god, no spaces. File size & readability.

Another pet peeve of mine: currently in windows.inc I find things like this:

Code Select Expand

Black                  equ 000000h
CDDS_PREPAINT          equ 00000001h
In my book this is just plain stupid. It's a carry-over of what I call C paranoia/anal-retentiveness. My preference: any numbers between 0-9 get defined as just plain decimals (because 00000000H == 0D == 0H. And please, please strip off those totally unnecessary leading zeroes (but one if it's a hex number that starts with A-F). But of course this will be up to whoever takes charge of this project.

As I see it there are only two types of items to be compiled, EQUs and structures. Both can be submitted by members in their simplest forms, just as they would appear in the include file:

Code Select Expand

SPI_GETCONTACTVISUALIZATION            EQU 2018h
SPI_GETGESTUREVISUALIZATION            EQU 201Ah

PRINTDLGEX        STRUCT
  lStructSize        DD ?
  hwndOwner        HWND ?
  hDevMode        DD ?
    .....
  nPropertyPages    DD ?
  nStartPage        DD ?
  dwResultAction    DD ?
PRINTDLGEX        ENDS

Whoever becomes the Ayatollah in charge of this project gets to make all these choices, as well as using their preferred tools to get the job done.

So anyone want to step up? We can't pay you anything, but you will definitely have our undying gratitude for doing this!

[jj2007]

WinAux.inc would be better.

Fine for me.

One file should be sufficient; there won't be anywhere near the number of items in windows.inc.

WinAux.inc plus ComAux.inc

File should use tabs, not spaces!

Agreed.

[sinsi]

Another pet peeve of mine: currently in windows.inc I find things like this:

Code Select Expand

Black                  equ 000000h
CDDS_PREPAINT          equ 00000001h


Just a note, hutch had a (mostly) automated way of parsing .h files, so what you see is probably how they appear in the header file.
You could also cut the file size down by using "Black=0" instead of "Black equ 0", but where do you draw the line?