While preparing the final release of fasm 1.52, I have mode also some changes to the Win32 includes that are the part of FASMW package. Some of them are improvement that utilize the new features of 1.52, so these includes won't work with previous fasm versions (before the official release you can grab the beta of fasm 1.52 here).

The "fixed" behavior of "include" directive allowed to simplify the main include files by using relative paths. You could even get rid of FASMINC variable by adding that path into your INCLUDE variable and using includes just like:

but FASMINC variable is still needed for WIN32AX.INC and WIN32WX.INC to function properly. Using relative paths there would make use of the INCLUDE variable necessary, so we have still to decide if we stay with current FASMINC, or go for the simpler INCLUDE (it no more causes problems, as fasm handles INCLUDE variable as all the other compilers, treating it as a list of path separated with semicolons). What do you think?

The most important change, that affects the compatibility (that is: it makes the old sources incompatible with new includes, but you can fix it with only small changes) is in the "proc" macro. Now it is much improved, but it needs the "endp" macro to be used at the end of procedure (similar to the standard which Fresh uses). The new "proc" makes the names of parameters and "enter" and "return" macros local to the procedure, also you don't need to use "enter" macro unless you want to declare some local variables on the stack - if you don't put "enter" macro between the "proc" and "endp" macro, the procedure entry point is just assumed to be at the first instruction after "proc". Here are samples from the ERRORMSG example modified to work with the new includes:

Second procedure doesn't use any local variable, so also "enter" macro was not necessary.

The "export" macro, thanks to use of the combined "load" and "store" tricks, is now able to sort the string table properly, so you no more have to worry about it. Also, the ordinals are preserved according to the order in which you put the functions after the "export" macro. At the same time, new "import" macro allows you to import by ordinal. For example, the export section of ERRORMSG.DLL example DLL may look like:

And you can import the ShowLastError function by ordinal this way:


Also, as the new macros use the macro-inside-macro trick, the new includes package contains the FIXES.INC file, which has to define some standard fixes for this purpose (it will get expanded later with more of them, to much some kind standard, as it was already requested by some users).

Please post all your comments or suggestions (or even own additions) here. I know that at least RESOURCE.INC needs some more additions, I'm working on them.

I miss in standards the KevinZheng's unified call macro.

It is very useful. i.e. I move some functions to a dll and the code that call them does not change; the code looks homogeneous and I save typing; people that likes invoke/stdcall instead are not affected in any way.

Nice work. Just one suggestion, how about one more level to the fixes so you can include them first and use them even after including win32*.inc?

And can i include your macros in our StdLib? Haven't looked deeply in your files yet, but i can say that the new export macro would be nice addition.

Looks nice, especially sorted export directory. Will new proc macro cause incompatibility with old one? If you use enter with no local variables, will it generate unneeded code?

Will the 'enter' macro clash with the x86 instruction of the same name? Perhaps it would be better to call the macro 'stackframe' or something similar?

"enter" macro doesn't interfere with the x86 "enter" instruction - if you use it as an instruction, with both required parameters, the macro passes it to original instruction handler.
In case when you don't define any local parameters, "enter" macro doesn't generate any more code than in case of proc without "enter" macro at all. Also, if you define proc without any parameters nor local variables, the stack frame won't be set up at all.
And if you don't use your procedure at all, its won't be put into output at all - the same as it is with Fresh macros.
New "proc" macro is almost fully compatible with old one, you only need to add "endp" at the end of each your procedure.

I think that's unnecessary

But does it hurt? It's just to make the JohnFound's idea of source libraries possible with those includes.

How about changing:

to:

Then if one wants to include all of his procs he/she just needs to add line 'PROC_INCLUDE_ALL = TRUE' after including win32*.inc

Or:

You can add it on your own if you need it.

What is your opinion about making the includes to use INCLUDE variable only?

Please keep as it is.

I use different set of macros for different source styles (fasm official, fresh, my own) so the selection is in the interested source file.
Having to edit environment variables or IDE settings is unlikely for me.

Thanks,

Why do you now use retn instead of ret? It is major hassle to change all code, and also add endp. Personally, I stick with old includes.

There's currently no difference in functionality between RET and RETN. I have changed the RETs into RETNs when I was testing the more TASM-compatible variant of macros, where "ret" was used instead of "return" - in assemblers like TASM or MASM RET is the mnemonic reserved for the instruction of which the assembler decides in what form should be generated, depending on where is it placed (near of far procedure, etc), while RETN and RETF are the mnemonics that refer directly to the opcodes. Outside of any procedure context, TASM was treating RET just as a RETN instruction, and I have chosen the same behavior for FASM, which doesn't have any procedure contexts. When I was making this new version of macros, that have the scope of all definitions limited by "endp" barrier, I was even considering using the "ret" as a name for a return macro, to achieve the syntax similar to that from TASM - but there was too strong opposition against it. And so RET is still the synonym to RETN, and you don't have to worry about replacing.

There is something wrong with "enter". In case with no parameters nor local variables it assembles push ebp and mov ebp,esp and in some cases the stack remains umbalanced causing unexpected crashes.
Fresh's "begin" macro does it good. Also manually erasing "enter" from the sources will solve the problem but I prefer to keep it for readability.

I look at new "proc" macro and I change these lines (in 2 places, enter and return macros):



And it works well, but the macro is too complex. I don't know if I have damaged something else.
[edit]
Sorry, damaged something indeed.
In some cases, the stack got umbalanced.
[/edit]

Hi,Pelaillo:
Can you give a complete demo file? I modified all of the proc/cproc macro defines so that it can use on DOS/Win32 platform. And I have writed a demo program "dos_seg.asm" and I have test it OK.
The instruction 'if ..ret | defined ..size" worked OK. Because we need create stack frame for using two sides: one is only parameters, another is only local variables. So I think that it should use "|" operator.

Please discomplied my test program.

Hi, Privalov:
I have a recommed that the proc/cproc macro defines should use on DOS/Win32/linux platforms. Do you think it?

Best Regards.

Hi KevinZheng, please consider this example:

Following Privalov's advice, it must assemble as

That is how "begin" macro works. But with new "enter", the same source will result in:

and thus causing the stack to be umbalanced. Besides the fact that this particular procedure should be writen better to avoid this, it serves as example of the problem.

Hi, Pelaillo:
I understand you. But I think that you only need remove the enter macro from code, it will implement the first one.

Because the enter macro is used for emulation and expand the "enter" instruction, so if you added it on the code, It should implement the behavior of the "enter" instruction.

Do you think it?
Thank you.

kevin is right. If you use enter-return, you can predict having original value of EBP pushed on stack, ESP = EBP - locals, etc. If someone wants procedure weithout stack frame, he uses retn.

Yes my friends,
the problem is that new macros was intended to provide a standard way to the fresh's proc macros.
And following Privalov's advice, he wants "enter" to work as "begin" macro but currently it is not the case.

I want to keep the same proc layout for all procedures.