Porting applications to KolibriOS

Aus KolibriOS wiki
Zur Navigation springen Zur Suche springen

The aim is to port applications from one OS to another, without rewriting most of the code. For porting, you need the source code of the desired program.

Here I will discuss the process of porting applications to KolibriOS by an example of SQLite (database engine).

Criteria for selecting applications for porting

Some applications port easier than others. Therefore, one should chose the application that's easiest to port, from applications with similar purposes.

  • The program you want to port must be written in a compiler that is supported on KolibriOS. Or do you want to translate the source code into another language? In general, there is little reason to prefer ASM over HLL (High Level Languages), or vice versa.
  • The less features of the OS you use, the better. This is explained by the fact that for each operating system function used by the application, you want to find or write the equivalent for KolibriOS. In some cases, however, it can be left instead to "stub", which does nothing, for example, I used such a function to lock the files in SQLite.
  • It's preferable to choose cross-platform applications, because they are generally easier to port. In particular, all calls are often grouped into the OS and you dont need to look for them throughout the code.
  • The less source code, the better.
  • If the source code written in good style, it's easier to read and edit. The less tricks and gimmicks, the easier it is to port the application.
  • Applications written in the rapid development environments such as Delphi, are not recommended to port, because the application code itself can be very small, but the code for libraries is huge. Better to chose an application that uses the native OS API.
  • Sometimes it is useful to reduce the possibility of the application, i.e. porting only a portion, discarding the rest of the code. Or you can choose to port an earlier version of the code which is smaller and uses less external functions.

Identify external dependencies

At this stage you need to write a list of functions of the OS (or functions of external libraries, which have not been ported to KolibriOS), which the program uses. Fairly simple way to do this if the program is written in C, is to remove references to the h-files (or hide from the compiler, these files) and see what the compiler complains about.

Writing Replacement of external functions

For each function identified in step 2, you want to write a "wrapper" - a function with the same parameters, but which works in KolibriOS.

Example: The application uses malloc () from the standard C library

Write a function:

void * malloc(int size)
{ 
	__asm
	{ 
		mov eax, 68 
		mov ebx, 12 
		mov ecx, size 
		int 0x40 
	} 
}

This function dynamically allocates memory, but in KolibriOS. Accordingly, all calls to malloc () will now use system calls KolibriOS and work in this OS.
Note: the files on the SVN in kolibrios.org\programs\develop\ktcc\trunk\libc\ There you can find the realization of a large number of standard library functions of C. There also is menuetlibc for GNU C.

Some remarks

  • For programs that are actively using the stack, you may need to increase the value in the header, sets the size of the stack.
  • If possible, you should use the compiler that the authors recommend the program.