The Curse of macOS Catalina strikes again as AccountEdge stays 32-bit The macOS Catalina bad news train kept on rolling this week as AccountEdge, friend of the Apple-using beancounters, threw in the towel over the forced migration of Macs to a 64-bit world. Mamut software, a UK tentacle of the Oslo-based Visma group broke the bad news to customers this week that Acclivity Software (the …
This is not Apple's fault.
This is the fault of a developer who found an excuse to shift customers to a subscription model.
The old price of AccountEdge was $300. So, about $100/yr for tiny/small businesses.
The subscription is $480/y for my one-person business.
My tiny business will use TinyBooks for accounting going forward. Not sophisticated, but will do the job.
I couldn't agree more. Apple have been making people aware since the advent of Intel on the mac that this day was coming.
"AccountEdge's 30-year-old codebase proved too outdated to establish compatibility with Apple's newest operating system"
Don't rely on unsupported libraries, which is what has likely happened.....
"It's already online whether you like it or not, that's how banking internet banking works."
No, it's not how it works. Your banking information is NOT your accounting information. Having Tesla's banking information could be very interesting, but having free reign to their accounting could mean vast profits buying and selling stock. It could also mean The Man warehousing that data and occasionally "Sharing" it with the tax mob. I found it very interesting in Ed Snowden's book that while he was working for a TLA, he also worked at Dell. How much would you like to bet that a few IT people working at Intuit are also employed by a government agency?
OK, but we don't want a repeat of the Y2K effort which was done so well that nobody noticed a problem. OK, there were some in the background that I know of, but we managed to avoid that iceberg so spectacularly well that people are now stating there never was one.
Thankfully we have at least Y2K2 already throwing some sand in the mechanics, and 2038 will give again an opportunity to show that we can, but only after it starts hiccuping and sales and/or accounts gets the blame*.
* Sorry, channeling BOFH for a moment :)
This post has been deleted by its author
If you think that I don't think I'm going out on a limb to assume you were not involved in anything critical then.
There were some truly spectacular problems that emerged when we started checking through it all, from industrial PLCs that would just freeze in an indeterminate state to telecommunication switches that would go nuts on rollover. Granted, that last one was telex bu you'd be surprised how much telex was still in use then (mainly because a delivered telex, thanks to the shipping industry, actually has a legal status)..
Even at the BBC some people had to put in some on-the-fly fixing to keep things up at midnight. It was far less than when nobody had gone through the trouble of addressing what was found already, but it wasn't as hitch free as people with only hindsight appear to assume.
This post has been deleted by its author
Sounds to me like they had pretty much stopped making any changes to the software other than maybe regulatory rules (i.e. new laws that change how accounting works) and have been found out.
For well written software it is just a recompile and some extensive testing. For a "30 year old codebase" that I guess is a spaghetti monster of hacks dating from the MacOS System 7 days I suppose it would be more involved. But I wouldn't want to trust my business to such crap code when there were better alternatives available. It would be like someone running Netware in 2020.
Not only hacks, it may well be the "lead developer" (or whatever the person who knew stuff was called) cashed-in/was let go//left, and that the marketing and bean counter droids just drove the company with enough technical input from a couple of junior "programmers" to paper over the cracks and do routine updates.
Disclaimer: A long time ago I designed and wrote specialist technical/financial/business software, and now look a lot like this >>====>
It can often be very difficult, if you have an old, legacy codebase. Chances are it isn't even written in Object C or Swift, it is probably written in COBOL, Lightspeed Pascal or something similar, with a bunch of kludges to keep it running on PowerPC OS X and then on Intel.
I've seen code written in the 90s that was just patched together. It was so wonky that the company was selling complete systems in 2015 based on a version of SUSE from 1999/2000, because the code "just about worked" and the programmers were too scared to address the issue of porting it to a more modern version of Linux. In the end, the lack of RAID drivers for modern hardware for the old SUSE forced them to address the problem, but it took a lot of effort and they had to put a freeze of new features and customer requests for over 2 years, because the whole programming staff was busy converting the system to the new version.
One of the biggest problems was that some of the code was bought-in from a company that went bankrupt in 1996, so there was no expertise for it and no real way to port it to something newer.
Without knowing the background, it is impossible to say if they were just dragging their feet or whether dropping the product completely is the more economical solution. From a user perspective, it is a crap situation, but I've seen enough old systems kept crawling along to not condemn them out of hand.
If they have to invest 3 - 5 years of development to get a replacement up to the feature specification of the old software, that is 3 - 5 years where you either need twice as many programmers or you cannot support and extend your old system (E.g. with changes in tax law), whilst the new system is being developed.
Why should I become a customer of a company that is doing that for a production relevant software (my production, running my business)?
They do not maintain their product properly. They do not announce on time that they're not going forward, leaving me with time to spare to find an alternative. Why should I be, or continue to be, their customer? It seems that there are alternatives.
Exactly.
I was just replying to the fact that people think it is just a simple case of recompiling for 64-bit. There are lots of reasons why it isn't that simple.
That the company didn't provide information in a timely manner to avoid this is a totally different matter. And how they have handled that stinks.
Gosh, if that was an OS you were describing there, you'd be describing SCO Unix.
All its compatibility problems with modern hardware are now addressed by it being only sold to run in a VM.
A VM running in FreeBSD, if you get the whole shebang from XinuOS. Now headquartered in that hotbed of technical advancement, US Virgin Islands.
AccountEdge is pretty much feature comparable to QuickBooks although I've always preferred their UI over QB. I've never had any serious issues, so as a long time user I wouldn't call their product crap.
It's no problem for me to keep using Accountedge. I have a couple of MacPros that won't run Catalina that I can use to keep the accounting going. I also have a MacMini taped to the underside of the desk for odd jobs that can host my accounting. They've let me know they'll swap my Mac license for a Windows one if I like or I can add an older Mac install to Fusion.
I think that some of the problem may have been that a complete rewrite wasn't in the budget due to a limited installed base. QB is the market leader. I just think their UI sucks and they are more concerned with "features" they can charge extra for than adding functionality that's useful.
You really can't say that they didn't give enough notice.
It's not just the ability to compile to x86_64 but also the changes in the APIs, which have been extensive over the last few years. I have quite a lot of software that will not run on Catalina and don't expect to use it as a result. But this is fine by me: I don't have any iThingies, don't use any of Apple's online services so the walled garden of convergence holds no appeal for me.
This approach, which punishes the user, is actually untypical for Apple. The shift from PowerPC to Intel was handled much better, but there remains a fundamental problem with the value proposition: porting costs money and on its own brings no discernible beneift.
If I read the article correctly, the program was originally written for MacOS and *NOT* OS/X.
There seems to be a significant difference between the two from the software side. So I expect that it has _LESS_ to do with 32-bit vs 64-bit, and MORE to do with a lack of a backwards compatibility later for MacOS API calls... (or did I miss the point here?)
Something like this would require a MAJOR re-write. Basically it would be a "start from scratch using the old code as a guide" effort. This might explain things better...
My opinion: If you're going to do THAT, re-write it using GTK and make it available for ALL platforms, from Apple to Linux and even Windows.
And THAT would be a GOOD thing! [Just don't make it 2D FLATSO like Firefox with Australis and Chrome - too much of THAT crap out there already]
Sounds like old MacOS version 7-9 code was brought over via the old Carbon API, which kind-of-mostly made OSX look like Old School MacOS. Carbon was 32 bit only and never upgraded. To be fair, it was trying to emulate baggage brought forward from the Motorola 68000 days (pre-mid-nineties) so it might have been a beast of a job. Ints are easy, pointers aren't.
Anyway, Adobe got hit by 32-bit-only Carbon some years ago. And you're right - Carbon to Cocoa is basically a rewrite of the GUI and a good time to see how well you isolated algorithms from UI. :-)
Something like this would require a MAJOR re-write.
I dunno. How many OS API calls does an accounting package make? I'd have thought that most if not all of what it wanted to do could be done through the RTL of whatever language it is built from and a handful of third party libraries.
I've done such ports before - from 8 bit DOS to 16 bit Windows then to 32 bit Windows. None of them were particularly onerous. We just upgraded to the appropriate (Borland) C++ compiler and fixed up the errors. The only real gotcha to be wary of was the 'int' type but that was rarely a problem. Typically it just meant upgrading some const MAX_XXX value but you also had to be careful if you were persisted ints (we didn't normally - we'd persist a WORD or QWORD).
So my assumption here is that either they are building their software using old, unsupported tools (naughty). Or are just trying to move people to an alternative service (naughty).
Moving to a platform with a wider 'bitness' is not particularly difficult for a competent development team.
> How many OS API calls does an accounting package make?
A GUI package? It will be built almost entirely on them.
> The only real gotcha to be wary of was the 'int' type
Not usually an issue. The thing that breaks everything is the pointer size change, and assumptions that it was the same width as a particular integer type.
You hit it on the head, Bob. They have offered to swap a Mac License for a Windows license and the data files are cross compatible so there are options and people aren't left in the cold. It's also the start of a new year so users that base their accounting on a calendar year can swap to something else without a massive amount of re-entering stuff. It's also possible to run old versions of OSX under emulation via Fusion. Speed isn't generally an issue with accounting software. If it takes another 20 seconds to compile a report under emulation, people won't die. In the mean time, plans can be made.
Sorry, reg.
This is not entirely Apple’s fault . Apple have been telling developers for several years now that they were removing 32 bit support. As a Mac user , I’ve been getting messages every time I launch a 32 bit app for several years now, and as a developer, I have had multiple emails from Apple.
In this case, the developer has failed (whether by choice or another reason) to put the resources required to update the software into updating that software. The fault likely lies with the bean counters at the software company, not Apple.
Well, indeed Apple has shown many signs that it takes users of software not serious, and focusses chiefly on media consumption. Primarily from its own services.
So the blame is on the Apple users still trying while the writing has been on the wall for a decade, while Apple is laughing all the way to the bank.
Yes and no. Apple are removing legacy interfaces, this is something Apple does regularly. It is what makes Windows such a monolithic system and more than its fair share of security problems, because Microsoft are very slow to remove legacy, if at all.
In this case, it is a problem with the software developer, because Apple are removing old interfaces that they no longer want to support - without regard as to whether it is at all feasible or economical for their developers to go with them.
The developer should have seen this coming and should have warned its user earlier. But, having worked with legacy systems, I can understand that it might not be feasible to modernise such an old codebase and that the only option would be a complete re-write, which on 30 years worth of code, isn't going to happen over night. You are going to need to freeze the current system for several years (no new features, no bug fixes, no compliance updates), whilst your developers work on replicating everything you had - and hoping that they haven't overlooked some kludge in the old code, so that the new code comes up with the same answers!
"without regard as to whether it is at all feasible or economical for their developers to go with them."
That's a big deal and Timmy doesn't seem to be as mindful as Steve. Lose somebody like Adobe or even just a couple of their main applications and lots of people will finally write off having Macs and make the painful switch to Windows/Linux.
I find Apple these days to be concentrating too much on the iPhone and not paying enough attention to computing and new products (that aren't iPhones). There really isn't much under the sun new with mobiles. There is only so much usefulness in a device with a tiny little screen and terrible input functionality. Make it thinner? How does that help me? I'm not a fan of reduced battery life. Double the thickness I say and give me days of use between charges. Bring back the function keys you Func. Put the ruddy touchbar on the consumer laptop and give me RAM slots I can stuff stupid amounts of memory in without having to visit the "Genius Bar" to have installed.
I'm sure Apple will miss you. Not.
Frankly, I've had so many warning that 64bit was coming (aka using the full resources of the system instead of limping along with kludges and shims) that I had been looking for a way to disable them.
If Apple had done this overnight, sure, but they have given more than proper notice, offered a transition phase in which you could port to 64bit and still fall back on 32 if you screwed up first time around, and now it is time to shut it down and remove it from the code base. This is also why MacOS in itself is quite tight and less exposed to legacy problems.
In a way, such a transition is a good test of your vendors: if they can't go along with this in that timeframe, I'd start worrying about their code and the sort of maintenance they can still perform on it. As far as I can tell, AccountEdge has been discovered not to be that much on the Edge after all..
Removing IA32 support has nothing to do with "using the full resources of the system" - that support is fully baked into long mode(AKA 64-bit mode) by design. It also doesn't improve security unless you really, really want to count ASLR. At most it saves Apple from compiling two versions of their libraries and having two versions of their system calls; there's no actual benefit to the user.
It has nothing to do with Apple (a company that I personally would like to see bankrupt and left for the crows to pick on unfortunately this is not very likely in the foreseeable future.) screaming about support for 32 bit being removed for however long making them somehow not responsible.
They are fully responsible for most issues caused by this as there's no "good" reason they couldn't have kept the 32 bit API as Microsoft have, they didn't want to keep 32 bit support because some beancounter decided that it's not cost efficient and thus forcing people to either stay on an old os version or in the best case scenario buy new versions of software if it's even available if they have legacy software they need.
If you think it realistic that all or even most legacy code can be changed without massive investments of time even if the codebase itself is fairly well maintained you are deluding yourself. making fundamental changes like this requires massive amounts of work rewriting what is likely to be core functionality and in turn requiring changes in other parts of the system and so on. Once you have a barely working system comes the fun part of near infinite iterations of testing and fixing just to get back to an apparently working system.
In the case of some critical software it will simply be better sense to just drop it like in this case as the amount of trouble you may get in from a bug you didn't find combines with the years of work needed far outweighs any future sales you may have.
To me this is nothing but another sign to stay away from apples overpriced garbage.
Now let the down votes rain...
And the software for my printer and scanner? Apple seems to want us on I-Phone refresh cycles for everything… Again, whatever you think of the merits of the approach and of the relevant developers, it's customers who're actually getting punished.
I'm sure Apple will miss you. Not.
Yes, because I'm the only person who's pissed off at this kind of behaviour. Look through history at how well companies have done with this kind of approach. A 32-bit VM would have been a cheap and easy way to solve this for everyone.
Why does your printer and scanner require specific software?
I have a LaserJet 4200 which wikipedia tells me is from 2002, it still works perfectly with pretty much anything. It supports Postscript and PCL so i can print from the very latest systems (catalina has no problem), and even from vintage unix boxes or amigaos.
There's nothing to stop you running a 32bit vm either...
I updated to Catalina when it came out and everything just continued working. Apple has had 64bit support since the first port to x86 (even 10.4 could run 64bit cli tools) and even 64bit PPC support before that, it's not like the removal of 32bit is a surprise to anyone.
Many vendors updated their mac apps to 64bit years ago, so they just continue working if you update to catalina and users don't notice a thing.
The problem is those who just keep kicking the can down the road until it becomes a major problem and then panic leaving users in the lurch instead of a smooth migration, the same thing that's currently happening with ipv6 deployment. Behaving like this shows contempt for your customers, so i wouldnt want to use software supplied by such a vendor.
Why does your printer and scanner require specific software?
I'm not sure if it requires it. It certainly comes with it and it won't work with Catalina. I think I bought it in 2013 and replacement cycles for printers are much longer than for PCs.
Again, this isn't really about going 64-bit (Apple fumbled the transition in Snow Leopard but has since been fairly consistent) but about APIs that Apple wants to remove.
Many vendors updated their mac apps to 64bit years ago, so they just continue working if you update to catalina and users don't notice a thing.
And some didn't and users are being punished (by Apple) as a result.
I have been getting messages for years about upgrading to a new version of Adobe Acrobat Pro.
I've only done it because Catalina said "NO", and I need the bloody thing once a month.
These guys are developers, I buy software for a living and I understand their pain, but seriously, siting on your arse for thirty years?
At some stage you've got to upgrade your code, launch something new if it's too much work, or just retire. Looks like they chose option 3.
I have to say I was wondering the same thing. If this was a device driver or something else that would need to give a rat's arse about the size of pointers and suchlike, I have a hard time coming up with a rationale for accounting software to really care that much to take multiple years to "port".
Their code must be pretty awful.
I have a hard time coming up with a rationale for accounting software to really care that much to take multiple years to "port"
The main issue is probably the data files. Accounting software is quite likely to have a reasonable amount of data that it still has to be able to access. Also, software written that long ago was running on hardware with much less memory and storage available, so it much more likely to be using binary file formats designed for compactness and memory efficency rather than ease of porting.
I'm currently working on a piece of software of a similar age, and whilst the codebase is suprisingly well written it is most definatly not 64bit. Converting the software to 64 bit would just be a recompile in a more modern version of the IDE, however then ensuring that all the data files it relies on, full of packed records that are basically just in memory structures dumped to disk, would be a nightmare.
Doing this with financial data; data that probably has to be correct and has regulatory issues regarding it's quality would not be a task I'd like to undertake lightly. It only takes one customer with a corrupted accounts system to give you a load of grief.
Combining that with most managers aversion to 'risk' when it comes to work that has no new feature benefit and I can understand how it's happened.
They still have had enough warning though.
There is an AppStore for Mac, but it isn't the only way to deliver Mac application software. Personally speaking, I only use the AppStore if it's the only delivery mechanism for a particular application. Otherwise, I get software elsewhere and it doesn't need Apple's approval.
I have a mix of both, but the only unreliable bit about the App Store that I have come across is that old apps which indeed would no longer work or lack support are still allowed to hang around, and their age is not very well indicated.
Apple is very good at quickly refunding such and then also cleaning it up, but my main driver to buy direct from companies I trust -important caveat- is because I know that Apple takes a good 30% for the privilege to be in the App Store, and I personally think that's about twice as much as it should be. In addition, Apple has made some choices that I understand from a risk management perspective (such as not allowing apps direct access to certain system resources), but in some cases that gets in the way, and I deem myself moderately capable of doing my own risk assessment ("moderately" because that assertion is a risk in itself :) ).
Thus, by going direct I know I'm giving the software authors more, such as Serif's Affinity (I have all of their apps by now :) ), OmniGroup's OmniGraffle and an annual payment to the NeoOffice guys. Worth it.
It's also very expensive for developers; and app store rules mean that products from that channel are often feature-limited vs their direct-install counterparts. The Windows app store has many of the same issues, and it sucks too.
I'll use the Mac or Windows App Store if it's the only place something is available, but neither is my first choice for finding software.
"There is an AppStore for Mac, but it isn't the only way to deliver Mac application software. Personally speaking, I only use the AppStore if it's the only delivery mechanism for a particular application. Otherwise, I get software elsewhere and it doesn't need Apple's approval."
MMM, true for now.
Until Apple decides users are to much of a danger to apple that they only allow "appstore"
and that solves the problem of Lusers avoiding the apple 30% tax
Enjoy your freedom whle it lasts, personally I'd rather chew glass than buy anything from apple.
There are a lot of deprecated APIs that have also stopped working.
Not all of them have working replacements, and very few of them have replacements with identical functionality.
If they've not been given the three or four oodles of time each year to migrate during the last 10 years or so, then they're now suddenly having to migrate everything at once.
While also making the changes they need to make every year to retain that HMRC compliance thingy that the business is 100% reliant on and has thus been their primary focus over said decade.
Which is a testing nightmare.
Couple that with a small user base and legal consequences for bugs, and the business case for bothering vanishes.
There's code. There's OSes. In-between there's the APIs. Ooodles and boodles of APIs. Wanna bet the brick wall is making the latest APIs somehow meet the expectations of 30-year-old code, without rewriting the app?
Aluvasudden training yourself up on the last 3 decades of API changes may have exceeded the developer's abilities. Realizing the actual need is to rewrite the app may have exceeded management's tolerances.
But an accounting package has no business making direct use of OS APIs. It should be possible to write an accounting package sticking to functions provided by the language RTL and third party libraries.
The business logic (where the value lies) should be platform independent.
The RTL wont change much and third party libraries aren't usually radically different even if you are forced to change to a different one.
The code might have been pretty good when it was new. It's just it was new 25 years ago. And machines were rather more limited back then - getting things to work at all, could be an achievement. (And unit tests were for pussies. ;-)
I was looking at some of my old code the other day and wondering "Why did I write it like that? Or like that?" And then it dawned on me: the APIs I'd use now didn't exist back then. In retrospect, what it did was pretty impressive. But the limits of technology were stretched and trying to disentangle it is a pain. And newer code using newer APIs has been added along side it, without anybody updating the old code so there are now multiple systems.
TL;DR it's probably bloody awful and needs a scratch rewrite.
again, I don't think it's the "bit-ness" in this case. I would expect that this 30 year old code was written for the MacOS APIs and is effectively incompatible with OS/X APIs. As such, the "32-bit" code (which would be for older MacOS APIs) would have to be re-done to use the OS/X APis instead.
I'm not familiar enough with OS/X coding to really know for a fact, but I suspect it's NOT a trivial thing. That being said, a re-write is apparently in order. And like I mentioned before, if you're going to have to re-write, use GTK or maybe even Java, so that it becomes cross-platform, so that the market goes beyond "just OS/X" and covers every OTHER operating system, too.
"porting code from 32bit to 64bit should be straightforward"
assuming the APIs haven't changed. But this was MacOS 32-bit vs OS/X 64-bit, most likely. That wouldn't be trivial (not the way I understand it, anyway)
It has to do with the way the old MacOS windowing and menus and other OS APIs work. I looked into it once. I understand that OS/X was a MAJOR change to how this worked, hence the compatibility layer.
Libraries can be replaced, perhaps with shim layers. Compilers can be changed. Compiler options can be switched. This is not rocket science, but...
If you have a decent test suite, ideally automated, then you can port gradually and you can be releasing the semi-ported version and the porting work can proceed in parallel with the normal product evolution.
If you don't have a decent test suite then you have to do the port as a Big-Bang change and you have to execute that change quickly enough that Sales and Marketing don't lose patience and insist on "briefly" going back to the old code, making some "minor changes" and releasing a new version. Every time they do that, your goal-posts have moved and it will take longer to complete the porting project. You don't need many such changes, drip-feeding in, before the porting project becomes essentially impossible because the old codebase is evolving faster than the port is progressing.
So my guess is that anyone who says they *can't* do a 64-bit port probably doesn't have a decent test regime.
32 to 64 bits: Depends on how stupid you were. Storing pointers in 32 bit integers is a good one to bite you. Writing 32 bit structs to a file and hoping that you can read them back as 64 bit will be a pain.
Any bit I write know easily works as 32 bit and 64 bit because I know the problems, 30 years ago that was different.
That said, it’s all just a bit of pain, no real problem. Now if you have a 32 bit binary library from a broke third party developer and can’t get the source code, _that’s_ a problem.
Obviously Apple could do this, but maintaining backward compatibility with ancient versions of an OS is a pain. Forcing a switch to 64 bit means Apple can bin their old APIs once and for all.
Also, they may be right to be suspicious of unmaintained software. 30 year old and no one employed to patch security issues, etc?
Or 30 years of features being added and maintaining compliance with a crazy, ever-changing set of tax rules, sat on top of a pretty stable and generally working base that's more or less only had feature and security fixes
It's quite rare for developers to get time to pay down technical debt, because the payoff is usually long after the product managers have left the company.
"Obviously Apple could do this, but maintaining backward compatibility with ancient versions of an OS is a pain"
ah, so they're pushing that pain on their users and developers. And this from a company having zig-billions in off-shore bank-accounts through dubious business practices. I hope you won't mind if I'm not impressed.
sudo softwareupdate --ignore "macOS Catalina"
"Obviously Apple could do this, but maintaining backward compatibility with ancient versions of an OS is a pain. Forcing a switch to 64 bit means Apple can bin their old APIs once and for all."
Apple don't care about keeping backward compatibility, because that might get in the way of making even more profits.
"Personally, I'm confused why we can't have 32, 16 and 8bit software running"
Generally it's to do with efficiency. 64 bit processors can physically run 32bit applications, but it requires the OS to contain (and maintain) mountains of code to allow cross-compatibility. There are also some security reasons for going 64bit - address space randomisation for example is an anti-hacking method which is an order of magnitude more effective on 64bit than 32bit.
Apple made a business decision not to support legacy 32bit applications for a number of reasons including the above, plus the fact that unlike Windows, there is no massive 32bit device base out there which they need to maintain. A lot of ATMs, billboards and industrial control systems run on WinEmbedded and cannot be upgraded, only replaced; which means Microsoft are obliged to support 32bit for at least the next few years. Apple doesn't have this problem.
To come back to the point of the article, the fact that Apple has pulled 32bit support is not unexpected. As a number of commentards above have pointed out, they have given developers years to port apps to 64bit, and this is rarely rocket science - as long as your app is well written. The fact that new Macs will not run this particular accounting package is a developer issue not an Apple issue, and the author is being slightly melodramatic considering there are many good accounting packages out there which DO run on Mac. If a business really truly desperately needs THIS package, they can run MacOS Mojave in a virtual machine, and run it on that. It'll run quite well too.
You are assuming that the changes made year-by-year can be expressed as changes of parameters to a fixed algorithm. I very much doubt whether governments would even understand the sentence I've just written, let alone take the trouble to constrain themselves in that way. It is probably more likely that you change the code but keep the parameters the same!
Yes, and changes to the tax code usually mean you have to collect different information about transactions to previously. Usually more detail, sometimes less.
British Sage for example still has separate account codes for UK and Overseas Entertainment even though that has been treated the same for tax purposes for about 30+ years.
Remember when all those MacOS Classic applications that disappeared in the late '90's because Carbon was almost but not quite compatible? There was no technical reason, just that there was no one left at Apple who actually knew how the OS codebase really worked. For real world applications. The Nexties had driven them all out. So the Mac ceased to be the second viable platform for small / medium size I.S.V's. Because they did the revenue numbers and the cost of a major rewrite was far greater than any likely revenue return. So they became Win32 houses. Or went out of business.
Then Carbon was broken by MacOS X 10.5 when Apple began arbitrarily breaking Carbon API calls. Again no good technical reason. It was to try to force developer to use Cocoa and Object C, which had very low take up. For very good technical and business reasons. But the Nexties at Apple were intent at forcing it down the throats of developers. Net result over the next few releases was the end of life of a lot more MacOS applications. For those who had to support cross platform codebases QT was usually the only pragmatic solution for supporting MacOS. Which was now a fringe revenue product even for MacOS original titles going back to the early years.
And now we have the 64 bit forced obsolesce. Again no viable technical reason. Unless you are caching long segments of hidef video for VFX/Compositing/NLE you aint going to use 64 address space or offsets for real world software. Ever. Very specialized math applications are a zero market share segment. Saying this as someone who started shipping commercial software for the Mac written in 68k ASM back in the days we had 24bit addressing in MacOS...
So a whole bunch more of useful end user software has now been deliberately obsoleted by Apple. For no very good reason. But the software obsoleted will not be rewritten for a very good reason. Because the cost of rewriting is far greater than any plausible future net revenue from the product. I've been telling potential clients this simple fact of life for the last twenty plus years. Which is why almost all porting project over the last 20 years have been off MacOS. To Windows. In the previous 10 it was almost all in the opposite direction.
Because despite what more recent fanboys may think the MacOS hardware market share is still pretty much where it was 25 years ago. But its software revenue market share was at best maybe half and now much closer to a third and less of what it was back then. So the only product codebases that have any serious MacOS work done on them now by ISV's are those with large enough installed bases and very strong user lockin. The rest have all pretty much died. At least on MacOS X. Because it was a waste of money. Better to spend your dev budget on a platform that might have reasonable revenue potential return.
"And now we have the 64 bit forced obsolesce. Again no viable technical reason."
And I'm sure we could find the same arguement for 32bit and 16bit all those years ago.
How about memory space for starters?
Multiple applications?
Chrome wih JavaScripts enabled? Just kidding on the last one....we know Quantum computers are required for that.
If you had worked on real world *shipping* MacOS end use application code bases (my last one shipped 600K plus on all platforms) you would known that none of these actually apply to t real world application codebase. The only MacOS application code base I have ever seen and worked on over last four decades ( generated probably $50M plus in revenue over its lifetime) that might possibly need data address offsets greater than 2^32 was a high end VFX video compositing app. And at the time no one could afford 4G of RAM. And bigger than 2^32 data segments was a bad way of dealing with the data anyway. In the end the MacOS product was killed and it was Win32 only. So 64 bit native on MacOS was now purely academic.
For single application execution address space 64 bit native addressing is irrelevant for all plausible MacOS commercial codebases. Its just not a big or deep market. There is no technical reason why single instance 32 bit address spaces applications cannot be run on 64 bit OS's in 32bit processes. The application process can have more than 2^32 K of memory page allocated to it but the actual executable is still 32 bit native. If all memory pointers are returned from malloc() and all offsets are unsigned longs the application can run happily in 64 bit flat memory space. This assumes that Apple are doing everything straight simple x64 and not doing any of the x86 segment juggling stupidity that Intel tried when going to 64 bit originally. The rule is read the AMD docs and do it that way.
To indicate just how irrelevant 64 bit addressing is for real world desktop applications I had to write a linker for a compiler for a very verbose language that had to deal with large many MLOC size codebases. Even in the worse case symbol table scenario, where absolutely every symbol in the complete software stack had to be available for global scope linkage, when you did the numbers 32 bit symbol table offsets was more than adequate. Even when future proofing the code.
So 32 bit native addressing for a single process instance will suffice for quite a long time. At least for desktop applications. Whereas 16 bit offsets was a big problem even back in early 8 bit days. I did my first 16 bit offset limit work around on a 6502. Thats how long ago. Back then the wide open 32 bit flat addressing space of the 68000 was like heaven. Whereas over on the 8088, they were still banging rocks together. And in many ways, still are. x64 still does not have proper orthogonal PC relative addressing. Just the RIP. Better than nothing I suppose. Which is what we had for 20 years..
"There is no technical reason why single instance 32 bit address spaces applications cannot be run on 64 bit OS's in 32bit processes. "
Nobody's disagreeing with you. Yes it's possible, it just doesn't make sense from a business perspective. Amongst other reasons, including the 32bit codebase represents a huge increase in attack surface - which is a solid enough reason all by itself to ditch it.
And thus many, many software companies will drop macOS because Apple have ensured that supporting it doesn't make any sense from a business perspective.
Apple have deliberately made it extremely expensive to maintain Mac applications - Catalina is a true cliff to climb, it's even worse than the change to x86.
The blame is thus on Apple, and only Apple.
"So you agree...." words designed to imply someone's been caught out and has had to accept righteous justice; except this was never an issue, much less denied. Of course they're doing it to save money; as a component of optimising their ratio of cost to benefit. That's Basic Business 101 for Dummies.
Software companies dropping MacOS because of this are those that MUST continue to support 32bit; either because there's a legitimate business requirement such as a major product containing embedded code, or because their code is too crappily written to make porting viable. In which case they will either succeed as a bespoke company, or they will fail; either way not Apple's problem. Whether Apple's decision is right or wrong will be determined by their bottom line; if dropping 32bit means they lose money over time then it was the wrong decision, if dropping it means they make money (by saving costs, improving efficiency and strengthening security) then it was the right decision.
As of today, there are 1.397 trillion reasons pointing to Apple making on balance right decisions - that's 1.397 trillion reasons why they probably won't care too much about your 'blame' jibe.
Probably because the entire point of an operating system is to hide hardware and software platform differences from the application, to make applications easier to develop.
When an OS deliberately makes it more difficult to develop for, it is basically inexcusable.
” When an OS deliberately makes it more difficult to develop for, it is basically inexcusable.“
There’s a cost involved in maintaining a codebase. When the ratio of cost to benefit exceeds what the company can accept, they will stop supporting it.
Apple stopped supporting Flash because it was buggy, insecure and superceded by better technology. This made life more difficult for Flash developers, but it was unquestionably the right move for Apple, their customers and the industry in general. Are you arguing they should have poured billions away over the years to continue to support this security nightmare because to do otherwise would have been ‘inexcusable’? And if not, what’s the difference in your view?
And now we have the 64 bit forced obsolesce. Again no viable technical reason.
As noted elsewhere, address layout randomization is a *lot* more useful in a 64-bit virtual address space. That means it's a lot harder to exploit 64-bit buffer overruns.
Better to spend your dev budget on a platform that might have reasonable revenue potential return
The key reason that quite a lot of companies switch to MacOS has less to do with keeping legacies alive, but because they have started to add up man hours. MacOS tends to be less costly in man hours to use and maintain because (a) usability (although I noticed that especially iOS 13 is IMHO now edging towards Microsoft's fetish with features at the cost of substantial usability) and (b) far lower downtime keeping it patched and up to date, and by that I include the lack of random "I am shutting down now and updating while you're in the middle of a presentation" events that Windows is still famous for. I've had a telecoms engineer in the office for an hour (not billed to us, but it would be churlish to not give him a cup of coffee and a seat), because on shutdown his laptop decided not to do so and run its updates instead, leaving the user a choice of forcing a shutdown and risk nuking the platform or suffer through it yet again.
Man hours cost a lot of money, and the moment you start adding those to your TCO you will find that MacOS and its associated hardware is actually a lot cheaper, at least right now - and that's without mentioning automatically included global hardware support, something you pay a fortune for with others.
Does this make me a fanboy? No, simply someone who can count.
64 bit and 32 bit assembly instructions are by their nature separate and while Intel currently support both in x86 this isn't a given forever and Itanium was only ever 64 bit from the start. Intel dumped full 16 bit support from x86 a while back and eventually they'll dump 32 bit support too because there is a non zero cost both in production and usage to maintain it.
And where is Itanium now?
It was an abject commercial failure, because even hyperscale customers still have a few 32bit applications. Intel only kept making it because of contracts with HPE.
If you drop support for X while some customers are still using X, you lose those customers unless you can sweeten the deal.
Moves to a new platform - or even new compiler - are expensive and risky, and so will only be done if there is a likely commercial return. So unless Apple are going to pay small developers to transition, many will not because it'll just cost too much.
Actually AMD dropped first the Virtual86 mode in 64 bit mode because AMD doesn't know how to design an advanced chip.
It also dropped the segmentation model which will need to return if we warn really secure applications at the hardware level and not address spaces where everything is writable and executable, and just a mapping bit isolate kernel from user space.
But AMD can see only "performance, performance!" (and Intel followed, with the Spectre/Meltdown bugs) and so removes any feature to truly isolate applications and kernel.
Actually AMD dropped first the Virtual86 mode in 64 bit mode because AMD doesn't know how to design an advanced chip.
What are you on about? It was dropped in 64 bit mode as it was an opportunity to remove legacy cruft. Virtual86 mode was/is still available in 32bit mode. The silicone is there.
Also, what do you mean AMD doesn't know how to design an advanced chip? The designer of the AMD 64 bit stuff was one Jim Keller, who's previous work included the DEC Alpha. You know, that 64bit chip that was one of the most powerful in it's day?
It also dropped the segmentation model which will need to return if we warn really secure applications at the hardware level and not address spaces where everything is writable and executable,
Unless you set the 'not writable' or 'no execute' bits, both of which are enforeced in hardware.
But AMD can see only "performance, performance!" (and Intel followed, with the Spectre/Meltdown bugs) and so removes any feature to truly isolate applications and kernel.
Eh? Intels first superscaler CPU with cache was the Pentium Pro, in the mid 90s. Spectre/Meltdown was a side effect of this design decision that took YEARS to be discovered, please don't pretend like it's an obvious issue that should've been spotted at the design stage, it wasn't. It was also nothing to do with AMD. (AMD were still making mediocre 486 clones when the PPro was designed).
64 bit and 32 bit assembly instructions are by their nature separate and while Intel currently support both in x86 this isn't a given forever
True, but not really an issue.
Remember how Macs were originally 68000 family processors ? Then Apple went to PowerPC and 68k programs (mostly) still ran ? Well Apple managed that by being in the group making PowerPC and putting 68k emulation modes in the processor.
Then they went Intel and PowerPC stuff still ran. In this case, they employed software (QuickTransit) from a Manchester based outfit (I interviewed for a job there once - had to sign an NDA before they'd talk about the job) which did "real time translation" to run PowerPC code on an Intel chip. I see that outfit got borged by IBM some years back.
So from a technical PoV, if Apple wanted to, the technology exists to run 32bit code on a 64bit system without processor support. But as others have pointed out, there's not really any incentive to do that. Apart from the fact that there's no need as Intel still provides 32/64bit chips, they've done what they've done before - keep supporting the legacy processor/whatever for several OS versions and warn everyone to update. Mostly that's worked fine - with a space of "some years" people have been able to upgrade/replace software so that when the old feature is dropped, most don't have a major problem.
That doesn't stop it being really, really, REALLY flipping annoying when you are reliant on a feature (such as sync services) and it "just disappears" with little fanfare in an OS update. I still haven't found a replacement for some features of software I used to use that relied on it.
but it requires the OS to contain (and maintain) mountains of code to allow cross-compatibility.
For x86 and x86_64? Not really. It's always more work for the application developer. But this is really more about Apple's fairly rapid turnover of APIs in the last few years and it tries to force MacOS into an IOS corset.
You'd think there could be some sort of API layer to separate the crufty old bits out, and run them under a specialized application. The Codeweavers folks could do it, call it "MINE" (you know, like WINE but for Mac).
It's the same sort of idea I've thought Microsoft could do; purge out the ancient APIs, open-source those bits and then bring them into Wine. At which point MSWin would just incorporate Wine as a compatibility layer.
There are two reasons: One, if you want to be able to run say 64 bit and 32 bit software, you have to maintain both. Which costs Apple time and money. Two, if you run both 64 bit and 32 bit software at the same time, you will need 64 bit libraries and 32 bit libraries in memory at the same time, which makes the user's computer slower. Basically the last 32 bit application is really expensive.
Now on the iOS side of things, newish iPhones have processors that are not even capable of running 32 bit code - which makes them simpler, cheaper, and faster. On the macOS side, every Mac since around 2007 or so has been capable of running 64 bit code, so there isn't much excuse.
Now I must say that I would really love to know what APIs _accounting_ software is using that are hard to update.
"Which costs Apple time and money ... newish iPhones [...] which makes them simpler, cheaper..."
You seem very confused, yes: Apple is sitting on 250 000 000 000 $ off-shore money, so what would be the "cost" of maintaining backward compatibility ? new iPhones cheaper ? Than what ?
"Now I must say that I would really love to know what APIs _accounting_ software is using that are hard to update."
I may be wrong, but haven't they've ditched Carbon? Previously, any app using the Carbon API would probably run. But now they've got to be rewritten to Cocoa. As I say, I may be wrong. I'm not doing any Mac work, these days.
Yes but the point remains. We're talking about an accountancy application, not CAD software or a game. It's an application that reads data from somewhere, manipulates it in memory, displays it to the user, takes user input and writes the data back out somewhere.
Every language supports most(*) of those operations out of the box via its RTL (Run Time Library). A Windows application for instance doesn't call CreateFile() unless it's doing something esoteric. Accountancy packages will call open() or File.Open() or whatever the language provides. As long as there is a version of that language available for the target platform it doesn't matter what the OS offers for an API because the compiler vendor deals with that.
(*)GUI would be the main area of concern. GUI frameworks come and go eg; the uncertain state of WinForms on Windows. Accessing a database might also be a concern if they've tied themselves to an ORM but I think it's the GUI framework I'd be most concerned about.
Cocoa is Objective-C. So instead of FILE* file = fopen(path, "r"); you do
NSFileHandle* fileHandle = [NSFileHandle fileHandleForReadingAtPath:path];
and reading data from the file has to be done [fileHandle readDataOfLength:bytes] rather than fread() So the entire IO section needs to be rewritten. (And given the age of the app they presumably have a bespoke file format that users would like to maintain backwards compatibility with.) With a bit of care something can be done. But it's a helluva lot of work.
And it doesn't end there. It's every single fucking API call everywhere. Even basic strings are manipulated with that square bracket notation. And that's before you get to the GUI - which is a large chunk of any modern app.
Presumably the tax logic itself could be factored into a shared library. Other than that, its starting again writing a new app in a new language.
Ouch, that's nasty. Still, that's a language compatibility issue rather than API so it doesn't invalidate my point. But it does make we wince on behalf of Apple developers and goes a long way toward explaining the problem.
I only have experience of MS platforms but at least we've always had a fully supported C/C++ pathway. For the last couple of decades I've been using C# so arguably that potentially puts me in the same boat but so far MS haven't done anything drastic that would kill it off (although the current multiple .NET 'editions' does my head in sometimes). Large parts (all the recent bits) of C# are now open source (hmmmm) so maybe that will help ensure its future even if MS abandon it.
And of course a fair number of VB developers screamed when it was brought into the .NET stable.
So the moral here might be to always be careful with proprietary languages and if you must use them then be prepared to jump and change direction when the owner suggests it.
"Still, that's a language compatibility issue rather than API so it doesn't invalidate my point."
Is being forced to rewrite your app in a new language not enough?
You can actually do it from C++. But those square brackets are indicative of message passing using named parameters. So every API call has now become objc_messageSend() after first finding the object, then looking up the method and preregistering some atoms. And have fun constructing objects that will the OS will use to interface with you. (And the OS does expect to be able to make method calls into your app as a matter of course.)
I've not looked at this in detail so I have no idea how compatible individual APIs are or which ones have gone missing. But that's the point - every C API call has not got to be reevaluated to see if it has an equivalent Objective-C one with identical semantics. If they're not - it's rewrite time. The UI APis were very different, partly because the C interface came from the old Macs whereas Objective-C ones came from NeXT and partly because different languages naturally have different idioms with different conventions.
Meanwhile, 25 year old, 32-bit code that ran on Win95 continues to chug along fine on the latest iteration of Win10.
One, if Apple is going to switch to ARM CPUs as rumored they only want to support 64 bit code. The last few SoCs in iPhones don't even have hardware support for 32 bit code. Sure, they could run it via an emulator but that means they'd need 32 bit versions of all libraries just to support old code from companies too stubborn to update. That wastes RAM having them loaded and doubles your testing effort just a few laggards who don't want to switch. Easier to give them a few years warning, like Apple did, and then force the issue.
Two, technical debt. If Apple is going to convert to the ARM ISA they don't want to support all the ancient pre-OS X APIs that a lot of really old code that was ported from PPC to x86 still use. Supporting stuff hardly anyone uses costs money and is difficult to do because you have so few examples of actual code to test it so it is more "release and wait for companies using the old APIs to bitch". Better to just dump them, and if you lose a few software products that have a 30 year old codebase they refuse to bring into the world of the 2020s, oh well.
Given the far better performance at lower cost of AMD and their ability to run more threads I think your assertion that Apple's is looking at migration to AMD makes perfect sense (or at least give itself leverage in negotiating with both parties).
After all, quite a substantial part of Apple's higher end users are in video production, and nothing chews on system resources quite so enthusiastically than rendering and video.
You misread. Apple will be (likely) switching ARM, not AMD! There would be no benefit to them switching to AMD - if they had done it last time AMD pulled ahead of Intel they would just have had to switch back in a year or two. They want to own
My guess is they'd use the exact same 'X' version SoCs they do in the iPad in their Macs. It has four big cores and based on Anandtech's SPEC tests would exceed the performance of every Mac except the iMac Pro and Mac Pro. For those they could add some interchip fabric (that would be unused on iPad and smaller Macs) to the design that could make them "chiplets" as part of a bigger CPU package like AMD does. I strongly suspect the recently released Mac Pro will be the last one that's x86.
That partly depends on the CPU, and part depends on the OS support for old APIs and CPU modes, as applications are written to depend on a given CPU mode/instruction set, and OS APIs.
For example to run 16 bit DOS applications you need to emulate how the CPU works in real mode, and the OS has to make available the various DOS API calls (i.e. the "INT 21" calls) and the expected ABI.
To run 32 bit applications you need the CPU in a 32-bit compatible mode (so it won't, for example, use addresses and structures a 32 bit application can't manage), and the 32 bit API - because in the newer 64 bit one many parameter will have changed size.
Windows still run 32 and 64 bit applications. 32 bit version of Windows can still run 16 bit applications - that support was removed in 64 bit versions because when the CPU is switched to 64-bit mode it can no longer support the "Virtual86" mode which is used to simulate a real-mode CPU, so the old "subsystem" no longer works.
The 16 bit support could be added as a full software emulation - slower but given the increase in power since the 8086-386 days noone would notice, I guess, but there's no business incentive to add it (you can use a VM, anyway).
Same for 8 bit support - you could emulate many 8 bit CPUs and their OS in software (and emulators do exist), but there's little need to run CP/M application directly today.
The difference between Microsoft and Apple is the former know it has a lot of customers running old applications which may be used to perform critical tasks in factories, hospitals, etc. which may not be easily, cheaply and quickly rewritten. Crippling them will be a huge issue and a big damage to MS reputation.
Apple knows its customers base is totally different, and can tell them "64 bit or else" without losing money or reputation.
As others have said, it likely has nothing to do with pointer sizes. MacOS has always had very complex and platform-specific APIs. When those APIs change, your codebase is dead and can't be salvaged. Your codebase might not even be in a compatible programming language (Pascal, C, Objective-C, ...). I went through a couple of those API revisions and decided not to be a MacOS developer anyone.
Not sure if it is similar, but I've worked in a few post-startup companies, and the story usually goes as such:
- Company starts off with a proof of concept/demo, maybe written by a cheap third party contractor
- Demo product has some niche that enterprise customers want, starts to sell
- The cracks start showing up, customers want more features. Company builds out software teams to maintain it.
- Eventually the technical debt gets so bad that a freeze is put on product 1.0, and product 2.0 is started. This is usually after years of convincing the beancounters that a new product is needed, that it will work out cheaper to maintain, while yes it won't have no new features
I'm assuming that the tech debt is insurmountable, but the product is too complex for a ground-up rewrite.
It does strike confidence in how secure the code for AccountEdge is going to be if they are unable to move it to 64 bit only. It suggests parts were either written years ago by people no longer working there or that the source code isn't well documented so no one wants to or is able to update it.
Given that it is a program that has been around for many years, probably had many different maintainers and has probably had at least some of the design documentation lost then the cost of porting it to a new environment (macOS 64 bit) would not be cheap. Add to that the fact that it needs to meet regulatory requirements and could be sued if it produces incorrect results and the porting bill increases. Doing the port is only worthwhile if the profits from doing the port exceed the cost of the port by a large margin.
Given that the software is available on Windows and that the vast majority of businesses use Windows computers instead of Apple for most commercial applications, it is understandable that the company may think porting to the 64 bit version of macOS is not worth doing.
"The failure to upgrade their solution will drive the user base to the online solutions like Xero." - best thing in my opinion. Keep a load of 30-year-old code running on your own computer? No thanks. Mamut's PC offerings are bad enough* - it's a hassle to maintain, support is absymal, things go wrong and you have to look after a server running SQL. Not exactly simple of a small business. And if you have remote workers, you'll need to set up some sort of remote desktop solution. It's all so early 2000s.
*I have to qualify that by saying Mamut is far easier to keep running the Sage but that's a whole other story!
For reason I don't know each new release of macOS requires new drivers and sometimes even firmware for devices, especially USB connected ones, so OEMs have to deliver updates.
The software that comes with scanners is usually OK only for simple needs. Specific tools like SilverFast does offer a lot more for demanding scanning applications - but they may not not be cheap and some are sold tied to a specified scanner model only.
Depends on what scanner you bought, and what you scan.
In Windows you can scan images too via WIA, but that's fairly limited, and it's OK for simple documents scan only.
If you need to scan something more complex, and your scanner support specific features, you may want to use them. Scanner used by imaging professional may need calibration/profiling as well.
Sure, the devs had lots of warning that this was coming down the line but bizarrely, all of the mac users at my work were caught unaware. Is it really so difficult to scan the Applications folder for 32-bit software and warn the users 'if you upgrade to Catalina, the following apps will stop working!' Eh, it's apple. I'm sure someone will macsplain the reason to me.
Agree, whilst the upgrade to Catalina did warn that some applications were not compatible, the warning wasn't totally clear. So in my case it warned that Office 2016 needed an update, update was applied, on the other side, clicking on Word 2016 simply resulted in being taken to the iStore and being offered to install Office 365...
Now having fun locating discounted digital Office licenses that stand some chance of actually being kosher.
Last June, Ubuntu decided that the 19.10 release would drop 32-bit support. It was promptly pointed out that this would kill Wine.
https://www.theregister.co.uk/2019/06/24/steam_wine_ubuntu_32_bit/
Eventual decision (at least according to the update at the end of the Fine Article) was that some compromise would have to be made. Just killing Wine wouldn't be an option. (Which, as a person who uses Wine a fair bit, I was relieved to hear.)
As the "deadline" approaches, it could be that Apple realizes that nuking 32-bit code from orbit will cause some similar trouble. (Or maybe not. Microsoft did just that with 16-bit code a while back, and they seem to value maintaining compatibility back to the Stone Age much more highly than Apple.)
I assume we'll lose Wine on OS/X as a result of this.
Microsoft dropped 16-bit compatibility because AMD did(they also axed the segment registers 16-bit code would need, leaving only two that Windows actively uses for other purposes). It's kind of difficult to support applications the processor refuses to run.
At this point it should be obvious to Mac users that your binaries aren't going to run forever. From M68K to PowerPC to Intel and now to 64 bit only, Apple has made it clear that they can and will change the underlying architecture at any time, and they're only going to provide backwards compatibility for a short time. Are we going to be good for a while now? Of course not -- everyone knows by now that the next move is to ARM; the only question is when.
"Apple has made it clear that they can and will change the underlying architecture at any time, and they're only going to provide backwards compatibility for a short time."
13 years of supporting 32-bit software on 64-bit hardware is hardly a 'short time.' Note the introduction of Core Duo Macs in late 2006.
List of Macintosh models grouped by CPU type
"...Everyone knows by now that the next move is to ARM"
No. There is in fact no indication whatsoever that Apple has even considered the possibility of moving Macs to ARM RISC processors. There are only ragged old fabricated rumors. That rumor has been stomped to death here at The Register as well as across the rest of the Internet. The first such rumor was posted in 2013, and here we are in 2020. What Apple has done instead is hybridize the Mac with both Intel and ARM chips, each used for separate duties. Meanwhile, any graduate of Computing 101 knows the tremendous time, difficulty, inconvenience, expense and licensing that would be required for Apple to ditch CISC based Intel chips for RISC ARM chips. (Please don't ask me to go over the raft of details again. You'll find them prolifically posted on the net since 2013).
I purchased MYOB for Mac in 1996, and upgraded to Mamut Accountedge 2008. There were some file verification issues following the splitting up of the UK vs Australian MYOB business but to their credit Mamut eventually took on the legacy server. MYOB (2008) still works reliably on Mac OS 10.8.5 and iMac 2007 and is free of any running costs.
The shift towards making tax digital means the MYOB software will not be compliant. I considered moving to MoneyWorks but decided it would be better to buy into the annual Mamut support contract which would provide the latest version of Accountedge and add this capability, releasing the legacy hardware. However if the roadmap for their software is a dead end it looks like I have dodged a bullet.
Thank you to The Register for this timely news... I now know my MYOB-2008 is not going to survive another incarnation and I will be looking for a fresh start with another accounts package. Thank you MYOB, it's been emotional.
This particular software aside, dropping 32-bit support in MacOS also means that software that doesn't get updated any more will no longer work, either. I'm seeing warnings over on GoG.com recently about this version of MacOS not running games that I'm looking at. Because a lot of them are 32-bit, and as older titles they aren't being updated any more.
Maybe Mac users are okay with this, but to me this seems like a weird direction to take. Can one even dual-boot different MacOS versions?
Can one even dual-boot different MacOS versions?
How many methods would you life ?
Firstly, as long as your hardware supports the OS versions you want, you can install different systems in different disk partitions (and/or on different disks) and dynamically select which one to boot from. That's "built in" and needs nothing extra.
Or, you can use VirtualBox, Parallels, (some others I can't recall), and run one OS as a guest in the other. I have quite a few Parallels VMs for different tasks - even one running DOS, though I forget what I needed that for now.
I see Mamut say:
AccountEdge 2020 will be released in March, as normal, with feature updates and payroll tax compliance, and AccountEdge will continue to receive updates in the future.
If many customers are so upset and looking at alternatives, I wonder how long updates will continue to be released?
We still have another year of infamous Adobe Flash to endure. When Apple began in 2007 to move from using old PowerPC RISC based Carbon code to Cocoa code for programming in Mac OS X, Adobe dragged their feet upgrading until 2010. Have no tears for Adobe going 64-bit. All new Mac hardware went 64-bit at the end of 2006. Adobe has dragged its feet catching up with 64-bit for 13 (thirteen) years.
I have Metrowerks Codewarrior Pro 5 for both Win32 and MacOS, released in 1998...
The Win32 version has been installed on every Win32 machine I have owned since 1998. Have it running on my Thinkpad right now. Compiles and debugs 20 year old project codebase without a problem.
Whereas on MacOS it stopped working more than ten years ago.. First serious problems appeared 15 years ago.
Enough said.
Those of you old enough to remember CW will know it was the best IDE ever shipped. We could do stuff 25 years ago that only showed up in other IDE's in the last decade. Some useful CW features still not found anywhere else.
Apple stopped making any serious effort in backward compatibility in the late 1990's. In fact it was only through gritted teeth that they ever released Carbon. We were actually supposed to through away all our existing MacOS codebases and rewrite for NextStep 3.3. That piece of errant arrogance only abandoned when the top ISV's threaten to shutdown all MacOS development.
AccountEdge is built around the flat-file CTree-ACE database, using code that indeed has not changed since the days of System 7.
Their “multi-user” versions literally work by locking an entire database file, transferring it over the network using ancient protocols, modifying it on the client end, then transferring the entire file back to the server.
This was pretty cool when they introduced it in *1992*. But now we have relational databases that can maintain thousands of concurrent client connections at once. And the code is free.
There is *absolutely no* excuse for Acclivity (or whatever they’re calling themselves this week) not to pay a high school kid to convert their database structure into a modern SQL format and update the code to use it.
The only explanation for their refusal is pretty ugly: the ancient database amounts to a proprietary format at this point, making it difficult for third parties to work with AccountEdge files.
So when a customer has a data corruption issue — which happens with fair regularity, as CTree-ACE has no journaling, and the AccountEdge server crashes often, with the database open — the customer must pay hundreds of dollars to Acclivity (or whoever they are today) to fix the file their own bad code screwed up.
It also makes it harder for customers to switch away from the product, and prevents third party solutions from accessing company files for web integration and such. A progressive company would see those limitations as liabilities — Acclivity (?) seems to view them as business opportunities.
And their “solution” for the Mac now? It’s a terrible stabdalone Wine instance, running the Windows version of AccountEdge. And it *does not work*.
They could have *the* killer app for Mac bookkeeping with a couple of weeks of coding. It’s absolutely baffling that they are instead abandoning their only profitable market. We’ve been with them since the late 1980s, but are now planning a migration to QuickBooks for Windows. What a shame.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
