Posts Tagged: perl

Revisiting ActivePerl… Part Two!

In our previous article, we took an in-depth look at ActivePerl.

ActivePerl is a way of installing a Perl environment under Windows. Perl is the underlaying programming language that our MIDAS software is written in.

In essence, we felt we could no longer recommend ActivePerl to customers looking to install a self-hosted room booking system on their Windows servers.

Well, ActiveState (the developers of ActivePerl) took notice of our original article and have quickly reached out to us…

ActivePerl Icon

ActiveState’s Response

Pete Garcin, Director of Product at ActiveState reached out to us:

I saw your blog post about revisiting ActivePerl — it was great to see the engagement you had with the platform and the process you went through trying to get your build to work. It’s unfortunate that you ran into issues during that process though!

One of the goals of the platform is to provide a simple, reproducible process for generating builds from an expansive catalog. While it’s not always possible to keep 100% of the catalog building 100% of the time, we do our best to keep critical packages running.

Since the time you attempted your build, DBD::MySql and the maria-db-connector have been fixed (they were transiently broken) and one of our build engineers bumped the timestamp on your project so that now all of your projects for later versions should work. If you use 5.32 or newer, it ships with the mysql client DLL by default! In the future, making any change to a project will move the timestamp forward so that you pick up new changes to the catalog.

Also, you are free to use 5.32.1 or 5.34.0 — as both are now classified as out of beta (website might lag behind slightly). In fact, we highly recommend using one of the newer versions as the build experience is much faster and they also include the mysql DLL.

Also, if you’re distributing to your end users, our CLI provides a super simple way for anyone to set up the environment without needing to distribute a full installer — and they can also receive updates and stay sync’d. For modern versions of Perl (5.32+) you’ll see the instructions on how to install the CLI and the build on the platform dashboard in the Downloads tab.

Again — sorry to hear you had a rough experience creating your build, we’d love for you to try again with the updated projects and always happy to help work through any issues with you! Feel free to reach out any time.

– Pete Garcin, Director of Product, ActiveState

ActiveState’s CTO, Scott Robertson, also reached out:

Thanks for the amazing write up, really sorry you had a bad first impression. Even though ultimately we didn’t win you on the first shot I took heart that you’re starting to see the vision to our ambition when you say “We admit, we were actually a little excited – we appeared to have a custom Windows distribution of..”.. That’s the goal!

You’ve noted the number of packages we now support is over 100k! We’re coming pretty close to our goal now of being able to build 100% of CPAN in a secure reproducible way including all native dependencies. Something Strawberry perl can not claim. Unfortunately we’re still experiencing some growing pains going from 500 packages to over 100k and supporting every version the night it’s dropped. Looks like when you tried this project MariaDB updates entered our catalog and were broken. We have since fixed them. The post you found in our community forum was way out of date. We’re working on producing better support materials, but in the meantime know we’re here to help.

– Scott Robertson, CTO, ActiveState


First of all, we have to give credit to ActiveState for reaching out to us so quickly. We certainly weren’t expecting that, but it’s encouraging to see their engagement.

Secondly, it would appear – at first glance – that ActivePerl 5.32 and 5.34 do now successfully build on the ActiveState platform.

So let’s take a look…

Missing stand-alone installers

Here’s what the “Download Builds” tab on the ActiveState platform looks like for our ActivePerl 5.28.3 build:

.exe and .msi Windows installers are available for ActivePerl 5.28.3
.exe and .msi Windows installers are available for ActivePerl 5.28.3

Notice that there are two install methods offered; “Download Installer” and “Install via Command Line”.

The “Download Installer” section contains download links for standalone Windows installers for our ActivePerl 5.28.3 build.

The “Install via Command Line” section allows the build to be installed from the command line. This is achieved by using Windows PowerShell and ActiveState’s “State Tool“.

Now, let’s be realistic; the average non-tech savvy user will always prefer a familiar Windows Installer over having to use Windows PowerShell to execute arbitrary commands.

So it’s strange and very disappointing that no stand-alone installers appear to be provided for our 5.32/5.34 builds:

No stand-alone installers for Windows are provided for ActivePerl 5.34
No stand-alone installers for Windows are provided for ActivePerl 5.34

