TL; DR

Omea is an "Integrated Information Environment", similar to modern apps like Obsidian but developed in Windows Forms and .NET Framework back in 2004. It was open-sourced by JetBrains in 2008, and so I took the sources, dust them off a bit, and uploaded to GitHub. It now builds and works in modern environment (only Windows so far), though a lot of old modules are still defunct.

Scroll to the bottom of this post to see a screenshot of how it looks on Windows 11.

Early History

Back in early 2000s, JetBrains decided to invest into development of Omea, "The Integrated Information Environment". That was a different time, when most of the software and even approaches to sorting through the information weren't yet invented or widespread, so it's possible to see how it was a logical decision.

At 2004-10-04, they released Omea Reader, the RSS reader application (remember when RSS was a hot topic?), and later that year, at 2004-12-15, Omea Pro followed.

It is kinda hard to find the real history now after all these years, but my understanding (based on the Omea Pro announcement post and following Omea 2.1 changelog, available as a part of the source drop) is that Omea Pro was a paid product, and Omea Reader was (or eventually become) a free one.

Let's talk about Omea Pro first. The general idea, as I see it, was to just create a central place to organize and search through every piece of information you own: your email, various office document formats on your desktop, RSS feeds, random notes (including fragments from web pages you could save for future reference), and above that — message history from instant messenger apps.

The general app structure really reminds me of modern organizer apps such as Obsidian and Roam Research, but maybe with more focus on importing data from sources like IM apps and email.

And Omea Reader is essentially just a trimmed-down version of Omea Pro, with all the plugins except the RSS one removed (similar to how modern versions of IntelliJ IDEA Community and Ultimate are connected). You could upgrade from Omea Reader to Omea Pro and use the same database and all that, but extend its functionality with all what's available in the Pro version.

There's no public information I was able to find on what else was happening with Omea, but several years later, on 2008-05-13 (or maybe a bit earlier?), it was open-sourced by JetBrains under the terms of the GPL v2 license. And here our history begins.

So, What to Do Now?

After some thoughts and after I wasn't able to find any other community attempts at doing anything with the released sources in the last 16 years, I decided to try doing that myself. I believe in software preservation and situations when something has the potential to completely disappear make me uneasy. That random SVN server hosting Omea sources was undoubtedly at risk, seeing how even the notice of releasing the sources has disappeared and I have to link the Web Archive now instead.

And I was unable to identify any reasons to not do that, so here we go.

In the sections below, I will tell about my adventure on porting Omea's sources from 2008 to modern environment, retelling some anecdotes I encountered while doing that, and show-casing some of the tools and approaches I take when restoring old software.

Previously, I've been kinda successful in restoring a project from similar era, Bloodmasters — but that's a story for another time.

The Sources

First things first, if we decided to work with the sources, let's investigate what we have in our hands. Thankfully, ol' good SVN is still available for all the modern operating systems, so it's as easy as

$ svn log http://svn.jetbrains.org/omeaopen

This will show that there were just five commits in the SVN repo, from March to August 2008. Most likely this indicates that the work as performed elsewhere, and the sources were uploaded in several bunches (or "snapshots" as they are named in the commit messages).

For some SVN repositories, it's quite hard to convert them to other version control systems, because they use SVN-specific features such as (ab)using per-file merge history, branching only a file subtree out of the common repo, or something like that. For Omea and its five commits, this is thankfully not a problem: there are no branches in the repository whatsoever.

Since I prefer Git, I used a tool to import the old SVN commits, trying to preserve as much history as I can. You can use basically everything for a simple situation like this one (starting from the infamous git-svn), but I used the simplest solution: GitHub SVN repo importer, and it did its job well. Interestingly, SVN import has been discontinued since then by GitHub (I still managed to use it several months ago, though). So, I am really running on the edge here, saving the crumbling reality from the inevitable touch of time!

And it turns out, only three commits out of five are meaningful: the other two were initializing the SVN repo's directory structure. And here are the imported commits: 2008-03-07, 2008-08-04, 2008-08-14.

From the commit structure and the word "Snapshot" in the message of each of them, we can conclude that they used the aforementioned approach of dumping the code in batches, and not developing in the same open-source repository. The last commit included a fragment of the SVN history from the main repository in the Changelog.txt file, for further bookkeeping I assume. The commits were done using an anonymous account, but we know the names of the current and the former contributors, because they all are mentioned in the credits window. Some of these people are even still working at JetBrains!

Speaking of the Omea legacy: at least one asset of Omea outlived the product itself: it's the product icon! Some of the files in Rider distribution still bear this icon to this very day (at least in the latest stable 2024.1.4 release), and internal build system, ABuild.exe, also bears that. My understanding is that the "product launcher" was initially developed by .NET department exclusively for Omea, and was further reused for all sorts of new things that were mostly not user-visible, and thus nobody cared to update the icon. At this point, it has nostalgic value even.

