Author: Dennis Kolva

When we first created Goldenseal, about 1/4 of the work was for resources rather than code. That means window layouts, menus, icons, and other cosmetic details that make up a modern GUI (Graphic User Interface).

The original Goldenseal resources were set up in Mac OS 9 format, which is now obsolete. We already converted most resources to newer formats, but a couple of the more difficult types were still undone. So we spent the past couple weeks hacking the current version of Goldenseal, to export the rest.

The hardest were the layouts for the action commands- Reconcile, Pay Bills, Write Payroll and a few others. They were stored in a binary format that the PowerPlant library could read, but not humans. Fortunately, we found a way to cheat. Loading each window also converts the data into text temporarily, with one line for each field, button or table. We then saved it into files for future use.

Both of the platforms we use have their own GUI for setting up window layouts. However, Xcode’s Interface Builder and Visual Studio’s wizards have many quirks, so it takes at least a day or two to set up each window. With 35 windows total, we’ll save time in the long run by reading the existing data from text. It’s a change that we have been meaning to do for a very long time.

The biggest challenges over the past couple weeks were with hardware. Building the current Goldenseal app requires Mac OS 10.5 , which means 10+ year old hardware that is showing its age.

Interestingly, for many years Apple made it relatively easy for us to update our code gradually after each system update. However, that stopped soon after  the iPhone was introduced in 2007.  We tried the usual update process with Snow Leopard in 2009, but it required such a huge code rewrite that we never finished it.  I would say that Apple’s neglect for the Macintosh has only accelerated since then.

Meanwhile, on the Windows side we are still slogging through setup details for fields and tables. It has been slow to get up to speed on the Windows programming, but the onset of gloomy weather will help with that.

Dennis Kolva
Programming Director
TurtleSoft.com

Microsoft has five or six different platforms for writing Windows software. You might say they are software hoarders, who rarely throw anything out. We looked through the choices a month ago, and got so confusing that we gave up, and decided to stick with MFC (Microsoft Foundation Classes). It’s what we previously used for the current version of Goldenseal. MFC is old, but it works. It will get the job done.

There have been very active discussions on the Apple developer list, the past couple months. Last week someone posted a link to Microsoft’s roadmap for WinUI 3. It looks great. Microsoft must have realized that their developer choices were a mess, and decided to put everything into one box.  It’s due next year, which probably means 2021. The fact that they are so transparent about the whole process is very reassuring.

By their roadmap we can write code in MFC now, and ship Goldenseal Pro for Windows in a year or so. Then gradually update it with their new libraries over the next few years. Because of their transparency, we are very confident about the long term future of Goldenseal Pro for Windows.

On the Macintosh side, it’s Opposite Land. Apple is very secretive about their plans. They have a new SwiftUI in the works, which uses their relatively new Swift programming language. Their goal is to have one set of programming tools that builds apps for iPhone, iPad, Macintosh, Apple Watch, Apple TV and any other hardware they come up with. But details about it are few.

Based on what we do know, it is extremely unlikely that we can move Goldenseal onto SwiftUI. It appears to be designed mostly for small single-window phone apps, not for software as complex as ours. It uses a new language that probably would mean an enormous code rewrite, even worse than what we already have done for their Cocoa library.

Will Apple have a way to connect existing C++ code to it? Or can we finish the Cocoa version in Objective-C, and convert it easily?  Will Apple keep supporting Cocoa, so we don’t have to convert at all?  Maybe.  There is speculation on the list, but nobody knows for sure.

It usually takes us years to write software. Then it takes years to sell enough to pay for the programming time. That makes it just too risky to be working without better knowledge.

Right now the future of our Macintosh software is very much in limbo.  I’ll post details, as we find out more about Apple’s future plans.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff is making progress on Goldenseal Pro for Windows. However, it will still take some time to get back to full speed. It’s easy to forget stuff after being elsewhere for two years. At least it’s already less frustrating than Cocoa was. We’ll be up the learning curve soon.

