Author: Dennis Kolva

When thinking about computers, I like to compare them to automobiles. Both technologies have followed similar paths, with a gap of about 100 years.

Cars and computers started out big, slow and awkward: massive steam tractors in the 1850s and 60s; room-size mainframes in the 1950s and 60s.

Then came a half-century of innovation, much of it done by small start-ups. One round created useful vehicles to move people and goods faster than horses. The other built hardware and software to run a business, view cat videos, and do other amazing things with glowing rectangles.

Next was a couple decades of industry consolidation. For cars, most innovators either disappeared, or became brand names at General Motors or Ford. Computer hardware and software followed a similar path, boiling down to Microsoft, Apple, Google, Amazon, Adobe, Meta, Intuit.

Then came a long spell of bloat, perhaps because competition was gone. Cars grew chrome, fins and stylish updates, with little focus on being reliable transportation. With some exceptions (e.g. VW Beetle), 1920 to 1970 was filled with gas-guzzlers: dangerous on the road and hard to maintain.

It took a few more decades until cars turned into reliable transportation that just worked, without much fuss. My current Honda Fit is light-years more reliable than my first vehicle in the 70s: a Fix-Or-Repair-Daily pickup truck.

Computers are not doomed to follow the exact same path as cars, but they sure are in the bloated/mediocre stage now. TurtleSoft first faced that 20 years ago, as Apple migrated through chips, frameworks and programming languages. At first we kept up, but each change grew harder. Goldenseal 4.96 was the furthest we could go without a total rebuild.

Coding a 64-bit desktop accounting app was a long, failed slog, mostly because of poor quality tools from Apple and Microsoft. Qt, a surviving scrappy start-up, saved the day.

Right now we’re struggling to build accounting for Android. It relies on code from two other superpowers: Google and Oracle. Setup has been a version-matching nightmare. We still can’t get it to build apps on TurtleSoft computers, despite more than a week of trying. There are too many libraries necessary, and no instructions on how to get them working with each other.

We will persevere, but it’s not an easy task.

Dennis Kolva
Programming Director
TurtleSoft.com

Our new accounting software now runs on Android tablets. It’s not even a reduced version: the GUI is almost identical to the desktop app. You can store your company file on the tablet, and use it just like a cheaper laptop. It’s also possible to keep your data on a desktop machine at the office, and sign on as an Internet client.

We haven’t tested the tablet version yet, to make sure it lives up to the promise. Our staff is still setting up Qt and Android so we can build the app here and run it. Setup is a complicated process. At the moment, all we have is a screen recording showing that the software works.

It may take a fair amount of testing and tweaking to get Android tablets to be crash-free. The app relies on at least 4 layers of code libraries, and they don’t always work well together. Even worse, Android doesn’t have much of a debugger, so we can’t step through the code to figure out problems. It may need much trial-and-error to get everything in order.

Work also is progressing on a phone version. That will be much simpler than the desktop and tablet versions. It only acts as a client, and only does one thing at a time. Getting phone accounting apps to be reliable will be much easier. They probably also will be used more often, simply because everyone has a smartphone in their pocket these days.

Next on the list is iOS apps to run on iPhone and iPad. With luck, programming those will go as smoothly as the Android project.

So far, Qt seems to be performing pretty well as a multi-platform development tool. There’s a lot to be said for writing code once, then having it run on 6 different types of hardware.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff uses the Qt framework to build the new accounting software. It creates apps for both Mac and Windows. If there’s enough demand, we could even release something for Linux.

Every month or two, Qt gets an update. Usually they don’t affect our code, but the latest one broke the Windows GUI. All colored backgrounds suddenly went white.

A while back I ranted about past hassles with text on computers. Colors have a similar rocky history. This is not the first time they’ve caused problems.

Our first estimating software (MacNail) ran on the Mac Plus, with simple one-bit black & white pixels. Monochrome was the rule back in those days.

Soon, the Mac II came along with an 8-bit graphics card (enough for 256 colors). In order to actually see more than B&W, we had to jump from the standard one meg of RAM to 4MB (an extra $4000, inside an already expensive machine).