Thinking this may be a glitch, we triggered a re-build of our ActivePerl 5.34 package on the ActiveState platform. This appeared to successfully build, but again no standalone Windows installers were generated.

We questioned this with ActiveState’s CTO who told us:

Installers vs State tool: It will be State tool only going forward for free versions. The service and command client is meant for developers. Installers are a paid option.

Scott Robertson, CTO, ActiveState

This is clearly a very recent decision which isn’t made clear on their website. In fact, the automated email notification the platform sent us when the re-building of 5.34 was complete, still asserts that you can “download the installer”:

Email notification from ActiveState indicating that a stand-alone installer is available
Email notification from ActiveState indicating that a stand-alone installer is available

Sadly, the lack of any standalone .exe/.msi installers for ActivePerl being made freely available going forward is a major block for us to recommence recommending ActivePerl again to our self-hosted MIDAS customers.

However, we were still curious ourselves as to whether the previous issues with lack of MySQL/MariaDB support had indeed been fixed in this 5.34 build. So we decided to try a test install using Windows PowerShell to install ActivePerl’s “State Tool” and configure our 5.34 build.

Here’s how we got on:

Installing via Windows PowerShell

We opened a Windows command prompt and then pasted in the command ActiveState provided to “Install via Command Line”.

The result was a spiel of console output that would baffle most:

Console output from installing ActivePerl via the command line
Console output from installing ActivePerl via the command line

…to be honest, we’re not even sure if we understand all of that… and we’re seasoned Perl developers!

Anyway, the console output ended by informing us that we were “Activated”.

So Perl 5.34 was now installed… right?(!)

We weren’t sure. So to test, we created a very simple .pl script that would print the words “Hello World!” in the browser. We saved this file into our test Apache web server’s htdocs folder.

This very simple .pl script contained just two lines:


print "content-type:text/html\n\nHello World!";

Trying to locate Perl

Now, let’s talk shebangs (no, not the 2000 hit by Ricky Martin!).

In Perl, the “shebang” refers to the very first line of any Perl script. It informs the web server as to the whereabouts of the perl installation to use.

On Linux servers, Perl may typically be located at /usr/bin/perl, therefore, the first line of any Perl script (known as the “shebang” line) should read:


On Windows servers, Perl was traditionally located at C:\Perl\bin, C:\Perl64\bin, or C:\Strawberry\perl\bin, and so the shebang could read something like:


However, Apache servers support a really cool configuration option called “ScriptInterpreterSource Registry“. What this does is instruct Apache to simply ignore the “shebang” line. Instead, Apache will determine the location of Perl based upon a Windows registry value (which should be set when Perl is installed).

That has the advantage that user’s don’t then need to set/change, or indeed care about the “shebang” line in Perl scripts, they should just work regardless!

That’s why we recommend enabling this config option when installing and configuring Apache on a Windows server.

So we tried accessing our simple “hello world” Perl script in our browser. This resulted in an Internal Server Error:

Internal Server Error when executing a .pl script
Internal Server Error when executing a .pl script

Upon investigation, it would appear that during install of ActivePerl, no registry value was set to allow Apache’s “ScriptInterpreterSource” directive to determine where Perl was located.

So we then had to find the location of the perl.exe executable on our test server and manually update the shebang line of our “hello world” script.

There was no obvious C:\Perl, or C:\Perl64 or even C:\ActivePerl directories present. We had to search the entire C:\ drive on our test server for “perl.exe”, and we eventually found it under:


So the “shebang” line we needed to add to our “hello world” perl script was the instantly forgettable(!): #!C:\users\wdagutilityaccount\appdata\local\activestate\052e8766\bin\perl.exe

Anyway, this at least allowed our hello world script to execute and correctly print “Hello World” to the browser.

The next stage was to try running our Server Readiness Tool.

Running our Server Readiness Tool

Our Server Readiness Tool is a perl script that our customers can freely download and access (via their browser). The tool checks that their server is correctly configured in order to install MIDAS.

As part of these checks, the tool identifies any missing Perl modules which MIDAS requires.

To our surprise, running this tool indicated a number of missing modules, which we thought had been included in our custom ActivePerl build:

Perl modules apparently "missing"
Perl modules apparently “missing”

