Microsoft Says VBA Is Here To Stay

Angostura writes "Microsoft's team blog for Microsoft Excel and Excel Services has responded with a denial to the earlier report that Visual Basic for Applications will disappear from Windows Office in 2009. The Slashdot discussion on the report on Tuesday got pretty animated."

Comments

that was a close one.

[kellyb9]

Oh thank god... don't know what I'd do without that!

That's not the problem

[Apocalypse111]

Customers don't want VBA to go away.

They want the damn ribbon to go away!

Would have been a mixed blessing

[HangingChad]

I absolutely hate VBA but it's conflicted because I've made so much money untangling some spaghetti coded VBA nightmare cobbled together as a spare time project that became a legacy application no one can live without.

Hate the language, love the money from fixing it.

Re:ISOfication of OOXML vs VBA

[morgan_greywolf]

Agreed. VBA obviously can't be part of the ISO-ificated OOXML. VBA is probably going to be considered a 'legacy' feature, with recommendations that customers do new development on VSTA/VSTO.

If history is any judge, many VBA apps will one day not work in future versions of Office anyhow. MSFT does plenty to break compatibility between releases. In fact, some VBA apps developed for Office 97 won't work on Office 2000 or later.

Well, that doesn't matter

[El Lobo]

We bashed them when we read that they wante to drop it. let's bash them because they don't. Hell, this is Slashdor, isn't it?

Re:Actually, no. Did you RTFA before submitting?

[HiredMan]

VBA is gone from Office for the Mac and VBA developers is closed. Microsoft is acknowledging that both these "clues" that made people conclude that VBA in Office was going away are true - but they contend that VBA in Office is not going away.

"The facts you cited are right - but your logical conclusion was wrong. We're Microsoft and we are not bound by logic."

Basically.

=tkk

How about using .Net?

[mallardtheduck]

What I would like to see would be a .net based macro system in Office. Something where we could write macros in VB, C#, Python, or any other CLR language.

Since .Net has built-in support for different trust levels, code signing, etc., security should be more manageable.

Most of the work is in fact already done. The Microsoft.Office.* hierarchy already exists in .Net, all that is really needed is a way to embed .Net code in MS Office documents.

Re:ISOfication of OOXML vs VBA

[ozmanjusri]

If history is any judge, many VBA apps will one day not work in future versions of Office anyhow.

Actually, that should happen sooner rather than later, so this announcement is a retrograde step.

DDE, OLE, COM and DCOM are fundamentally flawed models which were developed in a much less fraught security environment than we have now. VBA is heavily tied into that same flawed architecture.

Microsoft has tried to address the exposures by disabling macros by default in Office, but the control they provide isn't fine-grained enough to do more than pass the buck to the customers who have to enable the lower security levels to get their documents working.

They do have an answer in .NET, but until Office is re-written for that platform, and until there's some sort of converter for the massive collection of existing VBA to VBA.NET, they're stuck with the risky and clunky security fix.

Still...

[Nom du Keyboard]

Still, even if they keep in in Windows Office, there's no question that it's gone in Mac Office 2008, and that's a huge monkey wrench in mixed business environments. While I'm sure that the Microsoft "solution" is to just have you dual-boot into Vista when you need to run VBA on your Mac, this seems to clearly be an attack on Apple's recent success, and could be a deal-breaker in a significant number of environments.

Or Mac users could refuse en masse to "upgrade" to this "downgrade".

Re:Of course,MS is catering to their real customer

[samkass]

Looks like MS may be crippling the Mac version to stop enterprises from moving on from Windows.

Vista needs some competitive advantage over MacOS X, I guess. Since OpenOffice supports it, though, I suspect most Mac users would rather give up MS Office than MacOS when possible. Considering the Mac is growing 2-3x the industry rate, tying Office to Windows in this manner is just Microsoft nailing one more nail in their own coffin.

Re:Oh well.

[thePowerOfGrayskull]

...which is great until they want to share a document w/ macros with someone on Windows...

Boggled

[samael]

Has anyone actually read the original explanation for why Office 2008 isn't getting VBA?

http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/

Which makes it very clear that there are good technological reasons for dropping it. Or, at least, it's going to be such a huge amount of work to bring it natively to Intel that it's not worth it to MS.

I mean, sure, some people at MS may be happy about it vanishing, but it doesn't sound like a conspiracy to me...

Re:Boggled

[SpaceHamster]

Which makes it very clear that there are good technological reasons for dropping it. Horseshit. His post says, at great length, that they didn't want to write a whole new jitter for the mac-intel platform. Fine, sounds tough. Wouldn't interpreting the VBA opcodes be worlds easier (and more future-proof)? Or just running the good ole legacy vba engine under a mac-ppc emulator?

The real problem is that the company has lost its consumer market lock-in and is desperate to staunch Apple uptake in the enterprise, and removing VBA support is as close to a guaranteed deal breaker as they'll ever get.

Embrace, Extend, Extinguish

[Foerstner]

Or, at least, it's going to be such a huge amount of work to bring it natively to Intel that it's not worth it to MS.

At one time in the past, Microsoft considered it worthwhile to port VBA from Intel and Win32 to PowerPC and the Classic Mac Toolbox.

Today, it's too much effort to either 1) update the existing VBA engine or 2. Replicate the previous clean-sheet effort. Despite the fact that the Mac is growing in market share, and Office sales are very healthy--something that could hardly be said back in the late '90s when VBA was brought over.

I assure you, moving VBA from Win32+x86 to Classic Toolbox + PPC was a much bigger technical challenge than it would be to do the same on the modern Mac architecture. There is only one reason why Microsoft is no longer willing to do so. VBA is established and is ready to serve its purpose as a mechanism of lock-in.

Re:So Microsoft is at least still a *little* evil

[smittyoneeach]

Not necessarily. If the main VBA users are the PC-based ones, then MS could drop Mac support, retain PC, and the story is "reasonably" clear.
In any case, with the number of people involved in frobnicating the decision, there really isn't a need to label anyone a liar. Policies are variables, not constants, and get new values assigned to them frequently during business execution.

Re:So Microsoft is at least still a *little* evil

[Anonymous Coward]

I work with big banks on the fixed income side, and most traders have some excel spreadsheets with custom macros developed by internal IT. MS has to keep new version backward compatible. There is no way MS will break these spreadsheets, or else they'll piss off plenty of rich people and big companies.

VBA Went Too Far

[cjb110]

Personally I think VBA went too far, it wasn't a simple macro language.

Which meant it was ripe for abuse and overuse. Too many companies have important, business critical functions/logic entombed in Excel 'macros', or Access 'applications'.

If I've understood MS's intentions, they want all office programming to be done within .net, which is fine. But I think they should then 'freely' distribute an Office specific version of say C# Express. I can't see many customers being happy if they forced to also buy full Visual Studio versions if they want to convert their Excel/Access apps, esp not the SMB's.