[Openal-devel] OpenAL porting to WindowCE

[Vincent Richomme]

Hi,

I have started to port openal to windows CE 
platforms(http://www.smartmobili.com/Downloads/OpenAL-WindowsCE.7z)  and 
I have some remarks/suggestions to give you before I finish it.
First I have started from OpenAL-Windows and make a new folder called 
OpenAL-WindowsCE with VS2005 projects targeting Windows Mobile 5/6 devices.
On windows CE almost all API are natively in UNICODE and since openal is 
using ANSI I made a small library called compat4wce that implements 
missing ansi functions.
While I am talking about issues related to encoding, I have remarked 
that file alc.cpp inside Router module was using encoding in a wrong 
manner. Indeed all strings and functions were using
the _T() macro and if everything are ok when compiling in ansi it cannot 
work in Unicode because openal interface are using char*. In addition 
it's the only module to do that.

Let's take an example :

bool GetDefaultPlaybackDeviceName(char **pszName)
{
   ...
    TCHAR szPath[_MAX_PATH];
    HINSTANCE hDSoundDLL;

    if (GetSystemDirectory(szPath, _MAX_PATH))
    {
        _tcscat(szPath, "\\dsound.dll");
        hDSoundDLL = LoadLibrary(szPath);
        if (hDSoundDLL)
        {
            LPDIRECTSOUNDENUMERATEA pfnDirectSoundEnumerateA = 
(LPDIRECTSOUNDENUMERATEA)GetProcAddress(hDSoundDLL, 
"DirectSoundEnumerateA");
            if (pfnDirectSoundEnumerateA)
                pfnDirectSoundEnumerateA(&DSEnumCallback, pszName);
            FreeLibrary(hDSoundDLL);
        }
    }
}


In the code above you see that main parameter in a char* but inside 
function, it's using TCHAR and _tcscat so in unicode build there will be 
conflicting types.

To solve this I had 3 options :

1) define a openal_tchar.h that would be a copy of the windows tchar.h 
that is used to define functions and macros in function of character 
encoding.
On Unix platforms ansi would always be enabled and for instance _tcscat 
would expand in strcat while on windows platforms it would depends on 
encoding build.
This option involves to decorate all strings with _T() macros and to 
replace all char by a TCHAR

2) Implements missing ansi functions on windows ce, this is generally 
what is done in opensource projects when porting to wince(openvpn, 
opengles, ...).
I don't think it's a good idea because of performance loss and the fact 
that you can introduce new bugs, but since everyone is doing it ....

3) Trying to compile in ansi on wince : not really possible or I should 
say that's very difficult.

So I choose option 2 because it was simpler and as I said porting is 
generally done like that.

Now I am implementing a very simple DirectSound implementation 
(available here : 
http://www.smartmobili.com/index.php?option=com_content&task=view&id=37&Itemid=41&lang=english)
because on Windows CE DirectSound has been dropped before Windows Mobile 
5.0.
In a first step Dsound will not support DirectSound3D and will be added 
later on.


I will keep you informed about my progress.


--------------------------------------------------------------------------------------------------
Major changes between win32/wince:

#ifndef _WIN32_WCE
 #pragma comment(lib, "winmm.lib")
#else
 #pragma comment(lib, "mmtimer.lib")
#endif

#ifdef _WIN32_WCE
#include "compat4wce.h"
#pragma comment(lib, "compat4wce.lib")
#endif

Vincent Richomme
CTO smartmobili
www.smartmobili.com