back to article Microsoft's Office 2013 app-maker cloud drenches developers

It was in 1994 that Microsoft declared Office a development platform, and released the Office Developer’s Kit 1.0 for coders to turn out useful utilities. Using Visual Basic and COM automation, programmers could control Office applications using software. Automating, say, document editing in heavyweights Word and Excel in the …

COMMENTS

This topic is closed for new posts.
Silver badge
FAIL

Web apps in excel docs?

There's a TLA for that!

1
0
Thumb Down

EH?

Can anyone explain why I (or my employer, for that matter) would want to code macros/apps for a confidential company spreadsheet that contains 'server side' (i.e. in the 'cloud') code?

And why do I want to learn bloody Javascript???!!!

At least VBA is still in there.

I also worry that with this webby stuff built into the core of office that it's (in)security surface area has just been greatly expanded, potentially leaving it open to all sorts of virus/malware/spyware vulnerabilities. I presume (not based on any knowledge) that your web app enabled spreadsheet is as vulnerable as your browser in terms of Javascript and HTML exploits.

Oh yeah. My employers are just going to *love* that.

Having said all of that, I suspect it's technology that nobody will use. People will kick the tyres, and go "Oh, look, I can post a form using HTML GET from my spreadsheet. Groovy."

Then the bost will slap them and they'll go back to VBA and get on with their work.

2
0
Windows

Problem is VBA is NOT on the RT version

"Macros, third-party add-ins, and VBA support will all be dropped from the Office 2013 RT edition"

0
0
Silver badge

Well it's sandboxed code which is more than can be said for plugging most VBA applications into your system. The "Cloud" can also be your own servers. I don't imagine many big companies will be using SkyDrive for their storage. The Javascript is because you can use HTML5 + JQuery for the UI which is probably nicer and easier to develop with than all those VB-style forms. There's a lot more expertise floating around for GUI design in web applications than there is in VBA. It's probably less likely to be exploitable for malware / spyware as you suggest because unlike some VBA-based plugin you install, this doesn't need to install or modify DLLs or other system files. It's a lot more than "post a form using HTML GET from my spreadsheet."

0
1
Silver badge
Windows

@h4rm0ny

You speak of sandboxing as if it is a good thing. It can be; but sandboxing Office apps. takes away a major functionality aspect.

For example; in my Office 2010 I have a lot of address information stored in Outlook. Whenever I need to write a letter I use a Word template (VBA) which then accesses the address list in Outlook to retrieve the contact information I need.

And there's plenty more where that came from. Searching OneNote information and being able to setup stats in an Excel sheet. Going through all the Word documents marked as "bill" on my system from Excel, when identified it grabs information from the document such as payments and tax and such. All data is then put into a graph which helps me keep an (easy) overview of company revenue.

Office was build for interaction... If they need to sandbox the whole thing online then my conclusion would be that MS Office wasn't build for this.

1
0
Silver badge

Re: @h4rm0ny

"You speak of sandboxing as if it is a good thing. It can be; but sandboxing Office apps. takes away a major functionality aspect."

Well, I think you have taken my term sandboxed in too strong a way. You should really go and read the blog post in the article and the link from there to the developers' guide for this which gives a lot more detail than I can here. The runtime is sandboxed. So it can't go running away with your processor, can't muck around with other processes or use any old DLL however it likes as VBA apps could. The application can only (so far as I understand it) communicate with Office via a Javascript API they have written. But I think that's less limiting than you realise. Regarding your specific example:

"For example; in my Office 2010 I have a lot of address information stored in Outlook. Whenever I need to write a letter I use a Word template (VBA) which then accesses the address list in Outlook to retrieve the contact information I need"

From my reading of this, there's no reason you can't do this. I think you are thinking that an app gets embedded in a document or spreadsheet and is then sandboxed within and thus cannot get the information from Outlook's address book into your Word template. Correct?

