Some questions

[oddmario]

Hello,

I have some questions regarding Appacker.

1: Will Appacker handle the arguments of my application? For example, Can I pass arguments to the packed EXE file? Will Appacker send those arguments to the main executable EXE file?

2: On which line I can change the temporary path location which Appacker will extract the packed contents to?

3: Does Appacker set the correct working path? For example, if I have a file called hi.txt in the same location of the packed EXE using Appacker... Will Appacker read it from the temporary path or from the path of the packed EXE file?

4: On the 3rd question, if Appacker doesn't set the correct working path, is it possible to fix this?

Thanks!

[SerGreen]

1. No, it won't. I haven't thought of that, hm. I will fix this somehow, just have to figure out how to differentiate Appackers's args and target app's args. Nevermind, Appacker takes arguments to the main exe, but packed app is a separate exe (unpacker.exe), so that'll be easy to fix.

2. It extracts to the %temp% folder. If you want to change this behaviour in code, that should be Unpacker project, Unpacker Program.cs, lines 83-86:

   // Create temp directory to store unpacked files
   while (tempDir == null || Directory.Exists(tempDir))
   tempDir = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
   Directory.CreateDirectory(tempDir);

   That's where target app is unpacked. Auxiliary tools are extracted into separate temp folder, lines 97-100.

3. Yes, it should properly set the working directory, target app will search for files in its temp folder, so the files it creates go to the temp folder too and can later be repacked. Working directory is being set in Unpacker Program.cs, line 168.

[oddmario]

Thank you very much :-)

But for the 3rd question, I meant if my applications reads the content of the hi.txt file for example... and this file (hi.txt) won't be packed using Appacker because I want my application's user to write in it.. So hi.txt won't be copied to the temp path. How can my application read it then? It should give an error because %temp%\hi.txt doesn't exists but it exists in the location of the packed EXE file

Sorry for this long explainition xD

[SerGreen]

Ok, if i understand correctly, you want something like this:

1. You have target app in C:\apps\app.exe
2. You have some file in C:\apps\hi.txt that target app reads
3. You have packed app in C:\users\me\desktop\app_packed.exe
4. You want to be able to place hi.txt in C:\users\me\desktop\hi.txt, then run app_packed.exe and you want unpacked target app to read this hi.txt from desktop

If so, then this can not be done easily (if at all). The problem is that if you don't set working directory to the temp folder, then unpacked app will indeed find the hi.txt on desktop, but it won't be able to find other unpacked files from the temp folder (like resources or config files), because it will search for them also on desktop, where packed exe is.

The only way i can think of right now is to hook the unpacked app's read/write calls (as this stackoverflow answer says) and then check both folders for the requested files (where unpacked app is and where packed app is). I've never done anything like that and i'm not sure it's actually possible in this case, but one way or another, that doesn't sound easy, so i wouldn't count on me actually doing this.

That means that if you want your packed application to use some external files, they should be located inside app's directory or pass them via arguments (this i will implement).
I can make an option that will allow you to select where you want to unpack your application when you launch packed app, so it will be easier to find the folder and put hi.txt there.

[oddmario]

What about copying all the files and the folders that are in c:\users\me\desktop to the temp path too? Maybe a weird solution but I think it might so it

[SerGreen]

Well, that would definitely work, but you never know what can be there in the same folder along with the packed app's exe. In worst case scenario it would try to copy gigabytes of random files that just happened to be in the same folder, AND all those files then would get included in the repacked app.
Such behaviour is unintuitive and can lead to undesired results (such as copying tons of unrelated files), therefore should be avoided.

[oddmario]

But I think that when the packed EXE starts the target EXE, the operating system will see the working directory as the directory of the packed EXE. I remember that this happened before.

I can't try those 2 weeks because I can't be on PC :/

[oddmario]

This happens if it is a process... And as I can see from lines 165 to 171 on the unpacker program, Appacker starts the unpacked EXE as a process. Am I right?

[SerGreen]

Yes, Appacker starts unpacked EXE as a new child process. And yes, this new process will see the directory of the packed EXE as the working directory, but only if you don't specify another working directory during creation of this process, as we do on the line 168: WorkingDirectory = tempDir. And here's why we need to change the working directory for then unpacked EXE:

To test this, i have created a simple app, that tries to open two files — hi.txt and config.cfg, these files are expected to be right next to the app's EXE, so it tries to open them like this:

try
{
    using (StreamReader sr = new StreamReader(File.Open("hi.txt", FileMode.Open)))
        Console.WriteLine(sr.ReadToEnd());
}
catch (FileNotFoundException)
{ Console.WriteLine("<file not found>"); }

Then i pack this TestApp.exe together with config.cfg into a package using two versions of Appacker: the first one changes the working directory to temp folder and the second one does not change it. Now i place firstPacked.exe, secondPacked.exe and hi.txt on the desktop and run both packed apps. Here are the results:

As you can see, the package that changed working directory to temp managed to open config.cfg from the package, but did not find hi.txt, and for the package that did not change working directory it's other way around.

[oddmario]

If I changed the working directory, the DLL files won't be loaded, right?

[SerGreen]

If you load them manually using relative paths, then they won't be loaded, but if DLLs are referenced by your application and packed along with the main EXE, they load even if working directory is desktop (i just checked that). But everything that uses relative paths in your app gonna break.

[SerGreen]

Ok, i've published new update v1.3.5, it implements arguments for unpacked application. Also there are two new options for packing: you can change the directory to which extract application files, and you can select to open that directory in Explorer when you launch your packed app.

[oddmario]

Well! Thank you very much :-)