Archive for the ‘hexlicense’ Category

HexLicense, Patreon and all that

September 6, 2018 Comments off

Apparently using modern service like Patreon to maintain components has become a point of annoyance and confusion. I realize that I formulated the initial HexLicense post somewhat vague and confusing, in retrospect I will admit that and also take critique for not spending a little more time on preparations.

Having said that, I also corrected the mistake quickly and clarified the situation. I feel some of the comments have been excessively critical for something that, ultimately, is a service to the community. But I’ll roll with the punches and let’s just put this issue to bed.

From the top please

fromthetopI have several products and frameworks that naturally takes time to maintain and evolve. And having to maintain websites, pay for tax and invoicing services, pay for hosting (and so on), well it consumes a lot of hours. Hours that I can no longer afford to spend (my work at Embarcadero must come first, I have a family to support). So Patreon is a great way to optimize a very busy schedule.

Today developers solve a lot of the business strain by using Patreon. They make their products open source, but give those that support and help fund the development special perks, such as early access, special builds and a more direct line of control over where the different projects and sub-projects are heading.

The public repository that everyone has access to is maintained by pushing the code on interval, meaning that the public “free stuff” (LGPL v3 license) will be some months behind the early-access that patrons enjoy. This is common and the same approach both large and small teams go about things in 2018. Quite radical compared to what we “old-timers” are used to, but that’s how things work now. I just go with flow and try to do the most amount of good on the journey.

Benefits of Patreon

The benefits are many, but first and foremost it has to do with time. Developer don’t have to maintain 3-4 websites, pay for invoicing services on said products, pay hosting fees and rent support forums — instead focus is on getting things done. So instead of an hour here and there, you can (based on the level of support) allocate X hours within a week or weekend that are continuous.


Patreon solves two things: time and cost

Everyone wins. Those that support and help fund the projects enjoy early access and special builds. The community at large wins because the public repository is likewise maintained, albeit somewhat behind the cutting edge code patrons enjoy. And the developers wins because he or she doesn’t have to run around like a mad chicken maintaining X number of websites -wasting more time doing maintenance than building cool new features.


And above all, pricing goes down. By spreading the cost over a larger base of interest, people get access to code that used to cost $200 for $35. The more people that helps out, the more the cost can be reduced per tier.

To make it crystal clear what the status of my frameworks and component packages are, here is a carbon copy from

For immediate release

Effective immediately HexLicense is open-source, released under the GNU Lesser General Public License v3. You can read the details of that license by clicking here.

Patreon model

Patreon_logo.svgIn order to consolidate the various projects I maintain, I have established a Patreon account. This means that people can help fund further development on HexLicense, LDEF, Amibian and various Delphi libraries as a whole. This greatly simplifies things for everyone.

I will be able to allocate time based on a broader picture, I also don’t need to pay for invoicing services, web hosting and more. This allows me to continue to evolve the components and code, but without so many separate product identities to maintain.

Patreon supporters will receive updates before anyone else and have direct access to the latest code at all times. The public bitbucket repository will be updated on interval, but will by consequence be behind the Patreon updates.

Further security

One of the core goals on Patreon is the evolution of a bytecode compiler. This should be of special interest to HexLicense users. Being able to compile modules that hackers will be unable to debug gives you a huge advantage. The engine is designed so that the instruction-set can be randomized for a particular build. Making it unique for your application.


The LDEF assembler prototype running under Smart Mobile Studio

Well, I want to thank everyone involved. It has been a great journey to produce so many components, libraries and solutions over the years – but now it’s time for me to cut down on the number of projects and focus on core technology.

HexLicense with the update license files will be uploaded to BitBucket shortly.


Jon Lennart Aasenden



20% discount on HexLicense!

February 10, 2017 Leave a comment

For a short time Quartex Components offer you the FMX, VCL and VJL package with a whopping $40 discount! That is a significant saving for a great product!

By acting now you gain full access to the classical component packages – as well as the next-generation licensing engine and platform:

Ironwood now supports Smart Pascal! The Delphi edition is just around the corner. Start using Hexlicense in Delphi today!

Ironwood now supports Smart Pascal! The Delphi update is just around the corner. Start using Hexlicense in Delphi today!

  • 12 month subscription
    • 4 updates guaranteed
  • Full source code
    • VCL version
    • FMX version
      • Windows
      • OS X
      • iOS
      • Android
    • JVL version (Smart)
      • All mobile platforms
      • HTML5 applications
      • Node.js client and server applications
  • Solid documentation
  • Easy to use and drop into existing projects
  • Ships with examples
  • Support via E-mail