We double-checked back on the ActiveState platform. Sure enough these modules appear to have been successfully included in our build:

DBD::MariaDb and DBD::mysql appear to have been included in the build
DBD::MariaDb and DBD::mysql appear to have been included in the build

So what was going on?

Digging a little deeper in Apache’s error logs revealed the following errors:

Can't load 'C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/site/lib/auto/DBD/mysql/mysql.dll' for module DBD::mysql: load_file:The specified module could not be found at C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/lib/ line 193.\r: C:/Apache24/htdocs/

Can't load 'C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/site/lib/auto/DBD/MariaDB/MariaDB.dll' for module DBD::MariaDB: load_file:The specified module could not be found at C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/lib/ line 193.\r: C:/Apache24/htdocs/

Can't load 'C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/site/lib/auto/Net/SSLeay/SSLeay.dll' for module Net::SSLeay: load_file:The specified module could not be found at C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/lib/ line 193.\r: C:/Apache24/htdocs/

We checked, and verified that “mysql.dll”, “MariaDB.dll” and “SSLeay.dll” files were all present at the locations indicated.

Digging into line 193 of “”, this section of code included the comment “Many dynamic extension loading problems will appear to come from this section of the code … often these errors are actually occurring in the initialisation C code of the extension XS file. Perl reports the error as being in this perl code simply because this was the last perl code it executed“.

So whilst ActivePerl appears to have technically installed the modules as part of the installation process, right now they’re broken and don’t work on Windows under ActivePerl 5.34!

…and the previous “workaround” of grabbing the “libmysql__.dll” file from a Strawberry perl installation and placing that within the ActivePerl installation also didn’t resolve the issue.

Once again, we have a broken and unusable ActivePerl installation.

In conclusion…

ActiveState’s prompt engagement with us is very welcome and demonstrates that there is still at least some interest there with regards to Perl.

However, we’re sad that they still don’t have an up-to-date version of perl for Windows users that works with MySQL/MariaDB.

It was extremely disappointing when ActiveState abandoned their popular free “Community Edition”.

That disappointment has been further compounded now by the knowledge that ActiveState have made the commercial decision going forward to discontinue being able to build Windows .exe/.msi standalone installers. That is, unless you pay.

This makes ActivePerl a far less attractive option to us.

Why would we want to spend thousands of dollars a year in order to “build” a user-friendly ActivePerl Windows installer for our self-hosted customers to use, when our customers can simply grab and use Strawberry Perl’s Windows installer for free? Plus, in doing so end up with a Perl installation that actually works on Windows!

Even if a tech-savvy customer was willing to go down the route of installing ActivePerl on their Windows server via the command line script – as things stand right now, they would have a broken installation that wasn’t capable of interacting with a MySQL/MariaDB database. Therefore, they wouldn’t be able to install and run a self-hosted MIDAS booking system.

Now, if ActiveState are committed to resolving these issues, then we’d be happy to take another look. However, for us to be won over, ActiveState would also have to reconsider the decision to put standalone Windows installers behind a paywall!

Right now, we can’t see how we can continue to recommend ActivePerl to our Windows-based customers. This is with a heavy heart, as for years we’d been big advocates of ActivePerl.

For any prospective customers who are interested in MIDAS and considering a self-hosted installation in a Windows environment, we recommend installing Strawberry Perl. Alternatively, you could consider our no-hassle cloud-hosted offering instead.

Revisiting ActivePerl

Perl is the underlaying coding language that our MIDAS booking software is written in.

When it comes to developing with Perl on Windows-based systems, there are broadly two options, as Windows doesn’t natively come with Perl installed (unlike Linux/Mac systems)

These two options are:

Installing either of these products on Windows provides a Perl environment.

Here at MIDAS HQ, as we primarily develop using Windows-based machines, we need a Perl environment to develop under.

For many years, we opted for ActivePerl, but at the start of 2020 we made the switch to Strawberry Perl. You can read more about this in our earlier Strawberry Perl vs ActivePerl post.

A year and a half on, and we’re still very happy with our decision to move to Strawberry Perl.

But in some spare time recently, we thought we’d take a look at what ActiveState have been doing with their ActivePerl product since we moved away from it….

ActivePerl Icon

