Categories
All MacBU

So tell us what you want, what you really really want!

Thank you all for your comments about VB. There’s certainly a lot of passion, frustration, and outright anger being expressed here. For those of you with kind words, I greatly appreciate them. We’re reading every comment, no matter what the sentiment. I’ve personally seen MacBU leads reading your comments on my blog.
I had intended to post yesterday and answer some of the specific questions raised, but I’ve once again caught a nasty fever and cold from my preschool-aged son and didn’t get to it. Sigh… In lieu of that, I’ve got a couple of more general notes to make on yesterday’s post.
In my note on resources, I used a slightly extreme example of our headcount. I did have an opening for quite a long time, but our overall delta between having someone leave our group and hiring a replacement is probably something like 2 months or so. I have no idea how that compares to any sort of Microsoft- or industry-wide average. The complicating matter is that departures and candidates tend to happen in clumps, so we often end up with some abnormally long or short gaps in staffing instead of a more normal distribution. We’ve actually had a lot of folks very interested in working at MacBU (i.e, us having open headcount really is not due to a lack of people interested in working here). We hire world-class developers and they don’t simply grow on trees. For those readers offering a smackdown on the intelligence or capabilities of our developers, nothing could be further from the truth. We’ve even had some developers leave MacBU to go to other renowned Macintosh companies and then come back to MacBU because the grass really wasn’t greener elsewhere. We’re all proud to be here!
As for keeping VBA in PPC to run under Rosetta, that could be done but just vastly overcomplicates an already very complicated piece of source code. Rosetta only works on a per-process basis, so we’d be moving code and data out of the single app process into two processes. There are many many points in which apps call into VB and VB calls back into the apps (not to mention VB’s dependence on other lower-level shared library code that is now Mach-based) and marshalling all those calls and data cross-process is a heck of a lot of work. It gets even more complicated when you have more than one Office app running at a time, because then the new VB process would have to keep its internal state separate for each client app!
People have also offered the solution of porting the current Win Office 200x VBA over to the Mac. That’s pretty much a no-go too, because 1) it still has the assembly ABI problems, 2) makes calls to the Win32 APIs that don’t exist on the Mac (well, without WINE or any of the variants) and 3) relies on features in the Windows OS that don’t exist at all on the Mac. We’d have to port over large swaths of the Win OS and that might take even longer than writing VBA over from scratch.
VBA just wasn’t designed to be portable across architectures. The Mac and Windows implementations are very different, even though the actual language is the same. If I could go back in time about 15 years and tell the original designers to do it differently I would, but I can’t. Thanks to the heroic efforts of a few developers (Shuyi and Ying) we managed to Carbonize VB for OS X, but the move to Intel is gargantuan. We considered many, many alternatives. Each one turned out to be no simpler and as much or more work as the plain port would be.
None of this is work that we can’t do, it’s just work that would take away from everything else that we do want to do and would delay shipping Office 12. As I said on Tuesday, delaying Office 12 has other ramifications for cross-platform compatibility such as dealing with the new Office XML file formats and related features (like the larger cell grid in Excel, for example.)
Back to the idea of AppleScript… Folks who want to develop scripting modules on the Mac should check out AppleScript Studio. You can create GUI applications with it, and it is absolutely free from Apple. Also, a few bloggers have been wondering about scripting Office with Python and other languages. Yep, you can do that with the AppleEvent bridges available for those languages. We actually test Messenger in-house with a large suite of Python scripts that drive it through OS X’s Accessibility AppleEvent suite. We also drive Xcode via its AppleScript dictionary with Python scripts that send AppleEvents.
So, what now? Well, it is pretty obvious to me that the MacBU needs to provide some guidance for folks who currently use VB. The best way for us to provide the information that will help you the most is for you to give us some first. I encourage you to provide feedback to us — lots and lots of feedback! There are several ways you can do this:

  • Select Help/Send Feedback on ‘OfficeApp’ from within your favorite Office 2004 application
  • Click on this link and fill out the web form
  • Post a comment on any of the MacBU blogs
  • Send me email from this link and I’ll forward it into MacBU

Please give us specifics in your feedback. Just saying “I want VB!” or ranting about how we’re evil doesn’t provide us anything we can take action on. We’d like to know what you do with VB, what the goal was, did you share the macro with anyone, was it specifically cross-platform or just something on the Mac, what app was the macro in, and things like that. So yes, do tell us what you really want. Please keep it civil, it’s no fun reading through pages of insults. Your feedback directly helps us figure out the best ways we can help you.
[Aug 11, 9:26am — minor edit to correct the description of how we drive Messenger with Python]

110 replies on “So tell us what you want, what you really really want!”

There are very few corporate customers which are purely Mac shops, therefore cross-platform compatibility is vital. Furthermore, the cost of rewriting VBA code adds unjustifiably to the upgrade cost, even if your alternative Applescript solution manages to do everything that VBA did. (From this blog entry, it looks as if you are ackowledging this to be unlikely.) Therefore dropping VBA from Mac Office essentially kills the product for the corporate market. Companies will stick with Office 2004 or move their Office desktops across to Windows. They are not going to be happy to pay you for the privilege of being forced to rewrite all their VBA code.
Of course, not all customers are corporate. But individual users will generally only buy Office with a new computer – I suspect relatively few individuals will upgrade Office on an existing computer. Office long since reached (and passed) the point at which it was good enough for individual use. Therefore, just about any relatively recent version of Office would do for individual users, and so there is little competitive advantage in making a newer version for them.
So, with the loss of VBA ruling out most corporates from upgrading their copies of MacOffice, and individuals not buying upgrades, I wonder from where the you expect to get the additional sales that will justify the development costs for the next version.
Has Microsoft considered not bothering with a new version of MacOffice at all and redeploying the development resources to something that offers the prospect of sufficient sales to justify the use of them? You could continue to offer security patches, and you could make file filters for the new XML format (as is being developed for older versions of Office for Windows) and leave it at that.
VBA code that I provide in templates for my customers? Just take a look at the VBA code examples at http://word.mvps.org for some of the more common things that Word customers ask for. Just about every template I create has about 2000 lines of VBA code in it.

There are two lights at the end of the tunnel:
– Office 13, which might just slip in under the agreement if sales of Office 12 disappoint
– Parallels, or another “Red Box”. The funny thing is, this probably won’t make much of a surge
in Office for Windows sales at all, since so many places that have the ‘xplat’ issue are site-licenced.
(Bundling Office 2004 with Office 12 is a great idea, by the way. Who really loses here?)
I’ll just finish by mentioning how I use VBA. I literally learnt how to use it in two days while off sick from work because I had to hack up a workaround and got bored in bed. Which means I really don’t know VBA that well, beyond what I gleaned off a few Google searches … but then how many others are like me?
The point is, I barely use VBA for anything more than an unlimited-row lookup substitution — a function that I was missing in Excel due to a (pathetic) 7-deep nesting limitation. Actually fair’s fair: It’s a bit silly to have to nest Excel functions more than 7 times, but then there doesn’t exist anything like SUPERSUB(string,substr-from-column,substr-to-col) in Excel either.
Hmmm, I guess that means if a SUPERSUB function existed in Excel for Mac, then it would be equally useless in Excel for Windows as an AppleScript would be.
Personally I hope some clever third party is rubbing their hands together and looking to provide some kind of VBA AS translator.
CK.

Once again I’m very glad to see you blogging about this stuff.
When I heard about the demise of VB on the Mac, my first thought was whether it would be to the exclusion of any scripting mechanism. I’m really glad to hear you’re working no building up the AppleScript support. The few times I’ve used VB for office on the Mac, it’s been a workaround to do something that reasonably should have been doable in AppleScript. It felt like a hack to do it in VB.
I’m concerned about the cross-platform angle. The idea of files that “work a lot better” on a PC doesn’t sound good to me, and it must also cause anguish in the halls of MacBU. But I think you must have based your decisions on statistics more meaningful than my gut instincts, so I hope most Mac Office users will not be too disappointed.
It’s probably obvious but please remember to present a dialog to the user informing them of the limitations, when VB is present but not runnable. It would be worse for the user to simply see things not behaving the same as on the PC.
As a brainstorming idea: what do you think about allowing Mac users to package AppleScript into the file as VB can be done from the PC? I’m not sure how common it would be for a document author to include “functionality similar” scripts for each of the platforms, but having the option as an out for very serious shops might be an appropriate fallback position. I guess this would require some coordination with the Office PC team, which I’m assuming you must already do quite a lot of.

Hi,
I appreciate that you’ve looked at all possible options and selected the most pragmatic one. The one thing I would like for you to address is the option for third parties to extend Office 12’s scripting support. Will this be possible?
I’m thinking specifically of RealBASIC btw.
Where Apple script is concerned, Office is now becoming an increasingly better citizen of the Mac world by incorporating Mac OS X specific technologies. I suppose that full VBA feature parity with Windows is a pipe dream. In this respect, Apple script would definitely be a more robust platform for scripting Office Mac Applications. I’m also hoping that because of the move to Mach-O, Excel will be able to use the native ODBC drivers and not require a third party add-on like 2004.
Thanks again for being so open!
Shahram

What I want to know is how many users actually use VBA where it is a deal breaker to not have it anymore? What would that percentage be? I would be guessing that it is very small compared to the total users.

Robert, it wouldn’t have to be a dealbreaker for a large proportion of users, it would only have to be a dealbreaker for at least some users in a large proportion of companies or other large organisations who are customers.
Large orgs are not going to tolerate mixed installations, their IT departments have trouble enough already, so if there is a mission-critical VBA app somewhere that will break, it will abort the entire upgrade rollout unless and until it can be rewritten.
I would guess this scenario will apply to many or even most corporates. That is why I think the next version will completely bomb in the corporate market unless the VBA decision is reversed.

we use vb macros in a uni maths department to process the marks from dozens of examiners, who are on computers that range from mac os 8.6 to windows xp. the vb code is thousands of lines long, does tonnes of calculations to calculate the relative difficultly of different papers. You may find making VB run on Intel time consuming, but I would find rewriting this code much harder. i am a self-taught programmer, and i do not want to have to learn applescript. please please please please please please do whatever it takes to get VB on Intel, or i will cry.

Dude —
So, specifically, how will either of those help you? what will you do with them? how will you use them? Seriously, that’s what is helpful to us, like Rob’s comment above.

Regarding C# or .Net, some may recall Microsoft’s open source Rotor project for FreeBSD which was a CLR implementation. So MS has at least one Unix CLR implementation that it could use in Mac Office.
But apparently Rotor wasn’t very good. Mono is, however, open source and pretty good. I don’t know if MS would be happy taking Novell-developed code or not…
The Mac version of the Imeem client is partly built using Mono; they obviously think it is production quality.

What do I really want? It’s actually quite simple:
– Word
– Excel
– PowerPoint
– Access
– Messenger
That are fully cross-platform compatible. I want the same functionality on the Mac that I would have on Windows. I understand that the APIs are completely different but you guys are smart enough to come up with a way of bridging that divide. After all, Apple was able to come up with Quicktime for Windows and surely Windows didn’t have the Mac’s APIs then or now.
I want the functionality of Office with a Mac interface, touch and feel.
BTW – I’ve been trying OpenOffice and in addition to being pretty comparable to MacOffice, it’s amazingly fast on both my PPC and x86 Macs. Thus far, it’s displayed my documents faithfully to the MacOffice version.

