works for MASM programs. :U
But the breakup makes me say a biiiig :) "I told you so....." :toothy :bdg
Initial post...
http://www.old.masmforum.com/viewtopic.php?t=4836
Second one...
http://www.masmforum.com/simple/index.php?topic=98
More related...
http://www.masmforum.com/simple/index.php?topic=486
(I know about the code breakage and all) :'( ::)
...and AGAIN...I would like to say...lets make the include folder the way the MS Platform SDK is arranged !!! :bdg
japheth alreday moving the right direction
http://www.japheth.de/
shantanu,
You may have to get used to the idea that I did not design the include file structure with either yours or Japheths approval and nor am I interested. they were designed long before either of you were ever heard of when no-one had matching libraries and include files for assembler programming.
If you feel that you need to do it another way, feel free to do so like Japheth has done but note which methods has the track record with MASM over the last 8 years. The masm32 project has had two seperate techniques for include files that match the two different prototype methods that masm supports.
Without fail, every time I have accepted modifications to the WINDOWS.INC file in the past, it has come back to haunt me with some massive amount of work to fix it and with this I am not interested either, I have enough to do now.
> But the breakup makes me say a biiiig :) "I told you so....."
I have heard your comments in the past but unless you are willing to put in the man years to manually code and check the sum total of equates, structures and prototypes (both types) you have little to say here.
Then there is the following problem if you try and ape the layout of the C header files, you have no exact mapping from the include file you select to the library you use with it where the method used in masm32 has an exact correlation between both. If you need a function from a particular library, all you need to do is include both that library and its matching include file and you have both reliably.
Having worked with Microsoft SDKs since about 1990 when they cost over a grand US$, it is not a structure that I would wish to emulate in assembler.
Hutch...
QuoteYou may have to get used to the idea that I did not design the include file structure with either yours or Japheths approval and nor am I interested.
OK! FINE!
Quotethey were designed long before either of you were ever heard of when no-one had matching libraries and include files for assembler programming.
not questioning your initial design in any way whatsoever. The fact that MASM32 existed (rather than evryone having to generate their own .inc files) has helped many (thousand? tens-of-thousands?) of people to start with assembly.
The of kind of "pestering" you with the idea is NOT ONLY to be heard...but also to contribute ideas which I feel make sense (only to me I guess as per your "not interested" statement!)
QuoteWithout fail, every time I have accepted modifications to the WINDOWS.INC file in the past, it has come back to haunt me with some massive amount of work to fix it and with this I am not interested either, I have enough to do now.
OK...No more pestering about you about modification of layout!
QuoteI have heard your comments in the past but unless you are willing to put in the man years to manually code and check the sum total of equates, structures and prototypes (both types) you have little to say here.
Why the patronizing talk? :(
Anyway...you are boss...so I guess...it is curtains (door-shut for this topic???)
Note: Topic split as I was typing this...so...question: is it curtains after all or not? :8) :toothy
No, you misread what I have said. The technique of matching include files to libraries made include file automation possible and every install creates its own set of libraries from a set of include files that were automatically created from a reference set of libraries.
The alternative in manually coding a reliable set of include file is literally man years of work and the rate of new stuff coming out with each windows version is faster than you can code manually.
The windows.inc file has some massive amount of work already done on it and recently a lot more as I used to use ML directly to test for duplicates which was not reliable enough for POASM that checks all of the equates. I had to write software that does aggressive duplicate checking to get rid of the rest that MASM would tolerate and the result almost runs as is in POASM.
This stuff has all been learnt the hard way and with every mistake it has taken days to get the structure right again so I am not interested in structural changes that involve some massive amount of work to produce includes that are not as reliable as the ones we have at the moment.