neogna2 wrote:
Could you give an example where a script creator makes the AutoHotkey source available but still has a good reason to not make the C source for the included mcode available?
My suggestions was made from the POV of users of code posted to the AutoHotkey forum. When someone posts only compiled .exe scripts or .dll files here it is pretty common to ask for the source code. I think that's good (reduces malware risk and eases collaborative/derivative work) an I think the same goes for including the C source when mcode is posted.
I am referring to projects outside the scope of the forum, such as the production of non-FOSS freeware or code meant for personal or internal business use.
neogna2 wrote:
Do you have time to expand on that? It would be useful with a short explainer, here or in the wiki, on factors that make the same C source input become different mcode output, such as different compilers and compiler flags.
Previous MCode generation tools would take the compiler's debug output of compiling a single function and manipulate it with regular expressions and other text manipulation techniques in order to extract hex bytes of compiled code, preserving for example the relative positions of all the bytes. This means its output ends up being very similar to a debug view of the compiler output like is provided Godbolt (assuming your Godbolt instance is set to use a similar compiler with similar settings).
MCL takes the
.o object file produced by compiling a source file with multiple exported functions and potentially very many extra functions pulled in from other C files by
#include. The order of exported functions within the object file is very likely to be different than the order of the functions in the Godbolt debug output. Then MCL uses a custom linker to manipulate the object data, replacing certain bytes in order to make the code more functional. MCL also sets up rules for run-time imports of DLL where the contents of the machine code will be altered dynamically each time the script gets run, making static analysis more complicated. Before getting put into the script, the static portion of the binary machine code gets LZ compressed then base64 encoded, which complicates the reversal process for casual inspection.
To compare MCL output to Godbolt output you would need to get past the encoding, compression, rearrangement, and automated modifications applied both at runtime and compile time, provided Godbolt even supports the compiler that was used. It's not impossible, just complicated. Consequently, Godbolt is not a great way to definitively say that the compiled code matches the source code.
boiler wrote:
geek wrote:
For what it's worth, publishing the source of your machine code blobs is not a requirement in many of the situations where you might want to use machine code.
Please describe such a situation, because the
forum rules do not note any exceptions to the rule stating “No closed-source scripts/code.”
I am referring to projects outside the scope of the forum, such as the production of non-FOSS freeware or code meant for personal or internal business use.
That some projects may be using MCode for sharing onto the forum is secondary to the case of people using MCode to perform work. High performance data processing is critical in many cases as a business need. Distributing script among an organization can be done easily by .ahk file where source visibility or obscurity is not really the point.
There are an uncountable number of ways to write, use, and share code outside of a forum with a strict open-source policy. That does not negate the requirement to follow the rules of the forum when posting on the forum, and I apologize if it sounded like I meant it did. I just mean that I am not writing a tutorial on posting on the forum, I am writing a tutorial on creating and using MCode.
boiler wrote:
This is not a valid reason for not providing source code. It is a bit condescending and patronizing to say, “I don’t need to provide the source code because many of you wouldn’t understand it anyway.” Not fully understanding source code and not being able to see it are not the same thing. When it is open source, there is at least the knowledge that it is available to be inspected and understood by others. Not being hidden itself provides a significant level of comfort to all users. But more importantly, it does allow it to be inspected and understood by anyone who has the requisite knowledge, while of course, closed-source code does not.
I do not mean to be condescending or patronizing, I mean to invoke the mental image of non-forum software distribution situations like tools created and distributed by Nir Sofer over at NirSoft, cresstone.com's apps like Shutdown Blocker, Antibody Software's WizTree, etc. There are tons of people online outside of forum situations where open source requirement policy does not apply, producing useful apps where, if they had been written using AHK, MCode would have been extremely valuable to them. People download and run these applications all the time, it is just the nature of freeware.
If you would like me to remove my guide for making machine code because it does not guide people how to follow the rules of the forum, I will gladly do so.