Making an .exe that executes source file inside itself.

[IntegratedDimensions]

On Friday, 27 April 2018 at 14:57:34 UTC, BoQsc wrote:
> On Friday, 27 April 2018 at 04:30:32 UTC, IntegratedDimensions 
> wrote:
>> On Thursday, 26 April 2018 at 06:18:25 UTC, BoQsc wrote:
>>> On Wednesday, 25 April 2018 at 20:44:10 UTC, u0_a183 wrote:
>>>> On Wednesday, 25 April 2018 at 19:54:26 UTC, BoQsc wrote:
>>>>> On Wednesday, 25 April 2018 at 19:43:31 UTC, Jonathan M 
>>>>> Davis wrote:
>>>>>> [...]
>>>>>
>>>>> Thank you Jonathan for a response.
>>>>> I was aware of this, and it certainly perfectly works where 
>>>>> command line/terminal interface is the main tool to control 
>>>>> the system, a good example would be linux/gnu distributions 
>>>>> and macOS.
>>>>> However in Windows while installing D language, I noticed 
>>>>> that .d source file extension is not associated with 
>>>>> neither D compiler (dmd.exe) nor D script interpretator 
>>>>> (rdmd.exe)
>>>>> So they can't be ran directly by clicking on those, nor 
>>>>> they have any icons that show that these source codes are 
>>>>> actually executable. This is a huge problem, because people 
>>>>> that are not aware of D language migh be harder to 
>>>>> understand that source script could be executable, at least 
>>>>> - without help from some more experienced user.
>>>>
>>>> If the purpose is to make scripts run by clicking them you 
>>>> can assign a file type to .d files.
>>>>
>>>> On Windows 10. 
>>>> https://www.digitaltrends.com/computing/how-to-set-default-programs-and-file-types-in-windows-10/
>>>>
>>>> Doing so would make the script engine the default program 
>>>> instead of a text editor so you might not want to. Or maybe 
>>>> assign .dxe and changing the filename before running.
>>>
>>> Executable has executable file type for a reason - it 
>>> self-implies that the main function of the file - is to be 
>>> executed.
>>> The problem with making source code files executable is that, 
>>> source code files, might not always be monolithic executable 
>>> code, but a part of a bigger interconnected program.
>>> That would lead to partily working program execution, and 
>>> most of the times guess work of whether source code file was 
>>> supposed to be executed.
>>>
>>
>> This is wrong. All code must be included. All library source 
>> code is included. If this is infeasible then simply the 
>> binaries are included. It would be no different than dynamic 
>> linking that already exists. It doesn't create any new 
>> problems.
>>
>> Sure certain things would need to be worked out properly to 
>> optimize the experience, but that is obvious. One can't make 
>> everything perfect though and one shouldn't expect it...
>>
>>> The clear alternative would be: .exe file on which, if 
>>> rightclicked - would open context menu showing posibility of 
>>> "edit/improve this executable". Which would not create 
>>> additional problem mentioned above.
>
> Yes, all the source code and required source code to make 
> everything work must be included. And where would all the code 
> mentioned before should be stored?
> It must be stored in a an single self extracting archive, self 
> executing archive, that is self-implying that it is an 
> executable code, which means it can't be .d file extension, but 
> an .exe file extension. (or any other, if anyone come up with 
> more common or self explaining extension name)
>
> If we use the same .d file extension on this self-executable, 
> self-extracting archive, it would confused people weather it is 
> executable or some novice programmer's written module/script.

No, it would have to be an exe on windows. an exe is basically a 
self executing container. Almost all exe's only contain the 
binary but they can contain data. For example, zip files can be 
saved as self-unzipping executable.

It is not a big deal to package the data in the exe and make it 
all work. Initially, it is not necessary to worry about. What 
happens is that the actual initial binary that will run will 
essentially decide what needs to be done and unpack everything 
and deal with it.

You can think of the exe as a small file system that contains all 
the files necessary and a binary that handles whatever needs to 
be done which is run by the OS.

Several binaries in the file would be things like the 
IDE/debugger and the compiled source code. If the user just wants 
to run the app like any normal app then the compiled source code 
would be extracted either to a temp exe file or to memory and 
ran. (so the initial process just does some unpacking and passes 
control)

If debugging and modification is to be done then the initial 
process will have to do more work such as compile the source with 
debugging symbols, special hooks, and all that. The files would 
have to be extracted in memory or on disk. The ide would be ran, 
etc.

For example, android apps are actually special zip files.

All of this stuff is childs play. The real work is having a 
proper design that integrates everything well. Nothing would be 
technically challenging but just a lot of work to get everything 
done.

I do think that apps that were designed to be used this way would 
need to be structured and designed in a way that makes it 
conducive to debugging and modifying easily and quickly.