@Nicole
Thank you so much to all authors for IBX as well as the components.
I can only agree with you on that. IBX is simply excellent.
Not for fun, I migrated TurboBird completely (about 25,000 lines) to IBX.
As a sign of appreciation and respect, I also dedicated half of the TurboBird About dialog to MWA Software and Tony
(my name does not appear in the dialog).
This way, every TurboBird user will get to watch Tony at work at least once 🙂
See screenshot.
Best regards,
Mauro G.
Mauro,
Thank you for showing your appreciation for my work on IBX in the about box for Turbobird. It is much appreciated. Adding "stars" on github is also appreciated.
Given that you have also chosen to honour MWA Software, I thought, for those interested, it might be a useful point to give some background on the name "MWA Software" and IBX for Lazarus, as well as what I am currently working on.
The acronym "MWA" goes back to 1992 when I registered the company "Mccallum Whyman Associates Ltd (MWA). Before then I had been a Principal Consultant with a large software company working mostly in the Defence and Civil Aviation sectors; times weren't good and I was unsure whether the company I was working for would survive (it got taken over later that year). I had been supporting UK NATS working on a new idea - replacing air traffic control air to ground voice communications with datalink comms - and negotiated a new contract for myself with the the Brussels based Eurocontrol Agency. I would still be working on the same international project (co-ordinated by ICAO) but with a funding agency that neatly side-stepped a non-compete clause. I needed MWA as the anchor for the contract. It was meant to be a five year stint but ended up dominating the rest of my career until my retirement earlier this year. At least I can point to the fact that most modern airliners now use the Controller to Pilot Datalink Communications (CPDLC) system that I played a role in creating.
I still get asked "what happened to Mccallum" (I am the Whyman in MWA). The answer was and still is that "I married her".
MWA Software came out of this (as the name suggests). I first got into this business through a love of programming and, given that even successful consultancy has some downtime, I filled this in with a bit of programming work. One of these bits of programming led to the creation of a database of training materials for CPDLC and for the Eurocontrol Institute. That database and the software that generated the presentations and workbooks was written in Pascal using Delphi 2.0. The database was InterBase and initially I used the Borland Database Engine to connect the two. That really was too inefficient to do the job and I replaced with with an early incarnation of Borland IBX.
That database itself led to a training and conferencing company - but that's another story. MWA Software also came out of a spin off of the project. Software was needed to render JPEG images and there was nothing suitable at the time for Delphi. However, the IJG had published an open source package written in 'C' for this purpose and I wrote a Pascal API to use it. Various message boards at the time were demanding such a package and so I documented what I did and published this Pascal API as shareware. "MWA Software" was the name I choose as a trading name for the publisher and mwasoftware.co.uk as the domain name for a first generation website to take registrations and from which the software could be downloaded. It was surprisingly successful with registrations coming from hobbyist programmers to large corporations, and was only superceded when, somewhen after Delphi 7, Delphi came with a JPEG library of its own. MWA Software also had a similar success with a text editor for very large text files (known as J-Write).
Before going back to IBX, it's probably worth recounting why Pascal and why Delphi.
Its really my university supervisor's doing, when I was a postgraduate back in the late seventies. He was an old buddy of Niklaus Wirth's. They had worked together on Algol 60 and _the_ University computer used AlgolW as its main programming language - for the Maths and Computer Science Dept that is - the Physicists insisted on using Fortran. Pascal was the next generation on from AlgolW and there was considerable interest in the department about moving to it. However, I never got to go beyond example use until when, a couple of years later, I worked on some early Ethernet projects at ICL.
The idea here was to develop Z80 based comms gateways to link older 1970s terminals to the mainframe via a modern Ethernet (then a thick yellow coaxial cable). Using Pascal as the main programming language for a real time box was almost an act of faith in this new programming language and I got recruited because I was still one of the few to have in depth knowledge of the language. I was initially responsible for the toolchain before becoming the project's Chief Designer. Perhaps, some might say remarkably, it all worked and we sucessfully developed an efficient real time system on a Z80 using Prospero Software's Pascal Compiler. Somewhat later, I worked on another real time development using 'C' and I still cannot understand why anyone perfers 'C' over Pascal - there are just so many bugs to get rid of in a 'C' program (due to its lack of data typing) and it takes so much longer to do the same programming task. (I suppose the answer is that the gcc toolchain was Open Source while Pascal compilers cost serious money until Borland created TurboPascal, and subsequently the development of the Free Pascal Compiler).
Anyway, given this background, Object Pascal and Delphi were, to me, an obvious choice for my database project.
Moving on, I was working on another project in the late 2000s, originally written in Delphi with IBX and a Firebird database. The problem was it was limited to Windows and we wanted to move the project to Linux. Kylix was no more and thus I investigated this new IDE called Lazarus and the Free Pascal Compiler. Even then it looked good and most of the software orginally written for Delphi could be quickly ported to Lazarus and FPC. The exception was IBX and it was needed to access the Firebird Database.
As it happens, when Borland/Imprise made available Interbase 6 as Open Source, they also did the same for IBX. I took copies of both sets of source code. The Firebird project of course came out of the Interbase software, but the IBX Open Source edition had just gathered dust. That is until I ported it to Lazarus. In the end it took about 3 months of part time work to do this and remove all Windows dependencies (the SQL monitor was the worst bit), but it worked and I published the result in compliance with the Interbase public license and in the hope that wider use would help improve stability.
That was in 2010. The software gathered users and I couldn't resist improving it. The code today only bares a passing resemblance to the original version. There has not just been extensive code cleanup, but also the Firebird OOAPI is now supported, a completely new buffer management strategy and more, including the Firebird Pascal API providing a managed (COM) interface for programmatic rather than visual access to the database.
I also wrote a near complete User Manual for IBX, but if I am going to point to what is the biggest improvement then it is the Test Plan and its implementation. Here, I borrowed techniques used in the high reliability world of aviation software, identified all the package's features and designed a set of tests to demonstrate the correct operation of each feature at least once. The test program runs from the command line and, in use, the output is compared with the last known good test output. This is used to identify any regressions. Before I release a new version of IBX, the rule is that the test plan must be passed for Firebird 2.5, 3, 4, and 5 and on both Linux and Windows. I regard this as essential to ensure product quality.
Another rule is that whenever a new bug is reported and fixed, the tests must be updated to ensure that that bug never repeats. Similarly, whenever a new feature is added, the test plan is extended. Across all IBX packages there are now 52 individual test programs each designed to test a subset of the 335 separately identified features.
The Test Plan, in addition to ensuring product quality also gives me the confidence to make major improvements - a good example being the relatively recent new buffer management strategy. A successful result when running the tests with a major improvement gives the confidence necessary to release an update.
Another important update is due to the next release of FPC; this FPC update is currently in development. The new release of FPC changes the in memory layout for object instantiation and has consequentially invalidated the original Pascal implementation of the Firebird OOAPI. In order to make IBX FPC 3.3 and later compliant, I have had to change the Pascal Firebird OOAPI to one using extended records inside of object instances, changing Firebird's cloop utility in order to do this. The extended record interface is backwards compatible with FPC 3.2 and is in current use across all FPC versions. As long as you are using a recent version of IBX (with the fbintf package 1.4.2 or later) upgrade from FPC 3.2 to the next version should be seamless. Again, the Test Plan allowed me to release this fundamental update with confidence.
IBX for Lazarus is now mature. I may certify it for use on Delphi, but otherwise there is nothing planned.
Currently, I am working on Indy OpenSSL 3.x support. In itself this is a spin off from another project I have been working on to record and analyse statistics from the various Energy Management devices I have around the house. These include Solar Inverters, Batteries, Diverters and weather reporting. All come from different suppliers, each with their own cloud services and REST based APIs. For one I needed an oauth2client, all have JSON encoded data (FPC has excellent support for JSON) and all need an https client with up-to-date TLS 1.3 support. The long standing Indy Component Library provides an https client but didn't work with recent versions of OpenSSL (needed for TLS 1.3 and modern encryption). I have been putting work into providing an addon to Indy supporting the latest OpenSSL releases and oauth2client support.
The current versions of both the OpenSSL addon IndySecOpenSSL and the oauth2client are both available on github and OPM. There is also an alternative (TaurusTLS) available. I have been working on and off with its developer and our objective is next to merge the codebases. In this regard, I have been going down the rabbit hole of 'C' header file to Pascal unit conversion. This is really the issue that caused problems with bringing Indy up-to-date. There are more than 50 header files for OpenSSL and which change with each major release. The current IndySecOpenSSL package uses the result of a manual (h2pas supported) conversion of a limited API subset necessary to support http. However, there is still a long term maintenance problem with each new release of OpenSSL and supporting new features.
I have thus been trying to develop a much more automated approach using gcc to perform C macro expansion and an improved version of h2pas. The h2pas program that comes with FPC is a very old program that appears to predate the introduction of "classes" to object Pascal. It also has many "features" (bugs) that needed correcting. This work is going well but there is still a need to patch the original 'C' header files to deal with issues such as header file circularity, incomplete types and declaration order. It should deliver the intended result with the effort of supporting a new OpenSSL release reduced to updating the patches. Hopefully, this work will get published in Q1/Q2 2026 and provide an example pathway for the 'C' to Pascal conversion of other complex 'C' APIs.
My Energy Management project is already working in prototype supported by a Firebird database and, of course, IBX. I hope to publish this on github later on in the year.
Otherwise, I have accumulated many other useful Pascal code libraries and projects that I intend to tidy up and publish. Just a few things in the way of finding the time to do all this - a house that was bought as a bit of a "doer-up-er" and six grandchildren under the age of seven all demanding attention...
Recent