ironwood2The next generation HexLicense formula and license generator is nicknamed “Ironwood”. This has been in the making for some time and is through the beta phase. It uses the absolute latest RTL for Smart – which will be in circulation within a 1 to 2 weeks (hopefully sooner!). So you are getting the absolute latest to play with – which is can be used by both visual and node.js projects.

By acting now you not only save money but you also get a great deal on our classical Delphi components. Most importantly however, is that the discount buys you access to the next generation components for Delphi as well. These will retail at a higher price when they hit the market.

Smart Pascal

With mobile application development taking place more and more through HTML5 and phonegap – not to mention that node.js is quickly becoming a market standard server-side, compilers that targets the JavaScript virtual machine is becoming increasingly important. Especially for traditional languages like Delphi and C++.

With access to Ironwood for Delphi and Smart Pascal, your existing VCL and FMX products can continue to function as they do right now – while you move your licensing mechanisms to the cost-effective, scalable and portable node.js platform.

Why pay huge amounts of money to rent a full virtual instance to host a native Delphi service – when you can do the exact same under node.js for but a fraction of the price? Not to mention the many benefits node brings to the table.

Discount covers all platforms!

discountThe offer gives you the entire system, including VCL, FMX and JVL editions. You also secure access to Ironwood for Delphi.

Again, this package will retail at a higher price and forms the basis of our future cloud based licensing services.

Hexlicense for Delphi can be dropped directly into existing projects, comes with a license generator application and is considered very easy to use.

By acting now you secure early access!

Buy Now Button with Credit Cards

Note: This is a time limited offer. Only the link above this text is valid for this discount.

To read more about HexLicense, head over to the website. You can also download the documentation which is substancial and covers everything.

Delphi bytecode compiler

January 10, 2017 1 comment

This is a pet project I have been playing with on/off for a couple of years now. Since I’m very busy with Smart Mobile Studio these days I havent really had time to write much about this in a while. Well, today I needed a break for JavaScript – and what is more fun than relaxing with a cup of coco and bytecodes?

The LDEF bytecode standard

Do you remember Quartex Pascal? It was an alternative pascal compiler I wrote a couple of years back. The plan was initially to get Smart Mobile Studio into that codebase, and essentially kill 3 birds with one stone. I already have parsers for various languages that I have written: Visual Basic .NET, Typescript, C# and C++. Adding support for Smart Pascal to that library of parsers would naturally give us a huge advantage.

In essence you would just pick what language you wanted to write your Smart apps in, then use the same classes and RTL across the board. You could also mix and match, perhaps write some in typescript (which is handy when you face a class that is difficult to “pascalify” via the import tool).

LDEF test environment

LDEF test environment

But parsing code and building an AST (abstract symbol tree, this is a hierarchy of objects the parser builds from your source-code. Basically your program in object form) is only half the job. People often start coding languages and script engines without really thinking it through (I have done that myself a few times. It’s a great way to learn the ropes, but you waste a lot of time), after a while they give up because it dawns on them that the hard part is still ahead: namely to generate executable code or at least run the code straight off the AST. There is a reason components like dwScript have taken years to polish and perfect (same can be said of PAX script which is probably one of the most powerful engines available to Delphi developers).

The idea behind Quartex Pascal was naturally that you could have more than one language, but they would all build the same AST and all of them emit the same bytecode. Not exactly a novel idea, this is how most scripting engines work – and also what Java and .Net have been doing since day one.

But the hard part was still waiting for me, namely to generate bytecode. This may sound easy but it’s not just a matter of dumping out a longword with the index of a method. You really need to think it through because if you make it to high-level, it will cripple your language. If you make it to low-level – the code will execute slow and the amount of bytecodes generated can become huge compared to normal assembly-code.

And no, I’m not making it compatible with CIL or Java, this is a pure object pascal solution for object pascal developers (and C++ builder naturally).

LDEF source language

I decided to do something a bit novel. Rather than just creating some classes to help you generate bytecode, I decided to create a language around the assembly language. Since C++ is easy to parse and looks that way because of its close connection to assembler, I decided to use C++ as the basic dialect.

So instead of you emitting bytecodes, your program only needs to emit LDEF source-code. Then you can just call the assembler program (command line) and it will parse, compile and turn it into assemblies for you.

Here is an example snippet that compiles without problem:

struct CustomType
  uint32 ctMagic;
  uint32 ctSize;
  uint8  ctData[4096];