Since tables were the hardest thing on Macintosh, it makes sense to start work on them right away. Windows does not have a built-in table class, but we probably can adapt our existing C++ table code. We also are checking out a couple of open source libraries for it.

Goldenseal has 30 or 40 action windows to handle Reconcile, Pay Bills, Write Payroll and a few other commands. We set up one of them for the Mac version, and started a second one. That’s when we realized they would take a week or more apiece to build, or a good fraction of a year total. That was the last straw that convinced us to delay work on the Mac update.

The Windows version has the same issue. Fortunately, we just figured out a way to convert the existing screen layouts from Goldenseal into text files. We can read those and build the windows with generic code, rather than redo each layout individually, twice. It’s the same approach we already use for data entry screens, reports and printed forms.

As for the Macintosh version, Apple likes to burn bridges. Rumors are they will switch from Intel to their own chips next year. When that happens, it’s very possible they will retire the Cocoa library that we used for Goldenseal Pro, and replace it with an entirely new framework called SwiftUI. Right now it only runs on iOS, but Apple wants a single OS for all machines.  If that happens, I don’t know if we will ever be able to write a Goldenseal for SwiftUI. From the specs it seems even less friendly than Cocoa.

I personally have used Macs since 1985, and prefer them to Windows. But the many bridge-burnings are annoying, for users as well as developers. When I bought my current house in the mid-90s I made detailed blueprints in MacDraw, with layers for electrical, plumbing, HVAC etc. It has been handy for permits and planning. Sadly, MacDraw didn’t even make it from OS 9 to OS X, and our last old Mac that can open that file just died.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff has been posting comments to Apple’s developer mailing list, detailing some of the problems we’ve had with the 64-bit update for Macintosh. Some folks there reported similar problems. Some think we are lazy slobs for only starting work on it 5 years ago, instead of 10.

We plan to forward comments to Apple soon. Hopefully it will inspire them to make improvements to Cocoa before we finish the Windows update and move back to Mac. However, as a small company trying to steer a trillion-dollar one, we aren’t very optimistic that it will change anything. We’ll see how things look in a year or so.

The MFC library we use for the Windows version is rather old. Before committing to it fully, we spent a few days exploring other, newer development tools from Microsoft. Most of them are based on C# instead of the C++ that we used for the rest of Goldenseal. Despite the similarity in names, the languages are quite different. C# is more like Java. Its main feature is ‘managed memory’, meaning that programmers have to worry a bit less about crashes and memory leaks.

After some poking, we finally decided that MFC is still the best choice. So we are now programming Goldenseal for Windows in earnest.

Before we switched to Mac-only programming two years ago, we already had many things working in the Windows version. So our staff is off to a running start.

We are now finishing up a top ribbon that is similar to the ones in MS Office. That and the outline view will replace all the current menu commands. Similar to many other Windows apps, Goldenseal Pro won’t need a top menu bar at all.

After banging heads against Cocoa for more than two years, it feels really, really good to make steady progress again.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff restarted work on Goldenseal Pro for Windows last week, and it’s moving right along.

There are two cross-platform libraries that use one code base to run for both Mac and Windows: QT and wxWidgets. We checked them 5 years ago, but eventually decided to write native code instead. Last week we revisited them, since they might be a way to get a Mac version out more quickly. Both have improved, but they still have a steep learning curve. Their end results still don’t look as good as native. So I think we are better off continuing with MFC for Windows, and then returning to using Cocoa for Mac after that is finished.

One of our staff members posted to Apple’s Cocoa Developer mailing list last week, explaining the problems we have had. Several other companies responded with their own complaints.  We are not alone.

Apple has earned many, many billions from the iPhone. They probably feel a bit of hubris because of that. But maybe they will respond to developer feedback, and make Cocoa easier to use before we return to programming the Mac version. It would sure be nice for the work to go faster.

At the moment, the estimated timetable for Goldenseal and Goldenseal Pro looks like this:

