You’re definitely lying about it ‘not supporting the newer xml formats’. It already supports the only ISO standard XML format - ODF.

Solution:

1. Remove the PPC byte-code compiler/linker completely and discard

2. Create a simple byte-code to C translator, which emits each macro as a C function. Don’t worry about generating efficient C, the compiler (step 3) will take care of that.

3. Compile the macro(s) using your favorite (external) C compiler.
e.g. system(”gcc -O3 …”);

4. Dynamically link the compiled macro(s) to the Office executable.
e.g. dlopen(…);

5. Find macro function entry points and save in a suitable data structure.

6. Call the compiled VBA macro functions as necessary.

7. If feeling adventurous, embed the compiled object(s) in the Office document that contains the macros so that compilation is a one-time effort.

How hard is this? Worried about the cost of calling a compiler? It’s faster than you might think, and better than losing compatibility and all those paying customers. And if you need a hand - I’ve done this before.

Thats just not true. They almost certainly could make more money using the MacBU developers for other jobs, they just keep it going for goodwill and to be seen as playing nicely with competitors.

Plenty of platforms have seen major applications just dropped because they are too expensive. For example Lotus Notes only supports Windows for a client now despite thousands of businesses using it on other platforms. It could EASILY happen to Mac Office.

Scanning the post above, seems VBA is struggling with legacy approach (probably dating to Win3? and slow cpu’s). Amazing such a valued tool could create a major headache for the big “M” ?

To compare stories, years ago when enterprise computing introduced 4GL’s for business queries, tons of reports and queries were written; the major issue again became compatibility and converting those reports and queries to the latest technology–SQL, Access or Excel spreadsheets.

Does this merry-go-round ever stop?

See this post from Paul Vick: http://www.panopticoncentral.net/archive/2007/05/01/20383.aspx.

I hope that the MacBU will check these out!

—
Taiwo

I’ll buy an extra couple copies of Office 2004 to tide over my organization for any potential needs in the next couple years while I investigate migration alternatives — although such alternatives are unlikely to involve Windows or MS Office, aside from maybe one document recovery and conversion machine (as it slowly become impractical to continue using 2004). Without cross-platform scripting compatibility there’s little reason for me to stick with Office.

Office 2004: the last useful version of Office for Mac. Kind of a shame to throw away an otherwise reasonably good product line, and it sure throws a spanner in the works for me, but I guess the world has to move on. Oh well. RIP.

- dropping VBA for Mac in the next Office version, even if this hurts a minority, but a loud minority of users - this is what you chose ;
- porting the existing code base, which is a technically hard thing to do, because an enormous legacy code which contains deep dependencies into obsolete assembler, PPC and windows code. You expect that porting to be outrageously expensive, and worse, to take two full years to complete, which is why you won’t do it.
- just rewrite the hole damn thing in a modern high level .Net language, get your-selfs or buy a nice modularized editor and build the interpreter in three months, and spend 6 months in testing as to pick compatibility errors.

I mean, two years to port an existing application, this just sounds like a communist apparatchik junta deciding over the fate of the old town bridge built in the 19th century, while blaming it’s architects for not forecasting 21st century’s trailers over it. This and that blog over how to build a desktop side bar in a three years period are just throwing lights over what has become a giant buraucracy, shame on you.

Dropping support for VB will likely make these documents unreadable in newer versions of Office. So there’ll be no incentive for me to upgrade to Mac office, leaving me with two choices Open Office/Neo Office, or running a later version of Windows Office under some sort of virtualization software.

Neither alternative bodes well for the MacBU.

The other point I’ll make is, despite the -superior- job the MacBU does ‘mac-ifying’ MS Office, I’m still really upset at the chronic bugs I run into that never get fixed. #1 on that list is double-clicking a MS Word document, selecting Print, causing MS Word to immediately crash.

dave

This post is amazing, by the way. Here we have a manager / leader / developer at Microsoft, a software DEVELOPMENT company, complaining how hard it is to build software! Duh. What should Apple have done for you, give you a big green button and volià here is your fully-functional and backwards-compatible VBA? Building something like VBA is not a trivial task at the best of times. Development is FAR more complex than it was when big Billy G. hacked against Microsoft Basic in the 1970s. To be retreating from the challenge, even though the bar is higher than yesterday, says to me that you are not up to the challenge, and perhaps you are not the right person / team / company to lead the way to tomorrow. To quit because something is hard is a cowardly response, and a way to certain defeat. You allies (all those developers you’ve heard from) in the trenches have been let down by your abandonment of the battlefield. Such a move, no matter how ‘justified’ is a choice that will have grave consequences for your business for years to come. You’ve given up the fight and abandoned ground you’ve invested years and millions of dollars in winning.

