Today I created an Automator action that moved the currently selected file to the Desktop, then Exposed away all the windows. The crux of the script is found in this Mac OS X Hint

-- All windows tell application "System Events" to key code 101

use the using command etc parameters to "hold" the command key down.

In the WWDC buzz we heard the announcement that Microsoft was discontinuing VBA support for its office suite. This came as a serious blow to me: right before I left Rochester, my co-worker at my part-time job was porting a spreadsheet solution that used VBA from Windows to the Mac. Of course, he complained that the Mac version of VBA didn't work like the Windows version, and of course if you were making a Windows call that you had to replace it to call the appropriate Mac thing. But it was possible using the same codebase.

Well, as of a few days ago, it's not anymore. To write a cross-platform Office workflow you have to write it twice, once for Windows (in one language) and once for the Mac (in another). Probably this will mean less Office workflows will make their way to the Mac.

Thanks to the blog of a developer (the Software Design Lead at the Macintosh Business Unit at Microsoft, actually, so this information is golden), we now know why.

I want to say right up front that the MacBU is very aware of the pain this decision will cause for users, consultants, and enterprise organizations. I’ve personally seen the phrases “apoplectic with rage” and “absolutely livid” in two emails that crossed my inbox. Some people made comments on my post yesterday that were expressly clear about how this decision would drive them to one of the free Open Office variants instead of buying Mac Office 12, and other posts in other forums made similar statements. I’m sure some people will indeed decide that lack of VB is an absolute deal-breaker and they will plan to use other software. I’m truly sorry if that is the case for you.

The MacBU did not make this decision lightly.

and...

[The Execution Engine for] VBA, on the other hand, is incredibly difficult to port to Intel. The execution engine basically runs through the previously mentioned opcodes and, well, executes them. The hard part is that ‘executing’ them doesn’t mean interpreting them, it means converting one or more at a time into a block of assembly generated at runtime that looks and behaves like a regular function that can be called directly by other normally compiled code. This is in essense ’self-creating’ code, and VBA is constantly flushing the CPU’s code cache in order to mark these chunks of data as executable. VBA’s generated code must adhere to the Application Binary Interface of the host platform (historically PowerPC and the Code Fragment Manager). This means register allocation, stack alignment, parameter passing locations, etc. VBA is basically a compiler that emits code at runtime.

Basically: It would be painful beyond belief to get this to Intel. Also, given the rate of development of GCC it might break with every version (or even revision level) release of the OS.