Follow Us on Twitter
by Peter Galli on December 17, 2008 09:29pm
Microsoft has released documentation that details the implementation of the Open Document Format in Office 2007 Service Pack 2, which is available at no cost on the Document Interoperability Initiative (DII) Web site.
This, along with the soon-to-be-released Open XML notes, gives developers insight into how Microsoft is implementing file formats in Office.
The release of these notes is significant as they explain the reasons behind some of the decisions made in the implementation, thereby being open and transparent so that developers can make informed choices in their own implementations.
We know that our customers care deeply about interoperability and the ability that brings to share and exchange documents across different applications. But that requires participation, transparency and collaboration among vendors, which is already happening.
These notes help promote interoperability by providing details that others can use as reference points for their own applications, and include information about which attributes and elements are supported, as well as details about how Office functionality maps to specific constructs in the ODF specification.
With regard to what is in the implementation notes, Doug Mahugh, a Microsoft senior program manager who specializes in Office interoperability, points out in a PressPass article that bold text is one good example, since the ODF specification supports a wider variety of "font weight," or boldness, than other formats supported by Word.
"Therefore, we sometimes adjust the font weight in a document to match the specific values that Word supports. The implementation note on this topic will help other implementers understand the coding behind that adjustment," he says.
Microsoft will also be publishing, over the next few months, implementation notes for ECMA-376 (Open XML) in Office 2007.
If you want to read more on this subject, a number of articles have appeared in the press, including at eWeek and InformationWeek, both of which are based on interviews with Doug Mahugh.
by Peter Galli on December 15, 2008 04:34pm
The feature complete Release Candidate for Eclipse4SL, an open source, feature-rich RIA application development environment for Microsoft Silverlight in Eclipse, has been released, and can be downloaded here.
Guidance will also be given in the coming weeks on building Silverlight applications accessing Java Web Services using REST, SOAP and other standards
As planning is ongoing, the next few weeks will be focused on the final sprint to Spring 2009, which includes support for the Mac and an improved C# experience.
by Peter Galli on December 09, 2008 01:40pm
I'm on the road with Robert Duffner, our Senior Director of Platform Strategy, talking to tech press in New York, Boston and San Francisco this week.
So, imagine my surprise when top Microsoft blogger Mary Jo Foley ran an article about a new open source content system known as "Oxite."
The alpha code for Oxite, which is an open source, standards compliant, and highly extensible content management platform that can run anything from blogs to big web sites, and which already runs MIX Online, was recently released on CodePlex, our open source project hosting site.Oxite is licensed under the Microsoft Public License.
While we were surprised by Mary Jo's blog, this is a great thing as it shows just how many open source projects are taking place under the covers here at Microsoft. Having a range of our developers across Microsoft working on a variety of open source projects targeted at different communities of users, is exactly the goal of our group.
Stay tuned, as I expect to be surprised a lot more going forward and, as I do, I'll bring these projects to your attention, however they come to my attention.
by Peter Galli on December 08, 2008 10:24am
SMB (Server Message Block) is a remote file protocol commonly used by Microsoft Windows clients and servers that dates back to 1980's.
Back when it was first used, LANs speeds were typically 10Mbps or less, WAN use was very limited and there were no Wireless LANs. Network security concerns like preventing man-in-the-middle attacks were non-existent at that time.
Obviously, things have changed a lot since then. SMB did evolve over time, but it did so incrementally and with great care for keeping backward compatibility. It was only with SMB2 in 2007 that we had the first major redesign.
In this blog Jose Barreto, a senior technical evangelist in Microsoft's Storage Solutions Division, explains some of the history behind the protocol and outlines important improvements in SMB2, particularly in regards to reduced complexity, pipelining and compounding.
SMB (Server Message Block) is a remote file protocol commonly used by Microsoft Windows clients and servers that dates back to 1980's. Back when it was first used, LANs speeds were typically 10Mbps or less, WAN use was very limited and there were no Wireless LANs. Network security concerns like preventing man-in-the-middle attacks were non-existent at that time. Obviously, things have changed a lot since then. SMB did evolve over time, but it did so incrementally and with great care for keeping backward compatibility. It was only with SMB2 in 2007 that we had the first major redesign.
A History of SMB and CIFS
When it was first introduced to the public, the remote file protocol was called SMB (Server Message Block). SMB was used, for instance, by Microsoft LAN Manager in 1987 and by Windows for Workgroups in 1992. Later, a draft specification was submitted to the IETF under the name Common Internet File System (CIFS). The CIFS specification is a description of the protocol as it was implemented in 1996 as part of Microsoft Windows NT 4.0. A preliminary draft of the IETF CIFS 1.0 specification was published in 1997. Later, extensions were made to address other scenarios like domains, Kerberos, shadow copy, server to server copy and SMB signing. Windows 2000 (released in 2000) included those extensions. At that time, some people went back to calling the protocol SMB once again. CIFS/SMB has also been implemented on Unix, Linux and many other operating systems (either as part of the OS or as a server suite like Samba). A few times, those communities also extended the CIFS/SMB protocol to address their own specific requirements.
One important limitation of SMB was its "chattiness" and lack of concern for network latency. It would take a series of synchronous round trips to accomplish many of the most common tasks. The protocol was not created with WAN or high-latency networks in mind and there was limited use of compounding (combining multiple commands in a single network packet) or pipelining (sending additional commands before the answer to a previous command arrives). This even led to products created to address the specific issues around SMB WAN acceleration. There were also limitations regarding the number of open files, shares and users. Due to the large number of commands and subcommands, the protocol was also difficult to extend, maintain and secure.
The first major redesign of SMB happened with the release of SMB2 by Microsoft. SMB2 was introduced with Windows Vista in 2007 and updated with the release of Windows Server 2008 and Windows Vista SP1 in 2008.
SMB2 brought a number of improvements, including but not limited to:
It is important to highlight that, to ensure interoperability, SMB2 uses the existing SMB1 connection setup mechanisms, and then advertises that it is capable of a new version of the protocol. Because of that, if the opposite end does not support SMB2, SMB1 will be used.
The SMB2 protocol specification was published publicly by Microsoft and you can find the link at the end of this post.
One of the ways to showcase the reduced complexity in SMB2 is to make a comparison to the commands and subcommands in the old version.
Here is the complete list of the 19 opcodes (or commands) used by SMB2 in the message exchanges between the client and the server, grouped in three categories:
When you try to get a similar list for the old SMB, things get a little more complex. I tried to make a list of all commands and subcommands using only the documents linked below and came up with over 100:
I make no claim that the list above for SMB is exact or complete, but it does make a point. As an interesting exercise, check the lists above to verify that, while SMB2 has a single WRITE operation, there are 14 distinct WRITE operations in the old protocol.
SMB2 also requires TCP as a transport. SMB2 no longer supports NetBIOS over IPX, NetBIOS over UDP or NetBEUI (as SMB version 1 did).
A key improvement in SMB2 is the way it makes it easy for clients to send a number of outstanding requests to a server. This allows the client to build a pipeline of requests instead of waiting for a response before sending the next request. This is especially relevant when using a high latency network.
SMB2 uses a credit based flow control, which allows the server to control a client's behavior. The server will start with a small number of credits and automatically scale up as needed. With this, the protocol can keep more data "in flight" and better utilize the available bandwidth.
This is key to make a large transfer go from hours (in SMB) to minutes (in SMB2) in a "long and fat pipe" (high bandwidth, high latency network).
For an example of how pipelining in SMB2 can improve performance, check out this blog post.
When you look at the command set for the new SMB2 protocol, you notice that they are all simple operations. The old SMB1 protocol had some complex commands and subcommands that combined a set of simple operations as required in specific scenarios.
One of the important changes in SMB2 is the ability to send an arbitrary set of commands in a single request (single network round trip). This is called compounding and it can be use to mimic the old complex operations in SMB1 without the added complexity of a larger command set.
For instance, an old SMB1 RENAME command can be replaced by a single request in SMB2 that combines three commands: CREATE (which can create a new file or open an existing file), SET_INFO and CLOSE. The same can be done for many other complex SMB1 commands and subcommands like LOCK_AND_READ and WRITE_AND_UNLOCK.
This compounding ability in SMB2 is very flexible and the chain of commands can be unrelated (executed separately, potentially in parallel) or related (executed in sequence, with the output of one command available to the next). The responses can also be compounded or sent separately.
This new compounding feature in SMB2 can be used to perform a specific task in less time due to the reduced number of network round trips.
I hope this post has helped you understand some of the important improvements in SMB2, particularly in regards to reduced complexity, pipelining and compounding.
Below is a list of important links that document SMB2, SMB and CIFS, including the latest protocol specifications published by Microsoft:
by Peter Galli on December 03, 2008 03:05am
The work to promote interoperability between different document format implementations is yielding some concrete results.
A number of new technology solutions were announced in Brussels on December 3 by the Document Interoperability Initiative (DII), which was launched in March of this year, and where industry leaders and representatives from vendors around the world gather for technical discussions and labs to identify, test and develop solutions to overcome document interoperability barriers.
The solutions - which will improve the installation, performance and stability of translated documents - include the Open XML Document Viewer, which translates Open XML documents to an HTML Web page and allows readability on Web friendly browsers like Firefox. You can watch this video demonstration of the Open XML Document Viewer, while the CTP is available here.
Other new solutions include the Open XML/ODF Translators Version 2.5, a document translator that improves translations between different formats through optimized templates, and which will be made available as an add-in for Microsoft Office 2003, 2007 and XP. You can watch the video demonstration here.
The Apache POI Java SDK for Open XML gives customers and independent software developers greater choice as they create and use business applications that manipulate business documents and which are built on Java.
As transparency and co-operation are vital for initiatives like this to succeed, it's important to note that the DII's goals are to increase interoperability between document format implementations across a range of formats, applications, platforms and devices, and that the initiative is open to any vendor who wants to collaborate with the community to identify and address interoperability issues between different implementations of document formats.
We believe that the industry has a responsibility to come together to address the interoperability interests of users as well as effective data exchange between widely-deployed document format implementations, and so the development of these technical tools, which is due to the open and constructive industry dialogue at DII, is gratifying. This work also underscores the progress being made as the global IT community continues to work together on developing real-world interoperability solutions.