Dude: Porting .NET would be even more work. Like, a *lot* more, as I understand it.
(And note that the VBA here is not VB.NET; if they did somehow port .NET to OSX, VB.NET wouldn’t be much if any harder to manage there than C#, at least as far as I understand it, but I don’t work at MS and I don’t know the internals.
In fact, they might both be free once you had .NET and a cross-compiler to get things self-hosting. That is, if the VB and C# compilers are .NET themselves; I don’t know if .NET is self-hosting yet.
It’d be double-cool if Visual Studio was, but that would also require porting System.Windows.Forms to OSX, and… Jesus, I don’t even want to think about what a cluster**** that would be.
I’d love if it happened, though, since then the code I get paid to write would work on OSX as well as Windows, and the Mini is actually a fairly compelling form-factor for our market…)

I guess the overall lesson here is one of open data format compatibility. The original drop-VBA decision comes about because the original implementation code is over a decade old (indeed, some of the code in Mac Office is older than some of the people working on it). It’s too old and too awkward for the MacBU to update it for the new Mac architecture.
Any company or user who invests considerable effort and time in building VBA macros (or AppleScript macros, for that matter) is, consciously or not, buying into a proprietary language that may or may not become obsolete in the future. Whether VBA in Mac Office gets updated is a decision that must rest entirely within Microsoft, because the company owns the language. Similarly, what AppleScript is able to do is something entirely under Apple’s control.
When you build workflows based on that, you’re taking the risk that, at some future date you cannot predict, the language won’t be supported anymore. That’s what’s happening now.
So, as a non-developer, my suggestion and question is: is there a way to use *open standards* to continue to support scriptability in Mac (and Win) Office without relying on either Apple or Microsoft in the distant future? Is there some sort of scripting environment related to the OpenDocument standard that might persist into the foreseeable future?
Is this just a pipe dream?

I want precisely what Neema Agha above wants.
Specifically, we use a VB app called Wordfast. It is the only translation producivity tool I know of that works both on Windows and the Mac. It’s a brilliant little app. Having used it for years, we have built up an enormous data base of translation memories that keep us competitive. We use it mostly in Word and sometimes in Excel. Unfortunately, it doesn’t work very well in Powerpoint on either platform, but the developer is working on that. For us, Office for Mac without VB, which enables us to use Wordfast, plus some specific Word macros sent to us by our clients, is a deal-breaker. Please find a way to keep VB, to make it better and keep it compatible with Office for Windows.

I agree that being able to use Windows docs using VBA is what’s going to be key here. If there’s someway to get them to translate over using REALBasic, Applescript/Automator, or something, that would be great.
What’s most frustrating is that I just don’t get the feeling that MS is doing anything beyond plain maintenance for the Mac side. (And when I mean MS, I mean the MacBU’s bosses, not the unit itself which I think does great work with what they have.) You would expect the largest group of Mac developers in a company outside of Apple would have more to show for it, you know? If you kill something, there should be a backup plan in place: no more IE because we have Safari (that’s fine), no more Virtual PC now that the Intels are out (also makes sense), Flip4Mac replacing Windows Media Player (not a one-for-one exchange, so I’m not keen on that, but better than total abandonment), but VBA just gets plain ol’ dumped.
In short, I’m not happy with your corporate overlords. MS has been taking more away from Mac users than they’ve been putting in. And if you’re having a staffing shortage, they should be stepping up to the plate with better incentives to do something about that as well. I don’t want to be told that “as always, cross-platform compatibility remains a top priority”: I want to see the proof for myself.

Just a quick note, Windows Media Player for Mac was done by the Windows Media division in Microsoft and NOT the MacBU. Complaining about the WMP9 drop here is no use. The MacBU was never in charge of it.

I appreciated your candor about how difficult it would be to port to Intel. I would submit that no one really wants you to spend time building a new editor/compiler/runtime/forms interface, but rather people want a cross-platform API that allows them to write code once for both Windows and Mac office. How about working on a javascript implementation of the API? Maybe MS would be willing to spare some Win Office folks to work alongside you. There’s already a javascript engine for MacOS, so now you need to implement only the office hooks, which is what you do best.
Its always painful to take away features, but you really are hurting some businesses with this one, and threatening the existence of the MacBU. Wouldn’t you agree that the less cross-platform compatibility you have, the less likely people are to bother using your product, since that’s its primary niche?
Maybe you could get some help from Open Office? They’re working on a VBA implementation (an obvious dig, but not altogether without substance):
http://wiki.services.openoffice.org/wiki/VBA

Just a quick question for those who know more about this stuff than I do.
I rely on two add-ons to Word, namely Mathtype and Endnote. As best I can tell both of these use a fair bit of VB Script. I’m guessing this decision is going to make the lives of the developpers of these apps a fair bit more difficult.
Does this seem plausible? If (big if given how long I waited for the OSX port of Mathtype) they decide to update using applescript, will I still be able to exchange documents with Mathtype documents with Windows users?
Any informed speculation would be much appreciated.

Thank you for writing about the reasons why VisualBasic will not longer be supported on Mac Office. I am a beginning VBA developer on Windows, and noticed that even the most basic of scripts had problems running on Office 2004 (mainly because of the ActiveX controls rather than Forms).
Nevertheless, I certainly hope that there will be something done so that people who buy the Mac version of Office will be able to run VBA. Personally, I would be a much happier customer if Mac Office shipped with some kind of Visual Basic platform – even if it only ran on Windows.
Thus, I would be happy if Microsoft/MacBU could include Word/Excel 2007 for Windows with the purchase of Office:mac at no/minimal additional cost. The reason is that VBA is so common that I would still need Office 2007 for Windows – and it is very difficult for me to justify buying a copy of Office for Windows and a separate one for Mac.
If I had to buy separate copies of Office for Windows/Mac, I might just get Office for Windows, and iWork for Mac – and just stick with Office 2004.
It might even make business sense for Microsoft to include Word/Excel 2007 for Windows with the Mac version, too — because it would probably increase purchases of Windows licences.
Hopefully this is specific and actionable — maybe not by yourself, but if it could be raised with those responsible for decisions regarding marketing/selling/etc.

Maybe the solution to this “Impasse”, is in the wild:
You could try something like putting a bounty for it, “Microsoft will pay “x” amount to an individual or a company that could satisfy this need”
Or something like that.
I have never ever used a macro, so I’m not in pain like so many others, but I love Office so it worries me that an issue like this could be the beginning of the end for this app.

Hi there,
You know, after allowing all this to sink in for a bit, I really think you’re doing the right thing, with a few qualifications (which I’ll get to later).
Honestly, I personally don’t write VB. I don’t know how, and I’m not that interested in learning. I have been known to script Excel with Applescript and would be thrilled if its object model and scriptability were improved.
However, at school I quite frequently receive Excel worksheets with VB embedded in them. These take the form of chemistry calculators, helps for Calculus homework, or something as mundane as a class schedule calculator. The thought of no longer being able to use these at all sickens me. But my University has good open access computer labs, so all is not lost for me (until I graduate and enter the workplace, that is).
Now, here are my reservations about your decision. I think cross-platform scripting needs to return to the Mac, eventually. Make this a temporary situation. Devote a few resources to it, not enough to significantly hamper other efforts. Rewrite it in a higher-level fashion, or whatever makes sense. Like I said on the last post, I don’t care if it takes 3-5 years, but from my outsider’s perspective, it has to be done.
If it is really true that “if you can do it in VB, you can do it in Applescript”, then how about a cross-compiler/interpreter? Translate the VB into Applescript (or raw apple events, even). You could even do it on the fly. This seems feasible to me, though I really have no idea if it’s practical. If it is, it seems like a good compromise to provide compatibility.
Once again, thanks for being forthcoming – were it not for your posts, I would still suspect MS of deliberately attempting to marginalize the Mac, especially in the Enterprise that has for many years been almost exclusively its turf.

I’m not a power user or anything, but I’d guess that I’m pretty close to an average mac user in what I want out of my programs. I want interoperability. I quite enjoy Mac Office currently & upgrade soon after a new version comes out. This is in stark contrast to my earlier habits. Why do I upgrade? To be honest, Mac Office has done almost everything I need it to do for years. I upgraded to office x because it was OS X native. I upgraded to 2004 only because it was the most current & most compatible version with the most recent versions of Windows Office. I was planning on upgrading to the next version of Office when it came out, for the sake of compatibility with the new versions of windows office. That’s not the case any more & actually 2004 will be more compatible than the next version (2007?). I remember well the days of Apple bundling dataviz’s translator with macs to read windows files & translating them back & forth. It was a real hassle & you had to cross your fingers that when you sent a file, people could read it & when they sent you one, you could read it. Now, aside from small issues (font stuff & PP mostly) Office files work great on either platform. I can create them on my mac & send them to windows using friends or vice versa. I can’t remember the last time I had a major problem with an office file. My wife’s boss recently sent her a microsoft works file that we tried to open on our macs. We couldn’t do it. In the end, we had to go to a friend’s house & use a windows machine to translate it to windows word & then it transferred fine to the mac. This is the kind of stuff I fear. The file that we got was something that we needed immediately. It was last minute, working on a presentation the night before it was to be given (no we couldn’t have planned better, the project came up last minute.) Yes I know that it was works, not office, but this is the kind of stuff I fear in the world of differing feature sets for Mac & windows office (and yes I know that they currently have differing feature sets, but from a practical standpoint, they are close enough that MOST business users won’t notice a difference. Removing VB would change this)
I recently helped create a spreasheet for my wife’s boss to help track hours/sales/calls/etc for each person on the team. The file was originally created on a PC (and made use of VB), then sent to me where I finished it & sent it on to the boss, who was able to use it on his PC. Everyone on the team is able to use the file on their wondows PCs, as is my wife on her mac. I don’t want to have to worry in the future about situations like these. Will they work, won’t they? With differing feature sets, this becomes a distinct possibility. I use VB only a tiny fraction of the time, in a tiny fraction of my documents, BUT when I need it, I need it.
thanks for the interoperability you have given us in recent years.I’m sure ti was a lot of work but it has truly been a blessing (PP is still a bit of a PITA, but that’s life) & is probably one of the major behind-the-scenes reasons for apple’s recent resurgence. Please keep it that way.
BTW, if I had to choose between your two pillars, mac-like & interoperable with windows, I would lean towards the interoperable side. Obviously I want my programs as mac-like as possible, but the farther you go down this road, the closer you get to iWorks. That is the ultimate mac-like program. While I like it & it’s a great program, I buy office instead because it’s interoperable with my windows buddies. As soon as a .doc or .xls file becomes anything less that standard (Is that a mac .xls or a windows .xls file) then office becomes that much less desireable.

I’ve only read this blog entry and the last one (and almost none of the other comments), but allow me to oversimplify the entire issue and provide a few random thoughts:
1. The original implementation seems to be far too “deep”, but perhaps it was written this way for memory and performance reasons “back in the day”. I also don’t know what your minimum configuration is for the next release of Mac Office, but it seems to me that a higher-level scripting approach would be much easier to implement.
2. I’ve never written a line of VB (inside Office or out), but it occurs to me that most of what you’d want to do in VB would be (a) to modify the document and (b) to perform some calculations, string manipulations or other non-document-specific variable manipulation. With JavaScriptCore available today through the open source WebKit project, perhaps it would be possible to write a VB-to-JavaScript translator wherein objects, functions and properties would be bound to the Office DOM on an as-needed basis to provide the requisite functionality.
3. Instead of using JavaScriptCore, perhaps VB code could be “compiled” into ObjC runtime calls, akin to what F-Script does. I think this would be more work than using JSC, though.
4. I’m guessing there aren’t any good test suites that could be used to test a brand new VB implementation in Mac Office. Such a pre-existing test suite ought to reduce the number of man-hours by quite a bit (assuming a large portion of the original estimate included manual testing of a brand new VB implementation). Even an external VB test suite that could be internalized on the project would be helpful.
5. Finally, it’s unfortunate that this part of the Mac Office project couldn’t be open sourced so that the people who want it most could work on it. Coordinating such a project would probably take more time away from your project to ensure a high quality of code, although the benefits are great. (Just ask Apple’s Safari/WebKit team.)
Dave