2019:
Macintosh– Goldenseal runs on Mojave (OS 10.15) and anything earlier. It does NOT run on Catalina (OS 10.16)
Windows– Goldenseal runs on any current or recent Windows OS (XP, Vista, 7, 8, 8.1, 10). Some annoying screen problems caused by QuickTime dependence.

2020:
Macintosh- no change.
Windows– Goldenseal Pro released for current 64-bit Windows 10. Maybe also for some recent Windows versions. Easy platform swaps for Mac users.

2021 ?????:
Macintosh- Goldenseal Pro released.

Dennis Kolva
Programming Director
TurtleSoft.com

I sat down with a spreadsheet this week, and tried to estimate how long it will take to finish the Mac version of Goldenseal Pro. It said 6 to 8 months of small details, plus whatever new problems arise with the Cocoa library. Based on past experience, that’s probably another 2 or 3 months. Plus whatever I forgot, which could easily double the time estimate.

I also checked our past sales data: 64% were Goldenseal for Windows. Only 36% Goldenseal for Mac. That surprised me. I though it was closer to 50/50.

Our staff has struggled with Apple’s Cocoa library for more than 3 years, under pressure to finish the Mac version of Goldenseal Pro before 32-bit support ends in OS 10.16 Catalina. For the past two years we abandoned work on the Windows version and focused exclusively on Mac, trying to meet that deadline.

We failed. It wasn’t even close.  There has been far too much time spent on weird Cocoa problems. Not enough time spent on actual Goldenseal stuff.

It’s time to stop short-changing our Windows users. Our staff is shifting gears. We just put the Mac version on hiatus, and will focus on Goldenseal Pro for Windows until it is finished.

The Windows MFC library is much more compatible with our code. It uses the same programming language (C++). Its basic design is more similar. MFC and Cocoa are both 30 years old, but Microsoft has done a very good job of updating their code. Probably better than Apple has done with their Cocoa library.

Even better, some of the prep work we’ve done on the Mac version also applies to Windows. I would not be surprised if we finish Goldenseal Pro for Windows in less than a year. With hindsight, we should have followed this path two or three years ago, or at least kept working on both in parallel.

Meanwhile, Apple is planning to switch from Intel chips to their own ARM chips in 2020 or 2021. They are also working on something called Marzipan that merges iOS (for iPhone and iPad) and Mac OS. Apple has not announced details for either project yet, but odds are good that the changes will make life more difficult for us. One way or another. Maybe even impossible. That is yet another reason to delay the Mac work for a year. Better to throw away 3 years of effort if we are doomed, rather than 4 or 5.

Unfortunately, this decision means that our Mac users will need to stick with existing hardware that can run 10.15 Mojave or earlier, at least for a while. Every model currently available is fine, but future Macintosh models probably won’t support 32-bit apps like the current Goldenseal. I’m sorry. Unfortunately, the best we can do is make it easy to switch to the Windows app when that is ready.

Dennis Kolva
Programming Director
TurtleSoft.com

Apple plans to release the latest version of Mac OS (10.15 Catalina) in October. It will not support 32-bit apps like the current version of our Goldenseal estimating/accounting software. They just won’t run.

This is not a surprise. The change was on the roadmap more than 5 years ago, which is when we started work on Goldenseal Pro. Back then, 5 years seemed like plenty of time to get it done. Unfortunately, the project was much bigger than expected. Our resources to finish it have been smaller than expected.

I apologize for the delay.

Catalina is a big release. Apple has been updating their own system code and apps from 32-bit to 64-bit, and it is not an easy process. Many testers are reporting that the beta versions have been very buggy. Odds are good that the first 10.15 release will still have some of those bugs. It’s probably a good idea to wait for version 10.15.1 or 10.15.2. Maybe even later.

In the past, the problematic big releases have been followed by a small update a year later, with code that is much more stable and reliable. Back in the cat era, Leopard was buggy, while Snow Leopard was fantastic. Ditto for Lion and Mountain  Lion, then Sierra and High Sierra in the current California geography era. It’s a good guess that next year’s 10.16 will be similar. Will Apple follow the same naming system and call it Santa Catalina?

