The current version of Goldenseal is a 32-bit app. Goldenseal Pro is 64-bit. You might wonder why that makes a difference. So, let’s look closer at computer bits, and how they affect our accounting and estimating software.
First of all, a bit is just a yes/no choice. It’s the smallest possible unit of data. Numerically, a bit is usually considered a 1 or 0. Physically, it may be a tiny magnetic spot, or a tiny laser-etched dot, or a tiny transistor’s state.
Computers have gradually increased the number of bits they can handle. Early PCs used 16-bit addressing for RAM, which meant a limit of 64K (65,536 bytes). Early Macs increased that to 24-bit (16 megabyte limit). In the 1990s, PCs switched to 32-bit addressing, with a 4 gigabyte limit. In the 2010s they’ve moved to 64-bit, with a theoretical limit of 16 billion gigabytes (=16 million terabytes =16,000 petabytes =16 exabytes).
Our accounting software is not likely to ever need more RAM than the 32-bit limit. Likewise, file sizes will also stay comfortably below 4 gigabytes. However, there are other reasons why 32-bit apps will become obsolete, relatively soon.
On the Macintosh, that impending obsolescence is obvious. Starting in Fall 2019, Mac OS will only run 64-bit apps. Apple has not updated its Carbon library to 64-bit, and does not plan to. That means all software must switch to Cocoa, which requires either Objective-C or Swift as a programming language.
As we have painfully discovered, converting from Carbon to Cocoa is not trivial. Existing C++ code can connect to Objective-C, but it’s a pain. Replacing old interface code is an even bigger pain. The Goldenseal Pro update is less work than the original programming for Goldenseal, but far more than any previous upgrade.
On Windows, the situation is less dire, because Microsoft takes great pains to support older software. However, 32-bit apps are already starting to be cranky, on newer versions of Windows. They often require special installations of older libraries and DLLs, and they may not be compatible with newer printers or other hardware. Running 32-bit apps is already a nuisance, and it will only get worse.
Updating our own programming code from 32-bit to 64-bit was not difficult. Memory addresses changed from 4 bytes to 8 bytes, but it’s rare for code to care about their length. There were other small changes to make, but nothing overwhelming. That prep work only took a few weeks.
Unfortunately, that’s not all that is required to get from 32-bit to 64-bit. Problem is, it’s not practical to write everything needed for a full-sized app, so we rely on libraries written by other people to handle “the basics”. Some are system libraries from Apple or Microsoft, some are open-source, and some are third-party code. Many of those libraries don’t work in a 64-bit world, and will never be updated by their authors.
We faced that situation with the NeoAccess code that runs Goldenseal’s database. It was so old and so badly written that a rewrite would have been a soul-sucking task. Replacing their code completely was faster, and less frustrating. It was a half-year project, but at least the new code will be more reliable, and easier to maintain.
We also had to toss most of the PowerPlant library, and a few smaller 32-bit libraries from the 1990s and 2000s. This massive conversion is something that every software company will have to deal with, if they want to stay viable.
Of course, there are many gains that come from the upgrade. For example, PowerPlant (and the original Macintosh) drew on a 16-bit “canvas”. As a result, reports with more than 1,500 lines were too long to display on the screen (though it was still possible to save them as text, and open in Excel). We tried to rewrite that code to 32-bit, but never got far. By going “native” with the screen drawing, Goldenseal Pro gets a huge canvas for free. It also gets better looking graphics, support for UniCode text, and many other improvements.
Dennis Kolva
Programming Director
TurtleSoft.com
