A suggestion! ("FILE" and "INCLUDE")

Index > Compiler Internals > A suggestion! ("FILE" and "INCLUDE")

Goto page 1, 2 Next

Author

Thread

asmfans

Joined: 24 Jan 2008
Posts: 5
Location: China

asmfans 12 Jan 2010, 03:50

Perhaps we can let "FILE" directives such as "INCLUDE" directives, can search directories.So that we can introduce the data files need to put in a fixed position.

EDIT by DOS386 : enhanced subject and moved from Main to Compiler Internals

12 Jan 2010, 03:50

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 12 Jan 2010, 06:23

+1
once ago i already asked about this Smile

12 Jan 2010, 06:23

Teehee

Joined: 05 Aug 2009
Posts: 570
Location: Brazil

Teehee 12 Jan 2010, 09:06

huh? I didn't understand Embarassed

12 Jan 2010, 09:06

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20511
Location: In your JS exploiting you and your system

revolution 12 Jan 2010, 09:49

I think asmfans wants FILE to also use the include path to search for the file. In the same way that INCLUDE used the include path to find the files.

12 Jan 2010, 09:49

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 12 Jan 2010, 12:51

asmfans,

Isn't it already there?

flat assembler 1.68 Programmer's Manual wrote:

2.3.1 Including source files
…
The quoted path can contain environment variables enclosed within % characters, they will be replaced with their values inside the path, both the \ and / characters are allowed as a path separators. If no absolute path is given, the file is first searched for in the directory containing file which included it and when it's not found there, in the directory containing the main source file (the one specified in command line). These rules concern also paths given with the file directive.

file "%windir%\notepad.exe" works, fasmw.ini's [Environment] section allows you define private envvars for fasmw.exe.

May be I misinterpret your proposal and you need file directive to search multiple folders (and use first matching file)?

12 Jan 2010, 12:51

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 13 Jan 2010, 06:14

suppose we have such files:

c:\A\main.asm

c:\B\second.inc
c:\B\second.bin
c:\B\second.mac

-- it is common situation when you keep you library files in separate folder.

let's main.asm has this:

Code:

include "second.inc"

and let's second.inc has:

Code:

include "second.mac"
file "second.bin"

suppose, folder "c:\B" is accessed with INCLUDE env. variable.
the "second.mac" will be included correctly, but "second.bin" will not be found, because "include" and "file" use different algorythm of related searching files

13 Jan 2010, 06:14

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 13 Jan 2010, 07:07

shoorick,

Did you read that manual quote thoroughly? It says "If no absolute path is given, the file is first searched for in the directory containing file which included it…".

13 Jan 2010, 07:07

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20511
Location: In your JS exploiting you and your system

revolution 13 Jan 2010, 07:13

Manuals be damned. Just try it and see what happens, then report back here to say what really happens.

13 Jan 2010, 07:13

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 13 Jan 2010, 07:26

revolution,

Already tested. Works OK. Main source includes this file:

Code:

file "WIN32A.INC"

File to be included is located in FASM's INCLUDE folder, as filed WIN32A.INC do.

13 Jan 2010, 07:26

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 13 Jan 2010, 08:26

mmm.... yes, i just created a simple example as desribed above by me and it works. then reproduced a situation where i got a problem and start to understand why problem appeared Smile

it was because "file" was used in the macro, macro was in the file in the library subfolder and binary was near that file, but when macro is unfolded in source, then appeared fasm do not know where to search file relating to the file where macro used

now it is not solved for me, but at least clear...

++++++++++++
btw, moving "oemtable.866" up to d:\projects\shoolib folder, pointed by INCLUDE, same does not help Sad

++++++++++++

ok, well then:

-1

Very Happy

below is an illustration of my situation:
dr.inc:

Code:

macro dr [args] 
 { common local ..size,..char 
   virtual at 0 
      db args 
      ..size = $ 
   end virtual 
   repeat ..size 
      virtual at 0 
        db args 
        load ..char byte from $ - ..size + % - 1 
      end virtual 
      if ..char > 0BFh 
      virtual at 0
        file 'oemtable.866':..char - 0C0h,1
        load ..char byte from 0
      end virtual
      end if 
    db ..char 
   end repeat }

Description:
Filesize:	3.17 KB
Viewed:	21996 Time(s)

Description:
Filesize:	19.59 KB
Viewed:	21997 Time(s)

_________________
UNICODE forever!

