I need the help of some of the more experienced programmers to test a new utility that creates INCLUDE files for MASM32 by using EXTERDEF format.

The utility is L2EXTIA.EXE and it writes a complete set of include files in the following format.



externdef _imp__AbortDoc@4:PTR pr1
AbortDoc equ <_imp__AbortDoc@4>

externdef _imp__AbortPath@4:PTR pr1
AbortPath equ <_imp__AbortPath@4>

externdef _imp__AddFontMemResourceEx@16:PTR pr4
AddFontMemResourceEx equ <_imp__AddFontMemResourceEx@16>

externdef _imp__AddFontResourceA@4:PTR pr1
AddFontResource equ <_imp__AddFontResourceA@4>

externdef _imp__AddFontResourceExA@12:PTR pr3
AddFontResourceEx equ <_imp__AddFontResourceExA@12>

externdef _imp__AngleArc@24:PTR pr6
AngleArc equ <_imp__AngleArc@24>

The method that I have tested it with is to make a new INCLUDE directory so that the existing one is not messed up, copy the current WINDOWS.INC to it and add a macro that is enclosed in the WINDOWS.INC file. Run this utility from the INCLUDE directory using the path of the LIB directory in the format,

L2EXTIA drv:\masm32\lib\*.lib

and it will create a complete set of include files in this format. The difference with using this format is that you get a direct call to the function which is different to the jump table that MASM normally builds with normal prototypes.

The code is no different, it uses the existing MASM invoke syntax and it has all the advantages of parameter type and count checking.

The only problem I have encountered with it so far is a few naming conflicts from modules in the MASM32 library. I renamed the functions in the ASM code and they then built OK.

Please let me know if this new system is working OK, there seems to be a demand for this capacity so I have written the utility to make it possible on a global scale across the windows APIs.

Regards,

hutch@pbq.com.au :alright:

NB: Please use the later version attachd to a message below.
Posted on 2001-07-20 23:50:23 by hutch--
hi hutch

some problems exist when including ole32.inc. Getting errors

Copyright (C) Microsoft Corp 1981-2000. All rights reserved.
Assembling: globals.asm
\masm32\include\ole32.inc(2) : error A2005: symbol redefinition : BindMoniker
\masm32\include\ole32.inc(17) : error A2005: symbol redefinition : CLSIDFromProgID


problem seems to be prototypes of this functions already defined in windows.inc

(by the way: line
ListView_SetExtendedListViewStyle PROTO :DWORD, :DWORD
in windows.inc is incorrect because this is not a real function but a message cracker)

japheth
Posted on 2001-07-23 07:36:21 by japheth
japheth,

Yes I found them, I did not know that Iczelion had put prototypes in the end of WINDOWS.INC, it was originally intended as a file of equates and structures only.

The format of the EXTERNDEF prototypes is not tolerant like the normal type that allows benign redefinitions so they would have to be removed to use that library.

It looks like the prototype format is working OK though, everything else seems to run OK.

Thanks for your feedback.

Regards,

hutch@pbq.com.au
Posted on 2001-07-23 08:44:27 by hutch--
What is the advantage to this alternative method?
Does it produce smaller (a definate plus) or faster code?


Give a man a fish he eats for a day. Teach him to fish, he steals half you're buisiness


G. Falen
Posted on 2001-07-23 09:21:24 by gfalen
Greg,

Its a technique that many people have wanted to try, I personally prefer the normal prototyping where MASM uses a jump table at the end of the EXE file but in keeping with the flexibility of a modern assembler, the alternative method is available.

Regards,

hutch@pbq.com.au
Posted on 2001-07-23 19:59:45 by hutch--
This is pretty selfevident but might be worth mentioning... you have to replace the new masm32.inc with the original one... some people might as daft as me and forget about that.. :)
Posted on 2001-07-24 02:39:33 by NervGaz
hutch,

i cannot find some prototypes in new generated kernel32.inc. Seems that all functions with no parameter are missing (GetProcessHeap for example)

japheth
Posted on 2001-07-24 03:02:48 by japheth
japheth,

Thanks for finding that, I must have messed up the filtering somewhere. Its an unusual one in that a lot of functions with no parameters are included and working fine.

Regards,

hutch@pbq.com.au
Posted on 2001-07-24 04:49:54 by hutch--
OK,

I have tracked down the problem, the filtering was a little overzealous and removed a duplicate that did not have a trailing "A" following it and it filtered out a number of valid API names.

I have included the new version and versioned it as 1.0a so it does not get mixed up with the old one. As before the included macro must be called BEFORE any of the include files that the utility creates and what I have done for testing is to place the macro in the windows.inc file and put all of the includes in another directory so they dont mess up existing includes.

The prototypes at the end of the windows.inc file should be removed as they are duplicates of one of the existing include files and cause redefinition problems. Nervegas is correct, the MASM32 library has to be rebuilt and what I did was put the include line for windows.inc in any that use the generated includes so that the macro was available for the include file that is called.

I find that a lot of code builds OK but some libraries when included cause a problem in windows.inc about structure redefinition and I have not tracked this down yet.

Regards,

hutch@pbq.com.au
Posted on 2001-07-24 20:26:23 by hutch--
Hello !

I like your ambitions to make masm jumptable free. therefore I try to integrate the extern deklarations into my directx8-exploration.
but there's a lib (d3dx8.lib) with which your tool produces only crap (some ascii-texts followed by byte-confusion)

