{"id":7473,"date":"2021-10-24T15:19:02","date_gmt":"2021-10-24T15:19:02","guid":{"rendered":"https:\/\/max-drake.cc\/?p=7473"},"modified":"2021-10-24T19:15:02","modified_gmt":"2021-10-24T19:15:02","slug":"setting-up-install-files-to-share-for-prototyping-with-security","status":"publish","type":"post","link":"https:\/\/max-drake.cc\/?p=7473","title":{"rendered":"Setting up install files to share for prototyping with security"},"content":{"rendered":"\n

Following on from Compile a program for install for distribution<\/strong><\/a> article.<\/p>\n\n\n\n

I’m thinking about doing some paid work, so I want to be able to send prototype scripts to people to use, but not the full version, or rather a version that will run for a while and then stop. <\/p>\n\n\n\n

That way the customer can test it out and see whether it meets their need, but not take it and run without paying if it does. <\/p>\n\n\n\n

After playing with a couple of installer setup programs (see other post) I’m satisfied, at the moment with NSIS. So this post is about using that. <\/p>\n\n\n\n

It seems to require a rethink on how I write files and also think about using files. <\/p>\n\n\n\n

Whatever procedures I setup at this point, I do not want to mess with the OS registry at this point. So do it all with files. <\/p>\n\n\n\n

Processes for short active scripts<\/h2>\n\n\n\n

There are a couple of methods that I’ve thought of (as in re-inventing the wheel) and they are ,<\/p>\n\n\n\n

  1. via count, you can run so many times, then it stops<\/li>
  2. a specific duration (trial period).<\/li><\/ol>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    File Structure<\/h2>\n\n\n\n

    For the file structure, you are giving them an .EXE compiled file (so they can’t EASILY look at the script- AHK scripts viewable) and whatever added support files that script requires, license, readMe, Library Files and importantly .ini files and write-to files. <\/p>\n\n\n\n

    The .EXE file is compiled, so can’t change, so any changes- eg Start\/End dates has to be put into a writable file such as an ini file. So if you do a FROM DATE (first time the program runs, eg INSTALL DATE) to an END DATE eg 30 days after the FROM DATE, then you need to be able to write these date somewhere and a .ini file is a good place to do so. <\/p>\n\n\n\n

    The same goes for COUNT. If you preset the .ini file to Count 5 and count down, or set as 0 and count up. <\/p>\n\n\n\n

    So, main file .EXE and a counter with an IF \/Then statement of some kind in the .EXE . If the COUNT less than 5 then DO …. The main script, if NOT then Quit with a Message Box saying no more playing, program has expired. <\/p>\n\n\n\n

    File Locations & where to define their path<\/p>\n\n\n\n

    I think, if you fix the path in the compiled .EXE file then you have to re-set each time. When designing the program you know what files you want, but you may change your mind later on where you want to locate them. <\/p>\n\n\n\n

    In fact, there is the opportunity to allow for the client to say where they want to keep & name the files that they use. I may look at that later, for the moment I want to define the paths. <\/p>\n\n\n\n

    So, better to have the file paths in the ini file and get the .EXE to pull them in to read them, this will work with all the other files apart from the ini file as its got to be found by the .EXE file, actually you can create another ini file, but this will then give away the location of the hidden ini file unless you do jiggery pokery and only give half the name and allow for a concatenation inside the compiled file. <\/p>\n\n\n\n

    File locations & first iteration<\/h2>\n\n\n\n

    So you don’t want your .ini file in the same folder as your .EXE file, otherwise they can just reset the count. Then they can use the program regardless. <\/p>\n\n\n\n

    An aside Note: The main .EXE has to be able to find the .ini file, otherwise it NEEDS TO BREAK. So if the directories are not setup right and the .EXE can’t check the .ini file then it shouldn’t be able to work at all. This would stop someone moving all the files somewhere else to run them. <\/em><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    So you want to put your .ini file somewhere a bit obscure, like in the AppData folder, that seems to be the programmers common place that people hide their files. As the AppData folder is a hidden folder you do need know its there to go looking for it. <\/p>\n\n\n\n

    Install Program<\/h2>\n\n\n\n

    First Install <\/h3>\n\n\n\n

    On first install the programs (using NSIS) all go to C:\\Program Files (x86)\\<\/strong> and because this is a program folder they don’t like you writing to it unless you have Admin permission. So it makes sense not to put files that need to be written to in this directory. <\/p>\n\n\n\n

    Now, if you have a file that you need to write to, for say, Time Capture or FileSaveLaunch, then the .TXT or .CSV file needs to be in a place that is :<\/p>\n\n\n\n

    1. Accessible by users, if they need to copy\/edit that file <\/li>
    2. In a writable place such as C:\\users\\%A_User%\\Documents or C:\\users\\%A_User%\\Downloads, so you need to make sure that its in the current users directory so easily found. <\/li>
    3. Set the ini file such that it can’t be overwritten on an update. This stops the file from starting anew at a new install. Otherwise you just reinstall and the file starts afresh. So new program working on each new install. <\/li><\/ol>\n\n\n\n

      So, in your compiled .EXE file, sitting in C:\\Program Files (x86)\\<\/strong> you need to make sure that the paths to its files are correct and working. <\/p>\n\n\n\n

      This means allowing for a File location at the top of the ..to be compiled file and then using a variable in the code below for that location, this makes it easy to relocate files you are reading or writing to. <\/p>\n\n\n\n

      In the install file you need to be able to create new directories in different places<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      Uninstall script in the First install build<\/h4>\n\n\n\n

      You need to allow for both the write to file & the ini file not to be uninstalled<\/strong> when looking to uninstall the program, this allows you to keep data and also remember, in the ini file that the timer\/counter has gone past its date\/count<\/p>\n\n\n\n

      If you delete the ini fil then re-installing will overwrite\/create anew so that you can use the same setup to start again. That is why its important that 1\/ you do not delete the ini file and that you don’t allow overwrite if you try and install again. <\/p>\n\n\n\n

      2nd Install\/update<\/h3>\n\n\n\n

      Some situations that need to be managed:<\/p>\n\n\n\n

      1. Client tries reinstalling existing install setup file.<\/strong><\/p>\n\n\n\n

      Directly reinstalling the original setup file to overwrite the previous install. <\/p>\n\n\n\n

      Need to block overwrite of .ini & any data files- in NSIS you need to :<\/p>\n\n\n\n

      SetOverwrite off\nFile \"Time-Capture_File_HotKeys.ini\"<\/code><\/pre>\n\n\n\n
      2. Clients program expired without testing. Too busy, or not enough attempts. <\/strong><\/p>\n\n\n\n
      In this scenario you want to be able to delete the existing .ini file and maybe even reload most of the program files (so updating looks obvious). So that you can reset clock\/count in ini file, and possibly send an adjusted ini file<\/p>\n\n\n\n