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]