the only immediate use for -d that i can think of so far is for debug builds where you don't really want people messing with it anyway.

Did you think about "standard" way, where you build each file separately to .obj, and at the end link them together? Yes, config file works, but it is worse solution because you have to mess with path to config file.

Now imagine you want to build these files into two slightly different versions (like FASMLIB, one with "fasmlib.init" names, other with "_fasmlib_init@0" names). Doing this with config file requires lot of trickery: you have to generate it with script anyway.

And did you think about mixed project? part of project in C, part of Asm? Using config files for asm there is real insanity.

As long as you only build to single executable file, and all sources are in FASM, do not use -d

I agree with revolution about adding to the command line. If people want things added to fasm it should only be considered as a directive that can be added to the programmers code. Tomasz please considered not listening to vid in the future.

I do hope you are not attributing all of your comments as agreeing with me, because I did not say those things. I was only trying to ask for restraint from people to think more critically before using such things. I am sure some others have perfectly valid uses for it and in that case there should be no impediment towards using it.

@Tomasz: Here's an example code that makesWinME to crash while using fasm 1.67.24.
I have included the error message (jpg) as well. I hope this helps to some extent.

regards,
Mac2004

I got the new version, yeap.
Mac2004 i'll try it on Windows 98, maybe later today and post if see something abnorman.

Now about the second change, I use fasm from the command line often, i think -d is a nice new feautre.
On the other hand one reason for me to love fasm is the total lack of command line arguments

and I agree with you.

I guess since Tomasz did not show restraint, there will be plenty of code in future that will not assemble because of some missing command line directives

Tomasz DID show restrainst that revolution was talking about. He didn't use the -d switch: FASM sources still assemble without it.

He did not show restraint to provide this switch for those (few) who need it, but that is different restraint than revolution was talking about.


I believe there will be *some* code that will overuse -d switch, but i doubt many FASMers will adopt it. As long as SSSO is enough for you (most cases), you 'd be stupid to complicate things with -d switch. And I don't think many FASMers are stupid

[joke mode]
Why I decided I don't like SSSO anymore? See the first definition at http://acronyms.thefreedictionary.com/SSSO
[/joke mode]
But, in fact, I still want this principle to be valid with fasm, and this means there will never be such switches like format selection and others that would directly affect they way fasm compiles the source.
The -d switch is a half-product in this aspect. It allows you to 'adjust' the source a little while assembling it, but I really don't want to encourage using it as an emulation of the 'forbidden' things, even though you may write programs in a way, that they will assemble with output format selected with the proper -d definition (but you still may be able to 'override' it and put the right "define" just in the beginning of "real sources"). I've added this feature, as in some multi-language environment cases it allows things that wouldn't be really possible otherwise (what vid showed to me). It gives you the power, it can be misused - but I just trust fasm's users are wise enough not to put it into the wrong use, conflicting with the fasm's ways of doing things.

I'm still scratching head trying to visualise where -d is really needed. I clearly missed the thread, can someone be kind enough to point me to it. Thanks.

Thanxs! I tested the example on WinXP and it seemed to work just fine...


Regards,
Mac2004

revolution: it wasn't thread, it was private talk. I'll give example it later, gotta run now.

Still don't want to take the risk huh




I think vid still secretly likes it though

Tomasz

Some time ago I think I remember you talking about incorporating some macros in core fasm. Am I correct, and if so, is this still part of your plan for beyond 1.67 and what features would you incorporate?

Regards

Chris

Thanks Tomasz! It makes finding errors alot easier.

I saw version 1.67.25 is out

thimis wrote:

> I saw version 1.67.25 is out

12 days ago

Suggestion (To Tomasz or LocoDelAssembly):

Create a "Global Sticky Locked Announcement" holding the latest FASM version number, date, and recent (from cca 3 versions) history.

Good suggestion, i was thinking something like this.
I've download most of the latest versions with some delay.

There used to be such announcement thread, but when sometimes it was hanging there too long I decided to make those announcement as a regular threads, so that they would stay on top only when something is actually going on.

Ok Tomasz, i missed the thread about version 1.67.25

Further discussion here: t=9634 split by DOS386 2008-12-30