13 Jan 2010, 08:26

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 13 Jan 2010, 08:36

Oh!

+1 again Smile

look at the example in attach and at the screenshot Smile

INCLUDE variable does not help for "FILE" same as for "INCLUDE" directive Sad

Description:
Filesize:	4.35 KB
Viewed:	21989 Time(s)

Description:		Download
Filename:	TESTFILE.ZIP
Filesize:	1003 Bytes
Downloaded:	658 Time(s)

_________________
UNICODE forever!

13 Jan 2010, 08:36

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20511
Location: In your JS exploiting you and your system

revolution 13 Jan 2010, 08:51

Well since you all seem to have a problem agreeing about what really happens I shall let you off the hook.

INCLUDE: Searches your "include" paths. (see PREPROCE.INC, "include_file:")
FILE: Does not search your "include" paths. (see ASSEMBLE.INC, "open_binary_file:")

When all else fails, read the source.

13 Jan 2010, 08:51

Tomasz Grysztar

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

Tomasz Grysztar 13 Jan 2010, 08:59

Oh, I forgot to document the INCLUDE environment variable, didn't I? Twisted Evil

Anyway, as name suggests, it applies to INCLUDE directive only. Wink

Other than that, INCLUDE and FILE work the same (including %var% feature).

13 Jan 2010, 08:59

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 13 Jan 2010, 09:44

then it may stay as just a suggestion Wink

(btw: who read docs until everything is working? Wink

)

13 Jan 2010, 09:44

edfed

Joined: 20 Feb 2006
Posts: 4354
Location: Now

edfed 14 Jan 2010, 02:07

one better bug is with xp vs 98

fasmw is in c:/fasmw folder, on both OSes.
it opens in lib folder by default.
lib is c:/fool

and then, what happens?

win98:
1:
i open a asm file from somewhere.
i want to open another file with ctrl+O

result 1:
it will point me to the current forlder.

2:
i open fasm, i want to open a file with ctrl+O
result 2:
no problem, it shows me the c:/fool folder.

under XP:
result 1:
it will open the c:/fool folder the first time.
or the last folder pointed to the last exited fasm session.
result 2:
as 1:
it is boring.

14 Jan 2010, 02:07

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 14 Jan 2010, 16:40

edfed,

This is not a bug but documented behavior difference between 9x/Me and 2k/XP implementations of GetOpenFileName(): 2k/XP remembers MRU folder on per-extension (first one from filter?) per-program basis (see HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU).

shoorick,

Probably you can replace file 'oemtable.866':..char - 0C0h,1 with include 'general\oemtable.866.inc' which, in turn, will contain that file directive? Looks like workaround.

revolution,

Did I accidentally claimed that file directive uses INCLUDE= in any way? Probably my example was misleading — comment about "WIN32A.INC" meant that it is in the same folder as included file, not about it being in INCLUDE-designated folder.

14 Jan 2010, 16:40

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 15 Jan 2010, 05:53

yes, there could be a lot of tricks to get desired result, but if we look at, say, masm/tasm/etc - they have "incude" and appropriate environment variable "INCLUDE" to point the default place of includes, "includelib" with appropriate "LIB" environment var to point the default place of libraries, same in fasm "file" directive might have appropriate environment variable to point the default binary includes, maybe "INCLUDE", maybe different, say, "INCLUDEBIN" or so. it is because such binaries may appear common for different projects, such as some binary tables, pictures etc. i suppose it would not make fasm much more heavier, but could be handy Wink

regards!

15 Jan 2010, 05:53

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 15 Jan 2010, 19:56

shoorick,

Single path could be used right now, multiple paths can contain file with same name but different contents (for example, I'd prefer oemtable.866 to cover at least 96 bytes from 0xA0 to translate "ЁёЄєЇїЎў°·№¤ " too, and my path in INCLUDEBIN= is before yours Wink

15 Jan 2010, 19:56

asmfans

Joined: 24 Jan 2008
Posts: 5
Location: China

asmfans 21 Jan 2010, 07:50

Thanks all.
It seems that I should continue to put these files into my project directory

21 Jan 2010, 07:50

Tomasz Grysztar

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

Tomasz Grysztar 15 Apr 2012, 09:26

As they say, better late than never. In version 1.69.52 I have made the FILE directive to follow exactly the same rules as INCLUDE directive. This is in fact a bug fix, because fasm's manual was stating that the same rules apply to both of them, but it was not true. It should be true now.

15 Apr 2012, 09:26

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