Initial Build Attempts

So, we have the sources. What to do next? Well, build them, of course!

A quick look at the sources shows a lot of things. First of all, as promised in the open-source announcement, the sources are targeting .NET Framework 3.0 and are were likely built in Visual Studio 2008 (the Src/Omea.sln file mentions the version directly).

Fun Fact

Visual Studio writes its version into any solution files it edits, and it's really eager to update that. Other IDEs, e.g. Rider, might have different behavior regarding the solution files, so if Rider was a thing back in 2008, it would make identifying the build tool version harder for me.

But there are other build files as well: some build files are duplicated for older NAnt-based build system and target .NET Framework 1.1 (possibly a leftover after the migration they mentioned?), and some of the plugin samples still target older framework since they were never updated.

Fun Fact

ReSharper is the only tool I know that supports NAnt to this day. Ant is a customizable Java build system, and apparently folks were preferring a .NET port of it, NAnt, to whatever build customization capabilities early versions of Visual Studio were offering.

Later, in Visual Studio 2005, in the days of .NET Framework 2.0, Microsoft introduced MSBuild with relatively the same customization capabilities but with the direct vendor support, and so usage of NAnt for .NET projects declined.

There are several main solution files, for sources and for setup, and a lot of other stuff to build the product, including the referenced libraries and MSBuild files.

When approaching an old source code dump like this one, the first thing I usually try is to actually build it. This will help to determine further steps: after we have a project we can actually build (however complicated the build process turns out to be), we can track our further changes to at least not break the build.

I have tried loading the solution in modern Visual Studio, and of course it performed a project file migration and broken the build. It was expected, but still worth trying. After taking a look at the build problems, I decided it's not possible to fix them quick, and perhaps I'll have more luck building the product in the original environment it was developed in.

So, back to Visual Studio 2008 we go!

Build Environment

Sadly, you can't deploy Visual Studio 2008 to a modern OS, so we'll need a virtual machine. At the time, I was still confused by the timeline and presence of .NET Framework 1.1 files, so, to be more safe (and possibly be able to deploy Visual Studio 2005 to the same environment), I decided to use Windows XP for this experiment.

