16-bit code in the old days
As part of my job I have been programming quite a bit of software, often including the development of a Graphical User Interface (GUI). In the time of MS DOS this was very challenging in the sense that libraries to create a GUI were almost non-existent. We created a GUI with 24 lines and 80 characters per line, based on code developed by Sequiter Software Inc, and we used a plotting library developed by Quinn-Curtis, to create VGA plots we could also send to a line printer.
At the time, code was developed using the Borland or Microsoft C-compilers. We used version 6 of Microsoft’s C/C++compiler, as it provided some more standard libraries. But for any serious math calculations, a copy of the book Numerical Recipes for C was really needed.
The memory limit of 640 kB for code and data, asked for complicated workarounds in case code + data wouldn’t fit in the available memory. Think for instance of programs for correlation of long vibroseis records with a reference signal. This required using Fourier Transforms with the overlap-add method, splitting a long FFT into several smaller ones that would fit in the available memory. Results were then stacked in the frequency domain before the final result was transformed back into the time domain for further analysis.
In those days there were also no Integrated Development Environments (IDE’s). Nor were there any decent debuggers. So you often had to write information to stdout to check the status of counters and variables.
Transiting to 32-bit windows
At a later stage, in the wonderful world of 32-bit Windows, things got easier in the sense that code and data no longer lived in the same address space and one could allocate dynamic memory in the order of ~1GB without worrying about data or code pointer types (tiny, compact, large, huge) as was the case with MS DOS.
Anyone familiar with Charles Petzold’s famous book “Programming Windows” (or any of the other Windows reference book) can tell you how cumbersome it is working with a message loop, dealing with all User Interface events, including keyboard accelerators in barebones MS Windows.
This is where Microsoft Foundation Classes (MFC) came to the rescue. MFC provided a complete framework, with a document/- view architecture, that enabled adding multiple views to a single document, and/or working with multiple documents, all open at the same time. Also a lot of UI controls were available under MFC, with further development supported by contributions on websites like CodeProject.com, SourceForge.net, GitHub.com and others.
Working in MFC implied programming in C++, bringing the blessings of object oriented (and reusable) code development.
It’s a fact of life, that things don’t always work straight out of the box, and then having a powerful debugger at hand can be a real life saver. For that reason, I always prefer to work with a dual screen setup; one screen for the application being developed and one screen for the Integrated Development Environment (IDE), so they don’t interact in an unexpected way…
64-bit, the new standard
Over time MFC got orphaned by Microsoft, in pursuit of more modern user interfaces such as Windows Forms, Windows Presentation Foundation (WPF) – and of late – the Universal Windows Platform (UWP). Both WPF and UWP require programming in C# (managed code) under .NET, where UWP is tightly integrated with the Microsoft Store for code distribution.
Considering all of the above, and with the world moving quickly to 64-bit I started to work with the the WPF platform, staying away from the Microsoft Store.
Please note that with projects such as Mono, and DotNet-core rolled out as an open source projects (also available under Linux) working with .NET is no longer equal to “locking yourself completely in with Microsoft”.
Ultimately, I decided that building a 64-bit application from scratch, with access to Google Maps and Bing Maps and other topographical data to render objects spatially, was just not the way to go.
So I looked around for the best open source GIS applications, and landed on QGIS, which is very actively maintained, and has a very mature plugin architecture.
The plugins are either written in C++ or in Python. The advantage of C++ is obviously it’s speed and the fact that QGIS itself is also developed in C++. The downside is that you need to compile and distribute your plugin separately for Windows, Linux and OSX
The downside of Python is that it is an interpreted language with dynamic typing; in other words, it is slooooow. The advantage of Python is that each QGIS installation comes with its own Python interpreter, that has full access to QGIS functionality, and more importantly, the plugins written in Python are platform independent. Therefore, they run on Windows, Linux and OSX out of the box.