Using text file (.txt) with an executable.

[pguild]

I have an awesome application that reads text file to expand it's native capabilities.
I might have 6 .txt files that the user can pick from when using the .exe application and an ini file too.

I currently compress all the files into a zip file and then distribute the zip file by
creating a link to it in dropbox zipped file. The user creates a folder and then extracts all files into that folder. 

Is there a better way?
I noticed that there is an "Other File" option i the compiler. What is that for?  Who does it work?

[JTaylor]

That would work well for your files.  It packages the listed files into the Exe like it does the extenders.  You can automatically extract them (compiler setting) or manually extract them, thereby gaining control of where to place them.

Look at the ExtractAttachedFile() function in the WinBatch.chm file.


Jim

[pguild]

Thank you! How would the user automatically extract them?

[JTaylor]

In the compiler under Settings.  You can find more info in that Help File.   I think Auto Extraction is the default but not certain.

Jim

[td]

From the Consolidated WIL Help file:

"The OTHER FILES button displays a File Selection Box of files which can be chosen and compiled into a Standalone EXE option. More than one file may be chosen. The selected files will be displayed in the WinBatch Compiler Dialog box next to the OTHERFILES button.

The OTHER FILES are written to the current directory.  If the directory is write protected, an error will occur.

If you would like to explicitly place the OTHER FILES somewhere other than the current directory, the Compiler contains a SETTINGS option to skip auto-extraction of extenders and "other files". ExtractAttachedFile() allows you to programmatically extract an embedded files from a Standalone EXE (except the WIL DLL, it is always extracted, if necessary).

Notes:

Keep in mind that adding too many large EXTENDERS and OTHER FILES can increase demands on memory and could cause an issue. This is dependent on available system memory. It should not have any effect on the script execution itself, once the files get unloaded."

or here:
https://docs.winbatch.com/mergedProjects/WinBatch/WINBATCH_OF_001.htm

[pguild]

In my testing it seems that if I add an .ini file to the other files, it does not get written to the directory that the .exe is in. However, the txt files do find their way into that directory. This is a big help because I will not need to compress all the files into a zip folder.  I gave up on trying to install the .ini file and just create it programmatically in the .exe. Maybe I am doing something wrong, becayse I cannot get the .ini file to be written to the .exe directory.
Thanks for your help! 

[td]

Some newer server versions of the Windows OS (last 8 years or so) treat files with the ".ini" extension differently than other text-based files. They can require user or group specific folder permissions to be able to write to the file. That said testing would indicate no issues specific to ".ini" files extracting when on a non-server version of the OS.

[kdmoyers]

I have noticed this too (though it was years ago).  Windows is a bit particular about .ini files.

For myself, I have stored fairly disposable UI preference settings, so I put them in

Code: Winbatch

shortcutdir("personal")

  or 

Code: Winbatch

environment("TEMP")

and that seemed to work OK.

[KeithW]

How about saving your .ini file with a unique (to you) extension... ie:   myfile.fooledya  and in your exe if you find a  *.fooledya rename it to .ini ?  Or would Windows be dumb enough (I mean smart enough that is) to stop that?  Inquiring minds always like to know.

[stanl]

How about saving your .ini file with a unique (to you) extension... ie:   myfile.fooledya  and in your exe if you find a  *.fooledya rename it to .ini ?  Or would Windows be dumb enough (I mean smart enough that is) to stop that?   Inquiring minds always like to know.

I started renaming .ini into .cfg

[ChuckC]

iirc, it's the INI file API functions that are doing the virtualization & redirection of file system locations, and they don't care what name/type you give the file.

[pguild]

Thanks for your reply, but I have no idea what that means. Please explain so a 9th grader can understand. 

[td]

iirc, it's the INI file API functions that are doing the virtualization & redirection of file system locations, and they don't care what name/type you give the file.

I have never tested it to be 100% sure but the APIs being the source of the problem is my belief as well. I should have indicated this instead of referencing the problem by file extension.

[stanl]

Thanks for your reply, but I have no idea what that means. Please explain so a 9th grader can understand. 

Tony and Chuck appear to agree that the native Win ini API will take control of where an ini file is placed when extracted from a WB exe, possibly regardless of the extension used.


Should not be confused with WB ini functions which can get/set items regardless of the location or extension [at least that is my experience]

[ChuckC]

With the release of Windows Vista / Windows Server 2008, Microsoft introduce a couple of significant changes that affect how the runtime environment is presented to a program that is running based on the 32/64 bit aspect of the program as well as whether it is running with or without elevation [admin rights] or if any application compatibility settings have been set for the program to make it think it's running on an older release of Windows.  UAC [User Account Control] is heavily involved in this behavior along with the "virtualization" that it provides.

In a nutshell, 64-bit application programs, which first gained full support with Vista / 2008, are expected to be 100% fully compliant with "how things get done properly on 64-bit Windows".

32-bit application programs, on the other hand, are effectively treated as a dumpster fire in need of being tamed when it comes to their behavior.  Prior to Vista and UAC, most 32-bit apps simply assumed that the user had full admin rights and they operated as if they should have carte blanche access to anything & everything in the file system and registry.  The moment that UAC stripped away admin rights and forced most programs to run under a restricted access token as a normal user, those programs would begin to break in various & sundry ways.  To compensate for this and to minimize the "breakage", Microsoft introduced some mini-filter drivers that intercept all access to the file system and registry that is performed by 32-bit applications and it selectively redirects those accesses to locations that are part of the user's profile instead of common/shared "system" areas that are now subjected to much more restrictive permissions.  One of the most common issues to be dealt with had to do with INI files and the API functions that are used to access them.  Many applications assumed they could write to any INI file in or under "C:\Windows", which is now disallowed.  So, any time a 32-bit application attempted to write to a INI file in/under "C:\Windows", the I/O operations got redirected to a location under "C:\Users\<profile-name>\AppData\...".  Likewise, 32-bit applications attempting to read/write the registry get selectively redirected to a "WOW6432Node" subkey that is an immediately subordinate of a key that shouldn't be accessed without "awareness" of the overall 64-bit runtime environment.  For example, "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node" is where a 32-bit app is redirected to when it attempts to access "HKEY_LOCAL_MACHINE\SOFTWARE".

Just do some Google searches for "Windows", "UAC" and "Virtualization" and then do some reading.

[td]

There are two types of ".ini" files - private and system. Private ".ini" files (WinBatch Ini*Pvt functions) should not generally be written to the "Windows" directory but to a targeted directory specified in the file's path. I have not experienced any issues writing private ".ini" files from a regular WinBatch script as long as the account running the script has write permissions to the target folder. This is the same rule that also applies to the WinBatch FileWrite of FilePut functions. I don't believe that the 32-bit redirection is a factor in the case of private ".ini" files as long as the target folder is not in the Windows folder tree.