I can buy the argument that it’ll take time and you don’t want to delay the next version. Fine. Can you release the next version without VB and work to have it back in as a feature in a later version… or even as a future update to the next one? I spent several years teaching myself VBA to create software for my school district that creates, modifies, and customizes about a dozen different forms we need. It’s a large project that includes a lot of code, autotext entries to manipulate, and a toobar used to launch certain features (more marcos). I work in a cross-platform school district so it’s been great being able to write a single code and have it work on any machine the template is installed on. Quite frankly, it was beautiful to see how well it worked on any machine in the district.
In order for this software to survive I see that I’d have to completely rewrite the Mac code (learning Applescript along the way) and then keep 2 versions up-to-date. I simply can’t afford the time do that since my time on the project was essentially “donated” (I’m not hired as a tech person, I was doing this to learn programming and provide a service). This move will essentially kill my project…
But it could survive skipping a single version of Mac office knowing the template would run on future versions.
Steve B.

I agree with the last poster, Steve B.
Office Mac skipped a version in v7 (Office 95) and v10 (Office XP), IIRC. When I think that my company only just upgraded from Office 2000 to 2003 (v9 to v11), then I think a few short years living with a fully OSX’ified v11 will work … and some kind of low-key press release later this year will assure MacBU’s fortunes.
Shortcuts that MIGHT work:
– Replacing the VBA/VBE/Forms with something that only interprets what’s embedded in a Windows file … interpreter speed is not an issue!
– Doing a long survey of VBA users and seeing what features they REALLY use, and seeing if you can develop a solution that fits MOST of them, following the 80/20 rule … a previous poster commented how “deep” VBA seemed, and yeah, it’s like Middle Earth in there!
Of course, such a shortcut would involve some Stevenote-style demonstrations, and asking people to walk up to an expo demo booth with their own documents to try it and see. They might likely have documents that contain VBA they only use, and were written by a developer on Windows long ago. And going through all the arguments from the last week all over again. But hopefully then with more people defending the move?
CK.

I’m surprised you didn’t consider getting the main office team to rewrite VBA in a more modern and portable style. I’m guessing it’s because it would a) probably subtly break compatabilty with existing scripts and b) still rely on win32 apis, but it’d be nice if you could confirm this.

The main concern of small businesses is that they be able to hire somebody else down the line to maintain my code. They may need two changes a year; it’s not reasonable to have somebody on staff, and it’s too risky from their perspective to assume that I will always be around to do things for them.
This means they need a language which many other people are using. There are far fewer AppleScript developers for hire than VBA developers. They’d have no idea where to even start looking for one, and they aren’t too thrilled with even remembering what language the stuff is implemented in.
From their perspective, game over: In order to keep the old VB macros, they will avoid upgrading for five years or more if necessary. They’ve done it before for lesser reasons.
What I’d really like to see in the long run is a new, cross-platform scripting language for Office. Deprecate VBA and keep it for backwards compatibility. Clearly this would require much greater cooperation between MacBU and whatever part of Microsoft is responsible for Office-for-Windows, but if that’s what it takes, that’s what it takes. Your explanation was very persuasive, but it keeps coming back to “we can’t do this because it would require working closely with the Windows team on an ongoing basis”, and that’s not a technical problem, it’s a business one – so solve it.

Well I’m glad I never learned VBA and stuck with XLM macros!
So, what is the future of XLM? Will XLM macros still be writeable in the next version of Excel? How about a resurgence of my fav– er, first programming language?

James said “I’m surprised you didn’t consider getting the main office team to rewrite VBA in a more modern and portable style.”
Quite frankly there is no chance of getting Microsoft to rewrite VBA in multi-platform way. If they did so, it would give the lie to their claim that VB6/VBA couldn’t be compiled to the .NET platform. Just not going to happen. Too much pride at stake in the Visual Studio group.
In fact, this whole problem ultimately has at its roots the VB6/VB.NET fiasco of a few years ago, when Microsoft took their eye off the ball with regard to forward compatibility, and shovelled dozens of unnecessary language and syntax changes on top of a very small number of essential technical changes in the platform (chiefly the new mechanism for handling object destruction). Had Microsoft taken proper notice of customer feedback at the time, VB.NET would have been about 98% compatible with VB6, VBA in Office could have sat on top of the .NET platform, the platform itself could have been ported to Mac, and we wouldn’t be having this discussion.

To all the people here who are compaining i want to say USE OPENSOURCE !!! Microsoft does as they use python internaly i bet they think it is a better choise but they wil never admit it

Erik, what’s the situation for third-parties calling into the OLE Automation layer (I believe REALbasic does this) rather than going via the current Apple event interface?

The OLE Automation layer is still there. In fact, the VB implementation and the AppleScript implementation are both written on top of the OLEAut layer (which is why if you could do it in VB you can do it in AppleScript.) If RealBASIC uses the OLEAut interfaces (which all still exist) then it can easily drive Office 12, just as it could Office 2004 and X.
As for VBA->AppleScript translators, we’ve considered the idea. The problem is that while the *object model* (ie, how you tell the app what to do) is basically the same, the *syntax* model (ie, what make VB ‘Basic’ or what makes AppleScript ‘AppleScript’ is pretty different. Its easy to get 80% or so translated, but the last 20% is a real pain. Consider the ‘whose’ clause in AppleScript. There is no such beast in VB. Consider VB ‘plurals’ — they don’t exist the same in AppleScript. So, people would still have to do some manual script futzing. Lastly, the Forms UI model in Visual Basic has no counterpart in AppleScript unless you build things in the AppleScript Studio GUI. That can’t be done on the fly, to my knowledge.

I think that compatibility is way more important than a mac feel. Ridiculously more so… So much so, I, and I think those who know that they are not getting a fully compatible version of office (if you were honest you might label the mac version as “Lite”), will probably be running Windows Office under Parallels.
So another suggestion. Forget the next version. Entirely. I will even deal with a more compatible Rosetta version rather than a Universal version. Just spend all that time on updating the current Mac version. That means file compatibility, fixing bugs, and patching things up as best you can. Rewrite only what needs to be rewritten.
And with that time you should theoretically save from not releasing the next version, begin the painstaking process of porting over VBA scripting and aim for the next major release. I have a feeling I am not in the minority about this at all…

I was stunned by the news, and after reading the long and detailed posts about the hows and why’s, I can only say that the festering sore has finally broken open. It should have been tended to long ago. However, in computer terms, everything seems to be a house of cards and nobody is brave enough to try and fix things when they first realize it’s getting wobbly, they hope it falls to someone else’s watch or the product is replaced or will fade into obsolescense. VBA should have been kept portable and done in a more portable way, but as you say, you can’t go back 15 or so years to suggest this, and you can’t even go back two or three years and start the work anew on making the Mac version work more cleanly.
Having said all that, I do applaud you for the more full support of Apple’s technologies that make the Mac stand out and will integrate better with the Mac workflow, which VBA does not do much for.
So, in that light, please at least consider a way to have Macros in the same sense that are stored in global templates and/or documents that contain the AppleScripts. I have nightmares of trying to keep macros and documents together if they are all external.
Thanks for the open and honest dialogue.

[…] In other news, Microsoft has decided to drop VB from the Mac version of Office. They’re open to suggestions. I would have thought the only point of Office on the Mac is to be 100% compatible with Office on the PC. It’s odd that they’re not just migrating to x86 for future versions of Office: Compile the Windows VBA engine with MASM, munge the binary to link into gcc. Yes the ABI isn’t compatible, but that only affects the input/output edge of the engine. I’m surprised that’s a concern to a company that invented thunking… […]

I wrote:
> Office Mac skipped a version in v7 (Office 95) and v10 (Office XP), IIRC.
Ouch; “IIRC” I did not. A few beers on Friday night and all those man-months disappeared. There was indeed Office 2001 (v9) and Office X (v10 for OSX). Sorry for any offence.
CK.

“The OLE Automation layer is still there.”
I did a quick search for an SDK but didn’t turn anything up. Is there one? It’d make more sense for third-party languages to hook in there as it’s much more like the Office/Win API, and cross-platform compatibility is obviously a concern for a lot of folk. Open that up and let the OSS folks have at it. It’d be much easier to do something like VBA->Python translation with vb2Py, for example, if the target API is the same on both languages.
“If RealBASIC uses the OLEAut interfaces (which all still exist) then it can easily drive Office 12, just as it could Office 2004 and X.”
I’m a bit curious that neither Rick or yourself has said anything so far about RB as a potential solution. Porting VBA scripts to RB sounds a much easier prospect than porting them to AS, so it seems an obvious option to yea or nay off the bat. This is not to put down the work you’re doing on Office’s AS support, mind, which is all for the better, but it really sounds like you need to offer existing VBA users some less disruptive transition paths as well. RB costs, but it’s mature and closest to VB so may be an acceptable fit for many VBAers under the circumstances.
p.s. I think you need to put up a bigger sign that says VBA is being killed on ALL platforms and it’s only on 32-bit Windows that it hasn’t stopped twitching yet. Else you’ll still be getting “So when are you supporting VBA?” demands in 2020. 🙂

And what about writting a simple C++ VM for the VB opcode?
There is no real need to write a JIT compiler these days.
Did this solution have been study?
For having written such program in the past, it’s not a huge amount of work. It’s also easy to debug and maintain.
Have you think about sub-contracting this part of the development if you did not have the resource internally?

I know this is VB/Office time in the mind of the MacBU, but to tell you the truth, right now, I have an Office that Works quite well (V.x), and does everything I need, so my main desire is for information (anything really) about my favorite app, Messenger!!
I use this app EVERY DAY, ALL THE TIME, and look with horrible envy (insane envy rally) the windows one…
Is there nothing you can tell us, something to have faith, to wait for??
I would really love that
Thanks

I think someone else made a good point that they’d rather run Office 2004 in rosetta than a new version sans VBA. I’d agree with that, except for the new XML based file formats that will need supporting within a year.
I do feel that withdrawing support for a feature as powerful as VBA, which will have had massive customer investment of time, is not something that the Mac BU should countenance. As a developer, I understand the problems involved, and you have my sympathy. But the reality is that for a lot of customers, an Office upgrade with no VBA is horribly broken.
My suggestion? Go back to the drawing board and figure out a way of making it happen.

We have some VBA code on our account dept machines (windows) that gets all buggy when running on our creative dept Macs. It’s only used as a wizard for address and contact info on letters, memo’s faxes and the sort. Since I can’t tell the difference between VBE, VBA or AS I just left it with that. No big loss there. We are currently looking at a completely different way to produce these kinds of documents, so don’t bother on my account. I did come across the suggestion to try and work it in at a later stage or edition of office. What are your ideas on that suggestion, Schwieb?
Now to get back to your question; I want outlook with decent Exchange support on my mac. Not Entourage as it is now.
– Public folders especially public calendars are almost unusable slow
– Loose files in pub folders are invisible
– Planner doesn’t even have info on my own calendar, oh now it does, oh now it doesn’t…
– I would love that fancy, yes/no answer Boolean to work on my Mac
– I want to know when a appoint has a conflict before I accept it
– I want to be able to accept appointment tentatively when there are no conflicts.
The list continues…
I it getting so frustrating that we are now starting to see Exchange server as a hindrance in stead of a need to have solution.
I understand that MacBU took over the exchange client from the exchange group a little while ago, is that correct. May be you can tell us what happened and why you choose entourage over outlook client, which really needed little more that html support and carbonization. (I am probably oversimplifying the problem).
Thank you for reading my rant and maybe even responding.

How about having a chat with REALsoftware and seeing if they’d be interested in mapping VB calls to RB calls? No point re-inventing a wheel that REALsoftware has already made…

This decision alone will undermine all the great new features that are undoubtedly part of Office v.Next, and it will generate a fresh round of bitterness towards the MacBU and Microsoft (er, it already has). As a manager of software engineers, I feel bad for all the engineers who are pouring their sweat and tears into this massive and important update, when all they will hear are rants and tirades about ugly their new baby is, from the very minute it’s born.
It’s also sad to see another reason created for Macs to become unsupported or forbidden in the enterprise. Every time the platform gets closer to enterprise acceptance, something like this comes along and sets it back. It won’t affect me much, personally, but I can understand the angst that other Mac users are feeling over this decision.
Office 2004 is pretty good. Macs will get faster. Rosetta will improve. I predict that Office 2004 will see a longer life than many intended because of this, as its performance on Intel Macs is already “good enough” and it will only get better.

I find that most of the public folder issues i see with Entourage are a problem with that lame IIS/Exchange interaction that likes to go straight to hell every chance it gets.

In the longer term, VBA will be replaced by the Visual Studio Tools for Office anyway and CLR will be used, so how about porting that to the Mac, at least in the next version of the Office after the next version of Office for Mac.

What needs to be expressed to the Mac community is what will replace VB. .Net?
Making Office “more mac-like” and tying it into the core services does make me happy, but we as a community need to know that no matter what platform a file is made on, that it will look and behave exactly the same, and we need to know what efforts are being made in that area.
Just saying “this is going away and here’s why” doesn’t work as well as “this is going away, but this is coming in, so don’t worry, if it’s made on a PC it’ll work on a Mac, and vice-versa”

Last year, I decided to create a program to transcode obsolete ancient Greek fonts into Unicode in all my Word documents (my PhD thesis in particular).
Since such a program could be useful to a lot of colleagues and students, I wanted to make it available not only for Word 2004, but also, if possible, for Word for Windows, even though I do not use Windows myself.
So, even though I would have preferred, being a Mac user, to explore Applescript for Word and use that along with Applescript Studio to create my program, eventually, I ended up creating a Visual Basic solution.
Programming a Visual Basic program on the Mac using Office 2004 is _really_ not fun. The editor is not user-friendly at all (I ended up doing most of my typing in BBEdit and then checking the syntax in VBE). It crashes a lot. The documents that contain the code get corrupted a lot. Etc. But in the end it worked and the program, GreekTranscoder, works under both Word 2004 and Word 2000 (or later).
The decision of the Mac BUT not to support VB in the next version of Office means it _won”t_ work anymore on a Mac. That is to say on _my_ platform of choice.
In other words, selfish as it may sound, since I was creating that program first and foremost for my own use, even though it would prove useful to others as well, had I known at the time VB would be abandonned, I would _never_ have learned it and used it for that project! I would have dug into AS for Word and used that instead. Since such a solution, while Mac only, would still work next year in the next version of Office.
Right now, I’m inclined simply _not_ to upgrade and keep on using Word 2004. I’m an Hellenist, not a programmer, and even though programming can be a fun hobby, I don’t have much time to devote to it.
If I were to upgrade, I would have to rewrite the whole program as an Applescript Studio project.
So, what I’m asking is this: please include a utility to translate — even roughly — the VB code into AS, so that a good portion of the work can be done automatically, even if one then has to check everything closely. Simply getting a good translation to start from will be a big help understanding the AS syntax Word expects etc.
And include tutorial detailing how to recreate a VB form using Xcode and AS Studio. How to link controls to scripts etc.
In a nutshell, offer first-rate documentation. Example, Sample code. And — even rough — translation tools. Comment out the non-translatable portions if you need to. But make it easy to go from VB to AS.
Best.

What do I want from Mac Office?
1) “no matter what platform a file is made on, that it will look and behave exactly the same” as Joe says
2) old bugs fixed: eg the one that means that exporting a Word file containing pdf vector images to pdf produces a file with non-vector images. How old is this bug now?
3) proper support for Unicode in multiple languages. Word 2004 is only halfway there.
I don’t care about VBA, personally, but if it gets in the way of (1), I don’t see why I wouldn’t just run Windows Office and/or NeoOffice instead, unless Mac Office, unlike all previous versions (because of bugs and half-implemented functions), is a real pleasure to use.

