It's now on my website - this is really an early pre-release of 1.47 version. Please check it.
Looks working. I was hoping you would include external debugger launching support.
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)
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!
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!
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).
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).
Ok, thank you! I see!
So long!
So long!
be the first to make a 64bit assembly compiler!
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.
This happens only when you don't set correctly the "code" and "data" flags for your sections.
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.
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.
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?
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?
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.
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.
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.
I know, RL is forceing me to leave the computer alone too every now and then :rolleyes: :(
;)
Take care and enjoy real life :)
;)
Take care and enjoy real life :)
your RL sucks, get a new one :grin:
I've still managed to add some of the most important fixes and updated it to 1.46.9.2
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
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?
Could you also please make FASMW not do "Optimal fill on saving" on characters inside a string? For example, if I do:
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.
mov dword [eax]," "
mov dword [eax],20202020hFirst 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.
Yes, please Privalov! I agree with comrade....