flat assembler
Message board for the users of flat assembler.

flat assembler > Compiler Internals > fasm as DLL

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
Aslan



Joined: 09 Sep 2013
Posts: 2
Post 09 Sep 2013, 19:04
View user's profile Send private message Reply with quote
DVicthor



Joined: 13 Sep 2013
Posts: 3
Location: Nigeria
Has anyone thought of making a pure or .pyd python wrapper around the FASM dll?
Post 16 Sep 2013, 16:13
View user's profile Send private message Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
Hi all,

This is my first post, so I hope not to break some board stated, or not, rules. Moreover, I expect there is not a problem of replying to a thread that is inactive for so much time.

I have been fasming for two or three weeks now and I am liking it a lot (I have been fasming with fasm and I pretend to start doing it with fasmarm), so, first of all, I would like to thank the authors of both the projects, in special Thomas, which has been the initiator of all this.

I have not tested the fasm dll yet (it would be great if there was such a dll for fasmarm too!) because I would need two more functions for what I pretend to do:

fasm_Assemble(lpSource,lpMemory,cbMemorySize,nPassesLimit,hDisplayPipe,pToCallbackFunction)

and

fasm_AssembleFile(lpSourceFile,lpMemory,cbMemorySize,nPassesLimit,hDisplayPipe,pToCallbackFunction)

the argument pToCallbackFunction would be used by the fasm (or fasmarm) dll whenever a file would have to be opened (file directive or include directive), so that I could open it, preprocess it, and only then pass the data associated with it to the fasm (or fasmarm) dll in a memory block (this memory block should not be changed in any way by the dll, only read by it).

the callback should point to a function like:

requestToDllClientToOpenFile(lpSourceFileName,lpAsnwerStruct)

where the argument lpSourceFileName should point to a null terminated string with the name of the file to open (the name associated with this does not have to point to a real file if the client knows how to handle it) and the argument lpAnswerStruct should point to a struct in memory where the dll client would pass info to the fasm (or fasmarm) dll.

the info to pass to the fasm dll on this struct should be something like this:

uint32 success - this would inform the fasm dll whether or not the openning of the file was successfully. If an error occourred, then the fasm dll should stop fasming and report an error.

uint32 lengthInBytesOfPreprocessedOpenedFileData - this would inform the fasm dll (in case the file had been successfully opened) the length of the data associated with the openning request.

uint32* pToFirstByteOfPreprocessedOpennedFileData - this would point to the first byte of the data associated with the opening request (in case the file had been successfully opened).

Thomas, it would be really good if you could implement this!

Thanks in advance!

Best regards,

Ippasm
Post 24 Oct 2013, 11:50
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6966
Location: Kraków, Poland
This is a very good suggestion - it would allow to assemble multi-file projects completely in memory and it is actually something that I wanted to do.

I think I'd prefer to implement it with an additional function like "SetFileCallback", so that the fasm_Assemble function would be kept as is, completely backwards-compatible.
Post 24 Oct 2013, 13:01
View user's profile Send private message Visit poster's website Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
I am very happy you liked the idea!Very Happy

Yes, using such a function would be ok! I was assuming that the dll would be memoryless between calls to assemble, so I would never ask for such a function...

As you sugest such a behaviour (not memoryless) from the dll, another non-memoryless inclusion would be a function to handle some inc files before hand.

Specifically, imagine I have 100 inc files with macros and all the programs I want to assemble take profit of some of these macros, in this case it would be great if we could preload those macros just once and then we would only have to take care of the files of the specific programs afterwards.

Of course, if I only have a "wish", then forget the mention of this last function. Embarassed

Best regards,

ippasm
Post 24 Oct 2013, 13:07
View user's profile Send private message Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
Even if a function to preload macros would be great, if it will not exist, then the client of the dll can simulate it to some extent by preloading all his files with the shared macros to memory and when the fasm dll asks for them (indeed, for the file that contains them!) due to an include or file directive, then the client will just give the pointer to them and, with a bit of luck, they will not be paged out, so it will be quicker to pass that info to the dll than to access the disk each time such a file is requested by fasm.

