Addsum web site and general info

Postings here will focus mainly on Advanced Accounting software updates, tips, and related topics. They will also include general comments relating to troubleshooting PC/Windows/network problems and may also include reference to our other software products and projects including any of our various utilities, or to the TAS Premier programming language. We considered setting up separate blogs for different topics so that users/others could subscribe to topics mostly aligned with their interests, but decided that it would be better to keep things simple since some topics cross over into others. We would nonetheless welcome your feedback/input in this regard. Our web site URL is Call us at 800-648-6258 or 801-277-9240. We also maintain so that older Business Tools users in particular have a greater chance to find us.


We highly recommend that accounting software users "follow" this blog via e-mail (enter your address and click on Submit below) or subscribe to a feed (see also below) as a way to keep current on the latest updates and accounting software news and information. You may also want to whitelist this e-mail address:

Follow by e-mail

Thursday, May 14, 2015

Win 8: This app can't run on your PC

A somewhat strange and potentially misleading message can appear on the desktop of Windows 8 PC's:

This app can't run on your PC
(much less walk!)

Most users will probably know that "run" is the same as "execute" or "operate" or "invoke" or "launch."   So we do not quibble with that terminology per se.

Use of "app" is for those of us who have been developing software programs and software applications for decades is a little disconcerting, but is now the widely used lingo for anything and everything that runs on "smart technology" (whatever that is).  We would however never refer to our accounting software as an "app" no matter how hip that might be.  

But, besides use of the informal "can't" in the context of a relatively serious and disconcerting error message like this, our objection is that the problem could well relate to the fact that it is the operating system that cannot execute the program.  Thinking that it is the program's fault, or that of its software publisher, immediately leads to potentially errant conclusions, provoking the user to start reinstalling previously working programs in acts of futility, and making a bad problem worse.

If you receive a message like this the very first time you have ever tried to "run" a newly installed program under Windows 8, then, yes, it could relate to the fact that you have a 64-bit program trying to run under a 32-bit operating system version, or perhaps anti-virus software, user permissions or SmartScreen conspiring to block your program and not allow it to run, and potentially any number of other culprits.

But, if this message suddenly appears after programs have already been working (i.e. running), then in fact the problem could be the result of incomplete processing of Microsoft automatic updates (which is why we do NOT like to enable automatic updates).

The actual solution may be to return to a prior system restore point.   Or complete the unfinished updates.

This is all sounding eerily familiar.  Incomplete automatic update problems that lead to applications not being launchable is not a new problem.  We just have now a new unhelpful error message associated with that circumstance.

Another recent example of a problem caused by an automatic update that we wrote about:

Microsoft automatic security update causes font degradation

Problems associated with incomplete XP Pro updates were legendary.   The legend continues!

Thursday, May 7, 2015

The staying power of a 25-year old application development system

While we extensively used the TAS 3.0 system released in the late 1980's by Business Tools, Inc.  (the second printing of the manual was in March 1989, and which reached its prime in about 1991) back in that same era, in recent years we have had little reason to use it except in rare situations involving converting data from very old systems.    TAS 3.0's short dates were not Y2K compliant and most TAS 3.0 users had migrated their applications forward to newer versions long before the year 2000 for many reasons besides just the date issue.

Yet some users persisted, especially those that were highly customized and also for some that did not want to deal with changes that the Business Tools TAS 4.0 development system brought to the picture in 1993.

Users of some of these older systems (who chose to fight rather than switch) survived the year 2000 by customizing their systems to use "long dates."   A conceptually simple change, it nonetheless required making dictionary changes to every file descriptor (similar to a "table"),  changing every temporary defined date field to a long date size, then going through every data input screen and report form layout to make placement changes in order to fit the long dates and replace them with the newly permanent field and temporary field changed sizes,  and recompiling every affected program.  In short, a significant amount of work.

Both TAS 3.0 and 4.0 (and also 5.0 and 5.1) were 16-bit programs, yet they continued to run on every operating system that Microsoft came out with.  They survived the Win 95 "scare."  Then Win 98. Then NT. They kept on running on XP Pro (in fact, XP Pro was and is an extremely stable and reliable environment for these systems) after another scare that 16-bit programs were not going to function.  And they still will run innately on 32-bit Windows 7 including some very old components.

Nonetheless and despite the fact that TAS (and products written in TAS including Advanced Accounting) have long since been migrated into graphical, 32-bit worlds, we have found ourselves in 2015 consulting with several users who have extensive customized systems running on modern operating systems:  one case using TAS 3.0 (see screen shot below), and another that until very recently was still using a system developed with TAS 4.0.   And we have recently we have had to make some programming changes into these environments.  With the 3.0 system, we are making bug fixes to customized source code involving EDT source files (but not using the built-in TAS 3.0 editor) on an ongoing basis,  and with the 4.0 system dealing with converting the older program code to the newer TAS Premier 7i.

TAS 3.0 components still running on a modern system on a multi-user basis (May 7, 2015)

Predecessor products were actually released long before in the early 1980's, so the TAS development system has it roots that now go back well over 30 years.

And, even in 2015, rarely a day goes by where we don't still use in some context the TAS Professional 5.1 development system (first released by Business Tools, Inc. in August of 1996).

The longevity of these systems is truly remarkable, and largely unprecedented in the computer software industry.