flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Windows > Basic Win32/Win64 headers for fasmg

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


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland
Basic Win32/Win64 headers for fasmg
Recently I've been working on a set of basic compatibility macros for fasmg that would allow to assemble sources written for fasm with its standard Windows headers, with as few changes as possible. I have now completed a version that assembles most of the Win32/Win64 examples from fasm package and I'm attaching it here.

Note that I do think that any such headers for fasmg (or fasm 2, if such ever arrives) could make better use of the macro capabilities of the new engine, therefore I think that developing some entirely new macros with new and improved syntax could be a good direction. But converting the standard fasm's includes is an important first step.

Not every behavior of fasm's macros is preserved - for example, as I explained in the other thread, "proc" macro I prepared for fasmg creates a separate namespace for every procedure - because this is how it should have always been working, and it was only because of the limitations of fasm's macro engine that its "proc" did not really work like that (though it at least kept the local data labels limited in scope). This means that local labels inside "proc" no longer need to start with dot.

The "struct" and "union" macros I used are the plain ones I created for fasmg, and they do not reproduce the complete behavior of fasm's "struct". This should change later - I still plan to write a variant more compatible with fasm's one for the inclusion in this package, though in general I prefer the new one, for its simplicity and flexibility. Using the new version required some changes of syntax in fasm's examples, because this variant of "union" needs to end with "endu" and the values to initialize fields in structure need to be labeled instead of providing them in original order.

When converting the resource macros I was really amazed how old and fossilized they are, with weird syntax choices that date back to the time when fasm had only very basic macro abilities, and implementations that have not been touched in ages. I converted them all, preserving the compatibility, but I think that their syntax really could use some renewal. The same can be said about import macros.


Description: Win32/Win64 headers for fasmg, with adapted fasm's examples (updated: 2017-11-15)
Download
Filename: fasmgwin.zip
Filesize: 348.23 KB
Downloaded: 410 Time(s)



Last edited by Tomasz Grysztar on 15 Nov 2017, 16:46; edited 1 time in total
Post 17 Oct 2016, 22:47
View user's profile Send private message Visit poster's website Reply with quote
uor99



Joined: 04 Dec 2014
Posts: 41
Well done !
Post 24 Dec 2016, 12:41
View user's profile Send private message ICQ Number Reply with quote
uor99



Joined: 04 Dec 2014
Posts: 41
I also hope fasmg can replace fasm in time. It's a pity that some of my written apps fail to compile.
Post 10 Jan 2017, 21:55
View user's profile Send private message ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland
I have updated the package with converted Win64 headers and examples.
Post 12 Apr 2017, 18:19
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland
And another update, this time with extended "struct" macro which allows to initialize fields' values sequentially, like fasm's "struct" did. Both ways of providing values for fields are now allowed.
In fact, the "struct" macro in this package should now support all the documented features of its fasm's counterpart, while still allowing the new (named) style of field initialization.
Post 13 Apr 2017, 15:50
View user's profile Send private message Visit poster's website Reply with quote
VEG



Joined: 06 Feb 2013
Posts: 69
Location: Minsk, Belarus
Maybe it is better to use ":=" in the equates to ensure that these values will not be changed by accident.
Post 30 Apr 2017, 14:17
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland

VEG wrote:
Maybe it is better to use ":=" in the equates to ensure that these values will not be changed by accident.

Good idea! The equates were simply copied from fasm's package and fasm 1 did not have such feature, but now as it is available it would be wise to make use of it.
Post 30 Apr 2017, 14:54
View user's profile Send private message Visit poster's website Reply with quote
VEG



Joined: 06 Feb 2013
Posts: 69
Location: Minsk, Belarus

Code:
section '.rsrc' resource data readable

        directory \
                RT_GROUP_ICONicon_group_list, \
                RT_ICONicon_data_list

        resource icon_group_list, \
                200LANG_NEUTRALmain_icon_group

        resource icon_data_list, \
                100LANG_NEUTRALmain_icon_16_data, \
                101LANG_NEUTRALmain_icon_32_data

        icon main_icon_group, \
                main_icon_16_data'16.ico', \
                main_icon_32_data'32.ico'

The result:

Code:
flat assembler  version g.hs4p0
examples\dialog\dialog.asm [120]:
        icon main_icon_group, \
        main_icon_16_data'16.ico', \
        main_icon_32_data'32.ico'
macro icon [9]:
        data file icon_file:position,size
Processeddata file '32.ico':position,size
Errordefinition in conflict with already defined symbol.

The icon macros tries to redefine the "data" label when there are more than one sources of icons are provided.

Also I propose to add an additional "align 4" in the versioninfo macro (market with +):

Code:
        macro vdata name,value
                local vs_data,vs_size,value_data,value_size
                align 4
                vs_data dw vs_size,value_size/2
                du 1,name,0
                align 4
                value_data du value,0
                value_size = $ - value_data
                align 4 ; + this one
                vs_size = $ - vs_data
        end macro

At least I've seen that other compilers do an additional alignment here and this is why the wLength and the wValueLength are different fields here. The same with the macros for the FASM1, it also doesn't have this align directive here.
Post 06 May 2017, 17:27
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland

VEG wrote:
The icon macros tries to redefine the "data" label when there are more than one sources of icons are provided.

I have fixed the bug there.
Post 08 May 2017, 16:06
View user's profile Send private message Visit poster's website Reply with quote
VEG



