The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,805 other followers

When your license check is faulty and causes customers to loose work it’s a cardinal sin

Posted by jpluimers on 2016/02/04

I wrote about this before, named it a cardinal sin too, but I seem to have to repeat this:

When your product thinks the license is validate and quits without allowing the customer to save its work, then you’ve committed a cardinal sin.

Yes, I can talk about cardinal sins: I’ve been named after the artist Hieronymus Bosch (:

For me it is OK if a product checks for binaries that do not to the product (and not signed by the vendor) in the product directories and fails to start, or to present a nag screen that takes a while to disappear, or even to limit functionality.


  1. The product should always tell why the license check failed.
  2. The product never can force the customer to loose work.
  3. The documentation should show failure situations (not just the OK counterparts).

Given some recent posts and the fact that over the course of 10 different versions I lost days of work and at conferences I usually get multiple questions from people having suffered from this, I really had to bring this up again.

The first link below contains a lot of useful information on how to run Delphi in a way that license issues have a smaller chance, but still they occur. A few of the tips there (read the thread for the details) combined with some of mine:

  • run only inside a VM
  • use snapshots
  • never change MAC address of network adapters
  • configure enough network adapters up front before licensing
  • never change the username under which you run Delphi
  • never change the machine name of the machine that runs Delphi
  • never change the domain under which the machine running Delphi is configured
  • save your work very often (Ctrl-Shift-S is your friend)
  • be careful when you see exceptions in the IDE: when they occur (especially with access violations and range check or list index issues), restart the IDE as soon as possible
  • be careful with 3rd party IDE extensions: the Open Tools API isn’t that stable or know enough to use error-free with 3rd party vendors
  • within VMware, use manually assigned MAC addresses of the form 00:50:56:XX:YY:ZZ where XX is not larger than 3F (see VMware vSphere 4 – ESX and vCenter Server: MAC addresses; VMware will use 00:50:56:40:YY:ZZ -00:50:56:FF:YY:ZZ for auto-generated addresses; all within the OUI 00:50:56 are for VMware based VMs)
  • only use Intel processors for your VMs
  • do not change the VMware hardware level for a VM
  • disable the first network card (it’s tied to your Windows license)
  • use virtual CD drives (not the VMware bound ones) to keep hardware changes to a minimum
  • never put stuff in the bin folders of Delphi
  • be careful with your Virus Scanner vendor (report false positives to them)
  • consider skipping the Delphi bin directories in your Virus Scanner
  • consider some way autosave your files (for instance autosave before compilation)
  • consider disabling authenticode checking when running older Delphi versions (likely 2010 … around XE3).
    • The problem is a certificate revocation list from
      The product validation routine needs this CRL to check the EMB certificates in the bin dir, but does not evaluate the error codes of the crypto api calls used in the right manner.
      If the CRL is out of date and a valid CRL can not be downloaded, the crypto api returns an error and the validation routines fail.

Then still, all versions from Delphi 2010 (maybe even 2009) and up I’ve used show this problem every now and then.

Edit: until at least 10.1 Berlin as per [WayBack] Licensing issue: has anyone experienced this before ?Using Delphi 10.1 Berlin Update 2 Pro with subscription… – John Riche – Google+

Read the interview Interview: Gabe Newell about Valve, Steam and Licensing. Very small excerpt: “Piracy is almost always a service problem and not a pricing problem… Most DRM solutions diminish the value of the product by either directly restricting a customers use or by creating uncertainty.”



7 Responses to “When your license check is faulty and causes customers to loose work it’s a cardinal sin”

  1. dennis said

    We never had any problems with license auth and I don’t understand the whining about losing code – the first thing as a delphi dev is switching on “autosave”, thus you may only lose a small portion of code if a ide crash happens (and that happens sometimes).

    • jpluimers said

      “Autosave” doesn’t cut it because it often saves too late or in a state where the code isn’t fledged out enough.

      Even for a cautious person like me (because of crashes, but those occur in more predictable usage scenarios), I’ve bumped into this dozens of times over the years and it each time costs me at least half an hour of getting back to the point where I was not even counting to get back in “the zone”.

      I’m very close to the point where I’m not going to actively hunt for Delphi work any more. Because the current state of the product brings less fun and more burden.

    • Well, you never had this problem has nothing to do with the fact that others have such problems. The “auto save” feature might reduce the damage level has nothing to do with the fact that the Delphi IDE should never have such annoying license checking implementation that might case their customers losing their source code.

    • Joseph Mitzen said

      For the amount you pay for Delphi, losing “only… a small portion of code” is still too much code. JetBrains IDEs save every keystroke automatically – no need to save, ever! They consider saving is replaced nowadays by committing with a version control system. They also offer unlimited level undo. Price for a single language IDE registered to a user (vs. business)? $89. $199 for business.

  2. lhengen said

    We to have had one dev experience this problem and lost all his work using DX Seattle. While the pricing of BDS vs. the value of the solution when compared to competitors has eroded, companies will still buy vs. pirate software. Individuals who pirate will even buy it if they can afford it, assuming they love the product enough to support it with their wallet. It’s the lack of bug fixing and listening to customers @ EMBT that results in people pirating, but you cannot change that unless you change the corporate culture, and that often means changing key people because they they are stuck in a rut, unable or unwilling to change with the times. Listening seems to be a lost art…

  3. Dennis said

    The link to “disabling authenticode checking” does not work

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: