Want to start recompile without using separate .exe and one other question...

[hackersarchangel]

So I was looking at the self delete FAQ code and was wondering if there is a way for me to modify that to do a self compile.

Basically, I want to be able to take my .exe, run it, have it unpack and change whatever files need changing, then recompile everything back into itself. I considered making a separate .exe so I could auto re-run the main.exe afterwards using a switch ,and I was also thinking I could make a placeholder file so the program would know it was just updated and run anything specific afterwards if I didn't make a separate .exe

MsgBox(0,"Start","Starting self-compile attempt.")
    $iDelay = 0
    Local $sCmdFile
    FileDelete(@TempDir & "update.bat")
    $sCmdFile = 'ping -n ' & $iDelay & ' 127.0.0.1 > nul' & @CRLF _
             & ':loop' & @CRLF _
             & @ScriptDir & 'UpdatesAut2exe.exe /in test.au3 /icon test.ico' & @CRLF _
             & 'if exist "' & @ScriptDir & 'Updatestest.au3 goto loop' & @CRLF _
             & 'Pause'
    FileWrite(@TempDir & "update.bat", $sCmdFile)
    Run(@TempDir & "update.bat", @TempDir, @SW_SHOW)

Also, if I make an includes file, to list all of the files that would need including, would that be relative to that file, i.e

This code would run the file from the main.exe being in the highest parent folder (like C: for example)

ShellExecute(""Subfolderincludedsubfolderfile.exe"

But in my subfolder: (example C:UpdateFileInstall.au3 and C:Updateextra_filesfile.exe)

FileInstall("extra_filesfile.exe", "file.exe")

If I was to #include that file into my main.exe, would it be placed in the right folder? I'm gonna test that theory in a bit, and post my findings. The basic thing is that if I was to re-compile the script, since that has to be a literal string, would prefer to not have to do a bunch of checking for those files to be in the right place lol.

As I'm running this through my head, I'm realizing that one option would be to compile that into the other .exe (update.exe) and then just have an extract all switch like /e.

Basic breakdown as I see it in my head: have the main.exe compile FileInstalling only the compiler and the update.exe files. The main.exe file would then extract the update.exe file and by default it would extract all files needed for running the sub programs. When going to update I would pass a switch /u to it so it would update any files, then recompile the main.exe. This is where the my need to possibly pass the command via the loopback into the computer would be needed. My testing shows that when going to run the compiler I need more time between the time I pass the command and the time it starts compiling due to it trying to pack the update.exe file and causing the compile to fail. One option I thought of was to do:

FileInstall("Update.ex_","Update.ex_")
FileInstall("Update.ex_","Update.exe")

but someone else didn't like it because they was thinking it would double the size of the file. I'm gonna test that theory in a minute as well after I finish making my final edit xD

Ok sorry for the massive post but this is a unique to me concept and was wondering if anyone else found this idea interesting and also had any advice.

Edited December 23, 2011 by hackersarchangel

[hackersarchangel]

Ok so I did a test with the option:

FileInstall("Update.ex_","Update.ex_")
FileInstall("Update.ex_","Update.exe")

and it did not double the size of the file. I used a 4mb file to test with, going to include a bigger file and see if it's any different. Also noticed that FileInstall put the files in the same Dir as the Update.exe unless I specified the subdirectory. Since running commands needs to be spot on, just have to remember to specify that Doesn't change anything though.

[czardas]

Why would you do this? Although I think it's an interesting idea, I don't see any advantage to it. On the other hand I can think of several drawbacks. What is wrong with simply writing commands to an external file such as an ini file?

Edited December 23, 2011 by czardas

[hackersarchangel]

What I'm gonna do is compile two .exe's. One that has all the files in it and the commands for recompiling the main .exe. Then I will pack that exe inside the main exe, and when running, unpack the update.exe and then send it a switch to tell it what mode to go into, either to self update, or to just pop out all the files that are needed with the main.exe

Some of the other stuff I was just thinking could be useful, I did notice yesterday on the self delete one that when I had it do that it didn't take long to loopback into the machine except in one instance of that where it took it a full 5 seconds to do that

Oh and the advantage is that with the way I'm designing the program is that we have some files that hardly ever update, but others that update more often, almost daily, so I'm going to pack the least updated files into the .exe but in the event we encounter an old file that needs replacing from our program, we want to replace that file, then rebuild itself on the fly. Sounds complicated I know, but we want a program that can self maintain and still as much as we can when in transport, not run time, stay as one .exe

Edited December 23, 2011 by hackersarchangel

[czardas]

I get the idea and find it intriguing. Perhaps someone else will be able to give you some suggestions, since I have never tried anything like this.. Good luck with it anyway.

[MvGulik]

Mmm, I still don't see any real clear described purpose (Describing how it should work don't count to me as purpuse.).. Only thing I can think of is the bad kind's. ... Posters name not helping in that respect. ...

[czardas]

MvGulik, maybe you are right. It's not a standard approach to updating an app as far as I am aware. I have thought about it a bit and I see it as being a bad idea anyway. Since nobody else has made any comments, I'm leaning towards your way of thinking.

[Melba23]

hackersarchangel,

as much as we can when in transport, not run time, stay as one .exe

This bit is easy. I have written a script which FileInstalls several files within itself (an exe and various graphic and data files). When the compiled script is run these files are extracted to a folder and the stored exe run with a switch set by the parent, using the other files as needed. When the extracted exe finishes, the parent deletes all the extracted files and waits until the next run.

I can see how this could be amended to get the original file to recompile itself with updated internal files, but I really see little advantage over simply replacing the entire file. The "creation" process is rather fiddly requiring the writing of a "compiler" script with a lot of multiple quotes in the strings (always a syntactic nightmare ) and also needing Aut2Exe.exe and AutoItSC.bin to be FileInstalled - which makes for a pretty hefty exe once everthing is onboard.

In my opinion your idea is not without merit, but is unrealistic in practice. In these days of fast broadband download speeds simply replacing the whole exe seems to me to be the better solution.

M23