Joined: 06 Feb 2013
Posts: 69
Location: Minsk, Belarus
resource.h has this line: "started = 1". But this variable isn't used anywhere and it is even not local. It seems that it is a leftover from some other algorithm and can be removed safely.
Post 10 May 2017, 12:05
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland
I have added the Challenger Interpreter to the examples, to demonstrate a bit more complex one assembling correctly. And I think that it is oddly fitting into a general theme of fasmg packages.

I found and fixed a couple of bugs in macros when assembling it for the first time.
Post 08 Oct 2017, 20:19
View user's profile Send private message Visit poster's website Reply with quote
kolpakchi



Joined: 09 Sep 2016
Posts: 1
How can i change the macros to declare proc with no "declaration"?

Code:

include 'win32w.inc'

format PE GUI 4.0
entry start

  start:
    stdcall someProc
    retn
    
  proc someProc
        ret
  endp





Code:

E:\fas>fasmg src.asm src.exe
flat assembler  version g.hy7gy
src.asm [8]:
        stdcall someProc
macro stdcall [48macro call [1macro parse_jump_operand [11macro parse_oper
and [10macro parse_operand_value [31]:
        ns.imm = +op
Processed@dest.imm = +someProc
Errorsymbol 'someProc' is undefined or out of scope.



There is no error when i append something like "uses ebx" .
It caused because no match in proc32.inc , right?

Code:

        match name declarationstatement


Post 14 Oct 2017, 13:17
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland
This has been fixed in the mean time. Please make sure you have downloaded the latest version (I have started adding the "update date" next to the file).
Post 14 Oct 2017, 13:49
View user's profile Send private message Visit poster's website Reply with quote
Kenneth Zheng



Joined: 30 Apr 2008
Posts: 13
Location: Shanghai, China
Hi, Thomasz:
There is one bug in the fastcall macro. The fastcall macro can't accept immediater >= 0x8000000 parameters. Please see below code in the examples\win64\template.asm:


Code:

examples\win64\template.asm:

CW_USEDEFAULT = 80000000h

invoke  CreateWindowEx,0,_class,_title,WS_VISIBLE+WS_DLGFRAME+WS_SYSMENU,CW_USEDEFAULT,128,256,192,NULL,NULL,[wc.hInstance],NULL





C:\fasmg\examples\x86\examples\win64>fasmg template.asm
flat assembler version g.hykpg
template.asm [25]:
invoke CreateWindowEx,0,_class,_title,WS_VISIBLE+WS_DLGFRAME+WS_SYSMENU,CW_USEDEFAULT,128,256,192,NULL,NULL,[wc.hInstance],NULL
macro invoke [1] macro fastcall [116] macro mov [92] macro store_instruction [86] macro simm32 [15]
Custom error: immediate value out of signed range.


The reason is that the CW_USEDEFAULT = 80000000h, so it will beyond the macro x86.simm32 imm size.

Thanks.

_________________
Pure Assembly Language Funs
Post 22 Oct 2017, 05:15
View user's profile Send private message MSN Messenger Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland
Thanks, I'm updating the file.
Post 22 Oct 2017, 09:03
View user's profile Send private message Visit poster's website Reply with quote
Kenneth Zheng



Joined: 30 Apr 2008
Posts: 13
Location: Shanghai, China
Hi, Thomasz:
It's okay with the newest fasm_win.zip. Thank you a lot Very Happy

And please see this file:

Code:
examples\win64\dll\writemsg.asm:
proc DllEntryPoint hinstDLL,fdwReason,lpvReserved
        mov     eax,TRUE
        ret
endp




I think that it should use "rax" to instead of "eax" as the returned value.


Code:
proc DllEntryPoint hinstDLL,fdwReason,lpvReserved
        mov     rax,TRUE
        ret
endp



The reason is that it's one 64bit DLL, not 32bit DLL.

Are you agree it?
Thanks.

_________________
Pure Assembly Language Funs
Post 22 Oct 2017, 13:50
View user's profile Send private message MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15233
Location: 1I/ʻOumuamua
IIRC TRUE == 1, so using either EAX or RAX will still put 1 into RAX, because the top dword of RAX is cleared to zero whenever EAX is written.

Perhaps ideally the code should look like this:

Code:
        if TRUE shr 32 = 0
                mov     eax,TRUE
        else
                mov     rax,TRUE
        end if

Post 22 Oct 2017, 13:53
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland

revolution wrote:
Perhaps ideally the code should look like this:

Code:
        if TRUE shr 32 = 0
                mov     eax,TRUE
        else
                mov     rax,TRUE
        end if


Another approach could be:

Code:
        assert TRUE shr 32 = 0
        mov   eax,TRUE

Post 22 Oct 2017, 14:06
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15233
Location: 1I/ʻOumuamua
It might also be worth noting for anyone not currently aware, and wondering why there is the extra complication, that using EAX instead of RAX produces a smaller code footprint because there is no REX prefix needed.
Post 22 Oct 2017, 14:13
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6628
Location: Kraków, Poland
One could also write a MOV macro that would do this additional optimization automatically, similarly to the TEST optimization that was once discussed. Since in case of fasmg instructions are just macros anyway, we could add a package of such optimizations as an optional variant that would not have much overhead compared to the basic ones.
Post 22 Oct 2017, 14:28
View user's profile Send private message Visit poster's website 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.