Because memory was so precious, apps and hardware often used a smaller range of colors: usually 8, 16, 32 or 64 of them. Goldenseal still contains ancient code to deal with black & white and the many possible color gamuts.

256 colors was enough for many tasks, but it was too sparse for photos. The best you could do was a custom set of colors to match the contents, then dither with dot patterns to get anything in between. Not great, not terrible.

As computers matured, RAM grew cheaper and colors improved. First it was 16-bits (65,000 choices): fine for almost everything, but photos still needed to be dithered. The specs used 5 bits apiece for red and blue, and 6 bits for green.  Human eyes are more sensitive in the middle of  the spectrum.

Then came 32-bit full color, with one byte apiece for red, green and blue. It allows for 16 million hues, good enough for all but the fanciest photo editing (humans can only distinguish a couple million colors). The left-over byte was soon used for transparency (called the alpha channel).

Life would be easier for programmers if everyone standardized on one color system, similar to UTF-8 for text. Sadly, that is not what happened. Web standard is 32 bit RGBA, but Apple uses decimal numbers instead. Qt stores 2 bytes apiece (64-bit colors). The spectrum also may come in CMYK (cyan/magenta/yellow/black) or HSV (hue/saturation/value), plus the usual RGB and RGBA. They all get to the same places, but with different numbers and different math.

The current Goldenseal uses a palette of 256 colors for lines, text, and field background colors. We set up a custom color palette with extra pastels (for backgrounds) and dark shades (for borders and text). Still plenty of bright colors in between.

We would have kept the same setup for the new accounting software, but 32-bit colors are easier to program. We actually store 64-bits for them, just to be compatible with Qt. Memory is cheap, and maybe it will help for a future RobotOS which adds X-ray vision.

Meanwhile, alpha channels are still evolving (it’s what broke our Windows version). Opacity doesn’t have much impact on accounting software, but we did find a few places to use it. You might like having alphas if you print forms in color?

Color pickers only set RGB colors, so the new Custom Layouts puts transparency into a separate dialog. Right now, it gives weird decimals as we convert between percents and integers. 100 doesn’t divide into 256 very well.

Dennis Kolva
Programming Director
TurtleSoft.com

Our new accounting software now connects over a network. Your company file sits on a Mac or Windows computer, then other users can sign on as a client. Goldenseal already does that over a LAN (local area network), but the new app also lets you use the Internet to log on from anywhere. It will make life easier for any construction business that spends time on job sites, or runs business from a truck.

The next step: mobile apps that do the same thing from a phone or tablet. Networking code for them is similar, but user interface and operating systems are different. Mobile is actually five different platforms.

iPhones and Android phones are the most common, and also the most difficult. Because their screens are tiny compared to desktops, they need a totally different user interface. Ours will just be a simple list of fields showing data from a desktop server. Here’s a really rough mock-up:

You’ll drag up to see more fields. Swipe sideways to see breakdowns or Find mode. To enter data, press a field, then either choose items with a finger-press, or type on the tiny keyboard. Changes save to a desktop server over the Internet. Our subcontractor is working on that now.

Rather than switch modes in one phone app, we’ll have single-function apps for each type of record. One will shows contacts. Others will handle labor hours and simple material purchases. Beyond that, we’ll wait for user requests. It may be possible to design some sort of construction estimating for simple projects, but phones really are the wrong size for that.

Tablets are totally different. They have enough space to fit the current desktop interface, so there’s no need to design a new look. The hard part is operating systems. There are three options.

Apple’s iPadOS is evolving the iPad into a slightly smaller and cheaper Mac. It runs real apps like Numbers and GarageBand. The problem will be Qt. It supports iOS, but four generations behind. It’s still not clear how much of the full app it can move to iOS. If we are very lucky, the new accounting app will run on iPad: either as a client, or as a stand-alone. If not, then it will just look like the phone app. Maybe we can make the window two columns wide and a bit prettier.

