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
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7276
Location: Kraków, Poland
All the Windows headers of fasm 1 are now emulated, including syntax like ".if" and basic parameter count checking.
Post 15 Nov 2017, 16:47
View user's profile Send private message Visit poster's website Reply with quote
Kenneth Zheng



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

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
Post 27 Dec 2017, 07:00
View user's profile Send private message MSN Messenger Reply with quote
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! Very Happy 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
Post 08 Jan 2018, 13:21
View user's profile Send private message Visit poster's website Reply with quote
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:
Image
Post 01 Apr 2018, 07:16
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2764
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?
Post 04 May 2018, 18:22
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7276
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.
Post 04 May 2018, 18:46
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2764
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?

I'll adapt - just confused.
Post 04 May 2018, 19:05
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7276
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'    
What do you think about this solution?

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.
Post 04 May 2018, 19:22
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2764
Location: dank orb
Excellent, now it appear to work from everywhere.
Post 04 May 2018, 21:31
View user's profile Send private message Visit poster's website Reply with quote
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?
Post 18 Aug 2018, 08:09
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7276
Location: Kraków, Poland
Yes, I moved it to GitHub, though the headers themselves had no updates recently.
Post 18 Aug 2018, 08:31
View user's profile Send private message Visit poster's website Reply with quote
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?
Post 22 Nov 2018, 17:56
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7276
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.
Post 22 Nov 2018, 20:32
View user's profile Send private message Visit poster's website Reply with quote
asmant



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

Thanks for the answer and your program!
Post 22 Nov 2018, 20:46
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2764
Location: dank orb
fasmg/packages/x86/examples/windows/usecom/usecom.asm, line 10
Code:
label . : 16    

_________________
¯\(°_o)/¯ unlicense.org
Post 20 Dec 2018, 19:17
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2764
Location: dank orb
On windows 10 and invalid PE is produced by:
Code:
section '.data' data readable writeable    
...if the section is empty. I know - a strange corner case.
Post 01 Jan 2019, 18:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7276
Location: Kraków, Poland
bitRAKE wrote:
...if the section is empty. I know - a strange corner case.
The case of empty section is even more strange and interesting than just this behavior on Win10:
https://twitter.com/grysztar/status/1023556002480832513
@grysztar wrote:
Modern Windows (based on NT kernel) rejects to load a PE file containing an empty section (one that has virtual size set to zero). Other implementations, like Windows 9x or Win32s, did not object to such setup.

On the other hand, Windows 9x interpreted relocation data containing no records as a signal that the image could not be loaded at another address. Therefore a DLL with .reloc section of zero length could fail both on Windows 9x and NT, but for very different reasons.

Win32s was the least fussy. It was not troubled by zero-length sections and correctly interpreted an empty but present relocation data.
In other words: this is not invalid PE if we go by specification only. And it is considered invalid by some implementations but not by others. For this reason fasm does not object if you try to make one - after all, being able to control such details is what many consider the heart of assembly languages.
Post 01 Jan 2019, 19:56
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 Previous  1, 2

< 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-2019, Tomasz Grysztar.

Powered by rwasa.