Platform "1C: Enterprise" - what's under the hood?

Hi, Habr!
In this article we will begin the story about how the 1C: Enterprise 8 platform is built inside and what technologies are used in its development.

Why do we think this is interesting? First, because the “1C: Enterprise 8” platform is a large (more than 10 million lines of code) application in C ++ (client, server, etc.), JavaScript (web client), and, more recently, and java . Large projects are interesting, if only by virtue of scale, because the issues invisible in a small code base in such projects stand in full growth. Secondly, “1C: Enterprise” is a replicable, “boxed” product, and there are very few articles about such developments on Habré. And it is always interesting to find out how they live in other teams and firms.

So let's get started. In this article we will give an overview of some technologies that are used in the platform, outline the landscape, without deep immersion in the implementation. After all, for many mechanisms a detailed story will pull on a separate article, and for some - on a whole book!
To begin with, it’s worth deciding on the basic things - what is the 1C: Enterprise platform and what components it consists of. The answer to this question is not so simple, because the term “Platform” (for brevity, we will call it that way) is understood both as a tool for developing business applications, and an execution environment, and means of administration. Conventionally, the following components can be identified:

server cluster
“Thin” client capable of connecting to the server via http and its own binary protocol
client for working in a two-tier architecture with a database located on a hard disk or network folder
web client
application server administration tools
development environment (known as Configurator)
Runtime for iOS, Android and Windows Phone (1C mobile platform)

All of these parts, with the exception of the web client, are written in C ++. In addition, there is a recently announced new generation Configurator written in Java.
')

Native applications

C ++ 03 is used to develop native applications. Under Windows, Microsoft Visual C ++ 12 (a profile compatible with Windows XP) is used as a compiler, and under Linux and Android - gcc 4.8, for iOS - clang 5.0. The standard library is used uniformly for all OS and compilers - STLPort. This solution reduces the likelihood of errors specific to the implementation of STL. Now we are planning to switch to the implementation of STL supplied with CLang, since STLPort has stopped its development and is incompatible with C ++ 11 support mode enabled in gcc.
At the same time, the code base of the server is 99% common, and the client's percentage is 95%. Moreover, even the mobile platform uses the same C ++ code as the “big” one, although there the percentage of unification is somewhat lower.
Like most C ++ users, we do not claim to use 100% of the capabilities of the language and its libraries. So, at us Boost is practically not used, and from language possibilities - dynamic type conversion. In this case, we actively use:

STL (in particular, strings, containers and algorithms)
multiple inheritance, incl. multiple inheritance implementation
templates
exceptions
smart pointers (own implementation)

Due to the use of multiple inheritance of interfaces (completely abstract classes), the component model becomes possible, which will be discussed below.

Components

To ensure modularity, all functionality is divided into components, which are dynamic libraries (* .dll under Windows, * .so - under Linux). In total components more than one and a half hundreds, we will provide descriptions of some of them:

backend	Contains the "engine" platform metadata
accnt	Objects that application developers use to build accounting (charts of accounts and accounting registers)
bsl	Integrated language performance engine
nuke	Own implementation of memory allocator
dbeng8	File database engine. A simple file server-based database engine based on ISAM, which also includes a simple SQL processor.
wbase	Contains the base classes and functions for implementing the Windows user interface — window classes, GDI access, and so on.

Separating into many components is useful from several points of view:

Separation promotes better design, in particular better code isolation.
From the set of components, you can flexibly assemble various delivery options:
- For example, a thin client installation will contain wbase, but there will be no backend
- on the contrary, wbase will not be available
- both options will of course contain nuke and bsl

All the necessary components for this launch option are loaded when the program starts. This, in particular, is necessary for registering SCOM classes, which will be discussed below.

Scom

For decomposition at a lower level, the SCOM system is used - ideologically similar to ATL library. For those who did not work with ATL, briefly list the main features and features.
For the specially designed SCOM class:

Provides factory methods that allow you to create a class from another component, knowing only its name (without disclosing the implementation)
Provides an infrastructure of smart pointers with reference counting. There is no need to manually monitor the lifetime of the SCOM class.
Allows you to find out if an object implements a specific interface and automatically bring a pointer to an object to an interface pointer
Create a service object, always accessible via the get_service method, etc.

For example, you can describe in the json.dll component a class for reading JSON (for example, JSONStreamReader).
Classes, instances can be created from other components you need to register in the SCOM machine:

SCOM_CLASS_ENTRY(JSONStreamReader)

-, .
:

IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));

SCOM , . SCOM-, (.. Service Locator), . SCOM . :

SCOM_Process* process = core::current_process();
if (process)
         return get_service<IMyService>(process);

, (SCOM) , , . , — SCOM-, , — . , , «» - . — , , .

SCOM - 1: .

, . Windows, Windows API. Linux- , wxWidgets.
«1:» .

1: , , 2009 , 8.2 « ». , — flow- . , , DTO (Data Transfer Objects).
- «1:», ++ JavaScript. . , , , - JavaScript API (, ), , C++. Internet Explorer Microsoft Edge (Windows), Google Chrome(Windows), Firefox (Windows Linux) Safari (MacOS).

, 1. «» , , «» «1:».