Android tablets have a similar problem. Probably worse, since they don’t have a desktop cousin. Our contractor is working on Android first, but anything on tablet probably will just be a bigger-screen version of the phone app.

Windows tablets will be easiest, since they can run regular Windows desktop apps. We’ll test the new accounting app on one soon, to see how practical it is.

Laptop computers are not much bulkier than tablets, so they probably are the better choice for most businesses. You get a keyboard and track pad, plus normal desktop apps. It’s easy to plug in a mouse, trackball, full keyboard or other USB devices. However, tablets do provide an opportunity. I’ll discuss that more in a future post.

Meanwhile, our staff is back to testing and bug fixing in the regular desktop app, plus tweaking a few final details in the multi-user version.

Dennis Kolva
Programming Director
TurtleSoft.com

Connecting your computer to a network isn’t hard, but plenty of stuff goes on behind the scenes to make it work. One part of that is ports: channels that carry a certain type of traffic. The multi-user version of our new accounting software needs one so clients and servers can talk to each other, whether over a LAN (local area network) or an Internet connection.

There are 65,535 possible ports (two bytes minus one). First up are the well known ports, using the first 1,023 numbers. For example, http web traffic moves over port #80, while encrypted https uses #443.  For email, there’s #109 for POP2 and #110 for POP3.

Most well-known ports are already allocated for something. They are much too classy for our accounting software.

Next step up are the registered ports, from 1,024 to 49,151. Only 10% of those are filled. Last week TurtleSoft sent in an application to register #21,587 for the new app. It’s TS as text. Goldenseal has been using #18,259, which translates to GS, but we want to keep them separate.

The Internet Assigned Numbers Authority (IANA) assigns ports. Sadly, they shot us down, and said to use the temporary range (49,152–65,535) instead. We appealed, explaining how users needed something easy to remember. Nope, shot down again.

Then we looked at the list of registered port numbers on Wikipedia. TurtleSoft is not the only one out in the cold. Apple, IBM, Microsoft, Cisco, Minecraft and many others use an unofficial port number rather than a registered one. Apparently IANA is stingy to everyone.

Right now, nobody else has registered GS or TS, and that status probably won’t change. So we will use 21,587 (TS) unofficially for the new multi-user accounting software. In the unlikely case that our port conflicts with some other app, you can easily switch to a different number.

Meanwhile, the networking code is almost finished. Soon we can get back to regular testing and programming.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff has started testing the networked version of our new accounting software. A contractor wrote the basic code to connect and send messages between computers, and we hooked it into a modernized version of Goldenseal’s multi-user code.

Like the current accounting/estimating software, the new version works over a local area network (LAN). You can connect either by Ethernet or wireless. One computer holds the company file and acts as a server. Other computers log on as clients. The app looks the same for them, but all data comes from the server.

The new software adds something new: connecting over the Internet. Enter an IP address for the server, then sign on just like the LAN version. A Mac or Windows machine then acts like a regular client, just a bit slower.

We’ll also have apps for Android and iOS to make the connection. Those can’t be full version clients: too small a screen, and not enough memory. Instead, phones and pads will have single-purpose apps to enter purchases, log in employee hours, or enter quick estimates. If there’s enough demand, we can app-ify any record window.

The original plan was that servers would need a static IP address. It turns out that may not be necessary. If you don’t pay for a static IP, your Internet provider assigns you a dynamic IP address instead. It’s easy to look up, and the new app can use that. In theory, dynamic IP numbers may change at any time, but in practice they usually don’t. Worst case, clients may need to switch to a different address to reach the server. We’ll test it for a while and see how practical it is to use dynamic addresses.

The whole IP connecting system has an interesting history.  The current version is called IPv4. Each IP address is a 32-bit number, usually split into four bytes with periods between. It has room for over 4 billion addresses.

When IPv4 started in 1982/3, the Internet was still very sparse, so the 256 top-level numbers were passed out like Halloween candy. Harvard, MIT, Stanford and a few other universities each got one. So did companies like Ford, Xerox and Apple, plus the military. Each of those sat on more than 16 million addresses. The leftovers were kept in reserve for future expansion.