Obviously, in this case, the client of the dll must maintain a data structure with the path in memory to the given files...

I am assuming that fasm does not "pre-compile" the macros and uses the files with the macros as an interpreter...

If it uses them as an interpreter and the client maintains these files in his memory, then satisfying an open request from fasm will be as quick as for fasm to maintain them internally in its memory and use them as required (the only difference in timming is a call to the client to pass the memory with the required file to the dll, instead of directly accessing its (fasm) memory where the files are maintained!).

By the contrary, if fasm does some kind of "pre-compilation" on the read files with the macros, then pre-loading them to the fasm dll will improve a lot the assembling, because this "pre-compilation", which surelly takes more time than passing memory around, would only be undertaken once.

Just some thoughts...

Best regards,

ippasm
Post 24 Oct 2013, 14:29
View user's profile Send private message Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
Hi all,

In my opinion there is one more plus to have the possibility of compiling multiple-file projects in memory: if the fasm dll does not access the file system, probably, it won't access any other file system call and, as so, we can use it in any other x86 OS (like android, linux, menuetos, etc) by undertaking the following steps:

1) open de dll file;
2) copy it to memory;
3) read the PE file data and find the code and data sections;
4) copy the data on the code section to a new location in memory and allow this memory to be read and executed;
5) copy the data on the data section to memory and allow this memory to be read and written;
6) find the pointer to the entry point of the dll and call it;
7) find the pointer to the function setfile callback and set the callback;
8) find the pointer to the fasm_Assemble function and start assembling the projects.....

Thomasz, if the client of the fasm dll undertakes all the 8 steps above, will he be capable of fasming projects in memory in non-windows oses, as expected?

I apologize for posing so many questions, but I am very excited with the possibility of fasming multiple-file projects in memory!

One last question, can we expect to have the said possibility soon (by the end of November, by the end of 2013, etc)?

Best regards,

ippasm
Post 25 Oct 2013, 10:23
View user's profile Send private message Reply with quote
Kenneth



Joined: 16 Nov 2005
Posts: 38
Location: United States of America
Trying to compile with most recent fasmw source cause an undefined symbol error for tagged_blocks. Commenting the offending line, the dll compiles fine.
Code:
cmp     eax,[tagged_blocks]
ja      out_of_memory
    

Is this check still necessary with most recent fasmw and what would be the equivalent? I don't have the old sources so I can't figure it out and it seems like it might be important.
Post 17 Nov 2013, 20:34
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Walter



Joined: 26 Jan 2013
Posts: 132
Kenneth,

Notice in the first thread of "fasm as DLL", it say
(assembled with 1.71.08 core).

My guess is that you are trying to assemble with fasm 1.70.03.

Use this version and you should be good:

http://flatassembler.net/fasmw17116.zip
Post 17 Nov 2013, 23:33
View user's profile Send private message Reply with quote
Kenneth



Joined: 16 Nov 2005
Posts: 38
Location: United States of America
I never notice there were newer fasm releases available on the downloads page, thanks.
Post 18 Nov 2013, 00:16
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
theBB



Joined: 24 Jul 2014
Posts: 1
Hi everyone, this was asked before but i think it hasn't been answered yet.

I would like to use FASM as .so in linux. How can i create .so version of FASM or do you have .so version of it?
Post 24 Jul 2014, 06:22
View user's profile Send private message Reply with quote
evk1



Joined: 18 Jun 2014
Posts: 24
theBB wrote:
Hi everyone, this was asked before but i think it hasn't been answered yet.

I would like to use FASM as .so in linux. How can i create .so version of FASM or do you have .so version of it?

ELF DSO usually use position-independent code, FASM uses absolute addresses for global variables, so I think it is hard to port FASM library to Linux without source code rewriting.

_________________
Sorry for my English
Post 24 Jul 2014, 14:43
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
rugxulo wrote:
Nifty. This makes me want a QBASIC-like IDE where you can run immediate assembly code. (To be honest, I'd never use it, but it'd be cool.)