I have read all of the comments for the previous article and this one, I know many have said it already, but I will as well.
I have coded in VBA, VB6, and AS for OS9, am now learning how to script for OSX. But this doesn’t mean I have the time and resources to create two versions of everything.
Office on a MAC is good only if documents can be seamlessly used on both platforms at the same time in the same Enterprise or by sending documents to others. A Windows user will add VBA, so this VBA needs to run for the MAC, and be able to be modified there so the Windows user can use it.
If VBA will be going away for Windows, then hook up with the Windows developers and make sure whatever replaces it is a solution for OSX as well. I don’t see a reason to upgrade to a version of Office that is not cross-platform compatible..
chris

There’s a 3rd category of users out there. All Mac companies that trade files with other companies. Architecture and construction are this way. None of the firms (well almost none) live independently. We trade files all the time. It maters to an all Mac architecture firm if VB vanishes even if that firm never ever ever writes a single bit of VB.
As to the two stated objectives of the MacBU for Office. The majority of Mac users I work with (all the way from my 78 year old mother in law to larger firms where I do their IT Systems Administration) only want office to “feel” Mac like. Applescript support is nice but 99% will never use it. Other “core” technologies are nice but what they really want is to be able to open up that Word document their credit union sent them to process for their loan app. Or the “I’ve read this” check off before passing on the critical change order.
Applescript is a total waste for most of these folks. Maybe a useful addition but in general a waste.
I’m all for a 2004 and a half release. Keep my keyboarding and visual styles Maclike. Keeping the PPC version running with Rosetta is much more important than a more Mac like new Office that breaks many of the reasons I work with it. There are other issues but this will keep many many many design firms in the Office 2004 camp with heavy research into alternatives.

I use VBA for Excel, both on Mac and Windows. I use VBA for solutions like this:
1) Delete blank rows from a worksheet
2) Automate the process of filtering
3) Create multiple PivotTables in a worksheet
I like that I can develop a solution on my Mac, and have it work on my PC, or vice versa. I immensely dislike having to redo my work one for each.
But I can appreciate the pain that the Office Mac BU is going through. Considering that so many userforms and controls in the VBE are tied to the OS, VBA for the Mac was always sort of a chewing gum and duct tape solution. (But damn it, I liked that solution…in absence of anything better!)
I might just have to get an Intel Mac and dual boot…get Visual Studio Tools for Office…not the Mac BU’s fault…just the winds of change.

While AppleScript may be a candidate for replacing VBA, it doesn’t appear to offer the same richness for seamless integration or customization of the Microsoft Word: Mac application. Or at least I haven’t figured out how to attach an AS to a button or menu item, capture keystrokes, or create global templates that automatically load AS ‘macros’.
While I can see AS being feasible for occassional use scripts, it doesn’t appear to allow the integration to make AS suitable for production. And without the ability to embed AS ‘macros’ within a document, it will severely complicate third-party solutions built around global templates. In many ways (from our POV), the defining characteristic of Microsoft Office as compared to other text editors on the Mac _is_ that it has cross-platform scripting. Without the macros, Word: Mac is just another word processor.
Our product relies heavily on VB macros (for both Mac and Win versions) for cross-platform compatibility of both file formats and functionality. The loss of VB for Mac has the potential to kill off further Mac development. If nothing else, it’s going to mean a significant redevelopment effort on our part and significant retraining for our customers as the present UI doesn’t appear to be possible via AS. Nothing something I’m really keen on as both tasks, due to their size, have the real potential to distract us from developing compelling new features.
All I can say is that I hope that there will be significant support to the Office: Mac add-on community to assist them with this forced migration. I’m concerned, very concerned… I don’t want to go all ‘woe is me’, but we definitely need details, and soon, of what features/possibilities with VB will NOT be available via AS, workarounds, equivalent and sample code examples, etc.

[…] E isso é em qualquer lugar do mundo. Olhem este post do MacBU (Macintosh Business Unit) da Microsoft:“[…]I did have an opening for quite a long time, but our overall delta between having someone leave our group and hiring a replacement is probably something like 2 months or so.[…]” “[…]We’ve actually had a lot of folks very interested in working at MacBU (i.e, us having open headcount really is not due to a lack of people interested in working here). We hire world-class developers and they don’t simply grow on trees.[…]” […]

Having read the details in your posts plus the additional comments listed above I don’t believe there exists a “silver bullet” to this problem. I think the best compromise so far mentioned have been 1) IF VBA is to be depricated in the Office suite of both platforms then work w/ the Windows Office team to delvelop a truely crossplatform solution to automation. 2) Provide for translation tools to help users migrate to the new scripting environment. 3)Some warning to users that documents contain VBA macros that will not execute and must be translated.
Aside from that I have to ask What has the MacBU been doing over the last few years??? Aside from a few hardware drivers, RDC and Office what are you doing? I would have thought that after Office 98 was released a small team of 2 to 4 programers would have begun to build Office using the Cocoa frameworks to eventually move away from the Carbon APIs. The understanding being that it may take two additional releases before a truely Cocoa based Office would be available. I know and understand the deep dependencies on C++ objects from Win Office but please in five years you could have found a very good solution ESPECIALLY in light of Apple allowing the mix of C++ and Objective-C. IF MS planned ahead, with the assumption that they were going to continue to market Office for the Mac, then a long term plan could have been put into place.
If you were to announce that the next Mac Office was 100% Cocoa based BUT had to sacrifice VBA I think that maybe you would not have gotten so much heat, MAYBE. OR five years ago when you made the first release of Office for OS X native had you begun the re-write of VBA then. From your description it sounds like hack built on a foundation that was known to be going away. Too many OS9 and CFM dependencies.
Lastly, related to “What are you doing?” How about porting some other tools like Visio or at least a Visio reader. Yes I know that there are programs that can read the Visio XML format files on the Mac but they are far from perfect. In Office 98 if I received a Word document with a Visio diagram embedded Word could display the diagram and print it perfectly. Today with Office 2004 that isn’t the case. Please spare me the “business case” argument, if there is significant demand in Windows, having a Mac version would have demand if for no other reason then to share files.
Finally how about implementing a full Exchange client for the Mac. Again it has been 5 years since Entorage shipped I would have thought your team, being the largest Mac Development team outside Apple, could have accomplished at least that.
Sorry for the rant but maybe now you can understand why Mac users are very skeptical of Microsoft’s Motivations. If you had workable solution to having a first class native Exchange Client for the Mac would the powers that be allow you to move forward? Or how about the ever elusive Access product? How much power does the MacBU have in setting its own direction and goals and priorities?

