Goldenseal Pro for Smartphones (Aug 12)

Many people have asked if we can put Goldenseal Pro on a smartphone. Unfortunately, the answer is a resounding “no”.  The hardware is too underpowered, the screen is too small, and the operating systems (iOS and Android) are simply not designed for building complex desktop apps.

However, what we can do is build multiple small smartphone apps that each do one thing, and “talk” with the home company file back on your desktop.

Android and Cocoa Touch (the Apple framework for mobile) both have excellent support for communicating via html. We can package our data easily into something called JSON, for sending between devices. The hard part will be getting the desktop version of Goldenseal Pro to act as a web server, so the mobile apps can connect to it via html. If that isn’t possible, we can use a VPN (virtual private network) or something else.

We already need to rewrite our current desktop networking code to run under Cocoa and MFC, and it would sure be nice if we can use the same code to connect all types of devices.  Right now Goldenseal uses TCP/IP sockets to communicate between desktops, but it’s time to consider other approaches. To test them, we’ll need at least a prototype version of a smartphone app. The best tool for that will be an app for iPhone and iPad, using the new Swift programming language. We will start with something very simple, like entering a purchase or viewing the contact log.

Prototyping is a gradual process, so we’ve started on it now, and will mosey along on it over the next year or so.  The goal will be to have it functional by the time we start work on networking, which is probably a year off. 

Networking code is very hard to write. In the past we subcontracted most of it. However, if we can use something that is built into the operating systems, we may not need to.

Dennis Kolva
Programming Director


Goldenseal Pro and C++ (Aug 3)

For the code that runs Goldenseal, we use the C++ programming language. C++ was first developed in the early 1980s as an object-oriented extension of the C language, which was introduced itself in the early 1970s.

C is currently the second most popular programming language (behind Java). It’s often used to write operating systems (Windows, Unix, Mac OS), code libraries, and imbedded systems like the one that runs your car or truck. C++ is the third most popular language (per Wikipedia). It is better suited for large desktop apps like Goldenseal. The object-oriented features make it a teeny bit slower, but they also make it much, much easier to program big projects.

C++ was first “standardized” in 1998, with a set of “standard libraries” for handling many basic programming tasks. At that time, we were already using PowerPlant, a similar framework written in the mid-1990s. We used a few of the new C++ standard library features, but for most, we already had a decent version from PowerPlant.

Since then, C++ had a minor update in 2004, and then big upgrades in 2011 and 2014. Another is due this year. Unfortunately, we couldn’t use the many new features and improvements in the C++ language until we updated from 32-bit to 64-bit. That broke most of PowerPlant, so we started using a few of the new C++ features two years ago, to replace the old PowerPlant code.

Some programming work requires intense “focus”. Basically, the programmer needs to immerse in the entire system for days on end, and not think about much else. It’s similar to what you need when working around high-voltage electricity, or on steep roofs. But it goes on for weeks, not hours. It takes a day or two to rev up.

We left some of the interface work unfinished in May. The weather probably won’t suck enough until October, to start back on it again. Dealing with the quirks of Cocoa, MFC and Objective-C require lots and lots of focus. However, there are simpler things our staff can work on, even with summer’s distractions. Some programming is fairly routine, and can start and stop at will. It’s more like, say, painting walls or mowing grass.

We are currently going through the C++ 2014 standards, and picking out things we can use now, to improve Goldenseal Pro. There is some really nifty stuff in there.

Some of the features will help us do a better job with the networked apps. Some will help support multiple threads (e.g. use the Find command, and then do something in another window while it runs).

Many of the improvements are “safety” features, which allow code to not crash or run out of memory. We already have ways to accomplish that, but modern C++ does it better, and more concisely. Some things make the code stricter, so the compiler will point out stupid errors. Using the new C++ libraries means we will accidentally fix a few bugs, and prevent more in the future.

There are a few things we can probably change with a huge text-replace. Most will require looking at hundreds or thousands of code bits, and deciding what to change. It is all stuff than can be done gradually. We’ll work on it now, and probably will be doing it for many summers to come.