It’s all about the packages…

There are over 100,000 additional Perl “modules” (or “packages”) available to enhance the “core” functionality of Perl.

Our MIDAS software requires a handful of these additional modules in order to function.

We originally loved ActivePerl as it made it really easy for our customers (and us!) to install these modules via the “Perl Package Manager” tool (or PPM) for short.

This unique feature of ActivePerl was sadly retired by the vendor (ActiveState) by ActivePerl 5.28.

From ActivePerl 5.28 onwards, if users wanted to install additional Perl modules they were encouraged to instead sign up for an ActiveState account. They could then “build” their own custom-build of ActivePerl containing the additional packages/modules they require.

This was a far less user-friendly to install Perl modules than it was to use PPM, where modules could be installed at any time with just a couple of clicks.

Anyway, we thought we’d try using ActiveState’s platform to generate a custom-build of Perl containing all the additional modules/packages which MIDAS requires.

Here’s how we got on…

Signing up for an ActiveState account

Signing up for an ActiveState account is required if you wish to “custom build” ActivePerl with the specific modules/packages you require. That is unless you have a GitHub account (which let’s face it, most of our customers likely won’t have) in which case you can just sign-in.

In order to download ActivePerl, you now need to sign up/in to ActiveState
In order to download ActivePerl, you now need to sign up/in to ActiveState

Having to sign-up and create an account to build/download Perl is a bit unnecessary in our view. You can, for instance, download Strawberry Perl without any of the hassle of having to create an account first.

Anyway, we created an account and logged in…

Configuring a new ActiveState build

Creating a new ActivePerl build was relatively straight forward – there was a big “Create a New Project” button.

Creating a new project on the ActiveState platform
Creating a new project on the ActiveState platform

This then allowed us to select a language – in our case, this was Perl and a Perl version.

Creating a new Perl project on the ActiveState platform
Creating a new Perl project on the ActiveState platform

The two most recent options (5.34.0 and 5.32.1) were flagged as “Beta”.

Perl 5.34 and 5.32.1 are currently classed as "Beta" by ActiveState
Perl 5.34 and 5.32.1 are currently classed as “Beta” by ActiveState

We therefore chose the highest version that wasn’t flagged as “in Beta”. This was 5.32.0.

Next, we could “Add package bundles”. We didn’t want this, as we wanted to add individual packages, so we unselected all package bundles at this stage.

We then selected the operating system we wanted our custom Perl build to be for (in our case, Windows).

Selecting a target OS for ActivePerl
Selecting a target OS for ActivePerl

Next up was “Project visibility” settings:

All projects on ActiveState are "Public" unless you have a "paid" plan
All projects on ActiveState are “Public” unless you have a “paid” plan

The “Project visibility” could only be set as “Public” (unless you opt for one of ActiveState’s paid plans). Finally, we gave our project a name and hit “Create Runtime”.

Adding packages

Once the project was created, we then needed to add the 24 additional Perl modules (packages) that MIDAS requires. These could either be added one at a time via the “Add Packages” button, or imported as a list via the “Import” button.

Adding "Packages" to Perl on the ActiveState Platform
Adding “Packages” to Perl on the ActiveState Platform

The platform then automatically resolved additional dependencies of the 24 packages we’d added, which was useful.

One other useful feature was that the platform indicated any CVE’s (Common Vulnerabilities and Exposures) for each package we were including.

Building the new build

Once all the packages MIDAS required had been added, it was then time to “build” our custom ActivePerl environment. Building indicated that it would take up to 20 minutes to complete, and the platform displayed build progress in real-time throughout.

Sadly though, our build failed!

Building ActivePerl 5.32.0 failed
Building ActivePerl 5.32.0 failed

The packages that failed related to Perl support for MariaDB databases. MIDAS supports both MySQL and MariaDB databases, so it was kinda crucial that our Perl distribution fully supported MariaDB. Anyway, the provided build logs shed no useful light on the root cause of the build failure, nor did ActiveState’s community forums.

Trying again…

We decided to try again. We created a new project, but this time selected an earlier version of Perl (5.28.3), and added in all our required packages.

This time the build completed in 23 minutes and 35 seconds, and provided us with .exe and .msi installer links.