Time for a new general.

With the rise in home purchases (albeit a small one) of Macs, the need for cross-platform issues to be as transparent as possible will be even greater. I know this will be a huge issue for me - sorry to see MBU making this (bad) decision.

Regardless of the pain and suffering it will inflict on developers, MS has ripped the rug out from under us and potentially has forced most of us Mac users in the business community to run Windows on our Intel Macs and run Windows Office. Sorry, your explanation may be convincing to some, but not to all of us. Let’s face it - if MS really wanted to keep VBA functionality in Mac Office they would devote the resources to doing so. As in Jeff’s post above, MS INDEED is protecting its Windows turf. The MacBU blew it here. You guys MUST reconsider - otherwise most of us will be stuck in the Rosetta world of Office 2004 for a long time to come.

A pathetic excuse for a company that clearly wants Windows domination. Sorry but that’s the message Microsoft sends “the rest of us”.

it does indicate to me that this creates a serious wedge petween the 2 platforms. mac’s next big growth market must be the mainstream business environment.

the only way for mac to make inroads there is to have FULL compatibility.

by not allowing this in the business tools companies use most, ms is protecting its windows turf. this is not a resource-allocation decision, this is a business strategy. it is very bad news for mac.

it emphasizes mac’s need to be ms independant and to continue to develop its own software.

i hope this decision comes back to haunt ms in a big way.

The only other option I can see is installing XP version of Office to run under parallels, but I really dont want to have to buy Parallels, Windows and Office for windows.

Ok The decision is made, but perhaps a more suitable decision would have been for the Windows Office to be written with cross platform in mind. Maybe this could happen in the future, so the same version of office could run in Windows, Mac and Linux

Every time I’m about to give Microsoft a second chance, they go and pull some stunt like this. From the sounds of this article it would seem that Microsoft is doing exactly as it appears- repeatedly reskinning the same code with no real reason to upgrade and now for me no reason to purchase at all. Every couple of years folks are charged $500 per user, just for the right to make word documents, a spreadsheets or two and some slide projections?

Mix up the format and bam… it must be a better file, but as this article clearly shows, its all built on dated technology. Well, this announcement synched it for me. I was going to give Mac Office a try for development since I can code in VB, but I’ll just pitch the VB altogether. So, in a way this works out for everyone. I have less to worry about supporting and Microsoft has less to worry about selling.

ciao

Sisco

No matter how awkward the transition, Microsoft has the resources and the brains to make VBA work in MacWord — and has the ability to release feature mapped versions of the program on both platforms.

To contend otherwise is completely is, literally, incredible.

My suggestion to both the MacBU and the WinWord BU is that they hire some new guy to data mine through the old CompuServe MSAPPS forum — surely someone has kept a record of those early days when the DevTeam actually spoke with power users rather than focus groups — and try to recapture, re-imagine, the astounding beauty and functionality in the original WinWord design. That’s why WordPerfect was crushed. Why AmiPro and WordStar 2000 never had a chance. Word for Windows dominated PRECISELY because of the elegance of it’s design, because it was customizable, because you could make it do anything you wanted.

You guys have forgotten why you’re making this thing.

In fact, the only requirement that counts AT ALL is #2. Macs have always had excellent word processors and spreadsheets and presentation packages — programs that many Mac users prefer over MS-Office. The ONLY reason that MS-Office has had an indispensable position on the Mac is because of its cross-platform compatibility — a compatibility, by the way, that is actually rather poor compared to what has been achieved by OpenOffice on all of the platforms that it supports.

Make the Mac product look and operate EXACTLY like the MS-Windows product and it will have better compatibility. More companies will be willing to use it because it will cause less trouble for their MS-Windows users. The fact that it won’t be a “Mac app” is actually irrelevant. No one buys MS-Office because it’s such a great Mac app; they buy it because they need to be able to exchange files (and macros) with MS-Windows users.

As an aside, if all of Microsoft followed clean programming practices in the first place, your code would be more portable, *and* more secure, as well as easier to update.