Some Macintosh apps will never be updated to 64-bit. The previous updates to PPC, OSX and Intel chips each killed off about half of the small-to-medium Macintosh apps, plus a few big ones. Most likely the same will happen with this transition.

Frankly, if TurtleSoft had a time machine, we would hop right in and set the dial for 2014. Then hit the Undo button, retire Goldenseal, and do something much more fun than learning Cocoa and rewriting 2/3 of the code.

However, in the present timeline Goldenseal Pro is far enough along that we will finish it.  It does have some big improvements that we are eager to start using.

Dennis Kolva
Programming Director
TurtleSoft.com

From 1987 until 2000, TurtleSoft sold Excel templates for construction estimating and accounting. They were very profitable for about a decade. Demand was huge, because many construction businesses were just starting to computerize. Each template took a year or less to develop, so startup costs were minimal.

Unfortunately, templates also had problems. For one thing, Excel just isn’t designed to create easy-to-use apps. Users required almost four hours of phone support, on average, to get things running. Excel itself had a bug that sometimes zapped our code. Even worse, some things were just not possible to do in a spreadsheet. So, in 1993 we started writing a C++ app that later became Goldenseal.

Building desktop apps is hard. It took more than 10 programmer-years (and 7 real years) before Goldenseal 1.0 was ready to release. Template sales paid for the first 2/3, but the rest was financially scary. Between 2000 and 2015 we invested another 10 programmer-years in new features, bug fixes, and system updates. That got it up to the current version 4.96.

The hardest updates were for the Mac: moving from OS 9 to OS X, then from CodeWarrior to Xcode, then from PPC to Intel. Each transition took a few programmer-months. We hoped that the 64-bit update would be similar, but that was not to be. So far we’ve spent 4 or 5 programmer-years on the conversion. It’s in the home stretch, but Goldenseal Pro is still not finished.

As we inch towards completion, it’s time to think about how to price and distribute the new product.

For the past 32 years, TurtleSoft has used the same pricing model. You pay one up-front payment, and get a perpetual license, a printed manual, plus free lifetime support. Updates are optional, and not very expensive.

That worked fine when many companies were just starting to computerize. Unfortunately, the software industry has grown mature.  New users are scarcer, so it’s harder to get a steady income from first-time sales. We found that out the hard way in 2007 to 2010, when construction collapsed.

These days, Microsoft, Adobe and Intuit have switched to online services as a way to keep income more steady. You pay them a monthly fee to use their software.  Apple is also moving in that direction. It’s called SAAS (Software As A Service).

SAAS probably is not a good fit for Goldenseal Pro. For one thing, it takes time to set up. It also requires an Internet connection for users to retrieve data and/or the app.  Our main audience is builders and remodelers. They often are mobile, or rural, or on jobsites without steady Internet.

SAAS also requires providers to run a server farm, and worry constantly about security. Based on past history, it seems almost guaranteed that there will be data breaches and/or outages. We would like to keep the free support going, because it provides good feedback for future product design. And we really don’t want hundreds or thousands of angry users to be calling. We are just not big enough to run a totally bulletproof set of servers. Nobody is.

I didn’t start this topic with a specific solution in mind. It’s a bit of a dilemma. Where should TurtleSoft go from here? Comments are welcome.

Dennis Kolva
Programming Director
TurtleSoft.com

Last week I mentioned a mystery problem we were fighting: the outline view in our main window used to work OK. Then suddenly, it didn’t.

Folks on the Cocoa-dev mailing list were very helpful, with many suggestions on what might fix it. We tried them all, but nothing worked. Along the way our staff learned way too much about Apple’s memory system. It’s called ARC (Automatic Reference Counting). Developers on the list think it’s the bees knees. It is certainly better than the old manual system. Except that ARC was deleting our outline view, even though code was there to prevent it.