While working on yet another old software restoration project of mine, Overtone (a more ambitious on that, though), I have already been researching the ways of running Windows XP in modern VM software (it's not as easy as it seems), so I already know how to get a working free (and seemingly legal?) copy of Windows XP. See the instructions I wrote for VirtualBox.

This time I decided to try the same image in Hyper-V, though, and it was quite a pleasant experience: it just tends to work a bit better in Hyper-V. One thing I had problems with was networking, but for now I decided to just bake the sources to another ISO image and copy them from a virtual CD. (Eventually, I figured out the networking as well, but only used it once to verify the last Omea source version that was still compatible with VS2008, before further migration.)

See my instructions on building Omea in the environment close to original. They explain how to

• obtain a working copy of Windows XP from the old Windows XP mode (that was part of Windows 7 or something),
• obtain a trial version of Visual Studio 2008,
• create a separate ISO image with the project sources, and
• build the sources.

Using this instruction, I was able to build a working version of Omea (well, the one that starts on the VM) and decided that's enough. Sadly, I was unable to build the installer, but if we want to move Omea to the modern age, installer will require huge rework anyway, so I decided to not dive too deep into that.

JetBrains' .NET department did a notably great job on preserving the sources in self-contained state, so that you can just drop them onto a PC with build tools, and they will be built with almost no additional configuration. Notably, modern software builds the same way in this department, of which the folks are rightly proud.

Licensing

After I verified that I can build the software from the provided sources, it's turn to figure out what is the provided source: who owns it and how's it licensed. Yes, the announcement told that the source is available under GPL v2, but reality is always more complex than that. While most of the source files even have the proper license headers attached, there are some third-party files in the repository, and to proceed with the restoration process, we need to identify any such files and their licenses.

My preferred tools to organize the software licenses in REUSE, a tool (following a corresponding specification) produced by Free Software Foundation Europe. Among others, this approach is adopted by KDE, and I try to follow it in my projects.

A project that follows REUSE will normally attach the licensing information to each file in the repository: either in the file itself, or in a companion .license file. This allows to track the licensing of each file more easily, and allows automatic detecting of the files that have no license information attached. So, when I receive an old project, first thing I do is applying the REUSE tooling and marking each file with the corresponding license. Sometimes, when the license information is unclear, this might take some time to figure it out.

And there were a lot of files in Omea repository that don't have proper licensing information attached, mostly third-party libraries, but also some assets. I understand why they are included: you see, NuGet, the .NET package manager, was only introduced in 2010, so back in 2008 there wasn't a standard solution to distribute the project dependencies. The best option was to just include all the libraries in their source or binary form in the source repository.

In total, it took several evenings of work to sort the licensing out, and in process, I found a lot of interesting facts I'll share in teh following section.

Documentation

It is quite interesting to see authors' approach to Omea documentation. They included all sorts of documentation assets: mindmaps, Visio diagrams, even SWF animation files. And, of course, a lot of HTML and stuff to publish all that in form of CHM.

For CHM, they were using RoboHELP, a tool acquired by Adobe somewhere in 2004: a quite unfortunate timing, since it was hard even to figure out if it was acquired before or after main Omea development took place. Interestingly, that tool was relying on distributing several of its libraries alongside the generated documentation, and had a quite vague licensing conditions. Eventually I figured them out, but it wasn't an easy task.

Perhaps we'll slowly migrate the old documentation to modern formats such as Markdown and update it, but I don't have a ready solution in mind to deal with the SWF files (Macromedia Flash). I wasn't able even watch them so far, though I believe they may include some interesting information.

One more thing I found: LibreOffice Draw supports opening and rendering Visio files. It is not ideal, but it works.

Third-Party Libraries

In this section, I'll share some random facts about third-party libraries used by Omea.

PDF

Omea was able to extract content (for indexing) and render PDF files. For content extraction, it relies on xpdf library (GPL), and to show them in the UI, it was using some libraries from Adobe. It turns out it's not allowed to distribute those unless you have a permission from Adobe, so I had to drop this part of the code and the libraries.

Microsoft Office

Omea has ability to extract content from Microsoft Office data formats, and to do that, it uses something called "Office Primary Interop Assemblies" (essentially, the API definitions for interop: they bear no executable code). These assemblies are quite hard to distinguish from each other, and I had to update them to a newer version I know the license for (taken from Office 2003).

Not every version of Office had published those, and some assembly versions were published with Visual Studio under some totally different agreement. 2000s were a licensing mess.

(Though Omea also seemingly tries to extract content using the open-source wvWare library, so I'm not completely sure what is used for what in this case.)

.NET Blog Extension

A quite interesting story: at some moment in the 2000s, there were so many RSS reader applications in .NET, that their authors agreed on using the same extension interface, to make RSS reader plugins portable between RSS reader software. Could you imagine that? There was, like, a whole market for plugins for RSS readers written in .NET!

You can read more of this story on Simon Fell's website.

Omea was, of course, supporting these plugins as well: you could take, say, a compatible plugin from SharpReader, and install in into Omea using a special UI. And it had to bundle the DLL with itself (I'm not sure what they were thinking about library versioning back then; perhaps there was some sort of backwards-compatible API).

I thought about just leaving that DLL and distributing under some permissive conditions (totally in spirit of the original), but eventually decided against that. There's not much point in supporting extensibility mechanism for the only purpose of interoperating with other old software that's no longer maintained; in fact, even less maintained than Omea itself (since I now maintain it!).

So, yeah, no more IBlogExtension support in Omea. But you have to agree that the story was fun.

OneNoteImporter

Remember Microsoft OneNote? Honestly, I barely remember it myself: was never a huge fan of that. But I think it's supported to this day, and people use it?

Anyway, at some point back in 2004, folks from Microsoft (credit to Donovan Lange) decided to open-source a library that allows content importing from OneNote. In .NET, yay!

Sadly, that was in 2004, and 2004 was the time of crazy licensing, so it was licensed under a dubious "Shared Source License", and sources were shared in a place that doesn't exist since then. Moreover, there are only 4 hits in Google if you seek for "OneNoteImporter.dll"! That's a level of obscurity even I did not even expect. Thanks to a random mention in RssBandit's issues, I was able to track it down, dig up from the Web Archive (these folks are doing the God's work!), and published on GitHub.

Now there'll be more hits in Google :)

I wanted to restore one old project, and now I have two.

Other Assets

One random notification sound in the repo was licensed by Microsoft, so I had to go to freesound.org and find a free replacement. Thanks goes to Joe DeShon (who prefers their name to be capitalized exactly this way, as it's emphasized in their freesound profile), for publishing a notification sound under CC-BY-4.0!

Sources

After organizing the licensed and doing inventory of all the available files, I was ready to port Omea to a modern build system, to be able to build it on my host system and not inside a Windows XP VM.

So, I opened the solution in Visual Studio 2022 to upgrade the project files (and break the build, of course, as expected), then opened the result in Rider and started digging further. There were several obstacles before me.

Managed Extensions for C++

The first problem that I encountered trying to build the upgraded solution was that the old C++ projects were written in Managed Extensions for C++. And its modern equivalent, C++/CLI, is quite different and doesn't even support all the used syntactic constructs!

So, after sorting out the problems with Outlook and Exchange libraries (thankfully, the parts Omea used are now available under MIT in scope of mapi-stub-library, so we don't have to rely on Visual Studio or Office SDK), I decided to upgrade the projects from Managed Extensions to modern C++/CLI.

Could you imagine, there's even a website devoted to this migration! Was quite an entertaining read. Most of the migration was simple keyword and syntax replace, and the main differences I was able to identify are differences in pointer semantics: in the Managed Extensions, garbage-collected references were marked as C++ pointers, while in C++/CLI, they are now marked with ^ and are represented by a different kind of entities. There's also a notable difference in how IDisposable is now described in the language constructs, but after everything else, it was a minor nuisance.

One or two evenings of work, and I was done with C++/CLI parts.

JScript.NET

The next trouble was quite an unexpected one. You see, at some point Microsoft developed JScript.NET, an abomination of .NET and Windows-flavored JavaScript. And of course, for whatever purpose, the Omea authors decided to use that — thankfully, in a quite limited set of places.

I wasn't even sure it's still possible to compile that (ah, yes, from what I see, JScript.NET is a compiled language, or at least it has a mode when it's compiled to CIL, in the same manner as C# and VB.NET are). But it actually is possible: .NET Framework 4 still bundles the corresponding compiler; it's still present in the Windows itself!

JetBrains developed a whole SDK for JScript.NET that allows including such projects into a common .NET solution, and after a minor syntax upgrade, I was able to build these projects in Windows environment.

.NET Framework

As promised, Omea was upgraded from .NET Framework 1.1 to .NET Framework 3.0 (quite an achievement, I have to say), and I further moved it to .NET Framework 4.8. That wasn't very hard: I only had to deal with some MSBuild files and JScript.NET; everything else was a piece of cake.

Other MSBuild Tricks

SDK for CIL

One more interesting thing is that apparently at some point, plugins in pure CIL (an assembly language for .NET) were also considered as a first-class citizen of Omea. There are corresponding MSBuild files and a project example included in the repository. I think that Microsoft started supporting .ilproj in the modern SDK only recently, and Omea did that back in 2008!

Architecture Notes

Several interesting things about the project architecture:

1. Omea uses a native launcher written in C++. It allows to handle absence of .NET Framework nicely, and also allows to show a splash screen before loading the actual runtime. Modern .NET products of JetBrains also use the same trick, as far as I know.
2. Omea uses a plugin architecture, somewhat similar to ReSharper, and menu/action system reminding me action registration in IntelliJ IDEA.
3. Omea has an underlying database / indexing engine, DBIndex, written in C++/CLI. It is quite an interesting read.

The Results

After some additional digging around, I was able to compile the whole main solution of Omea on a modern Windows host with Visual Studio 2022 installed (sorry, folks, no .NET 8 support yet — but read the next section). It is quite clunky, lacks HiDPI support and throws a fair amount of exceptions on startup (offering an option to report them to a defunct JIRA instance even) — but hey, it works!

I was able to start RSS reader and make it read some articles from my blog. Here's my victory screen for today:

While doing the screenshot, I have even found and fixed a bug with XML encoding in my RSS feed, so, yeah, another victory.

If you want to try Omea yourself — feel free to get a build from CI and try using it. Mind that it is provided as-is, though, and barely tested outside the limits I outlined in this post.

Future Plans

At this moment, I am totally happy with my open-source restoration attempt, and most likely I'll pause active improvements of Omea — for a while. Occasionally I wish I had an RSS reader application, and maybe I'll use it. For reading email and whatnot — probably not. Not yet, at least.

But if you want to help (you'll be surprised, but people do sometimes offer me help on some of my OSS projects), then I'll mark several fruitful directions where Omea could go from now.

1. Moving away from Internet Explorer. Yes, Omea uses the web view components from the old good IE. We are definitely getting rid of that.
2. Getting rid of unsupported languages. C++/CLI and JScript.NET are fun and all that, but they go against the further purposes of making the project cross-platform, so, sooner or later, they'll have to go.
3. Going even more modern. .NET Framework 4.8 is great. It is much better than 3.0. But still it is quite old. I'd like Omea to run on the modern .NET runtime, such as .NET 8. Eventually I am sure it'll be ported.
4. Going cross-platform. This one is obvious. I am a huge fan of Avalonia, and so I'd try porting it to that UI framework and producing builds for Linux and macOS.
5. Restoring the email capabilities. Currently, Omea still tries to use the old Outlook COM API, and I don't believe in this approach. We should port it to use IMAPI or POP3 or whatever people use these days for their email.
6. Restoring the document reading capabilities. I had to trim PDF content indexer, and the Office document indexers are almost definitely broken.
7. Restoring installers.
8. Restoring documentation.

Conclusion

Omea is an artifact from a more civilized age.

I am glad I was able to save its sources from the total oblivion, and that was certainly… an experience.

The one I never wanted nor asked for. But I would repeat that again.