Calling of fasm.dll from PowerBasic.

https://www.powerbasic.com/support/pbforums/showthread.php?t=50237

Has anyone thought of making a pure or .pyd python wrapper around the FASM dll?

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

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.

I am very happy you liked the idea!

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.

Best regards,

ippasm

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

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

Trying to compile with most recent fasmw source cause an undefined symbol error for tagged_blocks. Commenting the offending line, the dll compiles fine.

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.

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

I never notice there were newer fasm releases available on the downloads page, thanks.

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.

Scheme!

http://en.wikipedia.org/wiki/Scheme_%28programming_language%29

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.

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.

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.

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.

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).

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.

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).

@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.