Joe Barisa asid “IF VBA is to be depricated in the Office suite of both platforms then work w/ the Windows Office team to delvelop a truely crossplatform solution to automation”
Joe, I very much doubt that the Windows Office group would go for this. The Visual Studio group (responsible for the standalone versions of Visual Basic) would *love* for Office to do this, since they created an entirely new platform and an entirely new and incompatible version of Visual Basic to go with it. (See http://www.classicvb.org for details.)
But as far as I can tell, the Office group took a long hard look at the customer reception and the sales figures and decided they really didn’t want to have a comparable percentage lopped off their sales as well. Three versions of Office have been produced since the .NET platform was released (Office XP, Office 2003 and the beta of Office 2007) and VBA is still there.
I suspect that Microsoft has now done enough market research to convince itself that VBA cannot be dropped from Office unless there is a replacement that will enable VBA projects to undergo a conversion to a new language that is about 98% automatic and therefore relatively painless. 3 releases later there is still no such converter between the old VB6 and the current verson of VB.NET, so I suspect that such a converter is a far from trivial task. I would suspect that a converter to AS is probably harder still. How for instance would an AS program cope with the Application.ActionControl object – the button that caused the macro to run?
From what I can tell, even MacBU would be hanging on to VBA were it not for the recoding involved in the change to the Intel platform. They don’t actually *want* the loss of sales that may result from dropping VBA – even if they are spinning it in order to claim that there will only be a minimal effect.
I accept that MCBU are in a tight spot at present. But their choice really does seem to be between the following options, all fairly unpalatable.
1. Drop VBA for now, take the temporary hit in sales (whatever it might be) and work to put it back next time.
2. Drop VBA permanently and accept the consequences in terms of loss of compatibility and probably loss of sales.
3. Delay the next release until VBA can be included, and accept any loss of upgrade revenue in he meantime.
At present, it isn’t clear whether MacBU will choose between #1 or #2. I guess they haven’t themselves yet made the decision. Their actions are equally consistent (so far) with either path. They seem to have ruled out #3 which would be my preferred solution.

My Ideas!!!
Python sounds sounds exciting, and probabaly a better solution anyways. I’ll have to play a bit with that one. If I understand it right, it’s a write once solution? Now trying to get my windows friends to comply, another subject… It might not be so bad with 2007. That would be a very good how-to/best practices guide so we can write cross-platform scrips.
One of the things we use on the PC side is SmartDocs which from my understanding is tied to .net underpinnings. Namely VB.net. (uhhh… more VB) Mono says that their VB solution isn’t quite ready for prime time yet, but that seems to be the most resonable route. How much time it would require to implement it might be a challenge. I’m shure someone has tried it. Would be a very good post topic!
I have a few other things that would make my life easier. (notes and tasks from exchange, other interface improvements) but those i’m shure you have heard about countless times. That would be for another post:)

Rewriting VBA from scratch will not be impossible or too long.
It is not vital to have VBA pre-compiled: a small interpeter will work great.
The brand new Mac will be fast enough, and having the macro working is very important.
Think twice before destroying the only multi-platform (bi-platform) language Microsoft had.
Please.
bye 😉

I believe this choice makes the upgrade to the next version of MacOffice much less attractive unless the new feature that will be included will make it a killer app anyway; this opens up space for competitors although unfortunately I still don’t see many alternatives out there.
Moreover what worries me is that if we’re still debating about these foundamental issues then delivery of the first UB Office version is probably VERY far in the future although the transition to the Intel plaftorm was announced one year ago.

You seem to understand that this announcement translates into “Don’t buy our product” for those of us who are in the know. But have you thought about all those people who will think, “Oh, no VB. No big deal, I don’t use it.” without having a clue that they are using templates that do or that they have third party software that does? And when that group starts clamoring about broken documents, what will you tell them? Remember, you could print in massive red letters, “No VB inside” and a huge number of customers won’t know what that means for them until they start using it. So will Microsoft offer refunds?
This is a massive cluster F*** and in the coming months instead of looking forward to compatibility with Microsoft’s new document files I’ll be looking for a third party program that will let me open those files in Office 2004. I hope I don’t have to write it myself.

On one side we MUST have VBA compatibility – even the simple circumstance of a bank e-mailing you a home loan spreadsheet will suddenly be a problem with a lack of VBA.
On the other it is plain fact that, after much consideration of these recent blogs, VBA as it stands cannot be ported – for the simple matter that the Mac implementation has been clearly a disgusting mess when you consider the efforts put into the Windows equivalent (of any MS product I might add). It is truly a shame when you think back to Excel, PowerPoint, heck even QuickBasic all being such spectacular products on the Mac platform so many years ago.
However let’s wake up to a simple reality of today’s age, and one that Microsoft is only recently starting to finally open their eyes to – open source. This is a perfect opportunity for Microsoft to genuinely embrace the resources and potential of community effort. Why not have Microsoft focus their efforts on providing the VBA:MAC interface into the heart of Office:Mac, while the development effort VBA itself be opened to the open source community. After all, as much as I understand why Microsoft is trying to ignore the existance of OpenOffice, the reality is they HAVE managed to make headway with an open source cross-platform VBA… so let us not kid ourselves that the almighty Microsoft can’t!
Or, alternatively, let’s take advantage of RealBASIC’s proven cross-platform compatibility with VisualBasic (in fact RealBASIC has become what I always thought Microsoft would someday do with Visual Basic years ago)… strike a deal with them to provide VBA:Mac.
I don’t use VBA day in day out – I’m just a regular everyday person who, once in a while through everyday events, does end up eventually dealing with a document that has VBA that until now has simply “worked” transparently but would now, under a new version of Office, suddenly be a problem.
Finally, I hate to make an unproductive remark, but the fact is that for a long time now new releases of MIcrosoft products have NOT had groundbreaking earthshattering features that we MUST absolutely upgrade for. They have evolved in their own ways, but the reality is that for regular everyday use even Office 95 is perfectly fine and there have been plenty of Office releases since then. Now you’re going to sell yet another new release that intentionally omits a major feature that was previously there…. not smart. Fact is, people can just simply stick with their old Office on PowerPCs and likewise Intel users can also use it via Rosetta… a shame but a cold hard fact.
As I said, I consider this all from a pure everyday regular point of view… so then try looking at it from a point of view where you actually do need VBA… there you have an enormous problem…
Before I go can I make a cosmetic request? Office:Mac has some gorgeous custom aqua widgets – the splitter bar, the ruler controls, page buttons, view buttons, etc… and yet in the toolbars the aqua widgets (eg combo box arrows, etc) are crappy “cartoons”… can they please be re-rendered as aqua looking, or will they instead now be native widgets under the new xcode version of Office? Otherwise keep up the good work 🙂

Schwieb Says:
August 12th, 2006 at 5:15 pm
“The OLE Automation layer is still there. In fact, the VB implementation and the AppleScript implementation are both written on top of the OLEAut layer (which is why if you could do it in VB you can do it in AppleScript.) If RealBASIC uses the OLEAut interfaces (which all still exist) then it can easily drive Office 12, just as it could Office 2004 and X.”
Then if the MacBU could work with REAL Software to make sure REALbasic drives the OLEAut layer quickly and efficiently, it would be very good solution to the problem.
Unfortunately, right now, the REALbasic Office Automation features work extremely slowly on the Mac. So much so that’s it’s actually more efficient to use AppleScript from within RB to perform relatively complex tasks ;-(
So please, work with REAL and turn RB into a _real_ alternative to VBA for Office Automation on the Mac.

I’m one of the few Mac users at my work. I’m also the only person experienced in developing Excel macros. So I develop them on my Mac and pass the results on to be used by my Windows-using colleages.
If there is to be no more VB in Mac Office, then this is a problem. I guess that my solutions are:
* don’t upgrade from Office 2004
* stop using Excel workbooks with macros and implement something equivalent, perhaps mySQL/PHP.
So what I want is some way to continue to develop Excel macros on my Mac, pass them to Windows users and have the macros run on the Windows PCs.
If the macros have to be written in something other than VB, that’s OK, I’m prepared to learn a new scripting language. But cross-platform compatibility is critical to me.

How about a simple interface to user-written C++ code? Like the Excel SDK in Win32 land (and yes, even PPC land). Just make it easy to use, and well documented.

A quick search suggests that no one here has yet mentioned the importance of the Auto Macros in VB. In Word, I use AutoOpen daily to force documents emailed to me to open in the Zoom and Normal view that I prefer. I use AutoExec daily to keep enabled some preferences that randomly uncheck themselves. These are relatively simple uses, but are the difference between happily using Word and constant seething frustration for this home/academic user.

FWIW, there is support for cross-platform VB and there are resources who can help.
A colleague of mine has developed and maintained, for many years, a complex spreadsheet underpinned by scads of VB that needs to work across Macs, PCs and Unix. While the task was a continual pain in the butt, he quickly decided that the best solution, with the least cross-platform bugs, is OpenOffice. That (business-critical) spreadsheet is now ably supported by an outfit in Belorussia.
Perhaps a test of your VB code against OOo would be worthwhile?

Why continue developing a separate Office for Mac codebase?
Why not run the Windows version virtualized on the Macintosh? You might have to bundle a runtime copy of Windows, but that has been done before by the Office team, e.g. early Word for Windows versions that could run on top of DOS. Access to features provided only by the Mac OS could be provided by a thunker or native DDE-like server.
Tweak the UI, and nobody would realize it was a Windows program. (Actually, with its new UI, it already does not look like one!)
Moving to one codebase would ensure feature parity and more timely updates. Insulating the codebase from the OS would also hedge against further seismic shifts in Mac architecture (which occur, on average, once every SIX years!)

I have invested literally hundreds of hours in thousands of lines of VBA code that perform custom text-parsing operations on MS Word documents. By pulling the rug out from under all this work, and destroying the value that it brings to my clients, when there are reasonable alternatives (as suggested in other posts), Microsoft is demonstrating its contempt for its own customers. Mac users who don’t need VBA already have other word-processing alternatives; it’s the power users who really need (and are willing to shell out for) Office. For me, VBA has been the only reason to put up with some of the other obvious flaws in Word/Office (e.g. who, if anyone, is in charge of fixing bugs? How do you even report bugs without beingcharged $35 for the priviledge?) At the very least, whatever alternative scripting platform you offer *must* have direct built-in access to the objects/collections that make up a Word document: paragraphs, words, characters, tables, cells, etc… And you should develop and offer for free a utility that accurately ports VBA scripts to that alternative scripting platform. Without these features, you will simply be blowing off (and blowing away) all the people who have relied on VBA over the years, and they will be lost to you as customers.

First off, I appreciate the time and effort you guys put in explaining the whole scenario.
Second off, there’s not much point crying over past design decisions. We are were we are.
Thirdly, while this can be seen as killing Mac Office in the Enterprise, it’s not as dire as you might think. Anyone buying a new Mac is buying an Intel Mac. Which can run BootCamp or Parallels. Which can run WinOffice. Which runs macros. Granted, it’s not a perfect solution, but it works and is future proof. The downside is the cost for enterprise of a Windows Licence and the training / exra time costs for staff. Microsoft could ease these pains by producing white-papers, technical guides and training materials for corporate-types, IT depts and end-users. They could also greatly limit the cost impact by producing ‘bundles’; where if you buy MacOffice you get a Windows licence and a licence to run WinOffice to run exclusively on Mac hardware, at a cost less than that of buying them all seperately. It’s the least the WinOffice team can do (taking the revenue hit) considering their contribution to the problem.
Where this decision really kicks is users of non-intel machines who want/need/ are forced to upgrade to Office07. They are stuck in limbo. Some will be able to upgrade to intel machines, but I suspect most will not.
Other folks have commented on their perception of decreasing committment to Mac products. I say I have to agree – the product foot print is shrinking, the feature footprint is shrinking. I don’t understand why – Mac sales are growing – so you’re in an expanding market.

Can one of you guys explain why the language VB for Office is so complex that you can’t write a new x-platform interpreter, along the lines of python, perl, ruby etc? All of these languages (from the outside) appear far more complex, and yet have relatively small cross platform compilers and interpreters.

I very much appreciate this discussion and your “two pillars of focus” namely 1) making Office mac-like and 2) maintaining compatability with Windows. But I think you have the relative priorities of these two pillars very much reversed.
I suspect that very few of your Office:Mac users install your software expecting to get a “100% mac experience” (whatever that is). Instead, they install Office because they want to be able to use the same excellent productivity suite as their Windows colleagues and they want to be able to communicate and participate with them. If you diminish the participate/communicate part of Office:Mac, there is really rather little reason to buy Office:Mac.
I strongly recommend that you:
1) keep compatibility and feature parity as the number 1 priority for Office:mac
2) make VB implementation a high priority
3) to satisfy 1 & 2, consider delaying a Universal Binary release in the next version, or entertain creative stop-gap solutions that will maintain the functionality of VB, even if it is a temporary hack job

