C--. First meeting

The process of porting and creating software development tools for KolibriOS continues. We publish articles on the most actively used programming languages. Today we begin to talk about the language C--, around which an active community developed in the 2000s. Details under the cut.

Briefly about the language from the official site :

C-- is a programming language that is intermediate between assembler and C. Ideal for writing small programs, residents (TSR), drivers, interrupt handlers. To work with the language C-- familiarity with the assembler and C is necessary. Now C-- can generate 32-bit code under DOS and Windows (approx. Ed. And also under MenuetOS, KolibriOS) .

The author of SPHINX C-- is Peter Cellik (CANADA). The latest author's version of SPHINX C-- v0.203 is from 28.Oct.96. Unfortunately, the author refused to further develop the language. The language itself, together with the source code, was declared orphaned and given to no one else. Those. do what you want. Why not do it? On this page you will find the latest (but not the author's) version of the language itself, the library, examples of programs, a description of the language itself and libraries in the Notron Guide format, and many other useful information on the C-- language.

After Peter Sellik, Mikhail Sheker was involved in support, but he stopped development several years ago. Last year, the source code was posted on Github https://github.com/jossk/c--sphinx , but we only learned about this in March 2016 .

It was decided to talk about this language for two reasons:

1. Several popular KolibriOS programs are written on it, among which Eolite is perhaps the most used file manager.
   
2. Relatively recently, the compiler of this language was ported to KolibriOS (the answer to the question about the license can be found here ).

A little about the porting process from GerdtR :

So. At first I redid the code under gcc. The source code was simply written for Watcom C, well, if not significant, but there was an incompatibility. Corrected a couple of variable names (extern in the cotton committee can, apparently), and the designation of 64-bit numbers differently. Then Leency revealed that the gcc version does not search for files in the current folder at all, only in the folder with the file itself. When this fixed the most difficult: the port for the Hummingbird. Well, since I did not write to CBS under C, there was a standard problem - with whom to link, and what classes to take. The choice is not wide, the menuetlibc was dropped immediately, as I, having rummaged in the source code, saw still the old functions of accessing files (f56 like). In short, menuetlibc is outdated, newlib remains. For a long time I understood how to get kex and not PE at the output, one Makefile helped, where additional objcopy processing was written. Well, after that, adding functions that are not in newlib (for example, stat was not, in port.c its implementation lies). Well, a couple of functions for converting ANSI-> ASCII encodings, or rather stubs, because there are still no Russian letters in the compiler strings. Well, the last problem was, and partially this is left: because of newlib (most likely there is no one more), the current directory is set as the path to the mm itself (and usually / rd / 1), so it turns out that it is to find out where the source the compiler cannot, at least from where to start it. Exit at the moment - copy the compiler to the source folder, or specify the absolute path. By the way, before the symbol '/' was considered the beginning of the parameter and the absolute path was not possible to specify, it is now possible. But with an absolute path, I’m not sure yet what it will find. So far, I don’t want to bother with it, and you can just write -IP = "/ hd1 / 1 / my_source". In theory, it should work, in practice, no one asked. By the way ... indicate in the forum something, that the parameters through '-' indicate now ... And when you start without parameters, in the table correct, but then some confusion is obtained. Ok, then somehow. Well, in general, the whole story. The most difficult thing was to figure out where to get it from. :) The code itself is pretty simple, not in a super order, but I didn’t have to pick the code too much

The language guide is available at http://www.c--sphinx.narod.ru/c--doc.htm . Consider an example of a simple application for KolibriOS:

#define MEMSIZE 4096*10 #include "../lib/io.h" #include "../lib/gui.h" void main() { word id; dword file; io.dir.load(0,DIR_ONLYREAL); loop() switch(WaitEvent()) { case evButton: id=GetButtonID(); if (id==1) ExitProcess(); break; case evKey: GetKeys(); if (key_scancode == SCAN_CODE_ESC ) ExitProcess(); break; case evReDraw: draw_window(); break; } } void draw_window() { proc_info Form; int i; DefineAndDrawWindow(215,100,350,300,0x34,0xFFFFFF,"Window header"); GetProcessInfo(#Form, SelfInfo); for (i=0; i<io.dir.count; i++) { WriteText(5,i*8+3,0x80,0xFF00FF,io.dir.position(i)); } DrawCaptButton(100, 10, 100, 22, 22, 0xCCCccc, 0x000000, "Button"); WriteText(100,50,0x80,0,"Textline small"); WriteText(100,70,0x90,0,"Textline big"); DrawBar(100, 110, 100, 100, 0x66AF86); } 

As you can see, this code is almost the same as in C, but it is possible to write calmly in an almost assembler style, similar to writing wrappers for system functions. For example, the window creation function:

 void DefineAndDrawWindow(dword x, y, size_w, size_h, byte WindowType,dword WindowAreaColor, EDI, ESI) { EAX = 12; EBX = 1; $int 0x40 $xor EAX,EAX EBX = x << 16 + size_w; ECX = y << 16 + size_h; EDX = WindowType << 24 | WindowAreaColor; $int 0x40 EAX = 12; EBX = 2; $int 0x40 } 

What makes it attractive for software developers for KolibriOS? First of all, it's very easy to start writing on it. It was the only language, not counting FASM, in which one could simply start writing without bothering with the cross-compilation setting (now, in this case, C is already gaining momentum). Secondly, for C-- a lot of libraries and various wrappers were written over system functions. Among them is its own set of interface elements and even good fonts:

You will surely ask yourself a question: if everything is so beautiful, then what is the problem? Why does it not apply everywhere, even if it is part of the KolibriOS project?
The answer is as follows. Despite the advantage in ease of development, with its use and disadvantages emerge:

• poor result code optimization;
• operations priorities are practically absent (C-- considers everything from left to right, that is, 2 + 2 * 2 = 8, not 6);
• Most importantly, although it is similar to C, it is a different programming language with its own sphere of application. In the framework of KolibriOS, it is most suitable for creating programs with a graphical interface and is almost never used in system programming.