These days, most programming languages manage memory automatically. Stuff sticks around as long as you need it, then disappears when it’s no longer needed. Popular languages like Java, Python and C# use “garbage collection” to accomplish that. It’s probably not the ideal way to manage memory, but it works fairly well. And it makes life much, much easier for programmers.

Most of Goldenseal is written in C++. It is considered a difficult language, mostly because it doesn’t have garbage collection. On the other hand, C++ does give better performance. It’s also fairly easy to debug. There are many ways for programmers to manage memory reliably, and the language keeps improving every year.

Using C++ is a bit like, say, using power tools. Sure, they have sharp whizzing parts that can easily remove your limbs or digits. But they include guards and safety features. If you use power tools carefully, they get the job done safely.

Apple’s ARC seems to be somewhere in between C++ and Java. It promises easy memory management, but there are many “gotchas” that we discovered this week. It is not easy to debug. It definitely is not as simple as the garbage-collected languages. That applies both to the Objective-C language that we use for the new Goldenseal code, and to Apple’s new Swift language.

I hate to criticize a trillion-dollar company, but our life would be way easier if Apple used C++, Python, Java, or pretty much any other programming language. There’s a reason everyone else uses those other languages.

At any rate, we did find a fix. Our code worked OK until we made changes in June, and we can revert those changes. Theoretically it will leak some memory, but it won’t be very much. It won’t happen at all for most users.

With hindsight, we could have just reverted right away, and saved two weeks. But we learned stuff along the way. It was good to find out we hadn’t done anything obviously stupid.  If our staff did cause the problem, it was something extremely subtle. It may even be a bug in Apple’s ARC code, though it’s not worth another week of digging to find out for sure.

At least Goldenseal Pro is back on track. This is not the first time we’ve bogged down in Cocoa complexities, and lost weeks or months.

Dennis Kolva
Programming Director
TurtleSoft.com

A while back I mentioned how easy it was to set up the Goldenseal Pro outline view. It replaces the menus at the top, and does an excellent job of organizing things. I assumed that NSOutlineView probably was so reliable because it also runs the Macintosh Finder.

Unfortunately, I spoke too soon about that. This week we opened a few items, and the outline view stopped working. Clicking did nothing.

Usually our staff is very methodical. We add new code, make sure it works, and then commit it to the source control system. Nearly always, the process works well. Stuff improves, step by step. Unfortunately, a few times a year we miss something subtle, or change something with unintended consequences. It becomes a bug that rears its head weeks or months later. This is one of those times.

The first thing we did was check the weekly full-project backups, to see when it broke. Recent backups also had the problem. The June 2 backup worked OK. The June 9 backup didn’t. Most of the changes that week were related to bank transactions, and unlikely to affect the outline view. That week we did add a new NSSplitView to make the window resizable. So we removed that, but it didn’t help.

Next step was to rebuild from source control, to narrow it down to a shorter time range. June 7 was OK. June 8 wasn’t. Most of the changes that day were just accounting stuff, but we also started to add “weak” references. It’s an Apple thing that prevents memory leaks. That seemed like the smoking gun.

To test it, we set some breakpoints. Sure enough, the outline table was deleted randomly, after running a while. In earlier builds it stuck around. It didn’t work because it wasn’t there.

Apples ARC (automatic reference counting) is hard to debug. In C++ you can set a breakpoint right where an object is deleted, to see what killed it. Objective-C with ARC does the deletion some random time later. That makes it very difficult to find the cause of death.

Our staff spent a couple days stepping through code and reading more about ARC. It’s more complicated than we first thought. One website describes ARC as “kind of like a Japanese B-horror movie”. That seems accurate. We spent several weeks in April and May, struggling with a similar problem in the tab view.

Today we got too frustrated, and gave up for a while. It’s time to get back to more productive programming.

The Apple developer list is often helpful for odd problems, so we just posted a message there. This is the kind of enigma that may be solved in a dream at 3 AM, days or weeks later. Worst case, we get one support incident with Apple per year. It may be time to use it.

Dennis Kolva
Programming Director
TurtleSoft.com