It’s invisible work, but it will make Goldenseal Pro more reliable, and easier to program and maintain.

Dennis Kolva
Programming Director

Goldenseal Pro Cash Flow (July 23)

The cash flow for creating software is a lot like building a spec house. Income only happens when the project is finished, so the builder needs some way to finance labor and materials along the way.

TurtleSoft started out very, very easily. The first estimating template only took a month or two to write, during a slow winter spell in early 1986. Sitting at the computer was a welcome relief from swinging a hammer. Turtle Creek Carpentry made enough extra profits the rest of the year to pay for the time. In March 1987 we ran an ad in Fine Homebuilding to sell it, and the software business rocket-launched from there. You might say that the initial development costs were almost free.

As we expanded, each new MacNail module took about 1 year of programmer time. HyperEstimator took a year. BidMagic took 2 or 3. Those were good times, when a small investment in programming could create a massive amount of income. It wasn’t hard at all to finance new product development. The hardest part was dealing with exponential growth, and then, dealing with the plateau when it ended.

We wrote the first prototypes for Goldenseal in 1993, and started writing C++ code in earnest two years later. It was our first ‘real’ app, and a much bigger project than anything we had done before. The first estimates were 5 or 6 programmer-years. It eventually took almost twice that to get to version 1.0.

The first half went smoothly, with plenty of income from our older software to pay for the work. Then, in early 1997, Apple announced a $708 million-dollar quarterly loss. There was speculation the company would be swallowed by IBM or Sun, and Macintosh sales dropped almost to zero. More than half our sales were on Mac, and those disappeared.

The good times were over, and the second half of the Goldenseal programming happened on a shoestring. We couldn’t have finished it without loyal MacNail users who purchased pre-release versions (plus a lot of credit card debt).

Cash flow was tight at Turtlesoft until the release of Goldenseal for Windows in 2002. Then, for the next five years, net income became rosier than ever. Sales were better than the MacNail days, and support costs were smaller. Those were boom years for construction, and it flowed down to construction software.

However, we had learned a lesson about sudden loss of cash flow, and decided in 2005 to start a ‘backup’ business with steadier income, to offset the ups and downs of construction software. The result was SmartKnives, which sells Swiss Army knives and Leatherman tools (mostly purchased from airport auctions). It started out mostly as entertainment for the programmers, but as software sales declined post-recession, we ramped up knife sales.

Right now, SmartKnives is paying most of the bills, and funding the programming work on Goldenseal Pro. Running a second business does slow things down. However, programming work can be very draining (and fattening). There’s a lot to be said for doing it part-time. Cleaning and photographing vintage knives is a pleasant break from hours at the computer. 

Ever since the beginnings 30 years ago, our programming efforts have been very seasonal. October to April is the main programming season. We usually slack off or take a full break in the summer, and do outdoor things. Difficult problems often become so much easier after a couple months of being ignored.

As we did with the original Goldenseal, we have an option to pre-order Goldenseal Pro. It’s cheaper than the final upgrade price, and it helps prod us (and finance us) to work slightly faster. Most likely we will publicize it more (and probably raise the price) as we get closer to completion.

Dennis Kolva
Programming Director




Goldenseal Pro Tech Support (July 12)

As we modernize our code for Goldenseal Pro, it’s also an opportunity to update the rest of our software business. Right now we are thinking about tech support.

Our software has always included unlimited free support, by phone or email.

Naturally, it’s very popular with users, but it also helps us. Many of our new features and improvements come from user suggestions. And, even when there is confusion or a problem, it tells us what needs improving in the software design and documentation. The amount of support we need to provide keeps decreasing, as we gradually make our software easier to understand.

On the minus side, technical support is very hard work, especially when done over the phone. Helping frustrated callers requires tact, patience, technical skill, and a thick skin. It is hard to find all those together in one person, and even harder for any given human to keep it up for hours. Most callers are easy to work with, but some are difficult and draining.