An “oops” moment soon came, later in the 80s. By then the Internet was expanding, and the reserves were already in danger. From then on, IPv4 has survived by squeezing out extra addresses and finding ways to cheat. So far it still works, but some day 4 billion won’t be enough.

There’s already a replacement called IPv6, first developed in 1998 and made official in 2017. Rather than expand to mere 64-bit numbers (18 quintillion, or 2 billion for each person on earth), it jumps all the way to 128-bit numbers (340,282,366,920,938,463,463,374,607,431,768,211,456 addresses, or 9 quintillion for each person on earth). Apparently the planners want a system that can cover the known universe.

Qt supports IPv6, so you’ll just have to enter extra numbers to connect, some day. IPv4 and IPv6 don’t talk with each other at all, which will make things interesting.

Dennis Kolva
Programming Director
TurtleSoft.com

There are 689 records in TurtleSoft’s Problem Log, nearly all of them for bugs in Goldenseal accounting/estimating software. Most showed up during the first few years, then tapered off. This year there was a slight uptick because of old bugs caught while testing the new accounting app.

257 bugs are marked as Completed. Most of the others were fixed long ago, but didn’t get a status update. A few are user bug reports that we couldn’t duplicate.

Recent bug finds are usually small stuff: slightly annoying or very rare. However, last week we discovered a serious Goldenseal design flaw. It may be the cause for some mystery errors. The problem will linger on in Goldenseal, but not in the new version.

One handy feature in our software is linked records. There are many ways to see something related. Some are commands in the View menu. Others are buttons in records. You can also see links from clairvoyant/smart fields and from double-clicks on report lines. All those actions will activate a window, then jump to a record (some buttons start a new record, instead).

The system is nifty, but we overlooked something important. What happens if the window was already open, with an unsaved record? It’s an “edge case”. Probably rare, but it may happen. The code tries to save changes, but if it’s too incomplete to save, the record sits in limbo after another one is loaded. When you quit the app the dud record will disappear, but it may cause chaos before that.

Fixing it took a while because we discovered another problem. The different ways to see links were added gradually, with slightly different code each time. Rather than fix four different functions, our staff combined them so only one change is needed. That will make future upkeep easier.

The new accounting software now warns about the unfinished record, and cancels the link. Slightly annoying, but better than creating a mess.

Dennis Kolva
Programming Director
TurtleSoft.com

Last week, our new accounting software finally started to print good-looking sales receipts. We used it to run day-to-day TurtleSoft business for a few days, then took a break to fix all the bugs that turned up. That on/off cycle will continue for a while, with longer ons and shrinking offs.

The nastiest bug was in the memory cache system: code that decides which records to keep in RAM. It zapped some records, but also was the easiest to fix. Just one missing line of code when duplicating records. Easy-peasy.

The most complex bug happens for linked records. It’s a basic interface problem. Goldenseal puts everything in separate windows. It makes a cluttered screen, and needs windows-inside-a-window on MS Windows. The new accounting/estimating app has just one main window with tabs, for a more orderly screen. But it adds a new problem. What happens when you want to see a linked record?

The solution is to pop it into a separate window. In fact, you can still put everything in separate windows if you want.

But what happens if it used to be in a tab? The solution for that is to move tab contents into the window, then delete the tab so they won’t get out of sync. That has been working for a while.

But what happens if you close the window? There’s the bug: the tab is still gone. Slightly annoying. Going window-to-tab is the reverse of tab-to-window, but the code is complex and can’t just be flipped. Our staff is working on that now.

Breakdown tables have always been difficult, and there’s also more to do there. Most things display OK, but Billing Records, Bank Transactions and Payroll Records have more than one type of table. They still need a way to deal with that.

Meanwhile, the subcontractor working on networking is making good progress. Some time in the next month or two, we could use help testing the remote access feature. You’d need a static IP address, so clients can find the test server from afar.

Dennis Kolva
Programming Director
TurtleSoft.com