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

[Andreas Tønnesen]

Hi Takehiro,

The cfgparser can be buildt in three different ways:

* As part of olsrd. If MAKELIB or MAKEBIN is not defined the cfgparser
will just compile the source into object files ready to be linked into the
olsrd binary. This is what happens when building olsrd from the main
Makefile.

* As a shared library. If MAKELIB is defined the cfgparser will be buildt
as a shared library. LIBNAME defines the name of this share library. Since
windows uses .dll name convention, the definition of the LIBNAME is
different from win32 to the Unix variants. This is usefull if other
applications wants to build and parse olsrd configfiles.

* As a stand-alone binary. if MAKEBIN is defined the cfgparser will be
compiled and linked resulting in a stand-alone binary capable of
validating config files.

Regarding the various flags used for win32 building I think Thomas can
help you out there.

A winCE port sounds cool. I hope you keep us posted on your progress :)


- Andreas

Regarding the win32 flags etc. Thomas can probably help out.

> Hi Andreas,
>
> Thank you for your very quick response.
> I've already started on creating empty wrappers and this part seems
> extremely straight-forward.
> I've noticed that olsrd enables OS configurations such as IP forwarding
> within the code,
> and API calls needed are basically supported in WinCE 4.2 (as far as I see
> right now)
>
> Now, for the cfgparser. I'm sorry that I got you confused with Makefile
> configuration and
> the actual implementation of the parser.
> What I meant to say was the difference in Makefile for win32 and *nix.
>
> ifeq ($(OS), osx)
> DEPFLAGS +=	-D__MacOSX__
> endif
>
> ifeq ($(OS), win32)
>
> LIBNAME ?=	olsrd_cfgparser.dll
> BINNAME ?=	olsrd_cfgparser.exe
>
> PORT_CFLAGS =	-mno-cygwin -I../win32 -DWIN32_STDIO_HACK
> PORT_LDFLAGS =	-mno-cygwin
> PORT_OBJS =	../win32/compat.o
> PORT_LIBS =	-lws2_32
> DEPFLAGS += 	-DWIN32_STDIO_HACK -DWIN32
> INCLUDES +=	../win32
>
> Though I don't have much experience in Windows development field,
> most of the fields are self-explanatory or requires very little searching.
> -mno-cygwin - no use flag for cygwin emulater libs... should be disregard
> in
> this scenario.
> -lws2_32 - winsock2.... a must.
> WIN32_STDIO_HACK - not sure at the moment but seems like a must
>
> Hmm... I guess I'm just confused by
> "LIBNAME ?=	olsrd_cfgparser.dll" and "BINNAME ?=	olsrd_cfgparser.exe"
> as they don't show up on any other platforms.
> Loading olsrd_cfgparser.dll into the main program makes sense so it can
> understand the config
> file, but why would there be a need for a single executable?
>
> Thank you again for your help.
>
> - Takehiro
>
>
>
> -----Original Message-----
> From: (spam-protected) [mailto:(spam-protected)] On
> Behalf
> Of Andreas Tonnesen
> Sent: Friday, March 18, 2005 2:00 AM
> To: OLSR development
> Subject: Re: [olsr-dev] OLSR on Windows Mobile (WinCE)
>
> Hi Takehiro,
>> Now my question would be, what is the most proper approach to start
>> this process?
>>
>> I realize that there are some platform dependent directories, and I
>> understand that those need to be rewritten for WinCE.
>
> What you need to do is to build the OS dependent functionallity for winCE
> by
> following the already defined interface. The most critical function is
> kernel route manipulation, but network interface detection mechanisms are
> also important. But for a starter you can just create empty
> wrappers/hardcoded configuration for the OS dependent stuff, just to be
> able
> to build olsrd and the move on the implement kernel route manipulation.
> Hopefully the winCE API is not to much different from win32.
>
>> ported to WinCE platform as the Makefile under cfgparser seems to
>> contain options that are really different from Unix based systems.
>
> I'm not quite following you on this. The cfgparser Makefile is just as
> Unix'ish as the others IMO :) What you need to generate the parser code is
> flex/bison or something similar. This really shouln't cause too much
> trouble
> as far as I can see, and there should really not be a need to rewrite
> anything in the parser code...
>
> - Andreas
>
> --
> Andreas Tønnesen
> http://www.olsr.org
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>


---------
Andreas Tønnesen
http://www.olsr.org