The Odin Project

Wiki & Mailinglist

There is a page in the netlabs.org Wiki about Odin, feel free to contribute to it! Also we have a new ​mailing list at netlabs.org, you can read it at ​gmane.org, or you can subscribe by mail. The name of the list is odin-user@….

About Odin

Odin is the name of the project and software that allows users to run Win32 (Windows 95 and Windows NT) applications in OS/2 Warp operating system natively, almost as if they were intended to be OS/2 applications in the first place. It also makes porting from Win32 to OS/2 easier by providing a Win32 API implementation in OS/2: the Odin32 API.

Binary compatibility is achieved by converting Windows EXE and DLL files (applications are made of those) into the format that OS/2 uses. Conversion can be permanent, or it can be done transparently on runtime, when an application is started. Conversion and loading of Win32 programs, basicaly, consists of:

• Converting PE (Portable Executable - Win32 binaries) objects in OS/2's LX (Linear eXecutable) format.

• Reassembling them in memory in the way OS/2 applications are supposed to be assembled.

The program that will permanently convert binaries (EXE and DLL files) is called PE2LX.EXE. However, it's much more flexible to use dynamic, on-the-fly conversion (via PE.EXE loader) because in that case executable modules on disk are not changed, and you can use your Win32 programs in both Windows 95/98/NT and OS/2 from the same space on disk. Both methods can be automated and made absolutely transparent to users with the use of the WIN32K.SYS driver that allows OS/2 processes (WPS, command prompt...) to launch Win32 binaries as any other OS/2 applications, providing automatic conversion/loading at startup time.

Converted/loaded program will look and behave as any other OS/2 application. There is no emulation layer, no Windows "sessions" or virtual machines like it was the case with Win-OS/2 that IBM has provided for running Windows 3.1 applications: the code is executed directly by CPU with all rights, priviledges and limitations of normal 32-bit OS/2 programs. In order for program to operate, it must have access to the same API functions as in Windows operating system(s). Those functions are called Win32 API (Application Programming Interface) and Odin provides them, as well. It's the second part of the project whitch aims at: Providing runtime libraries that replicate Win32 API functions and that are used by loaded and running programs. Runtime libraries are supplied as a number of DLL files with the same names as the ones what are supplied with Windows 95 and Windows NT because Win32 applications expect to find them under those names. Any name conflicts (DLLs with same names shipped with OS/2) are resolved during the conversion/loading process. Odin32 DLLs are pure native OS/2 binaries which operate in the same way as their Windows counterparts. The set of API functions that are implemented for Project Odin is called Odin32.

The Odin32 API can aslo be used (and is used) for native OS/2 development, primarly for porting software from Windows. Since it replicates the functionality of the Win32 API closely, a porter can much easier match the basic functionality and then add OS/2 specific improvements.

A very good example of an application which is using this technology is Opera for OS/2. It is compiled using Odin32 API and OS/2 specific behaviour was added as well.

The final goal of the first part of the project is to make every Windows program load and operate properly, and the goal of the second part of the project is to create complete OS/2 implementation of Win32 API, which means that every single API function should be implemented or mapped to equivalent OS/2 API function via Odin32. Whether those goals will be ever achieved remains to be seen, but this project gives good results even now, since no Windows program uses all API functions and very few use even majority of them.

About Trac&Subversion, code guidelines

To allow proper coding and usage of Trac&Subversion features, it is suggested to follow some guidelines.

First, all commits must belong to a ticket; tickets can be created by project manager or by developers for defect fixing, code enhancements or other tasks.

Tickets will be used to tell other people about problems, and allow discussion of patches or new code added. Subversion commits needs to link their ticket in commit message. This can be done using the following syntax:

   svn commit -m "Here are my changes. ticket:1." *.*

Trac timeline will automagically convert 'ticket:1' into the URL of the ticket.

At the same time, the changeset number should be added to the ticket using the following syntax:

   (changeset:145) Here are my changes. 

This allows following ticket life without looking at timeline changes every time. While the commit message is usually short, developers can add more detailed informations in ticket record. Remember, other developers could not know what you are doing, or understand what has been changed simply looking at code.

Also we need to track changes to avoid regressions as much as possible: exhaustive descriptions makes life much easier when regressions or typos must be fixed.