A couple of comments have raised the question of people outside Microsoft using the various versions of RichEdit. Specifically, Teis Johansen asks, “Just to be sure. Can I redistribute RichEdit 6.0 with my application?” and Kyle Alons asks, “So what’s the point of listing these features without documenting how to use them? Just to make everyone outside of MS envious?”
To help understand the answers, it’s worth knowing some history of how RichEdit was developed. RichEdit 1.0 was created by the Microsoft Exchange group, notably by David Fulmer with help by Anthony Francisco and others. In addition to being used by Exchange’s mail program, RichEdit 1.0 was wrapped in MFC to produce WordPad as an example of how MFC could be used for text processing. This was shipped with Windows 95 as mentioned in the previous post.
In the spring of 1994, I moved from Microsoft Research over to the Text Services Group in Office with a plan to create a cool customizable keyboard particularly adept at entering mathematical symbols. But soon my work was interrupted by my boss Howard Campbell who asked me to develop RichEdit 2.0, making RichEdit 1.0 more compatible with Word’s look and feel. Naturally I tried to interest David Fulmer, but he wanted to stay with Exchange. The Forms^3 team with Christian Fortini was also very interested in having plain-text and rich-text controls with greater power and flexibility than available with the system edit controls. Christian did the early conversion of RichEdit 1.0’s internal engine from C to C++. Later on Christian became the development lead for Internet Explorer 4.0, which his team built on top of RichEdit 2.0.
A key concept was that RichEdit 2.0 would be based on Unicode, instead of the code pages used in RichEdit 1.0. Being on the Unicode Technical Committee in part because it provided the best character set for mathematics, I was convinced Unicode was the way to go, even if native math in Office was far from becoming a reality. Christian liked this idea too, since before coming to Microsoft he had worked on a technical word processor, just as I had.
I didn’t understand OLE, Microsoft’s object embedding technology, but I was lucky to convince Alex Gounares to join the RichEdit team. Alex was 23 years old and had become an OLE expert working on OLE32 in Windows. He was so good that within a year we made him RichEdit 2.0’s dev lead! In a later post, I’ll fill in more of RichEdit’s history. Hopefully the stage is set to see why different versions of RichEdit are available to different users.
As you see, starting with RichEdit 2.0, RichEdit has been developed by Office’s Text Services Group. Other groups have contributed important improvements, notably the Pocket Word folks, the eBooks team, Windows, and most recently the Encarta Math Calculator team. In all cases, improvements have been merged back into the main RichEdit code base maintained and developed by the Text Services Group. Consequently Office always has the most recent version or at least nearly the most recent.
On the other hand, Windows RichEdit support lags pretty far behind, mostly because of the extensive testing that’s needed to ensure that upgrading the Windows’ RichEdit’s won’t break the literally thousands of applications out there that use RichEdit. Within Office, we can test all applications and be sure that no disasters occur when we’ve added new features. It isn’t so easy in Windows, even though RichEdit 6.0 is way better than RichEdit 4.1. In fact, this backward compatibility nightmare led the Windows team to keep RichEdit 3.0 for emulating all earlier RichEdit’s (remember RichEdit 1.0 had many localized versions) and have RichEdit 4.1 with different Windows classes and dll name for WordPad and other “more advanced clients”. We could do the same thing with a system RichEdit 6.0, but it would certainly be simpler if we could just use the latter in place of RichEdit 4.1, assuming backward compatibility could somehow be solved.
Onto answering the questions: it’s fine for applications outside Microsoft to use RichEdit’s already installed on a particular machine. So if a machine has Office 2007 or the Encarta Math Calculator installed, then other applications can load those copies instead of the RichEdit 3.0 riched20.dll installed in the Windows system32 subdirectory. However it’s not fine for anyone to redistribute RichEdit 6.0. Part of the reason for this is that a RichEdit installed by a Microsoft program receives security updates, because Microsoft knows about it. When someone outside Microsoft copies a RichEdit, Microsoft doesn’t know about it and therefore can’t fix it if security problems occur. A second reason is that a newer version may break other applications if they end up using it. This problem is minimized by use of a private subdirectory that other applications don’t know about.
The second question addresses the lack of documentation for the new features. Since RichEdit 6.0 is owned by Office, documentation for many of the new features is available to Office partners. If the system folks decide to distribute a new RichEdit, the documentation will be added to the SDK. As far as using math in RichEdit is concerned, a user can type in math the same way as in Word 2007. The client application does need to provide a way for the user to toggle math zones on and off. I’ll document this in a later post.