Thanx again.

And no one was paying me out of some corporate budget. I came to Macs late in life, but if I could, would drop the various PCs I have just because the Mac is a beautiful machine.

The arrogance of Microsoft, with its screw the customer attitude is mind-boggling. (you once tried to charge me £230 just to ask a question when I found a bug in Access which then you credited after you admitted it was your fault). This is just another brick in the Microsoft stonewall built with complete disregard of your customers and the work they put in to adapt your undoubtedly great parts of the package (Pivot Tables for instance) to good use.

A plague on your house.

This does sound like a really feasible solution indeed.

what about LLVM anybody at MacBU?? or use an OSA component, with VBA as its language of course.

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.

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