It's now on my website - this is really an early pre-release of 1.47 version. Please check it.
Posted on 2003-05-15 08:23:04 by Tomasz Grysztar
Looks working. I was hoping you would include external debugger launching support.
Posted on 2003-05-15 19:42:58 by comrade
I donwloaded it yesterday when installing redhat, haven't test compiled anything yet. (just sat up a symlink and ran it to see the link worked, it did, fasm diplayed it's usage screen)
Posted on 2003-05-15 23:29:28 by scientica
Hi Privalov!

Here, it works fine! ;)

What do you say about adding the following features in version 1.47?

Structures:
- Automatically declare sizeof.x in FASM (without macros)
- Automatically declare a virtual structure at offset 0 in FASM (without macros).

New-instructions:
- The frequently used macros for windows programming as instructions (resource-macros, stdcall-macros, import-/export-macros etc.)
- proc-instruction for both 16-bit and 32-bit code (if you write a DOS-program, the stdcall-instructions will use 16-bit code etc.)

=> Much faster compilation...Especially on old computers... Doesn't it?

So long! Take care!
Posted on 2003-05-16 00:54:44 by Tommy
Originally posted by Tommy
Structures:
- Automatically declare sizeof.x in FASM (without macros)
- Automatically declare a virtual structure at offset 0 in FASM (without macros).

I'm thinking about it, maybe I'll implement it when I have enough time, but not as extension to standard "struc" directive, because this would break the compatibility (you can't simply declare a virtual structure at offset 0 when your struc macro definition needs some additional arguments, has variable size, etc.), it'd be some other directive (named "struct" probably).


New-instructions:
- The frequently used macros for windows programming as instructions (resource-macros, stdcall-macros, import-/export-macros etc.)
- proc-instruction for both 16-bit and 32-bit code (if you write a DOS-program, the stdcall-instructions will use 16-bit code etc.)

=> Much faster compilation...Especially on old computers... Doesn't it?

That doesn't really fit into my idea of fasm core (and wouldn't give you as much faster compilation, as you think, especially with import/export macros - you can compare it with the "extrn" directive, which is built-in, but causes very similar slow-down when is used large amount of times, like in windows headers), so it will be hard to convince me to it (BTW: you won't have such problems when you use the objects/linker-oriented programming model, which I recommend for larger projects).
Posted on 2003-05-16 05:07:40 by Tomasz Grysztar
Ok, thank you! I see!

So long!
Posted on 2003-05-16 07:30:50 by Tommy
be the first to make a 64bit assembly compiler!
Posted on 2003-05-16 23:57:29 by Qages
Can you fix the creation of the PE header. I realized today that when I have a valid PE header, OllyDbg shows the arguments for API calls.
Posted on 2003-05-17 00:52:23 by eet_1024
This happens only when you don't set correctly the "code" and "data" flags for your sections.
Posted on 2003-05-17 07:15:55 by Tomasz Grysztar
dare i ask.. "Whats new?"

Maybe you could make a changelog..? (maybe you did and i am blind?)
How about a opcodes.dat file where you can define your own opcodes?

A more open and easyly expandable assembler would be cool..

excuse my horrid spelling.
Posted on 2003-05-17 08:14:37 by xxNelix
What is the proper way to set the sections? I compiled the Hello.asm in fasmw147.zip with fasmw.exe and still get the error in OllyDbg.

An older version of FASM ( don't remember how old) did properly compile.

Why do programs (that have code, data, and import sections) compiled with later versions of FASM have the smalled exe size of 2k, while the older version created 3k executables?
Posted on 2003-05-18 02:48:42 by eet_1024
That's strange, because I don't have such problems with OllyDbg (I'm using 1.08b version).
Older versions of fasm (before the 1.30) did automatically put relocations into each executable, since 1.30 you have to specify a place for them to have them generated.
Posted on 2003-05-18 04:53:13 by Tomasz Grysztar
I'm sorry to say that, but it seems that in the following month I won't have much time to work on fasm, and when I have some time I'll probably spend it writing the source documentation. But that doesn't mean in any way that I'm abandoning the fasm project - I just have to use my time for other things now.
Posted on 2003-05-18 04:55:10 by Tomasz Grysztar
I know, RL is forceing me to leave the computer alone too every now and then :rolleyes: :(









;)

Take care and enjoy real life :)
Posted on 2003-05-18 06:57:58 by scientica
your RL sucks, get a new one :grin:
Posted on 2003-05-18 07:46:28 by Hiroshimator
I've still managed to add some of the most important fixes and updated it to 1.46.9.2
Posted on 2003-05-19 15:35:51 by Tomasz Grysztar


How about a opcodes.dat file where you can define your own opcodes?

You can just do it with macros, like it was done with AMD 3DNow! instructions for some old fasm version (which didn't support them): http://www.asmcommunity.net/board/index.php?topic=7892
Posted on 2003-05-20 12:19:39 by Tomasz Grysztar
Privalov, could you also please add to FASMW that when you make a selection, it would say in statusbar how many characters/bytes you selected?
Posted on 2003-05-20 18:41:18 by comrade
Could you also please make FASMW not do "Optimal fill on saving" on characters inside a string? For example, if I do:
mov dword [eax],"    "

mov dword [eax],20202020h


First line would be converted to tab, some space and rest are zeroes (depends how indented that line is). Second line is what I actually meant.
Posted on 2003-05-20 19:01:04 by comrade
Yes, please Privalov! I agree with comrade....
Posted on 2003-05-21 05:14:14 by Tommy