flat assembler
Message board for the users of flat assembler.

Index > Windows > New includes for fasm 1.52

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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:
Code:
include "win32a.inc"    

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:
Code:
; VOID ShowErrorMessage(HWND hWnd,DWORD dwError);

proc ShowErrorMessage, hWnd,dwError
  .lpBuffer dd ?
        enter
        lea     eax,[.lpBuffer]
        invoke  FormatMessage,FORMAT_MESSAGE_ALLOCATE_BUFFER+FORMAT_MESSAGE_FROM_SYSTEM,0,[dwError],LANG_NEUTRAL,eax,0,0
        invoke  MessageBox,[hWnd],[.lpBuffer],NULL,MB_ICONERROR+MB_OK
        invoke  LocalFree,[.lpBuffer]
        return
endp

; VOID ShowLastError(HWND hWnd);

proc ShowLastError, hWnd
        invoke  GetLastError
        stdcall ShowErrorMessage,[hWnd],eax
        return
endp    

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:
Code:
  export 'ERRORMSG.DLL',\
         ShowErrorMessage,'ShowErrorMessage',\  ; ordinal 1
         ShowLastError,'ShowLastError'          ; ordinal 2    

And you can import the ShowLastError function by ordinal this way:
Code:
  import errormsg,\
         ShowLastError,2    


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.
Post 31 Mar 2004, 18:09
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
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.
Post 31 Mar 2004, 21:47
View user's profile Send private message Yahoo Messenger Reply with quote
aaro



Joined: 21 Jun 2003
Posts: 107
Location: hel.fi
aaro
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.
Post 31 Mar 2004, 21:59
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
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?

_________________
comrade (comrade64@live.com; http://comrade.ownz.com/)
Post 31 Mar 2004, 22:25
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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?
Post 31 Mar 2004, 22:41
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
"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.
Post 31 Mar 2004, 22:52
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
Privalov wrote:

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.


I think that's unnecessary

_________________
comrade (comrade64@live.com; http://comrade.ownz.com/)
Post 01 Apr 2004, 03:56
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
comrade wrote:

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.
Post 01 Apr 2004, 11:03
View user's profile Send private message Visit poster's website Reply with quote
aaro



Joined: 21 Jun 2003
Posts: 107
Location: hel.fi
aaro
How about changing:
Code:
macro proc name,[arg]                   ; define procedure
 { common
    if used name
    

to:
Code:
PROC_INCLUDE_ALL = FALSE
macro proc name,[arg]                     ; define procedure
 { common
    if used name | PROC_INCLUDE_ALL
    

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
Post 01 Apr 2004, 11:22
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Or:
Code:
if used name | defined PROC_INCLUDE_ALL    

You can add it on your own if you need it.
Post 01 Apr 2004, 12:18
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
What is your opinion about making the includes to use INCLUDE variable only?
Post 03 Apr 2004, 13:02
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
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,
Post 03 Apr 2004, 14:32
View user's profile Send private message Yahoo Messenger Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
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.

_________________
comrade (comrade64@live.com; http://comrade.ownz.com/)
Post 04 Apr 2004, 03:05
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 04 Apr 2004, 08:16
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Privalov wrote:
Also, if you define proc without any parameters nor local variables, the stack frame won't be set up at all.


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):

Code:
;if ..ret | defined ..size
if ..ret & defined ..size
    


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. Sad
In some cases, the stack got umbalanced.
[/edit]
Post 12 Apr 2004, 20:05
View user's profile Send private message Yahoo Messenger Reply with quote
Kevin_Zheng



Joined: 04 Jul 2003
Posts: 125
Location: China
Kevin_Zheng
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.


Description:
Download
Filename: dos_seg.zip
Filesize: 15.98 KB
Downloaded: 164 Time(s)

Post 13 Apr 2004, 05:01
View user's profile Send private message MSN Messenger Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Hi KevinZheng, please consider this example:
Code:
proc SkipComment
   enter
       inc  esi
    cmp  word [esi],'?>'
   je   .done
  loop SkipComment
  .done:
    return
endp
    

Following Privalov's advice, it must assemble as
Code:
004023AC  /$  46             /inc     esi
004023AD  |.  66:813E 3F3E   |cmp     [word ds:esi],3E3F
004023B2  |.  74 02          |je      short TEST_HTM.004023B6
004023B4  |.^ E2 F6          \loopd   short TEST_HTM.004023AC
004023B6  \>  C3             retn
    

That is how "begin" macro works. But with new "enter", the same source will result in:
Code:
004023AC  /$  55             /push    ebp
004023AD  |.  89E5           |mov     ebp,esp
004023AF  |.  46             |inc     esi
004023B0  |.  66:813E 3F3E   |cmp     [word ds:esi],3E3F
004023B5  |.  74 02          |je      short TEST_HTM.004023B9
004023B7  |.^ E2 F3          \loopd   short TEST_HTM.004023AC
004023B9  |>  C9             leave
004023BA  \.  C3             retn
    

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.
Post 13 Apr 2004, 12:47
View user's profile Send private message Yahoo Messenger Reply with quote
Kevin_Zheng



Joined: 04 Jul 2003
Posts: 125
Location: China
Kevin_Zheng
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.
Post 14 Apr 2004, 04:32
View user's profile Send private message MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Post 14 Apr 2004, 08:38
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
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.
Post 14 Apr 2004, 12:46
View user's profile Send private message Yahoo Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.