in the past few weeks i browsed the board, i noticed that a lot of good masm coders turned to fasm. actually, and if i'm honest, i can't really understand why.. it seems a lot more complicated than masm to me. but nevertheless is also seems to be more lowlevel, it seems that you have more control over what you're doing.
hmm.. :confused:

Posted on 2002-07-19 16:28:13 by NOP-erator
Yes. Very interestingly. What for turn from the favourite assembler on FASM?:)
Posted on 2002-07-19 17:03:31 by Nexo
The more complex the better. ;)

I did gain some knowledge using FASM. If I didn't started using FASM I wouldn't have started creating a parser for the idata section. Which I'm currently, converting a lot of include files from MASM to FASM. And to tell you the truth I did learn functions I didn't knew before, of course platform sdk has all the API's listed but who would read the whole sdk from start to finish?

Personally, it's a matter of choice and preference. I still code in TASM, MASM but sometimes you just want a new assembler to work with. For DX stuff, I still do it in MASM, DOS stuff in TASM. I don't think MASM support would fail like TASM does. Considering MS is a big company whose main software is the windows OS, I don't think they would abandon their assembler.

I use FASM not because it's not from MS but just a personal taste. ;)
Posted on 2002-07-19 17:39:25 by stryker
One of the problem of MASM is his highlevel syntax, which sometimes generate code you didn't write (i'm not talking about .IF statements etc)... another advantage of fasm is there's not a bunch of include/lib files to have... without saying the assembler is still in development, so new features may be added...

I didn't switch for now, but I'm really considering testing it a bit more to decide if I switch or not... if many people switch, porting all the masm code to fasm would be relatively quick...
Posted on 2002-07-19 17:42:05 by JCP
Fasm got to be great because it got the full source with it and it is HUGE. But for some one like me, I fought with masm and windows for quite awhile now and sometime i think that masm is the best thing for windows because the MS himself used it for years. I think they wrote it but i don't think they were really that happy about re-leaseing that little MONSTER... It ended up cutting in on MS C++ and .NET sales.

I think masm really got a lot of good hidden stuff in it that can be use for good of a better program but you got to fight with it before you can see all the sh*t that Window and masm are hiding... THEY WORK TOGETHER to let you in OR keep you out of the Window process.

Even if i was as strong as these old pro's HERE , I think i would still choose masm or tasm FIRST...Yaaaaaa things get wacky, (((((masm writing extra jive in your source code Only at Times)))) but when you find your way around it and beat it is kind of fun sometimes (but sometime i think his way might work FULLY in my favorte at a time when really needed... but who really knows without playing with it....

But first and foremost i don't have another life time to wait for code samples while asking the same old questions over again just to get the thing working.... I am not that deep so I'll stick with the problem solver... I will keep an eye on Fasm and work with it as a true side study because it is deep but so is AMAGA or who ever. Anyway I got masm under full control now and i am not yet ready to give that up ...

Well at lease enough to be very happy by....

If you all an true Newbee, use both but go with Masm Frist so that you can be On The BALL . TODAY
Posted on 2002-07-19 18:14:56 by cmax
Subject: Modularity is the base of productive, quick and clean programming.

For all those "scared" about switching assemblers.. I think the problem per se doesn't exist at all.. you use the right tool for the job.. so please see it in a more serene and expecially general way:

Short of (if you know you have the need) making your own object file format and (dynamic or static) linker, IMHO a must for all would be to create for ~each of your functions an object file (e.g. COFF), and then pack them all in a LIB. Then it will not matter what assembler do you use or with what assembler the LIB <- COFF files were assembled: thus the eventual migration will be easier.. nonetheless you may prefer an assembler for a creating certain function, and another assembler (or, why not, a C/C++/BASIC/FORTRAN,etc.. compiler) for creating another function. The nice thing of LIBs is this: in your final EXE will be included only the really used sub-LIB object (e.g. COFF) files (a LIB is basically a set of object files).
This will improve (force you on) modularity, and indirectly increase assembling/compiling speed (since you work on just a module at a time).. and you will have those comfortable LIBs full of useful functions ready to use.. no matter how they were created.

Often beginners tend to stay away from linkers, feeling lost if an assembler doesn't produce (at least with an option) straight executable files.
Spend your time on evaluating the benefits of the tools you don't normally use.. you will have a wider and thus more wise view of the whole coding process, and often you will want to exploit the new benefits anyway.. maybe you will even find the solution to an annoying problem you long thought was "unsolvable".
Posted on 2002-07-20 04:26:50 by Maverick

thank you very much for your replies! You know, this thread wasn't meant as an offence or something, I just wanted to hear some opinions on it. Thanks again :alright:

Posted on 2002-07-20 07:23:04 by NOP-erator