CMD: Bat to Exe Converter - Temp directory problem

Question

Hello,

i am using 'Bat to Exe Converter' to convert my batch files to exe format.

Now, i am running into some problems. Whenever i convert something, and i set 'Working Directory' to 'Current Directory', and i start my exe in echo on mode, this is what i end up with to check if there is a specific file in the directory of my exe:

the actual command: if not exist "%~dp0\file.txt" goto :nofile

output: if not exist "C:\Users\MyUser\AppData\Local\Temp\4CBC\\file.txt" goto :nofile

Can anyone help me with this? I don't want it in the temp directory, i want it to be in the directory of my exe.

Thanks.

Answer 1

Use %CD% instead of %~dp0.

EDIT:

B2EC is not a real converter. Creation location of equipped .cmd file was chosen to be %TEMP% and this is a good choice. Application just lacks 3rd option for working directory of the script - .exe file directory. I advise you to mail the author about adding this one.

Different paths for .exe and created .cmd lead to information loss, i.e. we are unable to know .exe directory and current directory at the same time without providing additional information to the script (e.g. using environment variable or passing it as first/last argument to the script). This script would need to handle it and we would end writing cmd scripts tailored for this converter, which is bad.

%~dp0 - script directory (%TEMP%/.../) - practically useless

%cd% - working directory (as set up in the converter) - currently there are only 2 options: current directory (working directory of .exe) and temporary directory (actually equal to %~dp0, but without trailing backslash)

I think it can be solved by patching cmd.exe instance in memory to change the script path, but that's B2EC developer's duty.

Side note: Normal executable files can be easily executed with specified 0th argument by providing appriopriate lpApplicationName and lpCommandLine to CreateProcess function. Command files are executed via cmd.exe, so 0th argument cannot be set this way.

Answer 2

%cd% will give you the current directory:

if not exist "%CD%\file.txt" goto :nofile

Answer 3

Without having Bat to Exe changed by the author, I think you have two options:

1. Remove the need for accessing %~dp0

   Perhaps you can merge file.txt with the include option of Bat to Exe into the EXE file. If so, "file.txt" will automatically be unpacked in the current directory when running your compiled exe, and you can it access by %CD%\file.txt.

2. Get %~dp0 from outside and pass it to the exe as a command line parameter.

   This can be done by a simple starter bat file that resides in the same directory as your compiled main batch file. This script schould contain the line

   YourCompiled.Exe %~dp0% %%* 
   

   Your compiled exe then gets its directory from %1. So you cannot pack everything into one exe, but the main portion of it, perhaps that is sufficient for you.

Answer 4

Well, apparently your batch to exe converter simply packs the batch file and extracts it to a temporary directory prior to execution. Very simplistic, hard to get wrong (compared to actually understand the batch file) but it introduces errors such as the one you're describing.

Your best bet is probably to use another batch to exe converter; some of them are actually a little more sophisticated.

Answer 5

Generally, this is not a good idea. firstly, its prone to errors and instability of the converter on different cmd features. secondly, a determined hacker can still decode what you are doing with the batch. My suggestion, if you are so afraid of people looking into your batch,

1) let only the people who are authorized to use your batch to use it
2) give them the correct permissions.

OR, don't use batch at all

1) create a central interface such as a web interface, where all tasks to be done goes through that interface, like using an ATM machine where only buttons are allowed and all the available user options can be done by pushing buttons...etc..
2) authenticate your users through a central authentication system, eg Active Directory, or LDAP or a database.