Before I go on my rant, I would like to stress the point that the MacBU Office team has only a fraction of the size of the Windows counterpart yet it regularly managed to produce Mac-versions of Office that were nicer (and occasionally better) than the corresponding Windows versions. Must be a bunch of very talented people working there…
In science, in particular in life-science, Macs are very quite wide-spread, although Macs are more frequent in academic institutions where users can choose (and often have to pay for) their personal informatics equipment than in scientific enterprises where the IT department dictates.
I have personally considered Office a finished suite since Office 98. The only reasons I have upgrade to new versions of Office were compatibility with the current Mac platform (and I understand that Apple is asking a lot from its developers) and compatibility with the Windows counterpart. Otherwise, I think that with every release, the suite got more cluttered and resource demanding, but otherwise, it only gained little useful new features. The core functionality, in contrast, has hardly improved (I am therefore also not surprised to hear that a lot of the core-code of Office is ancient…)
As one example, Powerpoint 2004 has gained a lot of Keynote-like features (part of which were nicely – ehm – implemented, others less). Yet, when I open Windows Office-generated presentations, I often still have to deal with big-red-X-figures or vertical text that is not displayed correctly or figures that are otherwise screwed up. Not to mention that Office for Mac is a graveyard for OLE-data…. I personally think that this is pathetic, and I am really tired of not knowing whether my presentation will display correctly on the computer at the conference. I am also tired of spending a lot of time in converting graphics (e.g. vector graphics, various post-script formats) into formats that are high-quality but MS-safe (i.e. JPEG, PNG), in assistants who tell me that there is a problem but are otherwise not very helpful in solving the issue, or in testing my presentations on different machines. Similar things can be stated for graphics in Word, for that matter.
I really wished that the MacBU focussed an a good and COMPLETE Intel-port of Office because this is going to be the main reason why most users will upgrade (and not a fancy new animation of a toolbar). Please stop overloading the suite with new annoying features nobody is going to use anyway (wizards/assistants/other pseudo-enhancements) but rather focus on its core functionality including seamless and complete compatibility with most other versions of Office. This said, I really think that VB has to be ported, even if this happens at the cost that the Universal Binary of Office will not spot new features other than support for the new Office formats.

Well, the problem behind this is the approach of Microsoft developing first and foremost Windows apps and Mac apps basically just for fun.
Microsoft was to arrogant to develop Internet Explorer 7 for the Mac and Windows Media Player for the Mac, because 90% of it’s core business is Windows and 10% (best-case-scenario) is Mac. Virtual PC has been cancelled, too. A users has to feel dissapointed about this and feel betrayed.
Microsoft had the power to do this, because they could, but again there is a considerable downside to this arrogant approach, when they need their own technologies cross-plattform, well they just aren’t available.
Did you ever wondered why iPod and iTunes took off? It’s cross-plattform and easy. If you make the life of users a hell by getting rid of VB, you won’t make much friends. The same applies to the Office 12-format which is Windows-only for the next 3 to 4 months till a converter is available.
Adobe does it very differently, they do Windows and Mac apps just in sync e.g. Creative Suite or Acrobat. They (i.e. Adobe and Macromedia) get together and think about how to make a cross-platform solution for Windows and Mac.
The problem of scripting does exist in Acrobat 8, too. But on Acrobat 7 and 8 there is no such problem, because whoever wants to do cross-platform scripting never uses Visual Basic, they use JavaScript instead. And it works fine and on both systems!
Another arrogant move is introducing an XML-based Office 12 format which is Windows-only. Adobe has an XML-based PDF format which is cross-platform. It runs on Mac and Windows.
What can you do now?
1) Port VisualBasic to Mac OS X on Intel with Xcode 3 on Leopard (Mac OS X 10.5). Hire new Leopard-savvy developers for this. It’s a lot nicer too delay Office for Mac 6-8 months than searching a new job in about two years from now, is it?
2) In the future try to develop Mac and Windows apps in sync. Take a page from Adobe’s notebook and get smarter, a lot smarter.
3) Treat Mac users like human beings not just ‘cows to milk’. Adobe / Macromedia is quite too big for Microsoft to ignore them. And Apple is more successful with iTunes and iPod, because it works flawless on Mac and Windows. Think about it.
By the way, if you had a cross-platform scripting abstraction layer, you could translate such scripting files into a Windows- or Mac-format on runtime. But for this to take off, you would need one cross-platform solution for Windows Vista and Mac OS X 10.5.
Never the less, all the very best for the future.Take a deep breath and try jogging with an Nike-enalbled iPod. It works on Windows and Mac. Maybe this way you get better ideas.
Apple used to say that Microsoft has no taste. Well, Microsoft has fixed that, but they are still to arrogant. Consider being more open, less arrogant and think first and fore most what your users want to accomplish.
Maybe this gives you some clues what to do.
And whoever claims making great products for Mac and Windows doesn’t work, well check out Adobe. They are living prove that it works just fine. First you have to change your attitude towards your user base.
Read Dale Carnegie, maybe it helps… ;-))

Top 10 points of view/suggestions from someone who lives and breathes on Apple gear in a mostly Windows world. (in a somewhat particular, well maybe not, order)
1) Getting through this “transition” stage is going to be rough. I’m sure many of the MacBU team were wide eyed when Apple announced the move from PPC to Intel. This has exposed the legacy code for what it is. I know I had to pick my jaw up off the floor, as many products were still unfortunately not written within Apple’s development toolsets when the announcement was made.
2) I’d love to believe that Intel code is Intel code and that you can call over to the Win Office group and copy/paste. It’s far from it since each OS brings its own independent APIs – leverage the existing technologies as best you can – Rosetta, AppleScript, XML, etc. Produce what you can until the total death of VBA is complete – on both Mac and Win Office products.
3) As VBA is killed entirely, ensure that transition support is there (it seems like you’re doing this) for the major 3rd party vendors who built, no, resold their solutions based on it. If you can ensure their products will function moving forward, that’d be huge. Many folks utilize VB on the Mac without sending it roundtrip to Windows and don’t even realize they are.
4) Get to the next generation cross platform scripting/automation in Mac and Win Office AFAP (As Fast As Possible) if the VBA stuff is so old on BOTH platforms, get the braintrust working on the ‘next great thing’ TOGETHER, then get it into both Mac Office and Win Office – again, AFAP.
5) Don’t treat the ‘death of VB’ as secretive (as a marketing perspective). Honesty about a true future growth path would be better than just pulling the rug out from under people without a simplified, public explanation that things had to be redone, they’ll take some time, but the future will be good karma once more. But figure the future path and stick with a consistent message.
6) Make the next office rev Lean n Mean – a true Mac ‘suite’, worthy of being called the best ‘office suite on the Mac’ instead of just ‘the only choice’. Don’t try to make Word the be-all editor for web, DTP, and such. Focus needs to return to each aspect of the suite. (This being said as competition is obviously increasing with the resurgence of Apple in general) But don’t go overboard either. There’s a lot of insight in the “remember how people stuck with Word 5.x after 6.x came out?” comments.
7) Don’t get so caught up in Mac-ify-ing things for glitz that getting back to 100% cross platform compatibility never occurs again – it will hurt the Microsoft on Mac perceptions irreparably, and possibly tank the MacBUs reputation permanently. I think if there’s a ‘light at the end of the tunnel’ it can buy you time to get it done and shipped, but even that time will be limited.
8) This is #8, but probably could go first, since you were asking what do you really want – Make Mac Office AWARE of Mac OS X’s underlying ‘general’ technology changes. IE: there’s multiple users locally on the workstation, or better yet, server based LDAP directory users, with pure Network Accounts, with portable/home directory syncrhonization, Workgroup Management policy implementations, etc. The last 2 revs of Office for Mac cause needless suffering in these environments simply due to the fact that they seemed to be developed with “nobody but one user on one account will ever use this software – and only from/on one machine” syndrome.
People do use Office on the Mac independently – never sharing with Windows users or others. But more and more, people are using its outputs collaboratively, in workgroups, with designed workflows, server shares, restrictions, quotas, etc. Don’t think simply within the confines of Microsoft’s own server solutions – be aware that those collaborative environments are built atop a new OS X ecosystem of its own.
Just skimming the MS Kbase alone, the Office Suite Self-Centerdness (not that you guys are, just that the suite itself seems to be) seems to also plague the Win Office releases when deployed in highly managed Windows Server environments too, though maybe not as acutely.
9) As the previous poster noted – Releases that are in sync (Mac/Windows) would be huge, though I suspect that the resources on the Win Office side of the house are probably 5x Mac BU’s. If so, that’s just disheartening, as it would probably prevent this from ever happening. Hopefully the powers that be within Microsoft can be made aware and make the necessary changes.
10) Don’t give up! The work you do must be extremely rewarding in the long run. Make your mark! Us Mac afficionados await what’s next!

