Prague, 1998: The story of a breakthrough technology

What is secret of the company’s success?

I’m asked this question from time to time, regularly and in different words. Of course, there’s no simple answer to it, and there can’t be. The formula for “how to do as much as possible and get everything right” isn’t simple. Well, probably except for a lottery mega jackpot or suddenly inheriting a million. But that’s not how it was for me. Our success is attributable to a lot of factors, mainly technological. Today I’ll talk about one of the keys: a fundamental technology that has for many years helped us develop breakthrough products in all kinds of categories while guaranteeing maximum protection against all possible malware cyberthreats.

The technology is called “Prague.”

Why is that? Very simple: It was invented in Prague.

Back in the spring of 1998, we gathered a small group to drink beer and eat Czech goodies come up with a candidate architecture for our future products. The Prague gathering was extremely successful: We produced a new technology — the Unified Component Architecture (UCA), which binds a wide variety of products on all possible platforms (operating systems). The UCA continues to evolve and is the skeleton of nearly all of our products.

What’s more, the UCA is also eyed by other companies that have run into the problem of “multilingual” projects and developments, which happens quite often, especially with complex projects with many teams involved or when companies merge.

Our “Prague gathering” is twenty years old this year. I realised this when I went through the archives and stumbled on “Prague Technology Documentation,” a document dated June 22, 1998. Back then, we were preoccupied with fighting some “innovative” viruses and solving some purely technical problems with the antivirus engine. The solution we found was much broader, more powerful, and more useful. So in many ways Prague determined the core technology of our products for a good ten years to come.

How did it all start?

Back when the company was somewhere between the garage stage — in our case, the second floor of a kindergarten in Moscow’s Strogino District — and the glass office stage. We licensed our engine to a number of foreign partners. We already had an extremely successful version called Antiviral Toolkit Pro 3.0 on the market. However, the technological future wasn’t all blue skies.

Two big challenges remained: things that were clearly needed and promised to be very difficult to implement. The first was the ability to process suspicious objects regardless of how they were stored (a typical example is a “nesting doll” of embedded objects, that is, an executable malware file inside an archive packed in another archive). The second challenge was creating an antivirus engine that could be updated as quickly as possible and required minimal (ideally zero) changes to port between platforms.

In case anyone has forgotten, virus makers in the late 90’s were very inventive, and some totally new viruses required updating not only the databases, but also the engine itself. Users had either no at all or extremely slow Internet connections, so delivering an update of a couple of megabytes was a serious problem. Given that Windows 98 had just started its advance on the planet but still hadn’t completely replaced DOS, any innovations in detection had to work instantly in both operating systems.

Overall, there was a lot to think about when Alexey De-Monderik, Andrey Kryukov, Andrey Nikishin, Vadim Bogdanov, Larisa Gruzdeva, and I landed for a week in Prague for a brainstorm. We rented a conference room in a hotel, and every day from 9 to 5, we drew and discussed, and then moved to the restaurant and billiard room to taste Czech beer and let the ideas marinate.

We worked productively and went back to Moscow with a concept. De-Monderik wrote down our ideas, and that was the document that inspired this blog post. Here it is:

Kryukov and Nikishin continued to discuss Prague, but it was actually created in 1999, when Andrey Doukhvalov joined the team. His experience in system development helped turn the Prague concept into something more than a system of plugins for the antivirus engine.

In fact, Prague turned out to be an independently created, object-oriented and modular system in which objects were created and managed after the application was launched, the hierarchy of objects was observed, and the kernel enabled functions such as memory management and messaging. All of this communicated with the operating system and user interface through a fairly thin layer, so it was possible to write almost the entire kernel of the antivirus in the form of “Prague plugins.”

Doukhvalov developed the first version ready to use in the product for AVP 4.0. It wasn’t yet totally Prague-rewritten, but the strengths of the architecture were already apparent:

• It completely solved the problem of processing complex nested objects. The antivirus on the Prague engine was the first on the market to easily cure infected files inside archives, for example, or detect viruses on the boundary of volumes of a multivolume archive. And the detection and treatment modules didn’t care where the infected object was originally — in which archive, in which file system, and so on.
• The logic of the antivirus engine was easily updated with the databases, and there was no need to restart to accept the new logic.
• The modules were tiny and easily adaptable to various platforms. As a result, KAV version 6, for example, was easily ported to Mac.
• Everything worked very fast and required a minimum amount of memory; Prague consumed far fewer resources than any existing object framework at the time.

Thanks to the use of Prague, we were at the cutting edge of the IT industry — the modular approach to software development was not as advanced then. Later, we even got four US patents for Prague: 7386885, 7730535, 7418710, 8234656.

Prague was also easy to integrate with code written on different principles. That’s why it was initially built into version 4.0, but only to solve a narrow range of problems. It proved itself so well there that when major problems appeared during the development of version 5.0, Doukhvalov came up with the idea of making a new version entirely on Prague — and that led to the revolutionary Kaspersky Anti-Virus version 6, which has already been described in great detail.

To grow an “antivirus plugin” into a framework for creating a whole product, some approaches had to be generalised and re-imagined. The main driving forces here were Andrey Doukhvalov and Pavel Mezhuev — if not for them, Prague would not have been suitable for such complex tasks.

Naturally, nothing is perfect in the development world, and Prague had two major drawbacks.

First, debugging it was difficult. Second, it was difficult for developers to adopt. No matter how you look at it, it was a newly developed object system, which imposed fairly strict requirements on the code design. Besides, the modules initially had to be written in pure C. It was hard to train people quickly, and we needed more and more developers as the company was growing and products were becoming more complex.

Thus, as elsewhere in the IT industry, development speed became a priority, and we gradually had to switch to better known and more conventional object frameworks. However, fragments based on Prague are still working successfully in our products.

Of course, back then these drawbacks were actually purely process-resource-based. They could and should have been dealt with, because the advantages of implementing Prague considerably outweighed and fully justified the resources spent. Prague solved one of the most difficult (and most expensive) problems that has become especially relevant in the last ten years — the portability of technology (including binary portability) to various platforms.

Instead of creating a new product from scratch for each operating system and processor, we used a ready-made debugged engine. This long-term R&D investment has not only fully paid off, but maintains our technological leadership to this day — the Unified Component Architecture, which is the successor of Prague, is being used to the utmost, and we still don’t see any problems that it can’t solve. This is further proof that good architecture can stand the test of decades.

As Alexey De-Monderik is fond of saying, Prague has played a very important role in our company, and not just in the technological sense. A group of committed people naturally formed around it, and they later became the team of the famous “Six.” So cheers for the team!

And cheers for this unexpected little anniversary of our main and very game-changing technology!