Perhabs, somebody knows a solution ..?


Greetings, CALEB
Posted on 2001-07-29 17:39:25 by Caleb
Looks OK so far hutch. I've tried it on a handful of Visual Studio 6 lib files, without any problems. :)
Posted on 2001-07-31 07:53:17 by S/390
Caleb,

The limit of the tool is that it only works on import libraries that contain decorated names in the form _Function@16_ where the trailing decimal number is the byte count for the paramaters. What it does is read the import names and converts the parameter count into DWORD parameters so,

_Function@16_

becomes

Function PROTO :DWORD,:DWORD,:DWORD,:DWORD

or

externdef _imp___Function@16:PTR pr4
_Function equ <_imp___Function@16>

The trailing decimal byte count is the only information available for setting the parameter count so if the format is different, it will not work. I will see if I can find the library to see what has happened because it should have filtered the error out.

S/390,

Thanks for testing the include files for me, they seem to be working OK but I get the impression that WINDOWS.INC will need some editing to be compatible with the format that these include files use.

Regards,

hutch@pbq.com.au
Posted on 2001-07-31 20:58:01 by hutch--

What is the advantage to this alternative method?
Does it produce smaller (a definate plus) or faster code?




G. Falen


ask yourself what is smaller or faster
1. jmp label
.....
label: call

======
or just
2. call
=======================
To Hutch
Steve, you've done a big thing.
Considering the fact that doing it you stepped over your personal preferences it owes a great respect.

I encounterd the style first in iAsm.
And then we mannaged some macros to check parameters passing.
After I'd come to your wsite, I saw there your mentioned EliCZ iAsm. And wandered why didn't gave it as the second of calling API system. But never asked :)

The second question was about m32lib style.
The thing is that I was somehow trapped to convert some of my procs into m32lib style. I often avoid making explicit stack frame where it is not absolutly nessesary. It saves some size end speed, not, actually, a big deal talking of a proc itself but I always keep in mind of comulative affect and in a big prog with rapid calls of small procs in gives noticable effect.
But I thought that m32lib is serving two perposes
1. Practical
2. Educational.
And for not very expirienced programmer it's easier to read and analyse code in dissasm mode if there is always typical MASM stack frame construction while working with passed parameters.
Actually masm (and it is not bad) is assembler and as assemler writes PREDICTABLE code, to give control to programer (otherwise why do we need asm?) and as a result of it all HLL stuff, along with passing parameters and stack creations is far from optimal (to say the truth it is worse than any HLL compiler produces).
So I was like Booridan donkey - I hesitated to say about it cause thought you have very good reason to keep it that way(for example I, myself, send example code using .if uMsg == ... .elseif uMsg...
and in practice in my work I never use such caseswitch but I think I mention it some month ago, and here I use it just 'cause most people get used to it and talking of particular thing I may do it to
abstruct from something not related to the issue)
And in other hand I just couldn't brought myself to change it m32lib style :)
So my inner dramatic conflict was unseen :)

Good luck.
The Svin.
Posted on 2001-08-03 02:34:12 by The Svin
For users of TD32 -
there may be problems with correct return while using
TD32 in step over (not trace) mode over API calls
The program may works OK though after such steps
in td32 you'd get GPF as reading at address 0x00000

The Svin.
Posted on 2001-08-09 09:28:48 by The Svin
ask yourself what is smaller or faster
1. jmp label
.....
label: call


Actually, it is:

1. call label
.....
label: jmp :)
Posted on 2001-08-09 12:35:25 by bitRAKE
You are right, of course :)
Posted on 2001-08-09 21:57:34 by The Svin
Ok, I don't get it...

So, when I use invoke MessageBox, I am actually saying jump somewhere then call MesssageBox? What is faster, and what exactly do you mean?
Posted on 2001-08-30 16:11:57 by Kenny
Oh, and while wer're on this discussion, do you think it's possible to write a program to completely take out the call altogether and write a macro?

Like this:

my program:
invoke mydllcall, data1, data2

my dll:
mydllcall PROC
some display code that write something to the screen.
mydllcall ENDP

Now, what this program does is make a macro that looks like this:

_mydllcall MACRO VARARGS
;push all the args...
dd (the actual hex that used to be in mydll.dll for that call)
_mydllcall ENDM

Ok, I know there are syntax errors here because I don't write in MASM primarily, so just excuse that... What I'm asking is if I were to just take the dll code contents and practially just copy and paste them into my code, wouldn't that save tons of time in a far jump and a far return?

Seems logical to mee:)
Posted on 2001-08-30 16:17:31 by Kenny
Kenny,

2 things, what you are losing with your suggestion is the advantage of creating prototypes and that is parameter size & count checking. Without this you go back to the bad old days of manual push/call syntax with no error checking and very difficult to find bugs as you get no warning if the parameter count is wrong or the data size is incorrect.

Second thing is that in 32 bit FLAT memory model, there are only NEAR jumps so the only distinction you need to take notice of is between SHORT jumps and normal ones and this very rarely ever effects you.

Regards,

hutch@pbq.com.au
Posted on 2001-08-30 20:08:39 by hutch--
dang!

I originally posted the above but I realized I wouldn't be learning anything by swearing :)

So, would it make it faster or not? I just want to know this :)

What's the difference between a near jump and a short jump?
Posted on 2001-08-30 20:19:05 by Kenny