The Odin Project

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.

Wiki & Mailinglist

There is a (rather outdated) page in the ​netlabs.org Wiki about Odin, feel free to contribute to it! Also we have a ​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@….

Reporting Bugs

Reporting bugs and requesting new features is done through the ticket system. You can view existing tickets, add comments to them and create new tickets using the corresponding buttons at the top of every page. If you want to submit a new bug or request a feature, please use the Search function first to make sure there is no ticket for this task already created.
We review the tickets regulary and leave comments if we need more info. So please revisit the ​Feedback analysis as often as possible. If we leave comment and don't get feedback from the ticket creator, we will close the ticket after some weeks.

Anonymous access to the ticket system has been restricted due to multiple attacks of stupid spammers we've been suffering from lately. In order to create a new ticket or comment the existing one, you need to login with your Netlabs login id. If you do not have a login id, you can request one at ​http://www.netlabs.org/en/site/member/member.xml. We are sorry for inconvenience, but at the present time this is the only way to avoid extremely annoying spam.

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.

Pulling the Odin repository

The Odin repository has an issue with local directories containing a dash (-) during build (e.g. svn-code). A build failure can result.
For the primary environment:
svn co ​http://svn.netlabs.org/repos/odin32/trunk Odin
There are a couple of years worth of updates that are not in the trunk as the older trunk was used when Flash development started.
svn co ​http://svn.netlabs.org/repos/odin32/tags/odinxp Odinxp