I’m a translator. I make a living using a CAT (computer-assisted translation) tool called Wordfast, which is a series of macros that build a database of phrases and interactively suggest the best match. It’s fast, finding matches in less than 0.5 sec among thousands of entries. It’s the only CAT-tool available for Mac and I’ve been using it for four years.
As of today, the Wordfast forum at Yahoo has 4833 members (http://tech.groups.yahoo.com/group/wordfast/members).
Proz, one of several translator-resource sites, currently reports 8535 members owning Wordfast (http://www.proz.com/cat).
For the sake of using whole numbers, I’d say there are at least 10,000 users of Wordfast out there. Of those, about 4% would be Mac users, right? To that’s 400 less copies of Office 2007 for Mac you will be selling.
Daniel

I agree with all of the expressesd sentiment regarding the importance of VB to the corporate market – it is a key component. That said, instead of porting it, would it be possible to work with Apple to write some Rosetta ‘glue’ so you could just keep VB running in emulation within the native Office? I suspect the engineering work would be relatively (relative to porting VB) simpler and shared with Apple. Yes macros would be slow compared to the rest of the system, but I doubt very much slower except for the most complex among them.
This provides a real ‘win-win’ since MacBU doesn’t have to port the code, yet Office 2007 retains it’s cross-platform capabilities. All they would mostly have to do is maintain the glue and any bug fixes to VB (but no more than they do now).
Thoughts?

Ok – I should have read the entire article first (I went striaght for the comments) as this is obviously directly explored and rejected. I do agree it would add complexity, but there are no easy solutions here. Given the focus, couldn’t it be possible to offer a ported version of VB at a later date? That could preserve the current schedule, while allowing the MacBU to focus testing/rework efforts on VB after GM and resources become a bit less scarce.
I agree this isn’t perfect and still has them reworking old code – but I’m afraid there isn’t really a good alternative. Droping support entirely is the least best option as it drives office (eventually) out of the corporate world. Not right away, but it will curtain sales of office (as pointed out ad naseum here). I know the smart folks at the MacBU realize this, so obviously they’re taking a calculated risk. How much risk? Probably not much in the near-term, at least once the WinOffice ’07 converters are available. Few corporations are going to immediately buy and deploy new versions of Office on either platform – they’ll start their integration testing, etc. Most corporations will keep the current Office ’04 + converters in place for now and it will work just fine. Long-term, though, the landscape changes considerably.
Over time corporate IT departments will turn their plans to phasing out Office on the Mac and looking to alternatives, such as Parallels + WinOffice, especially given Parallel’s new abilities to run Windows apps in a seamless window off a bootcamp drive. This will satisfy them, since it becomes a single support solution, while still allowing those ‘Mac heads’ to keep their current systems.
The morale of this story is that the MacBU could still turn it’s attention to porting VB, warts and all, over a greater timeframe than the main application. If they took that course and announced it will be delivered later this year (or heck, even early next year), it would change everything.
1. Corporate users would be fine keeping what they have today (plus ’07 converters) AND be able to justify Mac purchases going forward.
2. IT depts. would be assured that the new functionality was coming and could plan their testing/roll-out, etc. To them there would be no break in functionality.
3. Small-business/home/etc. users will purchase MacOffice ’07 when it ships (those that don’t need VB support). So they get a new release AND they get to debug it before corporate users get it later on. This is a good thing as there will be several bugs fixed before the VB-edition would be available.
So, while the cost and complexity is there, the pros outweigh the cons from a customer standpoint. We understand it isn’t easy (working with old, crufty code never is); however, it is truly necessary for the long-term longevity of MacBU. Not today, or probably next year, but starting in ’08 without VBA, MacOffice sales into the corporation will start to falter.
And no one wants to see that!

Delay the release, however long necessary.
Without VBA support, we will not be upgrading. In fact, I may need to pro-actively purchase Office 2004 licenses so I am not forced to use broken Office release. Because without VBA support, Office is broken.

For a further typical example of how people are hurt by not having vb6 in Excel, just go to my website at http://www.japaneselearningtools.com.
Honestly, if Office for Mac isn’t compatible with anything but itself, I can’t think of any reason for anyone to buy it (except if they are ignorantly assuming it can read Windows Office documents). Claiming compatibility without vb support is basically a marketing invention and not compatibility in any real sense (WAAAYYYY too many spreadsheets have macros for any organization that uses Excel to find this acceptable).
I can’t argue whether it is worth Microsoft’s resources to port VB6 to Office for Mac, but if it’s not, then just kill the product. There’s no reason to release a product if people will only buy it by mistake (i.e., thinking it will read Windows Office documents). There are plenty of free and cheap alternatives that read Office documents without macros, and none of them are used by businesses either.

I use VBA extensively in my use of Excel and Word to interface with 3rd party SDK’s. However, I think given the problems, go ahead and throw VBA out. I would rather have the R&D time spent on making the existing product work more efficiently than throwing away time and money.
That being said, I would like to see a “Rosetta-like” translation of code. VBA instructions written on Win Office get a checkbox to “Compile for Mac”, AppleScript instructions on Mac Office get a checkbox to “Compile for Win”. Each office product would then be able to translate the instructions into it’s native format. It’s a sort of .NET approach where it doesn’t matter what language it’s written in. Would it be possible to have the Mac / Win Office BU’s get together on this?

May I make a suggestion: either make the new XML Office converters available for ’04, or release ’07 and work on the VBA as a later addon (i.e. after 5-10 months, or however long it takes to port VBA to XCode/Mac-Intel). This might make users frustrated, but they won’t go lynching you over the fact they have /no/ VBA support at all.
Just my suggestion.
Also, I agree with the majority of the people on this blog: Make the next scripting language cross-platform from the get-go. If you (and WinOffice) do, you will hear the collective sigh of non-frustration as MacOffice users will use this language gracefully with their Windows neighbors.

Madd,
The converters are going to be released for ’04 in a few months – that’s already announced. For folks asking MS to use a cross-platform scripting language, they really have no impetous at this point, given the large install base of folks that know VB already.
Instead, if they took the Monad approach, where it was a generic scripting engine with language plug-ins, then VB is just one of the options, AS could be another, Perl, etc.

All I can really tell you is that Office 2004 for Mac is just terrible. I would like to see Microsoft office the same on both Win and Mac platforms.
On the Mac it is not really worth the money because it turns out to be a substandard product when compared side by side to it’s Windows counterpart. Office 2004 doesn’t even come close. Even the wizards are a goofy substandard version.
For example, viewing page layout after completing the envelope wizard, the text is there. Looks great and ready to print. Click over to Normal View or Preview and the text is gone… and that’s what it prints… a blank page. I’m no expert, but if this were Windows, it would have been fixed already and two hours later, I wouldn’t be typing this on Schwieb’s blog.
Why can’t Microsoft just make one source for Office and port it to Windows, OSX or other platforms? How hard could this possibly be?
Thanks.

It seems like REAL Basic is a viable solution, and the syntax should only need minor tweeks from what we’re used to – as well as be cross platform.
My bigger question is what happens to our user-defined functions and formulae in the new version of Excel?

A followup to my previous post.
I wandered through CompUSA today checking out the new Mac Books and I tried Excel 2004. Under the Macros area it offers a choice of either the VBA Editor or the Real Basic Editor – built in!
Does anybody know about the built-in Real Basic editor or will it also go unsupported in 2007?

I have noticed that people continue to add to this thread, and that many have suggested RealBasic as a possible workaround for the elimination of VBA support. Others have suggested open-sourcing the VBA code.
It seems pretty clear from reading these posts that cross-platform compatibility is higher on Mac customers’ priority list than you thought. Given the substantial impact the loss of VBA has on cross-platform compatibility, I wonder if you could respond to these suggestions, and give us an idea whether tweaking RealBasic or open-sourcing VBA are under consideration as possible solutions or, if not, what the barriers are.
Also nice would be some indication whether the “next generation” scripting language will be cross-platform, and Mac compatible.
Thanks
Carroll Wills
P.S. FWIW Though I am not a “power user”, I also believe that cross-platform compatibility is, and should be the highest priority. MacOffice is a great product, but its single most important feature is the universal file formats, which allow us to work in a Windows world. I daresay that, for the vast majority of us, Office 2004 will continue to be useful for sometime ahead, but only if it can play well with Windows … in whatever form it takes.
My .02

I noticed a post on Endnote, but no follow up – does elimination of VB in Office mean that Endnote will not work with future versions of Office? In my field (academic biologist), probably half my peers use Macs, and if they are writing a grant or a manuscript, probably half of them (or more) use Endnote for reference management. If future office versions won’t work with Endnote, that’s a lot of lost upgrades, and a significant problem for a large market. I for one wouldn’t be able to upgrade of Endnote won’t work in future.

Sorry, I only took enough time to read through half the above comments.
My suggestion to your problem :
– publish the current Mac VBA / VBE etc. code to open source
– contribute one FTE (full-time equivalent) to answer questions from the open-source community
– open handles between Mac Office and VBA, and implement a scripting engine plugin architecture between Mac Office and Automator/AppleScript.
This way, you could expect the open source community to design, develop, test and deliver an open-source VBA engine to plug into that architecture, maybe even in time for the Office 2007 product release.
If you could finance some of that development (or tesing), that would be even greater … !

What I most need to be able to do is complete spreadsheets issued to me by my clients/suppliers which are built on Excel macros. (E.g. I regularly need to fill out time sheets and accounting information.) Occasionly I also get send Word documents with macros that I need to be able to complete.
I don’t know whether there is an easy way you could achieve this.
Oh and I find the “Record, Macro” function quite handy. Please make sure this can still be done with AppleScript. (Actually can you give us this as an update to Office 2004? It would give us a chance to prepare for the change.)

There’s probably a reason I don’t understand why you can’t do this but I thought I’d ask anyway: Could you have a PowerPC-only build of Offic 2008 that keeps the VBA? That way users who need VBA for cross-platform compatibility could continue running under Rosetta (it’s more than satisfactory IMHO) until you work out what to do for future versions.

I am not a developer. I am a professor of forestry and hydrology at a university in California. I just heard the news about VB not working on my new MacPro for the next Excel version. I guess the users in the trenches are the last to know.
Our department has one Mac lab and one PC lab. We teach both platforms in order to provide students with the ability to work in both environments. As such, we have to have cross-platform functionality.
I have written dozens of Excel VB programs for our students and our college. They are used on Macs and PCs alike. I’m sure a programmer would wonder what I am thinking if I shared my code, but the point is, that I can do it, and the programs work.
Literally, I have spent thousands of hours over the past 15 years writing vb in Excel. For example, my graduation planning program has been in service since 1991 and still works fine. Nearly 2000 students have used it, on both Macs and PCs. Another program was written for managing an urban forestry database. It is 13 MBs of code. Why in Excel? Because that’s what the majority of the everyday users know, and they can use it with minimal instruction and with familiarity.
Excel is a fantastic program and I have taken every opportunity to expose our students to its capabilities.
Now what?
Run a whole computer lab with Parallels?
Stay with Excel 2004 until I die?
Only hire new faculty that use PCs or don’t use VB?
Dumb down the curriculum using non-VB spreadsheets?
I’ve never seen such a disservice to MS users in my life. Rather than share my feelings, I’d rather ENCOURAGE RECONSIDERATION. We have been faithful MS proponents since Excel 1.5. Don’t leave us without feasible or realistic alternatives.
What do I want? I want VB in Excel — even if I have to wait for the next release.

This appears to be consistent with the the “Thou shalt not allow any Microsoft product to be used to create anthing resembling applications on a Mac.” rule. The only reason that I continue to purchase Office is the cross-platform compatibility. Now that this is gone I see no reason to put up with the “Microsoft treatment” any longer.
The same lame excuse was used by the IE developement group when asked why does IE _still_ not support XHTML in a standards-based way. What it boiled down to was a choice between doing it correct after several years of doing nothing and slipping the release schedule or leave it broken with promises to fix it now that they can catch their breath.
Cross-platform compatibility or nothing is how I feel. Stop wasting time making excuses and get to work _now_ on doing it right!

What about a VB – applescript converter. This would allow a Mac user to take VB code, run a converter on that translates it to Apple script allowing them to run it, alternatively, they could take an applescript and convert it to VB. Certainly going the other direction would require certain rules to be followed (Can only use vocabulary in the Office AppleScript dictionary) My concern is not having VB per say, it’s being able to ineteroperate with Windows users. The converter doesn’t necessarily have to convert VB sicne VBA is going away on the windows, side as well eventually, but if it did the latest and greatest application programing that would be far better then not being able to run them at all.

Mustafa’s suggestion from Feb. 9th is interesting and I think deserves consideration. Much like how we now have the situation of only having access to certain Internet Plug-ins if we run Safari via Rosetta (like Shockwave, and others), make VBA an option only if people check the “Open in Rosetta” box.
That way, you don’t have to port anything, and people still get access to the new features of Office. Then, when you’re ready to release the x.5 release and have figured out how to get VBA to be fully native, the first time Office notices itself being launched on an Intel Mac via Rosetta it can pop up a dialog box saying “Thanks for your patience! You can uncheck that box now!”

Okay here are some very specific things I would like to see in Office, mostly excel.
1. How about a feedback option where users can submit bugs, suggestions and feature requests similar to Apple’s iLife products.
2.A plug-ins set of programming templates that would be installed if xcode is present. Those who would like to write plug-ins would have the tools, interfaces and libraries present when they launch xcode.
3. Excel specific- How about a collection of BitWise functions like
value1 is an integer value of byte size “size” (1,2,4,8,16,32,64,128,512,1024)
value2 is an integer value of byte size “size” (1,2,4,8,16,32,64,128,512,1024)
Returns an integer value of same size.
BitAND(value1, value2, size)
BitOR(value1, value2, size)
BitNOT(value1, value2, size)
BitXOR(value1, value2, size)
BitNAND(value1, value2, size)
Bit test would be slightly different with value2 = to the 0 based index of the bit you wish to test (assuming a BigEndian formatted number)
BitTEST(value1, value2, size)
4. Excel based function. GetItem(string, item, del)
Returns a sub string containing the item “item” of the string that is delimited by “del”.
For example a string formated “fe80:0000:0000:0000:0216:cbff:fec0:c479”
GetItem(“fe80:0000:0000:0000:0216:cbff:fec0:c479″,3,”:”) would return “0000” as its value.
5. Excel based function SetItem(string1,string2,item,del) would replace item “item” in string1 with the contents of string2 using del as thhe delimiter.

This thread is old, but since the problem isn’t going away anytime soon, I feel it’s OK to add my comment anyway.
1. I don’t like Office. I think it’s ugly, confusing, slow, irritating, buggy, and generally rotten beyond description. I think Office isn’t even worth the HD space it takes up, never mind the considerable amount of money it we have to pay for it.
2. Despite my strong personal dislike, I always buy Office and install it on all of my computers. There is one single reason for this: Other people insist on producing .doc and .xls files (forgive them Father, for they know not what they’re doing), and I need to be able to open them. I’d certainly never tie any of my own work to these untrustworthy and proprietary formats, and keep praying with fervor the rest of humanity will come to it’s collective sense, but until that cold day in Hell comes to pass, I do need Office.
3. If a future release of Office looks any more or less like it belongs on a Mac is completely beside the point. It could look like it belongs on a Commodore 64 for all I care, I don’t like it anyway, and avoid using it whenever possible. The day I don’t have to start up Office at all is a happy day indeed!
4. The question whether feature X should be added or feature Y dropped from Office falls completely outside of anything I’d ever care about. I’ll be certain to use feature X precisely as much as I have previously been using feature Y, that is not at all, ever. Feel free to add as many paperclips and puppies and wizards as you like, it matters not the least to me. The ONLY feature of Office that has any value whatsoever to me, is the feature of being able to open all the .doc’s and .xls’s produced by those unwitting people out there (bless their ignorant little hearts). Amazingly perhaps, I’ll pay a stiff price for that feature alone.
5. A new Office version that cannot open .doc’s and .xls’s reliably is as useful as a – sorry, my imagination isn’t vivid enough to imagine anything equally useless to compare it with. Most useless things in this world can at least be used as doorstoppers, but the bits and bytes that make up Office aren’t even good for that, lacking the neccessary substance. No new feature of Office can possibly make up for such an inability to open the files it’s meant to open. Take away the sole reason for a thing to exist, and what do you get? Nothing.
6. I will not install any such crippled version of Office on any machine I own, not now, not in the future. I will rather install any other combination of software that performs the necessary function, even if this should end up being a whole Windows partition with a proper version of Office to go with it. I don’t like or want Windows on my HD any more than I want Office, but we’re talking about pure necessity here. If Microsoft intends to scrap Office for Mac, and thereby force me to buy two products instead of one, it’s a sacrifice I’ll just have to make. If Microsoft decides to bleed me, I’ll bleed, simple as that. That is, unless someone else offers another solution to the sole problem uniquely solved by Office: The problem of reliably opening .doc and .xls files produced by Office on Windows. In that case I give Microsoft the finger.
Am I alone feeling this way about Office? I think not. I understand it can’t be very fun to work on something so unloved, but the fact is, very few people buy Office because they love it, especially Office for the Mac. If you imagine otherwise you’re lying to yourself.
What should you do then?
You should make Office 100% cross-platform, at the very least as far as document compatibilty goes. For your own good, it should really be compiled for the different platforms from a common source tree. To have two teams working on two versions in parallell is just incredibly stupid. There’s no other way of putting it. Such an organisation wastes money for Microsoft, while at the same time guaranteeing compatibility problems for the end users. And as I said, no amount of ‘other benefits’ can possibly outweigh this! Of the two Office versions, the Windows version is obviously the reference version. The Mac version needs to be exactly the same, not better, and certainly not worse.

As one of the first to comment noted, few users upgrade Office on existing machines. By dropping features from Office, you simply make the distinction between Mac and PC that much greater. It seems that Apple will be happy to fill the void that MS leaves on the Mac, and MS is happy to cannibalize the Apple user base. Personally, I see little reason to upgrade from Office 10 for Mac, and will happily be living with my PPC machine for years. By the time I buy another machine, I expect that OpenOffice will have done a lot of catching up, and will be a reasonable alternative to MS Office, and that Apple will have their iWork suite perfected. If you want consumers to buy Office for Mac, it needs to have some compelling features – and I don’t mean proprietary file formats. Compatibility and standards are the wave of the future – if MS cannot embrace the move toward open standards, it will die a slow and painful death at the hands of Apple and the open source community, IMHO.

What about the idea of creating an add-in for handling the XML files?
It would insure compatibility with newer files and ‘buy time’ for the VB rewrite which could be done in a ‘more modern method’ to allow for future architecture changes…
What about using spawned processes to handle the macro steps? Spawn to GCC or other available language. I’ OS and Kernel ignorant but threw it out anyway.
What about creating a ‘pro-version’ of Office for the Mac that would roll VB or a follow-on bit to add the functionality. MS wants to make more money, right? There is another way to get ‘mo’ money’…
What about the idea of killing the PPC code for macros? Hell, I’ve bought software that wouldn’t do certain things because of the hardware that I happen to have so why would this be that much different…
What about turning the proposal for a new Mac/Intel VB over to the Idia programming group and letting them prove why they are better than using American programmers… I mean, if they are that ‘cheap’ that everyone is flogging themselves to jump there, why not use them… Heck, you must be able to use 10 for the cost of one of the formerly employeed American programmers wandering the streets… OR, better yet, why not submit the code that you have, all of it, and allow outside groups to do the dirty work for you. I know that looks like ‘open source’ but it might work… It would help keep out of work programmers busy and keep them from writing violent porno laced video games…
Sorry for the snark… I was replaced in a prior career by a ‘team’ of programmers in India…
PS: Is there a version of Basic for the Mac? I didn’t realize there might be which leads me to another possibility: What about switching macro’s in Excell to another language than ‘VB’ on the mac and depricating ‘VB’ on the PC too… I’m sure that a ‘better’ language could benefit BOTH the mac and pc realm…

You stated that the MacBU has two primary goals for office:
1-Cross-platform compatibility
2-Mac specific features, interface, etc.
It is my experience that the majority of Mac users / Mac businesses purchase Office because it is a good program and cross-platform compatible.
I strongly urge the MacBU to put more resources on cross-platform compatibility, and less resources on Mac specific features. Office is a good program on Windows – just give us the same. In fact, it is difficult to work with others (on Windows) that do not see the same menu options, features, etc.
Thanks for Listening

It might be just me but in the world of bootcamp i’d love to see a twin license for software. I switch between mac and win a lot and am fairly tired of rebooting to use apps which i have the other version of. This would at least let me get at the macro’s i know and love.
Cheers.

Tim Golobic question is relevant. Do we still get all the built in Excel spreadsheet functions? I have written a ton of functions that I use all the time including using very large arrays in memory which would be horrendous if possible in Applescript.
I am just reading the April 2007 MacTech issue on moving to Applescript from VBA. I seems like it deals mostly with formatting worksheets. Nothing about hard core number crunching user defined functions.
This is really incredible corporate integrity.

Life has to be tough at the MacBU in Microsoft, and I appreciate that this was a hard decision. My office is mixed platform of Windows and Mac, our primary work tool is Excel, and we use lots of Macros to perform all sorts of complex analyses; which we have to share with client who are all PC operations. Consequentially this means we’re not going to be able to upgrade to next version of Mac Office, but maybe we’ll upgrade Macs to Intel versions anyways and run Parallels.
However, yesterday I was reading about Silverlight and a mini-CLR from .NET running on Mac OS X.
Which leads me to the thought that perhaps if next Windows Office uses VisualBasic.NET rather than VBA — which seems like a sensible idea to me — it could be possible for the next next version of Office on the Mac to also use .NET?

As CTO for a vendor that makes enterprise content management software that competes (and cooperates) with the likes of Filenet, Open Text, Documentum – and these days Sharepoint 2007 – I want to convey that taking the decision to dump VB without providing a future unified (.Net presumably) direction to reunify the tribes is tantamount to corporate genocide for Mac Office and therefore Macintosh.
If that is the goal (who knows these days who is actually at the wheel), then declare it and be done with it.
If not, and we’re supposed to believe this is an innocent product management position, it is a stupendously ignorant move that will doom the product just as Word6 did for so many years, a primary contributing factor to Apple’s time in the corporate wilderness.
Schwieb, this is not a technical decision, regardless of your pain. It’s a political one. If you guys delude yourselves that people buy Office:Mac because it’s “Maclike”, or has great features, or is “better” than the Windows version, think again. They buy it because they have to in order to survive in an Office/Windows dominated world. They sure as hell aren’t going to buy it for Applescript.
At a time when large (>10,000 user organisations) corporate and government customers are beginning to return to demanding cross platform compatibility for software (at least in our category), you are dumping this very capability from your own product.
This is not about “telling you what we want to do”. Mapping feature for feature to Applescript, RealBasic or any other technology is like blowing in the wind.
100% document fidelity must be your foundation, then and only then can you erect your stated dual pillars of “Maclike” and “Winlike” on top of it. Document fidelity is a composite of presentation AND behaviour. That means VB in your world.
Please note that this isn’t an endorsement of the nightmare that is VB/VBA. However you guys made this bed. You have to lie in it. Weeping for the MacBU or the fact that none of you wrote this code is hardly a mature position to take.
The only way it is acceptable to dump VB is if the announcement is couched in terms of “Microsoft is end-of-lifeing VB on all platforms as of 2008, replacing it with xxxxxx.” Try doing that to the Windows world. Not going to happen.
Please reconsider this untenable proposition and restore confidence to what, until now, was a fantastic renaissance starting with Office:X

Leave a Reply to David Kilzer Cancel reply

Your email address will not be published. Required fields are marked *