Compatibility and conversion issues for existing VCL projects
Due to the fact that the original syntax used in KOL projects is forced to follow the restrictions of objects, unlike classes, I did not worry too much about other syntax compatibility. For example, objects do not support for properties of the default modifier, i.e. in an object type representing a list, for example, you cannot set the Items property as the default and write just as easily for a TList in the VCL: MyList [i]. You always have to write MyList.Items [i].
With function names similar to those found in the standard SysUtils module, I also took the liberty of deviating from the standards. Using this module in a KOL project increases the size of the application by about 10-20 KB, so it's better not to use it. Most of the SysUtils function counterparts are in KOL itself, and you can use alternative modules that are more compatible in function names. In particular, I decided to call the functions a little differently also in order to keep the possibility of simultaneous access to functions from both KOL and SysUtils. (Of course, you could always use modifiers like SysUtils.IntToStr, but what's done is done, and shouldn't be changed now).
As for more complex objects, such as lists, trees, and others, in KOL you can often find analogs that provide no less, if not more, capabilities than the standard set of VCL classes. Moreover, I now prefer to do almost all the work in KOL just because for KOL, thanks to the dedicated work of many programmers, a huge variety of various components of a very different direction have been adapted, and they turn out to be more accessible than similar tools for VCL. At the very least, they are already easier to find than similar VCL solutions: they are centered on a few KOL sites, built in almost the same style as defined by the tighter KOL framework, easier to customize to work with, and easier to integrate into your KOL project. (And they are free and with source, which can be important too).
But there is no need to talk about full compatibility with VCL components from the very beginning. You may find that a similar property is called differently, and is, for example, not a property, but a function, or quite the opposite. In the case when in VCL to create your own thread class (for example) you had to create your own class inheriting from TThread and override the Execute method, in KOL it is enough to call the constructor of the PThread object in the project and assign the OnExecute event to it.
There are a lot of such incompatibilities. And this is not at all because I specifically wanted the KOL library to be incompatible with the VCL. I just wanted to keep the projects developed in KOL as small as possible. Therefore, there is no Run-time Type Information (RTTI) that Delphi is so proud of, and there are no components that load themselves from a thread, and therefore the syntactic differences are great. But the language remained the same - Pascal. And the compiler is the same, with all its advantages and disadvantages.
But KOL itself is just very well compatible (if you can say so at all), in terms of transferring projects from any version of Delphi to any other. Almost everything that works in KOL for Delphi 5 or Delphi 7 is also available for Delphi 3 and even Delphi 2. There are a few exceptions, for example, Delphi 2 and Delphi 3 do not support Unicode WideStrings to ensure compatibility to work with doubled integers, it is necessary to use functions specially made for this in the project.
Throughout the entire time that the KOL library was created and developed, many "converts" asked me a question about how they can turn a ready-made VCL project into a KOL-compatible one. Despite the fact that there are already several projects that convert a VCL application or VCL component to an analog for KOL, I recommend doing this work manually anyway. There are not many differences, in fact, between KOL and VCL, but they are quite varied, and it is better to control the modification process personally than to trust the machine. (No, I do not insist, you can always try, the attempt is not torture, especially since if it works out at least partially, then manual work after that can be reduced, and this is also a plus).
