Before starting to code, please look at the sources and determine the area in which you are interested to contribute. We have a wide range of tasks and, most probably, one of them will be interesting for you. Please remember that our current main goal is to provide more or less the full set of OS/2 API on top of L4 microkernel. Before asking also read osFree whitepaper

You must follow the rules of the project:

• All submitted code must be written by you or be existing open source code.

• All code developed by others must be open source and credits must be kept and not changed in any way.

• The following people may NOT participate in developing code for this project:

• Former or current IBM employees unless they can positively prove they will not breach any of the rules in their employment contracts.

• People bound by contracts with IBM that gives them access to things that would be considered illegal or doubtful for inclusion in this project.

• People that fit in these categories may however participate in documentation, writing specification or non-code-related activities (building webpages etc.) as long as they don't violate their contracts with IBM.

Other languages may be used to develop parts of the OS. However, they must be open source and use the OS/2 API. Usage of free resources (read: can be downloaded from lot of places) is not prohibited, but also not recommended. Please use the Watcom tools to build this source.

When conflicting tools exists (ex. NMAKE and WMAKE) always use the Open Watcom tool.

COMING SOON! osFree build environment for Win32 will be present in near future. Next version of build environment is Linux build environment. We have no plans to release OS/2 build environment package but you can create such thing if you have an interest.

First of all you need to download all above tools for your platform from corresponding sites:

• http://www.openwatcom.org for OpenWatcom
• http://www.freepascal.org for FreePascal
• http://regina-rexx.sf.net for ReginaREXX

You can download non-regular source snapshot from the site or latest sources from SVN. osFree sources hosted at Sourceforge SVN. Sourceforge also provide possibility to download any revision as .tar.gz archive.

Before compiling check files setvars-somename.cmd and somename.conf file, and change settings according your system. After changes just execute setvars-somename.cmd and enter

wmake

build process will be started. For clean up source tree say

wmake clean

For more information about build system read Build system document.

Please look at the SVN code tree to understand how files are to be placed. Please understand that the osFree SVN tree containg the code for an operating system and some toolkit tools. Do NOT place unrelated tools or applications in this tree.

Each level of the SVN tree contains two standard directories:

shared - Contains code shared among all source at this level and deeper levels

include - Contains header files for the above

Each levels/part of the OS should have a specific prefix that allows a developer to easily find what part of the OS a header/library file belongs to. For example code shared by the whole tree should be included with:

#include <all_shared.h>

and code shared by all commandline tools should include:

#include <cmd_shared.h>

Try to create as few shared code headers as possible. Each “shared” directory should contain one (1) library (.lib) file (xxx_shared.lib) with all shared code and each “include” directory should contain one main header file including all other (xxx_shared.h).

Example of use of common files:

// Use the normal OS/2 INCL_ since our toolkit is the OS/2 toolkit
#define INCL_DOSERROR

// Do NOT include os2.h, use osfree.h instead
#include <osfree.h>

// Include any needed normal C library
#include <malloc.h>
#include <string.h>

// Include all shared code and shared code for command line tools
#include <all_shared.h>
#include <cmd_shared.h>

Private code (not shared with other code) should be documented only in the source.

Shared code (shared with code at the same level or at all levels) should be documented in source and in a “building and developing” document.

The API of the OS and the tools documentation should NOT be documented in the source tree but in the toolkit and release tree.

Source code should be documented in the source file (not the header files).

Each function should be prefixed with a description of what it does, what parameters it uses (in and out) and any external references it uses.

Place comments in the source that helps the reader to understand the logic and don't overdo it.

Use static linking, do not use dynamic libraries (LIBC style) or dynamic runtime.

Use the makefiles provided with the source tree, don't “do your own”.

Currently osFree development is done on OS/2 (minimum Warp 4) but in the future development will be hosted on osFree.

We use SVN to share code among developers.

We use Doxygen and Wiki to document our work.

• Make sure your changes follow the coding guidelines above.

• Make sure you are using the current versions of the sources so that the resulting diffs are comparing your changes with the head of the source tree.

• Create your patch either by using cvs diff -u (if you are using CVS) or diff -u original-file changed-file (if you are using a source archive - you can also create differences for the whole directory contents using diff -r) In the latter case include the old code first, the new code last – in the patch anything you added will be prefixed with a +.

• Remove all/any lines that reference files without changes.

• Send the patch file as an attachment in your email. Do not paste the patch directly into the email body.

• Maintainers will often reply in response to your patch, pointing out things to fix up, etc. before a patch can be checked in. Please always follow the maintainer suggestions closely and respond by sending a new corrected patch. Please do not expect the maintainers to rework your changes, you want to be able to claim all the credit for your great patches!