Successfully building ActivePerl 5.28.3 on the ActiveState platform
Successfully building ActivePerl 5.28.3 on the ActiveState platform

Testing the build

We admit, we were actually a little excited – we appeared to have a custom Windows distribution of Perl that our self-hosted customers could install on their servers, and all the modules MIDAS requires would be there right “out of the box”. Our customers wouldn’t need to separately manually install any Perl modules.

So we proceeded to install this custom distribution on a test Windows server, and all seemed to initially go ok.

Once Perl was installed, we ran our handy Server Readiness Tool. This is a free tool we provide to those interested in running MIDAS on their own server. Amongst other things, the tool checks that all necessary Perl modules are available.

To our surprise, this indicated that two modules; DBD::mysql and DBD::MariaDB appeared not to be installed. These modules allow MIDAS to communicate with its back-end database.

Running our Server Readiness Tool under our custom ActivePerl 5.28.3 distribution
Running our Server Readiness Tool under our custom ActivePerl 5.28.3 distribution indicates problems with DBD::mysql and DBD::MariaDB

Trying other versions

Wondering if it may have been an issue with the .msi installer, we completely uninstalled Perl and tried again with the .exe installer link instead. This produced the same results.

We also then spent time and built identical packages on the ActiveState platform under both Perl 5.26.3 and also Perl 5.34.0.

The 5.26.3 build produced the same results as the 5.28.3 build. The 5.34.0 build just failed to build (just like the original 5.32.0 build).

We looked a little deeper into our test server’s error logs and discovered that a key component needed by the MySQL and MaraDB drivers was actually missing and hadn’t been included within the distribution.

The “workaround”

It seems like we’re not the only ones having issues using recent builds of ActivePerl built on the ActiveState platform with MySQL / MariaDB packages included. A number of people have posted with similar issues in ActiveState’s forums (like in this thread, and this thread).

The issue appears to be related to a missing MySQL “client library” .dll file that doesn’t get included with builds of ActivePerl.

Their best solution… install Strawberry Perl, grab the required “libmysql__.dll” file that gets installed with that, and copy the file over to your ActivePerl install!

So we tried this, and it did indeed resolve the issue. But just to be clear – right now…

In order for ActivePerl to work with MySQL / MariaDB databases you need to install Strawberry Perl!

Yes – seriously!!

Why would anyone want to do this? – it would just be easier to install and use Strawberry Perl and not even bother with ActivePerl!


We’re really saddened by the recent direction that ActiveState have moved in with ActivePerl, and their apparent lack of enthusiasm for and commitment to ensuring that it actually works with popular databases!

For over a decade, we used to exclusively recommend ActivePerl to our Windows-based customers. Last year we changed to recommending either ActivePerl or Strawberry Perl.

However, in August 2021, as things stand at the moment, we can no longer recommend ActivePerl (we’ve even now removed this recommendation from our website).

In summary…

  • ActivePerl 5.32 and ActivePerl 5.34 fail to correctly build at this time, so can’t be used for MIDAS.
  • ActivePerl 5.28 and 5.26 do build, but are missing a required MySQL client library. In order to use either of these builds, you’d also need to grab a .dll file from an install of Strawberry Perl.
  • The last known “working” version of ActivePerl is 5.24. ActivePerl 5.24 is now 5 years old, and is no longer available for download from ActiveState’s website.

So for any self-hosted customer wishing to use install our MIDAS scheduling software on their Windows server, we suggest you avoid ActivePerl and use Strawberry Perl instead.

Alternatively, you may wish to consider our cloud-hosted solution.

UPDATE: Since originally publishing this article, ActiveState have reached out. Read more in Revisiting Active Perl… Part Two!

Strawberry Perl vs ActivePerl

Perl” is the coding language we develop our web based room booking and resource scheduling software, MIDAS, in.

Most Linux and Mac OS based operating systems come with Perl pre-installed, yet, Windows operating systems do not.

We test MIDAS on a range of operating systems, servers and platforms. Our in-house development of MIDAS is primarily within a Windows-based environment. This means that we needed to install a Perl distribution on Windows.

ActivePerl ActivePerl

When MIDAS development started back in 2005, there was really only one mainstream solution for running Perl on Windows. This was a Perl distribution named “ActivePerl“, produced by ActiveState.