class TBaseObject: object
  /* class-fields */
  alloc {
    uint8 temp;
    uint32 counter;

  /* Parser now handles register mapping */
  public void main(r0 as count, r1 as text) {
    alloc {
      /* method variables */
      uint32 _longs;
      uint32 _singles;
    move r1, count;
    jsr @_cleanup;
    push [text];

  /* test multi push to stack */
  private void _cleanup() {
     push [r0, r1, r2];

The LDEF virtual machine takes care of things like instance management, VMT (virtual method table), inheritance and everything else. All you have to do is to generate the LDEF assembly code that goes into the methods – and voila, the assembler will parse, compile and emit the whole shabam as assemblies (the -L option in the command-line assembler controls how you want to link the assemblies, so you can emit a single file).

The runtime engine is written in vanilla object pascal. It uses generics and lookup tables to achieve pretty good performance, and there is ample room for a JIT engine in the future. What was important for me was that i had a solution that was portable, require little maintenance, with an instruction set that could easily be converted to actual machine-code, LLVM or another high level language (like C++ that can piggyback on GCC regardless of platform).

LDEF instructions

The instruction set is a good mean of the most common instructions that real processors have. Conceptually the VM is inspired by the Motorola 68020 chip, in combination with the good old Acord Risc cpu. Some of the features are:

  • 32bit (4 byte) opcode size
  • 32 registers
  • 1024 byte cache (can be adjusted)
  • Stack
  • Built in variable management
  • Built in const and resource management
  • Move data seamlessly between registers and variables
  • Support for records (struct) and class-types
  • Support for source-maps (both from assembler to high-level and reverse)
  • Component based, languages and emitters can be changed

There are also a few neat language features that I have been missing from Delphi, like code criteria. Basically it allows you to define code that should be executed before the body of a procedure, and directly after. This allows you to check that parameter values are within range or valid before the procedure is allowed to execute.

Here is the pascal version:

function TMyClass.CalcValues(a,b,c: integer): integer;
    if (a<1) or (b<1) or (c<1) then
      Fail('Invalid values, %classname.%methodname never executed');

  result := a + b div c;

    if result <23 then
      Fail('%classname.%methodname failed, input below lowest threshold error');

I decided to add support for this in LDEF itself, including the C++ style intermediate language. Here it looks like this:

  /* Enter + Exit is directly supported */
  public void main(r0 as count, r1 as text) {
    enter {

    leave {

    alloc {
      /* method variables */
      uint32 _longs;
      uint32 _singles;
    move r1, count;
    jsr @_cleanup;
    push [text];

Why Borland/Embarcadero didn’t add this when they gave the compiler a full overhaul and support for generics – is beyond me. C++ have had this for many, many years now. C# have supported it since version 4, and Java I am usure about – but its been there for many years, thats for sure.

Attributes and RTTI

Attributes will be added but support for user-defined attributes will only appear later. Right now the only attributes I have plans for controls how memory is allocated for variables, if registers should be pushed to the stack on entry automatically, if the VMT should be flattened and the inheritance-chain reduced to a single table. More attributes will no doubt appear as I move forward, but right now I’ll stick to the basics.

RTTI is fairly good and presently linked into every assembly. You cant really omit that much from a bytecode system. To reduce the use of pure variables I introduced register mapping to make it easier for people to use the registers for as much as possible (much faster than variables):

  public void main(r0 as count, r1 as text) {

You may have noticed the strange parameters on this method? Thats because it’s not parameters, but definitions that link registers to names (register mapping). That way you can write code that uses the original names of variables or parameters, and avoid allocating variables for everything. It has no effect except making it easier to write code.

LDEF, why should I care?

You should care because, with a bit of work we should be able to compile fairly modern Delphi source-code to portable bytecodes. The runtime or engine that executes these bytecodes can be compiled using freepascal, which means you can execute the program anywhere FPC is supported. So more or less every operative system on the planet.

You should care because you can now write programs for Ultibo, the pascal operative system for Raspberry PI. It can only execute 1 real program (your embedded program), but since you can now run bytecodes, you will be able to run as many programs as you like. Just run each bytecode program in a thread or play it safe and call next() on interval from a TTimer.

You should care because once LDEF is finished, being able to transcode from object pascal to virtually any language will be a lot easier. JavaScript? C++? Python? Take your pick. The point here is standards and a library that is written to last decades rather than years. So my code is very clean and no silly pointer tricks just to get a few extra cycles. Stability, portability and maintainance are the values here.

You should care because in the future, components like HexLicense will implement its security code in LDEF using a randomized instruction-set, making it very, very hard for hackers to break your product.

Hexlog, building a better logging system

October 15, 2016 Leave a comment

Its been quite a busy couple of weeks for me. HexLicense has finally gotten a well deserved update and (drumroll) we have ported the codebase over to Firemonkey. I have deliberately waited a while with the Firemonkey edition, because compilers usually need a couple of releases before they become stable. And the same can be said about runtime libraries (I should know, I have created a few). I wanted to use FMX earlier but, it kinda died on me so many times that I gave up. Thankfully this is no longer the case and Delphi XE Seattle is a joy to work with.

Ironwood prototype

Ironwood prototype

Also, one of the coolest things these past weeks was returning to Smart Mobile Studio as a user. It’s really quite an odd experience because you get so locked into “author” mode when you have worked on a product for so many years. So when you sit down to actually use your own program as a means to an end, it’s a very different experience from looking at it purely architecturally.

I really love what we managed to do with Smart Mobile Studio. That might sound disingenuous since it originated with me, but somehow we captured something; some sense of creative freedom that I cannot find in giant productions like Visual Studio or QT C++. Naturally I’m biased, but I’m no stranger to self-critique either. But the speed at which I knock out a HTML5 or mobile application with Smart Pascal is just way beyond anything I can do in any other devkit. The only other development platform that have the same feel to it is Mono C#, which I love because it doesn’t contain all the .. bloat, I guess is a word, that large production environments insist on giving you. I mean, fire up visual studio and you have so many options – half of them that you will never use unless you specialize within a particular dicipline – that they just get in the way.

Anyways, Hexlicense “Ironwood” was written first and foremost in Smart Mobile Studio. We have started to port the code over to Delphi to make the Xmas deadline, but honestly: I’m so glad I could use Smart to prototype this product, because it would have taken me twice as long in Freepascal or Delphi. I’m not even sure I would have bothered if Visual Studio was my only option. Seriously.

So you may be wondering: why on earth would you implement a licensing system in JavaScript? Well that’s the cool part! Right now most licensing systems are native only. Which means that if you want to really get control over your software you have to fork out for a virtual host, if not a physical server box. The price difference between a node.js hosting solution and a native hosting solution is substantial. So implementing a version of our HexLicense server in Smart Pascal + node.js will save my customers the expense. It also means they can host the server on whatever operative system they see fit. And once again, the price difference between a Linux host (Ubuntu is wonderful to work with) and Microsoft Windows is still a factor.

Coding it in Smart Pascal also opens up the door for license based access to HTML5 based applications, be they compiled to native via Phonegap or Adobe build services or just running in a browser. So once again our JavaScript virtual machine formula get’s it right. And it’s magnificent to play with. Not a day goes by that I don’t learn something new and exciting about JavaScript from object pascal, which is paradoxical. I know.

Back in the saddle

For the past few years my life has revolved around Smart Mobile Studio and the companies I have worked for (a.k.a “the day job”). It must be at least 4-5 years since I actually sat down and built products, delivered components and offered up my services as a Delphi software architect. There havent even been any time for consulting or system design. With a full day job, two kids and a product you live and breathe for there is a limit to how much you manage. Add to that my back injury 4 years ago which rendered me unable to even walk and you get the picture; Thankfully my back is getting better. I do two rounds of boxing every week (or try to) and that has done more for my back than all the doctors and their witch-craft medicine combined.

It feels so good to create new products again. Products that are doable within a reasonable time-frame and that solve real-life practical problems (as opposed to having to solve potential scenarios that havent even occurred yet: the burden of the RTL architect). So while HexLicense for VCL and FMX is in the store, Ironwood is being ported to Delphi – I have decided to wake up another component-set that I initially created for myself. One that deals with a very practical and hands-on challenge, namely: HexLog.


Many years ago I was working for Hydro, which is the biggest oil company in Norway. Without getting to detailed (or breaking my NDA) logging was one of the problems we faced. With more than 50 Windows services communicating (read: 50 potential sources of bugs), the company’s lack of proper logging – logging in a format that made sense to people other than us developers (like system administrators, super-users and even insurance companies interested in locating where something broke down) made it almost impossible to work with the codebase.

So one day I had enough and sat down in my spare time to write a modular, thread safe, component based logging system that didn’t just “log some info”, but it did so by proxy. Meaning, that the writing mechanism(s) were isolated in separate components, abstracted from storage – which was isolated in other components. So when we needed XML logging we just hooked up the XML writer; when we needed RTF logging we hooked that up (and so on, for numerous formats).

You would think that Delphi developers in general had logging under wraps right? That is sadly not the case. Some people are very good at logging and have made it into a habit. But more often than not when I’m hired by a client – what do you think I find? Yup, plain old vanilla text-file logging. Which is fine as long as the coders have spent some time making sure the basics are in order. Sadly that is so rare it almost frightens me. Especially when I’ve upgraded software used by pharmacutical companies, doctors and organizations that really (really!) should do full journaling regardless of bugs or errors. In fact Norwegian law demands it in some cases; especially when medicine and prescription drugs are involved. If a doctor or nurse prescribes the wrong medication and a patient dies, the insurance companies will have a field day if there is no logging according to standards. And should it turn out to be the software’s fault.. well, let’s just say there is a reason only large companies operate with “within the hour response time” in their service agreements.

So what are the criteria people tend to forget?

  • File locking issues. It will happen the moment more than one process or thread targets a file
  • Making sure the information that is logged is organized by sections, visually distinct in the file
  • Making sure time and dates use UTC or ISO formatting
  • Logging the actual user, not just the program identity
  • Using mutexes and read-write synchronization when multi-threading is involved
  • Avoiding interface communication from threads without proper understanding of calling conventions and compartment schemes
  • Using memory mapped files rather than torturing the filesystem with an onslaught of IO calls
  • Use tab indentation to make the logs easier to navigate for the human eye
  • The list goes on ..

The most important oversight is not on the list, it’s actually something as simple as logging information that human beings can read, as opposed to adapting the information to what the computer wants to work with. A dentist wont know what to do with a stack-trace or “an error occurred executing MySQLQuery1.Execute”. But he or she will understand a log that states – in plain text – “could not store prescription for patient John Doe, the database reports the disk as full. An email has been sent to the administrator“.

You don’t have to be a programmer to replace a disk or move the database to a better location. But the log must make sense. It should just be there, not getting in the way yet easily accessible.

Journaling and big-data

When you are logging every action an oil-pump (and its regulators) do for 24 hours, logfiles can grow into the gigabyte range. Can you imagine one gigabyte of messy, purely technical jargon to wade through when a critical system is down? Well I can, because that’s exactly one of the things I faced 12 years ago when I was hired to “fix” a couple of bugs. A couple of bugs turned into 2 years of re-writing the entire system from scratch. Notepad crashed when it tried to load the original log-files.

The system was all written in Delphi 4, breaking every rule known to object pascal developers even back then. Like services opening forms and forms using DDE to communicate. It was a miracle that it had worked to begin with.

This is where I decided to write a journaling system that would present me, the programmer, with a unified API for writing, reading and even updating log-items stored in multiple files. So you can set a limit to how many log-items one file can contain, and when the log reaches that limit – it create a new file automatically for you. It takes care of everything in the background, keeping track of the files and their content through an index files. This solution helped solve the problem of monster log files. And you know what? That was the core bug in the system. They had used TStringList to load in the text file, append one item, then saved it back out again. Loading almost a gigabyte of raw text while trying to keep up with GPIO signals firing like mad. So yeah, logging does matter!

HexLog naturally implements this, now even faster than before due to Delphi’s dictionary classes and clever use of balanced trees. The best is that the writer mechanism applies to this type of journaling as well. So if you prefer XML thats not a problem, nor JSON, nor RTF for that matter. I’m even throwing in a PDF writer in update 1.

And did I mention both local logging and network logging? And that you can read the logs via a fancy HTML5 dashboard in any browser, both locally and remotely?

Reading more about HexLog

If you find the topic interesting and worthwhile, head over to my company website and read the release statement here: We dont take orders just yet, but it should ship out in the beginning/middle of next month.

And yes, there will be a server edition both for native Delphi and node.js, so there is a lot of value for money in this package.


Try out HexLicense in your browser

October 9, 2016 Leave a comment

If you head over to you will find both the roadmap for 2016 and beyond – but also that you can now testdrive HexLicense in your browser (!) That is pretty cool if I say so myself.

In the browser?

HexLicense "Ironwood" engine under HTML5

HexLicense “Ironwood” engine under HTML5

Hexlicense consists of two parts: the first is the generation process where you mint license numbers. These numbers have some nifty criteria attached to them, like being able to verify that they have indeed been minted using a root-key,  that they evolve and mutate in a non-linear fashion and naturally: they should obfuscate as much as possible.

The second part is the validation process. This is where the customer inputs the serial number he received when he bought your software. Under Delphi you validate such keys inside your Delphi program via the THexLicense component. In the future you will be able to do this via the HexLicense server system as well, which makes is going to make your life as a developer a lot easier.

HexLicense for Smart Mobile Studio covers both aspects, so you can perform the minting and validation. The code is so universal that it will run on your node.js server, in your visual applications – most of the code is actually shared between Delphi and Smart Mobile Studio.

Note: The demo of HexLicense running in your browser is just for educational purposes. It demonstrates that Smart Mobile Studio is capable of some very nifty things. And it also demonstrates the speed and flexibility of HexLicense.