Making an .exe that executes source file inside itself.

BoQsc vaidas.boqsc at gmail.com
Fri Apr 27 14:57:34 UTC 2018


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-exectuable, 
self-extracting archive, it would confused people weather it is 
executable or some novice programmer's written module/script.


More information about the Digitalmars-d-learn mailing list