The reason we liked ActivePerl was two-fold; firstly, a completely free “Community Edition” was available. Secondly ActivePerl came with a handy tool called the “Perl Package Manager” (PPM). This made installing and updating Perl modules easy. It provided a graphical interface where modules could be quickly installed, updated, or uninstalled with just a few clicks:

ActivePerl's Perl Package Manager

ActivePerl included a number of “default” Perl modules. MIDAS requires some additional modules not included within the standard ActivePerl distribution. The PPM tool allowed easy and quick installation of any such modules as required.

Many of our “self hosted” customers intended to install our MIDAS booking software on their Windows-based server. Therefore, we would recommend ActivePerl due to its availability, regular updates, and ease of use.

ActivePerl Strawberry Perl

Since 2005, other Perl distributions built for Windows have come along. Perhaps the most notable of these being “Strawberry Perl“, which first appeared in 2008.

Back then we explored what Strawberry Perl had to offer when compared to ActivePerl. After evaluating Strawberry Perl, we decided ActivePerl would continue to be the Perl distribution we developed under and would recommend to our Windows-based customers.

What initially made ActivePerl better than Strawberry Perl?

When we first evaluated the newcomer Strawberry Perl in 2008 against the more established ActivePerl, differences became clear from an ease of installation and use perspective.

Firstly, Strawberry Perl didn’t include a visual “Perl Package Manager”-type tool for installing and maintaining Perl modules. Rather, Perl modules required installation via the command line. On Linux-based servers, installing modules via the command line is the norm, but many of Windows-based users were less familiar with command line use. Consequently, a graphical Windows application which allowed easy installation of Perl modules was preferable.

Another difference was that ActivePerl was established and more stable. Strawberry Perl was still the newcomer and felt a bit “rough around the edges”. Some Perl modules were also not fully supported or failed to install easily/correctly in Strawberry Perl.

As such, because we continued to only recommend ActivePerl to Windows customers, it was logical to continue to develop under ActivePerl ourselves. We would however keep an open mind and keen interest in the ongoing development of Strawberry Perl.

For the most part, our Windows-based customers continued to opt for our recommendation of ActivePerl. A few chose Strawberry Perl instead and were able to initially do so successfully.

Are we POSIXtive?(!)

However, around June 2010, Strawberry Perl suddenly removed a key component from their distribution which MIDAS relied on; the ability to natively work with and set Timezones. This resulted in those running MIDAS under Strawberry Perl seeing “POSIX::tzset not implemented on this architecture” errors. We had no idea why Strawberry Perl removed this functionality, or whether it was just an unintentional bug/glitch in their software. The reason for the removal of this functionality wasn’t forthcoming, or even acknowledged, by the Strawberry Perl team. This led us to initially suspect that perhaps it may have just been a bug.

This wasn’t a major problem for us, as we’d never officially recommended or supported MIDAS running under Strawberry Perl. It was of course though an inconvenience for the handful of customers who had been running under Strawberry Perl.

As a fix wasn’t forthcoming from Strawberry Perl, the solution for affected customers was either to install an older version of Strawberry Perl, or switch to ActivePerl.

By late 2010, it became clear that the developers of Strawberry Perl weren’t going to address/fix this issue. So we re-engineered our MIDAS software to work around this issue. Our next release in January 2011 once again ran under Strawberry Perl without issue.

What we learnt from all this was that Strawberry Perl still felt in its infancy and in a state of flux. We still didn’t consider it “stable” enough for use in production server environments.

We continued to recommend ActivePerl for all our Windows-based customers.

ActivePerl was in continual development, with regular releases which reasonably closely tracked the latest versions of Perl available for Linux-based servers.

Something changed…

In late 2016, we felt things began to shift and change with ActivePerl.

We began to notice that the latest versions of Perl modules stopped being offered via ActivePerl’s Perl Package Manager (PPM). Initially, this wasn’t a great cause for concern. MIDAS didn’t require the very latest version of any Perl module.

The released of ActivePerl 5.26 saw things further decline…

As you may be aware, MIDAS uses MySQL as its database. Perl therefore has to be able to connect to a MySQL database in order for MIDAS to function. The critical Perl module for doing this (DBD::MySQL) wasn’t made available for ActivePerl 5.26 via the Perl Package Manager.

