After a short talk about the problems with fasm's maintenance I had with vid today, I have decided that it would be a good idea to give a job of enhancing fasm's standard headers and macros, and packaging it all, to the other people (leaving to myself only the continued work on fasm's core).

Therefore I'm now looking for people that would like to contribute and help with doing this. This would mean, in particular:

• maintaining the Win32/Win64 headers, adding the missing structures and equates, adding headers for more libraries and interfaces
  
• maintaining the set of standard macros, and also properly documenting them
  
• preparing the installation package for Windows, which would install fasm's core with all the additional headers and macro sets, and set up the environment variables, etc.
  
• making some kind of headers set for the Linux programming
  
• more ideas? please post them here
  

After we agreed how to assemble some group of people to work on such packages (we still have a fasm's account on SourceForge, it may be useful for this purpose), I would rename the current downloads on the fasm's official website to the "core downloads" (and I will still maintain them myself), while adding links to those extra packages to the download page aswell.

What do you think about it?

I would prefer single maintainer (not me), or very few maintainers (including me ), who will agree on solid design for all packages. Anyone could submit content to package, but it will have to go through some checking / fixing by maintainer.

Purpose is to make sure that all packages will remain synchronized, and to prevent duplication and mess. By duplication i mean state when common file shared among multiple packages will be updated in one, but not in other administered by someone else. This could be also solved by having one "source" package for all distributions and build packages from it with some kind script - I do this pretty successfully with FASMLIB distributions.

We could also think about some more "massive" (all-you-ever-need) distribution, something like MASM32.

For maintainers, I would prefer anyone who already has spent considerable time on board, is regulary posting, and proved his skills in area he will be responsible for.

If this topic becomes "messy" i will moderate offtopic talk out, to make it easily readable for everyone. Post only on-topic.

I post regulary but my skills are not so good though. If not enough maintainers appears then I offer myself for the project, otherwise I prefer much more prepared people for this task.

but the best is to let you ( tomasz ) do this.
only you can make a good maintenance of your soft.
because youy're the father of this code and you know each component.

actually, tomasz is currently busy with more important things, and that's why we (including tomasz) believe that (well regulated) community can do a bit better job

Actually I've always thought we'd there be possible invoke MsgBox 0,"aaa","bbb",0 with win32ax/p headers, but not with plain win32a.
I really wish it could be handled this way with simple win32a.inc

Okay - that was maybe too much in detail - but the general idea is to summon more headers from C-type dynamic libraries and make FASM
more useful. A few days ago I found myself coding Allegro and from a
sample on this board (tg2d topic) I discovered headers that were minimal and I had to "upgrade" them.

There have been (and I think will be in the future) compatibility resolving macros. There are very helpful when porting from other assemblers. This is a great and welcome effort.

Maybe moving instruction support to a more external place where it can easily be edited. It is very optional because new instructions tend to rise only as often as 6 month intervals. Moreover the optimality of the instruction parsing algorithm can be hit this way.

Some additional tools can be very handy sometimes. Like *.h => *.inc converter bundled with FASM or maybe (if we ever get this far) *ASM => FASM source converter. I imagine the latter being the size of Fresh or even bigger

And what do you think about making some CVS or SVN for the headers development?

If there are more maintainers, it is definitively needed. If there is single maintainer, still desireable.

I would personally prefer SVN.

Yes, for personal choice I would also prefer this one.

Okay lets take the first example - implementing SSE4.1/.2 and SSE5.
How would that go - what's the...erm..scenario

considering SVN is used, it would be something like updating the version of X86(_64).INC or something?

svn = software version number
cvs = code version system

Madis: no, you didn't understand that. FASM compiler will still be developed solely by Tomasz.

Things that will be left for community will be macros, headers, and additional tools. As for example, consider MASM and MASM32. Hutch takes MASM compiler from MS, adds tons of crap around (macros, libraries, documents, etc...), and makes package (or distribution) from that. Another example is linux kernel vs. GNU/linux distribution.

Maintainer(s) will take use FASM from tomasz, and they will take care for macro files, headers, maybe libraries and tools, and package those.

tom: ???

SVN = http://en.wikipedia.org/wiki/Subversion_(software)
CVS = http://en.wikipedia.org/wiki/Concurrent_Versions_System

@vid: Hmm okay understood now!

@tom: I think that what vid posted, were the acronyms used extensively in computer communities.

I'd opt for SVN as well, although something like the relatively new BZR could become pretty interesting, especially since it makes it a lot easier for casual contributers to contribute, without having to go through the administrative hell of either giving them repository write access (dangerous!) or dealing with diff/merge (bothersome).

as well as everybody from time to time meet structures/constants absent in fasm includes and make own additional include - it is possible just have a kind of pinned feedback thread in windows section where anybody can post these things picked from psdk *.h, msdn or somewhere else.

then we need just somebody to "manage" this feedback.

after entering "feedbacks" into "official" includes this topic even can be emptied to be clear.

That sounds very good. First, the technical hurdle for submitting new entries is then very low, which means that more new entries come in. Second, suggestions for new entries would then automatically get a kind of peer review -- errors can be spotted by the community before they make it into an official distribution.

No obvious progress over the past days ...

... maybe we could start small? LocoDelAssembly volunteered as a maintainer; shoorick suggested pinned threads as the I/O mechanism for changes and new entries.

I agree. Let's agree on Loco as maintainer (he'll be good one), and discuss nature of those packages.

Also, i just noticed the post (and didn't read it all) and if the point hasn't been discussed yet, let's try to keep some packages optional. FASMLIB and other custom libraries should probably stay outside the standard downloads, especially since it's probably still under development and being revamped and things like that. The only windows macros and strucs that i can think of that are to be added are the various struc types and some more resource macro. If you start adding to the standard we end up creating astdlib (parody of cstdlib). We need to keep the stuff included with fasm away from contraversy (like how to clear the eax register) or stuff that's dependent on situation (like using fpu for normal floating point code, but sse for masses of floating point calculations). We need stuff that no one can really argue with. Let's not go overboard and add random code to the lib just because it looks good. Remember that one advantage to fasm is that it's not a large mess of billions of library junk like masm and other assemblers but not low level only like other compilers. Fasm is a nice mix of high level and low level stuff. Let's try not change that or even add too much to the point you have to take a course on fasm's macros along with assembly just to use fasm. This is just my opinion, but i really like it when fasm fits on a floppy.