flat assembler
Message board for the users of flat assembler.

 flat assembler > Windows > Basic Win32/Win64 headers for fasmg Goto page Previous  1, 2
Author
Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 6999
Location: Kraków, Poland
All the Windows headers of fasm 1 are now emulated, including syntax like ".if" and basic parameter count checking.
15 Nov 2017, 16:47
Kenneth Zheng

Joined: 30 Apr 2008
Posts: 14
Location: Shanghai, China
The .if macro worked normally on, Thanks Thomas.

The fasmg_win.zip used the same CPU insturction include files, but it used difference file "examples\x86\include\format\format.inc" both fasmg_win.zip and fasmg.zip, you maybe integrated the fasmg_win.zip into the fasmg.zip, it can help user to use it easier.

Thanks

Kenneth Zheng

_________________
Pure Assembly Language Funs
27 Dec 2017, 07:00
yeohhs

Joined: 19 Jan 2004
Posts: 171
Location: N 5.43564° E 100.3091°
Tomasz Grysztar wrote:
All the Windows headers of fasm 1 are now emulated, including syntax like ".if" and basic parameter count checking.

Thanks! This is great.

_________________
“It’s not that we have a short time to live, but that we waste a lot of it.”
-Lucius Annaeus Seneca
08 Jan 2018, 13:21
VEG

Joined: 06 Feb 2013
Posts: 78
Location: Minsk, Belarus
It seems that you've accidentally included older versions of format.inc and pe.inc into the latest archive:
01 Apr 2018, 07:16
bitRAKE

Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
I was curious if there is some reasoning behind the use of absolute paths in the include files? With relative paths it'd be possible to just INCLUDE '..\fasmg\include\win64w.inc' without it being broken. Maybe there is a use case I'm neglecting which relative paths would break?
04 May 2018, 18:22
Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 6999
Location: Kraków, Poland
I wanted to say that it should not break anything, but wait, it breaks the "format" macros - they include files only when macro is called and the relative path is then of the file that called the macro.

This could be fixed by changing INCLUDE to INCLUDE!, but this would make it read all the files unnecessarily only to define the format macros.

Or, there is also an option of FORMAT.INC extracting its path from __FILE__ and then attaching this path to the name of every file it includes. I'm going to look into this solution to see how clean can I make it.
04 May 2018, 18:46
bitRAKE

Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
Thank you, I was seeing other side effects as I don't have the environment defined and some includes weren't throwing any errors. Yet, it doesn't seem like they would be in the path. One would initially think that all includes would be in the context of the file that does the including. But if it's wrapped in a macro or eval, what then?

04 May 2018, 19:05
Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 6999
Location: Kraków, Poland
I have a prototype working. The basic (and universal) macro goes like this:
Code:
```macro local_include? instr
local pos,chr,path
pos = lengthof __FILE__
while pos
chr = (__FILE__ shr (8*(pos-1))) and 0FFh
if chr = '/' | chr = '\'
break
end if
pos = pos - 1
end while
path = string __FILE__ and not ( (-1) shl (8*pos) )
macro instr file
include string path + file shl (8*lengthof path)
end macro
end macro    ```
Then in FORMAT.INC we may add this line:
Code:
`local_include format?.include    `
and then use "format?.include" instead of regular "include" to read files from the paths relative to FORMAT.INC. This is going to work correctly no matter where do we call "format?.include" from:
Code:
```format?.include 'pe.inc'
format?.include '../cpu/x64.inc'    ```

And by the way - when INCLUDE is used in a macro, the path it sees is of the file that called the macro and not the file that defined the macro exactly for the reason that you should be able to wrap things like INCLUDE with macros, etc.
04 May 2018, 19:22
bitRAKE

Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
Excellent, now it appear to work from everywhere.
04 May 2018, 21:31
VEG

Joined: 06 Feb 2013
Posts: 78
Location: Minsk, Belarus
You have stopped to update the file in the first post. Probably, it should be downloaded from another place now?
18 Aug 2018, 08:09
Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 6999
Location: Kraków, Poland
18 Aug 2018, 08:31
asmant

Joined: 02 Oct 2018
Posts: 2
Hi all!

In old FASM i did so and everything works well:
Code:
```format pe gui

use32
xor eax, eax

use64
xor rax, rax    ```

in new FASM i did so and have error ("Error: definition in conflict with already defined symbol."):
Code:
```include 'format/format.inc'
include 'cpu/x64.inc'

format pe gui

use32
xor eax, eax

use64
xor rax, rax    ```

Why not change by default (in file "format/format.inc")

Quote:
format?.include '../cpu/p6.inc'

to
Quote:
format?.include '../cpu/x64.inc'

?

This is the first thing that came to my mind. Any other suggestions?
22 Nov 2018, 17:56
Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 6999
Location: Kraków, Poland
This kind of architecture mixing is a bit unusual, so I would suggest in such case to use the new formatter directly and not through the fasm-like "format" macro:
Code:
```; example how to adjust some settings:
format binary as 'exe'
PE.Settings.Characteristics = IMAGE_FILE_EXECUTABLE_IMAGE or IMAGE_FILE_32BIT_MACHINE or IMAGE_FILE_LINE_NUMS_STRIPPED or IMAGE_FILE_LOCAL_SYMS_STRIPPED

include 'format/pe.inc'
include 'cpu/x64.inc'

use32
xor eax, eax

use64
xor rax, rax    ```
By using PE.INC directly you also have access to more settings, including ones not available with fasm-like syntax.
22 Nov 2018, 20:32
asmant

Joined: 02 Oct 2018
Posts: 2
Tomasz Grysztar wrote:
This kind of architecture mixing is a bit unusual