Both are latest version, downloaded from download section of this site, the output is as follow:



And it seems that the file macro/struct.inc does not exist anywhere at all:



Since find provides no output it means that no files with name struct.inc were found anywhere neither in fasm, nor fasmg distribution, even with case-insensitive search.

Another, but related problem:
I can't find any way to compile fasmg for x86_64 CPU.

I am trying to maintain a pure 64 bit operating system, including kernel and all binaries, so that's unfortunate.

Also why fasmg.zip doesn't have directory like fasmg-$version at its root? It's traditional to software source package have everything inside a single directory named after the package, for example if you download a zip from github and unpack it you will get a directory named fasm-master with all files under it. Would be nice if you made fasmg downloads be named like fasmg-ibh5n.zip and have a single directory inside named like fasmg-ibh5n. fasm (without g) follows this pattern already.

Also forum ate my line ends somehow, despite using [ code ] [ /code ] tags. What's wrong with it?

These source when assembled with fasm 1 use the macros that are only available in "fasm for Windows" package. Unfortunately, include sets for other ones have never been made. I hoped the community packaging project would make some, but that never went really well.

As for the availability of 64-bit fasmg, see the other thread. It might be possible to use the same trick as for fasm 1, though that would be a very "quick and dirty" solution. One day I hope to adapt sources of fasmg in such way, that they can be assembled to use 64-bit address size fully.

As for the package naming, I actually dislike the idea of making a new separate file every time the minor version changes.

Moreover, with fasm 1 I sometimes had a problem when I wanted to update only example files or documentation, which did not change the version number of the fasm's core (note that this is what the version number refers to, even FASMW/FASMD do not count as a part of core and I do not change the version of the core when I update either interface). When file name includes a version number, some people expect that this is a release file that should not change over time. While I was often updating the same files multiple times when I have been doing small changes that did not touch the core.

Note that this is a project maintained by a single person with almost a continuous release cycle. What you download is like a latest snapshot, not a release set in stone. However, in case of fasmg, if you need a previous version, there is a source repository publicly available.

Perhaps, it makes sense to add struct.inc in fasmg package and correct the include directive, to point there?


I have created a separate thread for this proposal. It is in feedback section.

Maybe it makes sense to split fasm stuff over archives in a different way?

For example:
1. fasm Core package, includes sources and binaries for fasm core, as well as fasm.txt and other txt files.
2. fasm IDE package, including fasmd, fasmw and probably windows include files
3. fasm Example package, including examples for all platforms.
4. fasm.pdf as separate download. Or you could include it in #1, or both.
5. Everything fasm. Includes all four from above in single package

All files have separate version numbers.

The fasmg package is by itself completely independent from fasm 1 installation, its self-hosting works out-of-the-box. On the other hand, to assemble with fasm 1 it assumes availability of the complete set of includes with Windows support as they are provided only in fasm for Windows package. A unified set of includes downloadable separately from the core packages would fix the situation and that is what I hoped that the community packaging could provide. I think that project might be the best place to direct your ideas to, the main reason it failed so far is that there were not enough active and interested people adding to it.

It seems that fasmg does not need anything else but struct.inc, and this file is fairly tiny. So, what is the reason that you can't simply add it to fasmg source tree?

Also, I don't understand how can fasmg compile itself without this file, while fasm1 can't. Is it a macro which emulates some fasmg innate feature?

This depends on the specific interface you want to assemble. The Win32 versions require an entire set of includes that comes with fasm for Windows, while Linux version uses only struct.inc out of them. And MacOS version cannot be assembled with fasm 1 at all.

The required macros for fasmg are defined in selfhost.inc, which is included only when fasmg is used to assemble the source.

I think, maybe it's not necessary really to split include files between OS'es.
Even if you install fasm in Windows, you might want to assemble linux programs and vice versa, so maybe all includes should be in same distribution, but, perhaps in different subfolders?