Hey hutch check this out-

chage your l2extia pgm so it outputs like this:

externdef _imp__SomeFunction@8:PTR pr2
SomeFunction equ <invoke _imp__SomeFunction@8,>

beter yet use my invoke macro which allows immediate strings...

invok macro _func:req, _args:vararg
ifb <_args>
invoke _func
else
$invok equ <>
irp $v, <_args>
$invok catstr $invok, <,>, @str(<$v>)
endm
invoke _func $invok
endif
endm


SomeFunction equ <invok _imp__SomeFunction@8,>

usage:
SomeFunction arg1, arg2

! NO NEED FOR INVOKE !

voila!
Posted on 2002-06-24 04:16:29 by gfalen
But then it would be difficult to differentiate between api calls and macros.

Btw, do you have a macro reference that's more in depth than the masm32.hlp file?
Posted on 2002-06-24 15:21:24 by grv575
Hello grv575.

That may be true but i for one like the idea of not needing "invoke". It makes everything tidier and more professional. Plus it will be much easier to cut and paste C/C++ code (such as from the MSDN/SDK docs).

It's just a matter of changing the INCLUDE environment variable (i don't use paths in my source) to chooose which method to use.

Actuallly i just realized i can just do a global replace "<" with "<invoke " in my editor. No need for a change in l2extia - cool.

Regards.
Posted on 2002-06-24 15:39:43 by gfalen
I made the changes and stored the new files in Include\Incx. I then modified generic.asm ( something simple) to the new style and it works perfectly.

Now i'm gettin excited!
Posted on 2002-06-24 16:30:24 by gfalen
gfalen, I like the idea, too. It is very similar to the macro I wrote for DX objects, which abstracts the calling macro away from the method and sets the object type for all methods. But for those new to Win32 or ASM, I can see how confusing and convoluted all these macros are. :grin: Macros let you slap programs together quicker, but they are very limited in helping speed up a program. We need access to the internals of the assembler from the macro language, imo.
Posted on 2002-06-24 16:43:34 by bitRAKE
Hey bitrake.

It's the same argument that can be made for "do i use C or asm?". There are times when speed is relevant and times when it is not. For those times when it's not, it's nice to have a simpler (ie. more sophisticated) interface IMO. I definately believe in relegating all the drudgery to an .inc or macro or whatever whenever possible.

You're right about the newbies. But if set up correctly you can have it assemble either way with just the change of a switch somewhere (I am defining - _INCX=1 to cause assembling with the new .inc files.) So the new guys can "grow" into it at they'tre own leisure.

As i said in the previous post i compiled the "generic.asm" file without problems. I'm in the process of making it usable so i can post it (i had modified it before to use my system & macros & .inc files which are specially contrived for me). Now i have to put things back the way they were originaly - DUH.

Should be ready to post it after dinner - hour or so.
Posted on 2002-06-24 16:58:31 by gfalen
Ok here's the files. Let me know if it does'nt work on you're system.
Posted on 2002-06-24 18:00:55 by gfalen
When i wrote the code for l2extia.exe I also modified a version so that the prototypes included the "INVOKE" statement with it and you could call imported functions without the leading invoke.

It has this problem in that it does not work with local functions or libraries that have code in them (static libraries) so while it is an attractive method for imports, it cannot replace the local and library functions. It would also break an enormous amount of existing code so it will not be introduced into MASM32.

Regards,

hutch@movsd.com
Posted on 2002-06-25 07:28:45 by hutch--
That's a shame, because it really does make the code a little more simple to read (if just a little).

Sliver
Posted on 2002-06-25 07:33:16 by Sliver
The solution around the local function names and library functions is to use a slightly different naming convention for the functions/procedures something like as follows.


Paint_Proc equ <invoke _Paint_Proc,>

This works OK if you wanted to change the entire architecture of an application and the code is a bit easier to read but the general comcept is a problem in that so much code has been writen using the conventional INVOKE syntax that it would cause a lot of problems.

Regards,

hutch@movsd.com
Posted on 2002-06-25 08:11:35 by hutch--
Point taken hutch. However if someone is going to go to the trouble to use the l2iexta format (i'm playin with it now), he might as well have the invokes too.
It is a fairly simple matter to do a global replace on the .inc files (this is what i did). Then I go through an example file selectively deleting the invokes that call API unctions.

I use a header file - app32.inc - which sets everything up for me. If it sees _INCX defined, it uses the new format otherwise it uses the old.

At any rate i have a few suggestions for you.

Heres a better (IMHO) way to make the pr0..pr24 typedefs. This method solves 3 problems at once.
It creates the typedefs pr0 through pr24
It creates ptr typedefs ppr0 through ppr24
It creates equates for protos of 0 TO 24 args so you can say

WndProc proto4

instead of the longer normal way

dllproto macro _count  ; name it what you will

$args equ <proto>
repeat _count
$args catstr $args, <,:dword>
endm
cnt@ textequ %_count
% pr&cnt@ typedef $args ;; pr0, pr1, pr2...
% ppr&cnt@ typedef ptr pr&cnt@ ;; ppr0, ppr1, ppr2...
%proto&cnt@ equ <$args>

endm

i@ = 0
while i@ lt 25
dllproto(i@)
i@ = i@ + 1
endm

... also you might want to add this to the top of windows.inc

ifndef @Model
.686
.mmx
.model flat, stdcall
option casemap :none ; case sensitive
endif

Posted on 2002-06-25 08:13:01 by gfalen
Greg,


ifndef @Model
.686
.mmx
.model flat, stdcall option casemap :none
endif

A lot have people have wanted this mod done but I am of the view that each project should have its own processor model defined according to the need of the programmer.

It easy to add all of the latest stuff, .XMM as well but some may wish to target early pentiums or even a 486 so it is a decision that is best left to the programmer.

The real problem is that changes to existing architecture break a lot of existing code so I have not chanjged the original design since the first version of MASM32.

There is of course room for individual preferences but these will be written by the programmer, they should not be forced to use a particular architecture as the package comes.

Regards,

hutch@movsd.com
Posted on 2002-06-25 08:43:56 by hutch--
The cpu can be changed at any time after the .model directive. It MUST come before it for 32 bit segments - ie. flat, but after that the programmer is free to change it at will.

Besides the "ifdef @Model" line prevents it from executing if the user has already defined .model. So it won't break any existing code - ie. the examples.
Posted on 2002-06-25 08:47:11 by gfalen
Hello Gfalen

Remember a few month back Hutch was having bandwidth problems ... By doing every thing out of his own pocket i think he came up with his ONLY solution, and that was to make the package as small as possible but strong as ever without going overboard ... Well it's my guest that he can't add another 100k or 200k more to it the package ....

But if incx.zip prove feasible along with other ideas maybe someone down the line would have a special package that can assist masm32 on the side lines....

Just a thought

Posted on 2002-06-25 11:01:27 by cmax