P.S. Any reason for including FASM.DLL in the .ZIP twice? (seems silly but maybe I'm overlooking something).


Scheme! Smile

http://en.wikipedia.org/wiki/Scheme_%28programming_language%29
Post 05 Dec 2014, 22:23
View user's profile Send private message Visit poster's website Reply with quote
Ben321



Joined: 07 Dec 2017
Posts: 57
Suggestion for improvement of this DLL. Since there is no way to know before compiling how big the output will be, it is impossible to pre-allocate the ammount of memory needed. To fix this situation, I recommend a size-check function, which allocates memory to run through compilation and generate an exact bytes size, and then discards the compiled data. After this, your program can allocate a buffer of that exact size using the return value from the size-check function. Then finally you can call the actual compilation function to compile to your own allocated memory.
Post 06 Jul 2018, 07:36
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6966
Location: Kraków, Poland
The block you allocate is not just for output, it serves as an entire working memory for the assembler. When the assembly is complete, the block contains also things like entire preprocessed source and other various buffers. You should copy the generated bytes out of it and then discard the whole area. fasm 1 uses an ancient memory management that was originally intended for DOS-like environment and for this reason it requires all of its memory to be in a single continuous block of memory that cannot be resized after assembly has started (it is used from both ends).

If you'd prefer something with more modern memory handling (and thread-safe), fasmg is the way to go. Though you need to include macro packages for needed instruction sets then. I have not yet made a DLL version of fasmg (there were no requests) but this would be in fact much simpler that it was with adapting fasm 1 for this purpose.
Post 06 Jul 2018, 07:48
View user's profile Send private message Visit poster's website Reply with quote
sesey



Joined: 21 Aug 2018
Posts: 3
Hello to everyone,
@Tomasz Grysztar
Do you think compiling dll for the current version of Fasm?
Do you have a work for x64?
I can not use this dll file in my x64 application.
thank you for everything.
Post 21 Aug 2018, 07:43
View user's profile Send private message Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 190
Location: Russian Federation, Sochi
Do you think compiling dll for the current version of Fasm? - Just put sources of dll and last fasm together - and compile - I already got fasmdll 1.73 this way.
Do you have a work for x64? - Actually win64 executables could communicate with x32 dlls (if dll functionality wraped in com object, and such dll registred and its coms registred too, than we could use such com object from any 32 or 64 bit process).
How to make a com dll? - Thou got to implement exports: getClassObject - where thou should realize thour classfactory, than thou got implement com object itself, implement counter cheker CanUnloadNow...

(that my final target in programming for windows - to write/to adapt fasmg as library, not as usual library but as com object extension for windows explorer, and make from it universal editor - name for it is ready "Can opener" or "открывашка") - at current state no fasmg as dll, and I couldn`t create working shell extension library in assembly. I already shared pieces of comdll sources (unfinished) somewhere in forum.
Post 21 Aug 2018, 08:29
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6966
Location: Kraków, Poland
sesey wrote:
Do you have a work for x64?
The tricks used to make it work as 64-bit ELF would probably be enough to make it into a 64-bit DLL as well, but you would have to provide it with a memory block that resides within the first 4G of addressing space (in Linux this is provided by sys_brk).

ProMiNick wrote:
at current state no fasmg as dll, and I couldn`t create working shell extension library in assembly.
It should be easy to make fasmg into DLL, would you like me to help you with this? One of less obvious things to do would be to move all the variables into a local (EBP-based) block, other than that all should be simple.
Post 21 Aug 2018, 08:52
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 190
Location: Russian Federation, Sochi
That would be perfect (requested only feature fasmg compiling memory to memory) if it will be done inside fasmg oficial pack that will be more than perfect, and than will be frequency updated as fasmg.
But internal variable __FILE__ without value can produce bugs in virtual blocks (when they are as additional files).
Post 21 Aug 2018, 11:14
View user's profile Send private message Send e-mail Reply with quote
sesey



Joined: 21 Aug 2018
Posts: 3
@Tomasz Grysztar and @ProMiNick
I thank you for your answers.

How can I compile this source code as x64.dll?
How can I make com?
I will use this dll file in the .net platform.
I will do this compilation in the windows environment.
I can compile it as x32, but x64 gives an error.
I have a little lack of information.
Post 21 Aug 2018, 11:47
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.