[olsr-dev] OLSR on Windows Mobile (WinCE)

[Thomas Lopatic]

Hi Takehiro,

Thanks a lot for offering your help!

I think the easiest way to approach a Windows CE port would be to start 
from the Windows port, as the Windows CE API is basically a subset of 
the Windows API. So, for a start you might simply want to use something 
like "-DWIN32 -DWINCE". My idea here is that you basically compile the 
Windows port ("-DWIN32") and, inside the Windows-specific code, then use 
"-DWINCE" to decide whether you want Windows or Windows CE code, if the 
platforms differ. So, my idea basically is:

#if defined WIN32

   [... code that is identical on Windows and Windows CE...]

#if defined WINCE

   [... code that is specific to Windows CE...]

#else

   [... code that is specific to Windows...]

#endif

   [... code that is identical on Windows and Windows CE...]

#endif

I've tried this a while ago with the cross-compiler that you mentioned 
in your first post and major parts of the Windows-specific code were 
compileable without any changes. I haven't investigated this further, 
though. The code that adds and removes routes and which is based on the 
IpHlpAPI DLL looked pretty good. The only problems seemed to be 
Interface enumeration, for which we use WinSock 2. I do not know, 
however, whether the functionality that we use (e.g. INTERFACE_INFO) 
does not exist on current Windows CE versions or whether it is only 
missing from the cross-compiler's headers and libraries. If the former 
is the case, then we should re-write the Windows code to use API calls 
that are also supported on Windows CE (which should be possible) to keep 
the differences between Windows and Windows CE to a minimum.

When compiling for Windows CE you should remove the "-DWIN32_STDIO_HACK" 
definition. This is only used for the Windows GUI. The Windows GUI calls 
the configuration file DLL to read and write configuration files. And in 
order to intercept the error messages produced by the configuration file 
DLL we redirect stderr to a pipe, which we then read. Each line read 
from the pipe is then displayed as a dialog box by the GUI. So, the idea 
is that the GUI intercepts its own output to stderr and displays it. A 
hack, as the name implies. :-) We should one day come up with a way for 
the GUI to report errors that is more generic than fprintf(stderr, ...). 
Some sort of callback function. The GUI could then simply register the 
callback function and in this way obtain the DLL's error messages.

Let us know if there's anything else that we can do for you and thanks 
again for helping!

-Thomas