Porting applications to KolibriOS: Difference between revisions
(Created page with '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...') |
m (Changed Hummingbird to KolibriOS.) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
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. | 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 | Here I will discuss the process of porting applications to KolibriOS by an example of SQLite (database engine). | ||
== Criteria for selecting applications for porting == | == Criteria for selecting applications for porting == | ||
Line 7: | Line 7: | ||
Some applications port easier than others. Therefore, one should chose the application that's easiest to port, from applications with similar purposes. | 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, or vice versa. | * 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. | * 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. | * 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. | ||
Line 13: | Line 13: | ||
* 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. | * 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. | * 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, | * 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 == | == 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 | 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 == | == 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 | 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 | Example: The application uses malloc () from the standard C library | ||
Write a function: | Write a function: | ||
< | <syntaxhighlight lang="c"> | ||
void * malloc(int size) | void * malloc(int size) | ||
{ | { | ||
Line 37: | Line 37: | ||
} | } | ||
} | } | ||
</ | </syntaxhighlight> | ||
This function dynamically allocates memory, but in KolibriOS. Accordingly, all calls to malloc () will now use system calls KolibriOS and work in this OS. <br> | This function dynamically allocates memory, but in KolibriOS. Accordingly, all calls to malloc () will now use system calls KolibriOS and work in this OS. <br> | ||
Note: the files on SVN in kolibrios.org\programs\develop\ktcc\trunk\libc\ | 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. | ||
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 == | == Some remarks == |
Latest revision as of 17:42, 15 September 2013
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.