This meant that MIDAS wouldn’t run for customers under ActivePerl 5.26. Customers would instead have to install the previous ActivePerl 5.24 build, which was still available for download from ActiveState.

Now, in the past following a new release of ActivePerl, it could take several weeks for Perl module updates to become available though the PPM.

So we waited… and waited.. yet still no DBD::MySQL module appeared for ActivePerl 5.26. ActivePerl 5.26 became useless for any application like MIDAS which need to connect to a MySQL database!

In our view, ActivePerl declined from there; in order to download ActivePerl an account was now required on their website. Additionally, they discontinued Perl Package Manager. Instead users had to “custom build” their own ActivePerl package in the cloud with the modules they needed, or use a command line tool to add in modules.

ActivePerl’s development started to lag behind Perl itself. For example, at time of writing, the latest official version of Perl available is 5.30.2. The latest version of Strawberry Perl available is also 5.30.2. However, the latest version of ActivePerl available today is 5.28.1 – nearly 2 years behind where Perl is currently at!

Then in 2019 ActiveState’s website was reportedly hacked.

Doubts began to arise over ActiveState’s commitment to continuing to continue to provide Perl and a free “community edition”. Their focus seems to have shifted more towards monetization and on their Python language products instead (as evident from the majority of their recent posts on Twitter)

Why we moved to Strawberry Perl?

These developments were a worrying trend for us. This is why last year we began equally promoting and recommending Strawberry Perl alongside ActivePerl on our server requirements page. We also provided a helpful step-by-step guide for installing Strawberry Perl, to complement our previous guide for installing ActivePerl.

Strawberry Perl has certainly come a long way since its first release. It’s now very stable, is passionately developed, and closely tracks the official version of Perl with frequent releases. Best of all, it remains completely free!

Whilst there’s no “visual” tool to install Perl modules as there was with the PPM under ActivePerl, installing modules under Strawberry Perl is still straight forward. We’ve found that the latest modules are always available (including DBD::MySQL!)

Many previous ActivePerl users around the world have already made the switch over to Strawberry Perl. At the start of 2020, we also moved all our development from using ActivePerl’s distribution or Perl to Strawberry Perl.

Should I choose ActivePerl or Strawberry Perl?

If you’re considering a self-hosted edition of MIDAS (remember that we also offer a cloud-hosted edition too!) for installation on a Windows-based server, whilst we still presently support both ActivePerl and Strawberry Perl on our website we would strongly recommend you choose Strawberry Perl.

If you must use ActivePerl, then we’d suggest getting your hands on 5.24, although this is now four years old, and we’re big advocates for keeping server software up to date. So going forward Strawberry Perl would be our preferred option on Windows.

Is your server ready for MIDAS v4?

MySQLThis Summer we have a major update coming to our web based room scheduling software. Starting with version 4, MIDAS will use a MySQL database for storage. Earlier releases of MIDAS have used different database architectures (which we look at in more depth in this blog post) and as such MySQL has not previously been a System Requirement for a server running MIDAS.

If you wish to run MIDAS v4 on your own web server, MySQL 5.1 (or later) is required.

MySQL, the world’s most popular open-source database, can be freely obtained from

In addition, two Perl modules not previously required for MIDAS will be required for v4. These modules, “DBI” and “DBD::mysql”, may already be present in your Perl installation, but if they’re not, they may be freely obtained from the following links:

  • DBI – Database independent interface for Perl (Get it here)
  • DBD::MySQL – A MySQL driver for the Perl5 Database Interface (Get it here)

If you’re unsure whether these Perl modules are already available on your server, our updated Server Readiness Tool will tell you!

Once your server is ready, our How do I update from MIDAS v3 to v4? guide will help you update your MIDAS installation.

If you’re currently running MIDAS v3 on your own server and are unable to use MySQL, you can carry on using version 3, (however this will continue to receive critical fixes only), or alternatively have your MIDAS v4 “cloud hosted” at instead

If we already “Cloud Host” MIDAS for you, you don’t need to do anything to be ready for MIDAS v4! – Our servers are already prepared for MIDAS v4!