Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook



The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic

Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.

If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.

Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.

Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Note: Issues with Runtime distribution and demos

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Re: Note: Issues with Runtime distribution and demos

    Hi Chet,

    Jeff pointed me to this and I think you raise a very good point.

    I'm also glad that I'm not the only paranoid dev who looks for quirky ways to circumvent things.

    Just a quick thought, I saw a post from, (I believe Dave M) suggestiing that command line args can be included in a vb.exe wrapper - which seems like a very good idea.

    So..., can vb.exe propogate or create the runtime.exe on app load and destroy it immediately after?

    For example, user clicks on exe that is essentially a vb wrapper for the launch & startup commands, also copying [whateverfilename] to 'runtime.exe' prior to running the app start. So, you would ship the vb.exe, along with [whateverfilename] - renamed runtime.exe when vb.exe is launched.

    I'm treating this more as a logic/thought experiment than any effective test but seems that, unless runtime.exe must reside on disk, once the rt.exe is loaded into mem to run the app, it's physical presence is no longer required.

    If this is true, and I'll test for it once I download and install A5, then runtime.exe can be called anything within the ship files, and only created/destroyed on app load. This avoids the problem of any user just starting runtime.exe (because it doesn't exist) and seeing the RT lic key via the about screen.

    Thinking further, the vb.exe wrapper could write the runtime license key to the registry, copy whateverfilename to runtime.exe, launch the app, kill runtime.exe (if allowed), kill/rename the license # in the registry.

    Should all happen before a use could interrupt....

    But, just a thought.




    • #17
      Re: Note: Issues with Runtime distribution and demos


      My exe is no wrapper. It simply starts Alpha with the proper switches that I choose. If you change the name of Alpha5.exe to something else, the start.exe has to be remade so it knows what to do..

      My operation is in a bootstrap adb. On start, it runs it's autoexec and does whatever I want and then destroys itself. On second run, the actual adb is used. bootstrap.adb runs, renames itself or destroys itself after starting another file that simply renames a shipped adb to the name needed for the app.

      Bootstrap destroys the runtime installer if it had to be sent with the install. Not my exe.

      I also have my runtime and the app in the same folder. For me, this makes sense and is easier. Others may do it differently.

      Using astrum installer, i send the needed registry entries, register some dll's, set the hidden files that I need, run any other exe files I sent with the app, and start the program.

      The app has the registration built in so if you move it to another computer, it needs to be re-registered. There are three checks now(newest way for me), then it builds it's reg code and I have to supply an answer. The code is always different now making the answer always different. I also just moved it so the answer code given can give a 15, 30, 60, 90 day demo time or make it unlimited.

      There is only one way to get to the back of my app. So far as I know, it has not been beaten yet. I did have it tested by a couple of hackers I know that can open MS stuff like a tuna can with a built in can opener. They open other really big stuff too when they want.

      Make sense?

      It just all depends how far you want to go with it and how much time you want to spend on it.

      Last edited by DaveM; 11-09-2009, 12:38 AM.
      Dave Mason
      [email protected]
      Skype is dave.mason46


      • #18
        Re: Note: Issues with Runtime distribution and demos

        Hi Dave,

        Interesting reply, & thanks for that.

        I meant no insult by referring to your suggestion as a 'wrapper'. Just thought your previous post was a good idea - to encapsulate in that manner.

        As I move forward, I'm certainly interested in installers that can also include in the build, required dlls etc.

        I'm always interested in anything as it relates to security.

        fyi, for users cloning and moving from one PC to another, we trap a lot of h/w id stuff at install but, as you know, when it comes to security, nothing is foolproof.

        I like A5's ability to use Win APIs. This is very useful because one of the most effective methods we have discovered in preventing license abuse is using what we call 'active licensing'. With this, we can allow users to 'share' a license - even if one user is in London and the other in New York.

        But we can also absolutely determine if multiple users are accessing the same license (say via VM, Roaming Profiles, T/S, cloned copies etc.)

        In this regard, I believe I may be able to offer some useful suggestions regarding preventing licensing abuse, as we move forward.




        • #19
          Re: Note: Issues with Runtime distribution and demos

          Originally posted by GaryRockley View Post
          Hi Cal,

          I'm curious, and don't want you to give away any secrets, but how does VM-Ware in this regard factor in?
          Sorry, I didn't see this until just now.

          My original routine only worked with locally run apps on a network. However, I ended up creating a modified version to work with Terminal Server - just don't ask too many details right now because it's been so long I don't remember them. I'm pretty sure it just limits how many users can access the app at one time. I don't think there's any limit on where they can access it from.

          Those are the only two situations I've addressed so far because I'm very sure none of my users has anything else and nobody that has purchased it has asked for anything else. (In fact, none of my users have TS but someone that purchased the registration routines asked me to add that capability.) I'm not sure if the requirements for VMWare would be the same as those for Terminal Server or not.


          • #20
            Re: Note: Issues with Runtime distribution and demos

            Hi Cal,

            Thanks for the response.

            fyi, MS changed the protocols for startup of TS.

            Used to be that start command: %windir%\system32\mstsc.exe /console would load TS with the active desktop (as if it were the active sesion)

            With newer versions of TS, you need to use %windir%\system32\mstsc.exe /admin to see the active admin desktop. Otherwise, a seaparte session is reated which will load a clone of the admin account - assuming permissions approved.

            I mention it because:

            * ms never made it generally known that they did this.

            * It could be important if you have a client running newer versions of TS and your code had specific params.

            Beyond that, my concern, and I'm sure anyone else who has apps delivered on a 'per seat' basis', is that the cloned admin account delivered by TS essentially allows multiple users to access the same app, but isolated from the other accounts.

            VM works in a similar way but handles each user as a separate and isolated instance, requiring a user logging in to start any apps from scratch. (although still isolated from other sessions).

            Either scenario allows multiple instances of a single licence, VM just handles the start-up differently. But, the ramification is that even if the license is per seat,. it is possible for say 20 users to access a single license, which is obviously not beneficial to any dev who licenses on a per seat basis.




            • #21
              Re: Note: Issues with Runtime distribution and demos


              When I send an app out as a 5 user, I have buried code in the app that limits all to 5 users. I read the muff files to determine how many users are on the application and if it exceeds the 5, then it will not open the 5th instance.

              Another app that uses a nodes type of control, each computer name is used along with some other stuff to stop a new node from starting up.

              Ok: let us say a user is on the nodes system and drops a new computer on a lan and copies the runtime from another or reinstalls from one of the disks. The app gets shut dow on start up even after they call me for the startup code they need for that computer.

              make sense?

              Remember, I only do desktop apps and all of them are using shadowed even if there is only 1 computer involved.

              Dave Mason
              [email protected]
              Skype is dave.mason46