What you (or a developer creating such an App) would do, would be create a "manifest" file, which is a description of the application in terms of what it can and cannot do, and when you installed the application, you'd be able to review these permissions and check they were what you wanted the App to have access to. The Manifest file also shows when and where the application shows up. So you could make it an App inside Outlook if you wanted (or in Word if you preferred), and when you ran it, assuming it had the right set of permissions, it would be fine to read addresses from Outlook, find the appropriate template and create your letters. You might find this interesting as it goes into how the permissions break down. Check out the diagram about 3/4 the way down. As you can see it's possible to give or withhold permissions in a far more sophisticated and elegant way than was possible with chunks of VBA or DLLs. That page is specific to Outlook but it will give you a good idea.

"And there's plenty more where that came from. Searching OneNote information and being able to setup stats in an Excel sheet. Going through all the Word documents marked as "bill" on my system from Excel, when identified it grabs information from the document such as payments and tax and such. All data is then put into a graph which helps me keep an (easy) overview of company revenue."

There's nothing in there that I think shouldn't be just as possible with the new system. But you'll be able to lock it down in ways that you cannot with VBA. When I mentioned sandboxing, I was primarily talking about a sandboxed runtime, though of course it also sandboxes what data sources it can communicate with based on the manifest file. E.g. if when you install it the manifest file says it can only talk to server.mycompany.com, then that's all it can talk to. It can't go off and talk to server.myrival.com.

"Office was build for interaction... If they need to sandbox the whole thing online then my conclusion would be that MS Office wasn't build for this."

Honestly, I think you should probably take a few hours to read through some of how Office 2013 and Win8 are set up for development. You obviously have a lot of experience and can put together a good argument. But I genuinely think you haven't actually read through these documents as you have some significant misconceptions about some of these things. Don't rely on El Reg for detailed analysis of this stuff, judge it for yourself!

2
1
Silver badge
Trollface

"Office apps that work seamlessly locally or on the web is compelling"

Or you could download Dropbox for free, tell it to sync a directory, still keep a usable version of Office (2003 being the most usable, followed by 2007/2010), and not pay yet more cash to Microsoft for the privilege of owning (or is that renting?) the latest most user-unfriendliest version yet of their Office suite.

2
0
Silver badge
Windows

And here we go again...

"Programmers can get started with Apps for Office by signing up for an Office 365 developer pass."

When I want to develop stuff for my Office environment all I have to do is either open up whatever program supports VBA and start coding. Or if I want to build external stuff I simply pick up VS Express and get to it.

All for free.

What El Reg doesn't mention is that "signing up for an Office 365 developer pass" is only free during the Office 2013 preview. You can see as much here (MSDN Office page).

So in the near future you'll need to cough up some big bucks if you wish to develop stuff for the new Office.

Gee; that reminds me of my Windows Phone. If I want to use C# and such to create programs for it then I need to cough up approx. $100,-/year. Even if I have no desire - what so ever - to publish stuff, but only wish to have fun with my own phone. The tools are free, but accessing my /own/ phone isn't.

With these developments I seriously wonder how long the VBA environment will remain a free feature. I wouldn't be surprised /one bit/ if that policy would change as well in the future, in an attempt to gross in even more money. So then you'd have a trimmed down Office and a (much more expensive) "Pro Office" which could feature many things you may not need, but need to purchase anyway if all you want to do is being able to program VBA macros.

4
0
Anonymous Coward

Java.... Java... ECMAScript!

What do you get if you cross a typical VBMacro Dev, Javascript and Support

The sane one, running for the hills!

1
0
Gold badge

@ShelLuser, heh. What an amusing contrast to Android. No fees for the SDK, I can always put apps on my own phone with it. A one-time $25 fee to publish (which they say they charge just to encourage high quality apps... i.e. spammers would start fake publishers if it was free.) And, besides the android SDK, technically I could install AIDE (Android Integrated Development Environment) and develop Android apps *on* the device.

Re: ForthIsNotDead.... I wasn't clear on that. Does the developer write code in Javascript, or do they use something else and this utilitiy generates Javascript? Anyway, I must agree with you, I wouldn't want to write a large-scale application in Javascript and HTML any more than I'd want to write one in BASIC.. yech! BUT, even if this is making you develop in Javascript, it shouldn't be too bad, since really you'd be using Javascript as a scripting language to tie together Word, Excel, and Outlook functionality rather than doing it from scratch. Javascript is a fine scripting language.

0
0
This topic is closed for new posts.

Forums