As phone service switches from land lines to cells and VOIP, there is also a latency problem. The cellular network typically adds a delay of 90 to 200 milliseconds each way. That’s only 1 or 2 tenths of a second, but it’s enough to disrupt conversation ‘flow’. Staff and callers are more likely to interrupt each other, and seem rude or impatient when it’s really just transmission lag.

The other option, email support, has the big advantage of being asynchronous. You can send a message at 3 AM or whenever, and we can answer it without interrupting our other work. In an email reply, we can paste a link to an Answers page on our website, or copy text from there. We also have time to compose a thoughtful answer (and do testing or research if necessary), without you waiting on the phone.

Of course, email support is not perfect. The worst problem is the delay, which is annoying even if we answer at maximum speed. Also, some of our users are vision-impaired or dyslexic, and can’t work with text. Some support callers are just generally frustrated, and need a reassuring voice, rather than text. In general, we find that some problems are much easier to solve by email, and some are much easier via the give-and-take of a phone conversation.

Live support is a third option that is becoming more common: it is text-based, but more real-time than email. It’s better in some ways, but also has its flaws. It probably can’t replace either of the other support options, but it may be a reasonable supplement.

We have been looking at tech support provided by other software companies. In general, support usually depends on the complexity and cost of the program. Small, single-purpose apps (less than $100) rarely include phone support, and often have slow email turnaround. Large, enterprise software (more than $3000) usually requires an annual fee for support and updates, or pay-per-call.  In between, phone support is more often available and free, but it is becoming less common. What there is, often goes to an overseas call center.

We are not to the point of making any decisions yet, and would welcome user feedback on this subject.

Dennis Kolva
Programming Director

Goldenseal Pro Database (June 28)

Goldenseal stores a lot of data. Many users have more than 100,000 records in their company file, and some have millions. The code that keeps track of everything is an important part of our ‘back end’. It needs to access records quickly, and store them reliably on disk.

For the original Goldenseal, we licensed an object database called NeoAccess. It ran on both Mac and Windows, and was very popular in the 1990s. Unfortunately, the source code had serious bugs that were never fixed, and we ended up rewriting a lot of it (especially after its developer folded their business).

For Goldenseal Pro, we looked at a couple dozen open-source and commercial database libraries, both object and relational. Using a 3rd-party library has its advantages: someone else did all the work, maybe they are an expert, and maybe they will keep it updated. However, as we found with NeoAccess, other people’s code also has disadvantages.  For one thing, it’s usually easier to fix one’s own bugs and design flaws. Every library also has a learning curve, plus quirks and limitations. There is no perfect way to manage a database.

After a few trials, we finally decided to write our own database code for Goldenseal Pro.  Since we already rebuilt half of someone else’s database, designing a whole new one didn’t seem too risky. We kept some of the design from NeoAccess, but replaced the parts that didn’t work well.

The main thing any database needs is a list of where each record is in the file. NeoAccess used a ‘binary tree’, which is theoretically the fastest way to find things, using the least amount of memory. However, modern computers are designed to move relatively big blocks of memory, so it makes sense to have a tree that is ‘wide’ (with more records in each branch, and fewer branches). A wide tree gives faster record access on modern machines, and also uses simpler, cleaner code.

We wrote the first part of the database last summer, then tested and debugged it over the winter. The past few months we finished the remaining ‘tree’ code, to handle larger numbers of records.

If you want to see what C++ source code looks like, here is our function that looks for an empty spot to index a new record, and creates a new index if the current one is full:

SInt64 DB_RecordIndex::AddObjectToIndex(const DB_PersistentObject *aObject, CTCS_FileStream *inStream)
    TCS_FailNILMsgID(aObject, errID_BadObject);
    TCS_FailNILMsgID(inStream, errID_BadStream);
    SRecordIndexInfo info;
    if (mTreeLevel > 0)
    {                   // add to the last subindex
        DB_RecordIndex *lastIndex = FetchLastSubindex();
        DB_ObjectWatcher watcher (lastIndex);
        SInt64 subMark = lastIndex->AddObjectToIndex(aObject, inStream);
        if (subMark != 0) return subMark;    // was added to subindex
        if (mRecordArray.GetAvailableSpace() > 0 && !IsFilled())
        {            // still room for more subindexes here, so add one
            return AddSubindex(aObject, inStream);
        else if (IsRootIndex())
        {            // Need to increase tree level by one
            subMark = ShiftItemsToSubindex(inStream, info.startID);
            return AddSubindex(aObject, inStream);
        {         // subindex is full. Pass back to parent
            return 0;
    else if (mRecordArray.GetAvailableSpace() > 0 && !IsFilled())
    {            // base level index with room here.
        info.fileMark = aObject->getFileMark();
        info.itemID = aObject->GetDBID();
        return info.fileMark;
    else if (IsRootIndex())
    {          // the array is full, so it’s time to become a new parent!
        ShiftItemsToSubindex(inStream, info.itemID);
        return AddSubindex(aObject, inStream);
    else return 0;            // this base index is full.  Pass back to the parent
There are plenty of quirks to managing a database. We need to keep track of empty spaces, so the file stays compact. We also store each record’s location in two different places, so it will be possible to fix a corrupted index (something that NeoAccess could not do).

To keep the database code simpler, we take advantage of the fact that record IDs are always increasing, so we can just add them at the end and have a sorted list. We also just leave empty spaces when you delete a record, rather than rearrange the whole tree. Our primary goal is to make the code reliable and easy to maintain. So far, that approach has been successful.

Dennis Kolva
Programming Director

Goldenseal Accounting- Audit Trail (June 19)

One of the lesser-known features of Goldenseal accounting software is the Audit Trail, tucked away inside the View-Security menu. It tracks when each record is created, changed or deleted. If multiple users sign on with different passwords, it also shows who did what. You can control exactly what gets logged with Options-Preferences-Data Entry. For security reasons, the Audit Trail can’t be changed, so it creates a permanent record of what happens to your business records.

The Audit Trail is a valuable accounting feature for larger companies. You can look back at all changes made to records, which makes it much easier to investigate possible fraud (or just carelessness). We also use it occasionally when diagnosing posting problems in user files.

On the flip side, the Audit Trail adds many records to the file, and increases file size by 10% to 30%. Many of our users do their own data entry (or have a relative do it), so it is unlikely they will ever need the trail for a security investigation. The feature is obscure enough that most people don’t even know it is running.

The conversion to Goldenseal Pro is a chance to redo some of our early design choices. After 17 years of user inputs, we have a much better picture of what is actually useful. The Audit Trail is one of those things we can probably do better.

It doesn’t make sense to remove the Audit Trail, because it helps some users, and it already works fine. However, when we import data from older files, we probably will skip the old Audit Trail entries. If they are ever needed for an investigation, they are still available in the old file. If moving them to the new file is important to you, please let us know.

We may also change our default settings, and leave the Audit Trail off for most users. If you don’t use multiple passwords, then you probably don’t need it.

Another option is to go in the opposite direction, and expand the Audit Trail into a full ‘journaling’ system. Some software programs (e.g. Photoshop) store a list of all changes made, so you can go back with Undo multiple times, or selectively apply some past changes but not others.

To make a journaling system work for accounting, the Audit Trail would end up using more than half of the file size. Having multiple undo would add complexity to our posting code, and it may have security issues.

We won’t change the Audit Trail by much in the first release of Goldenseal Pro, but we may revise it in a future update. If you have often wanted to undo deletions made days ago, please let us know. That is probably the best advantage we’d get from a more complete Audit Trail.

Dennis Kolva
Programming Director


64-Bit vs 32-Bit (June 8)

Apple recently announced plans for High Sierra, the next OS update, due in Fall 2017. It will continue to run 32-bit Carbon applications like Goldenseal, but the phase-out of 32-bit support starts next year. 32-bit apps will still run under the subsequent, yet-unnamed Fall 2018 update, but it will complain about them.  Starting in 2019, 32-bit apps probably won’t launch at all.

Goldenseal Pro uses Cocoa, which is 64-bit. It will run fine on current and future Mac OS versions. It looks like we will finish it well before Fall 2018, so there will be at least a year of cushion.

The current Goldenseal is 32-bit. It runs fine on the current Mac OS (Sierra), and will be OK with the next two after that, and anything older. But it will have problems with new hardware starting in Fall 2019.

It took until August 2016 for Microsoft Office to switch from 32-bit to 64-bit. Over the next couple years, we will see how many other Mac programs (e.g. QuickBooks Desktop) can build 64-bit versions in time. Going from OS 9 to OS X killed off about 75% of Mac software companies, and moving from PPC to Intel zapped another 10%. My guess is that the carnage this time will be similar. Converting from Carbon to Cocoa is not easy.

If you are confused by the meaning of 32-bit vs 64-bit, here is some background. 32-bit integers can handle any whole number from 0 to 4 billion, while 64-bit integers go up to 16,000,000,000,000,000,000 (16 quintillion).

For accounting, 4 billion pennies is $40 million, which is probably good enough for residential construction. However, some unit costs need fractional cents, some amounts are negative, and some countries use currencies with values much smaller than $1 US. That means 32-bit numbers are too small for estimates and accounting.

If starting today, we would probably use 64-bit numbers for money amounts. Even with fractional pennies, it is big enough to handle the entire global GDP. However, when we started Goldenseal, 64-bit integers were poorly supported, and memory was much tighter. As a result, we developed a CMoney class that uses 32-bits for dollars, and 16-bits for pennies and fractions (48-bits total, or 6 bytes). It took a few programmer-months to get CMoney working. Now that the code is reliable, there is little reason to change it (and it does save about 5% on file size). Maybe if hyperinflation hits or we run out of things to do in the version 7.0 update, we’ll make the switch.

The biggest impact of 32-bit vs 64-bit is in file addressing.  A 32-bit OS maxes out with 4 gigabyte files, while a 64-bit OS can have huuuge files.

As part of our database overhaul last year, we already converted to 64-bit addressing in Goldenseal Pro. It adds approximately 20 bytes per record, which makes files about 10% bigger. The change doesn’t mean much for Goldenseal users, who rarely need more than 100 megabytes (.1 gigabyte). However, we use the same database code for an app that stores genome data, and it definitely will help there. The human genome is 3 billion base pairs, or 750 megabytes compressed. Start doing comparative genomics, and it’s easy to get files in the terabytes.

Kilobytes = 1 thousand bytes. Megabytes = 1 million.  Gigabyte = 1 billion. Terabyte = 1 trillion.

Dennis Kolva
Programming Director


Goldenseal Pro Completion Estimate (May 31)

Since we develop estimating software, you’d think it would be easy for us to estimate the time it takes to build our own products. Unfortunately, that is rarely the case.

For one thing, software features are less tangible than roofing or cabinets, so it’s hard to turn them into unit costs. Also, most of our work is new invention and done only once, so past history doesn’t help much. It’s kind of like being a kitchen and bath remodeler, but calculating the cost to build a boat. App development is also a design-build process, and we often proceed without firm specs. It’s as if the only blueprints for the boat are ‘don’t sink’ and ‘catch fish’.

Years ago, Turtle Creek Carpentry had the same problem for construction estimates. We started by calculating actual costs on all past jobs, so we could make ‘comparison estimates’ for similar projects. The same approach ought to help for Goldenseal Pro. We just looked at our labor data, and calculated the following (all values in programmer-months):

Goldenseal first prototypes:  6 p-m
Goldenseal 1.0 (Mac): 108 p-m
Goldenseal 1.0 (Windows): 12 p-m (subbed)
Goldenseal 1.01 to 4.96 feature & bug fix updates: 72 p-m
Goldenseal Multi-User: 6 p-m (partly subbed)
Goldenseal OS 9 to OS X (Mac): 3 p-m
Goldenseal PPC to Intel (Mac): 2 p-m
Goldenseal Multi-User for Intel (Mac): 1.5 p-m (subbed)

Goldenseal 4.96 already has about 18 programmer-years of work in it.  It’s a fairly big app.

Based on the last three Mac updates, we seriously thought that going from Carbon to Cocoa (Mac) and from QuickTime to MFC (Windows) would only take a few months apiece.  Many subcontractors agreed, but we all turned out to be too optimistic. This update is harder.

My personal ‘gut feeling’ estimate was that Goldenseal Pro would be ready by late 2017, but it seemed worth pausing for some calculations, to get a more accurate prediction. The best way to estimate more accurately is ‘divide and conquer’: split projects into smaller bits, and calculate those individually. It’s the basic approach behind Goldenseal estimates. The strategy works well even if the data is imperfect, because errors tend to average out. ‘Divide and conquer’ is also a common approach for sorting algorithms, house cleaning, conquering Gaul, etc.

We divided past Goldenseal programming into 23 categories, then divided those into Goldenseal 1.0, updates from 1.0 to 4.96, and work so far on Goldenseal Pro. It involved a lot of guessing, but probably no worse than our first construction estimating spreadsheet (which became MacNail 1.0).

The most important numbers are the time spent so far on Goldenseal Pro. There has been 13 months of non-GUI work: replacing obsolete code, converting from 32-bit to 64-bit, rewriting the database, etc. The GUI  (graphic user interface) has taken 8.5 months so far, but a lot of that time was spent learning Objective-C, Cocoa and MFC.  It probably has been only 5 or 6 months of actual programming.

We divided that work into categories, estimated % completion for each, then calculated time remaining. Excel currently predicts 11.08 months until a final release, then another 4.75 months for loose ends like networking, app store listing and Custom Layouts.  It’s very guessy. The spreadsheet has predicted anywhere from 7 to 13 months, depending on the assumptions made.

Regardless of how long it takes, we are committed to finishing Goldenseal Pro.  We owe it to our long-term users, which includes our own staff! Switching our own businesses to another system would be almost as much work as finishing Goldenseal Pro. The software includes 7 or 8 programmer-years of well-tested C++ business logic that doesn’t need updating, and it’s worth leveraging that investment.

Dennis Kolva
Programming Director

Goldenseal 4.96 Released (May 24)

We just released the latest update to the current Goldenseal apps. If your download access is current, follow these steps to get it:

1. Go to our shopping cart.
2. Click the My Account link at top left.
3. Sign in with your Email address and the password you used to create the account.  The password is case-sensitive (capitals & lower case matter!).
4. Click the Completed Orders link.
5. Click the Download Files link, and save the download on your hard drive.
6. You may need to decompress the download file, if your browser doesn’t do that automatically.
7.  MACINTOSH– drag the Goldenseal program (tree icon) into your Applications folder. WINDOWS– run the installer.

If you paid for updates on or after Oct 1, 2014 and it tells you your access expired, please contact us. We will extend your update privileges.

Goldenseal 4.96 includes many small bug fixes, plus fixes for a couple of not-so-small bugs in the Find command, and range selections in Reports.

For our international users, we also added an alternate way to set the currency symbol (we also will add that feature to Goldenseal Pro).

The current Goldenseal code is growing old, as are the machines we use to build it. Our main focus is now on completing Goldenseal Pro, so this may be the last update we make to the current app. However, if a serious problem turns up, we will release another minor update.

Dennis Kolva
Programming Director


Goldenseal 4.96 (May 16)

We’ve taken a short break from work on Goldenseal Pro, to finish a minor update for the current version of Goldenseal. No new features, but it includes many small bug fixes written since the last update. It’s going through stress testing now, and will be released next week.

To build Goldenseal 4.96, we can’t use anything newer than Snow Leopard (10.6) for Mac, and Vista for Windows. In fact, the final part of the Windows build requires Windows XP or older. Fortunately, we were able to dust off enough ancient equipment (and rusty brain cells) to make it work.

Dennis Kolva
Programming Director