Got a great idea for a DLL version of NASM

[ben321]

The DLL should simply have one function (which would use the STDCALL calling conventions), and this function would have one parameter. That parameter would be a pointer to a null terminated ANSI string that contained the ASM code to assemble. The function's return value would be a pointer to a structure with 2 fields. The first field would be the number of bytes of compiled code. The second field would be the pointer to the first byte of compiled code. All pointers, and sizes would be 32bit ints (not 64bit ints), to make sure that it is compatible with both 32bit and 64bit versions of Windows. This NASM DLL would only compile 32bit code (not 16bit or 64bit code).

While it would be lacking a lot of features of the full NASM application, this DLL version would make it very easy for a person to write a program in a high level language such as C++ or VB6, and include "thunks" of machine code, as ASM code stored in string consts at designtime. At runtime these text strings of ASM code would then be compiled by this DLL when the DLL file was called by the program. Then one just needs to use Windows API function like DispCallFunc or CallWindowProc to get the program to start executing this raw machine code thunk which was the compiled output of the NASM DLL function.

[Rob Neff]

Hi Ben.  I've pondered on this idea before myself, but with the idea of using the DLL as part of a Just-In-Time (JIT) compiler/assembler for a high-level scripting language.

If the code to be generated is a self-contained function with simple CPU primitives then I theorize it will work.  However, one wall you're going to smack into is when the little assembly snippets need to make external function calls.  You then need the functionality of a linker.

I still think that the possibility of using Nasm as a Windows DLL or Linux shared-object has possibilities which haven't been fully explored yet.

[ben321]

Hi Ben.  I've pondered on this idea before myself, but with the idea of using the DLL as part of a Just-In-Time (JIT) compiler/assembler for a high-level scripting language.

If the code to be generated is a self-contained function with simple CPU primitives then I theorize it will work.  However, one wall you're going to smack into is when the little assembly snippets need to make external function calls.  You then need the functionality of a linker.

I still think that the possibility of using Nasm as a Windows DLL or Linux shared-object has possibilities which haven't been fully explored yet.

So would you be willing to take up the project of creating a DLL version of NASM using the specification's I've mentioned? I can think of many uses for this. One of which would be to generate a thunk of code for each of the main mathematical operations that need to be done (even as simple as addition or subtraction) in the main program, but the main program would instead of using its own internal addition and subtraction routines, depend on the addition and subraction routines in these compiled thunks. The thunks themselves would have no need to handle other DLLs. That would be the job of the main program, and in fact the main program would likely NOT be written in assembly. My programming language of choice is VB6. The application's code would only call the DLL NASM to compile the asm code, if the application's license is activated. Furthermore, as soon as the code was compiled by the DLL, the main program would encrypt this generated machine code. And then it would only be decrypted if the application's license is activated. This is a 2 point check on activation of the software (once for compiling on the fly, once for decrypting on the fly). And of course it wouldn't run at all if it didn't exist (wasn't yet compiled) and if it was compiled but encrypted it would still not run properly (resulting in a crash) if the encrypted code was executed. Both the compiling and the decrypting would be conditional on the main software being properly licensed. Therefore this could be used to make a highly secure copyprotection mechanism, whereby key portions of code would be missing if not license, and even if the first part was "cracked" the code that got compiled would remain encrypted and not run properly. This would pose a second obstacle for crackers to get past. Of course, this entire scheme that I've thought of here, hinges on somebody making this DLL version of NASM for me. Once that is DLL file has been created according to my specs in the opening post I made in this thread, then it will be a very simple matter for me to implement copy-protection in any future programs I write.

[Bryant Keller]

Hi Ben.  I've pondered on this idea before myself, but with the idea of using the DLL as part of a Just-In-Time (JIT) compiler/assembler for a high-level scripting language.

Some time ago I played around with a homebrew cluster (about 9 old laptops) out of pure curiosity in parallel computing. During this time I used a language called Julia that uses LLVM for JIT compilation. It was actually nice to go from prototyping ideas to looking over the machine code in a REPL environment. I think a DLL based implementation of NASM would be very interesting.. especially attached to a powerful scripting language. The real downside to Julia for me was that, although I could inspect the assembly code being generated by the LLVM, there wasn't much of an option for my to customize it while staying in the REPL itself. I had to exit to an editor, create a modified version of the code and link it into the session. 

[ben321]

After all this time after suggesting it, and nobody has yet taken on this project? I was sure at least one forum member would have done so by now.

[zolugynnav]

All the features of the DLL should be simply so that the users could use those features and learn those by practice,One of the Best essay reviews by wih the students should learn more details about the quality of the DLL version.

[ben321]

And still nobody has been willing to compile a DLL version of NASM?

[ben321]

Why has nobody made a DLL version of NASM yet?