Menu
▾
▴
#63 wince/winmobile port
hi,
i've ported the current libevent to winmobile using wcecompat library (http://github.com/valerino/wcecompat).
this is part of my project of porting tor to winmobile (already done).
included is the src patch and the vs2008 project file. to compile, set WCECOMPAT to path/to/wcecompat
regards,
valerio lupi/te4i
www.te4i.com
wince patch
It looks like the patch does the following things:
CRIT) Conditionally use InitializeCriticalSection rather than InitializeCriticalSectionAndSpinCount on WINCE.
This wants to be a function, or even just a define in evutil-internal.h
DEF1) Replace some (but not all!) WIN32 checks with defined(WIN32)||defined(WINCE), and others with defined(WIN32) && !defined(WINCE)
This seems reasonable.
DEF2) Replace some (but not all) _MSC_VER checks with defined(_MSC_VER) || defined(WINCE)
This confuses me; _MSC_VER is supposed to be defined whenever the compiler is Visual C.
PROJ) Add a project file
This is a non-starter for Libevent. We had project files long ago, and nobody ever maintained them, We now have nmake Makefiles: See makefile.nmake.
INCL) Add a winsock2.h include to include/event2/event.h when building with WinCE.
Why?
WCHAR) Replace lots of FooA functions with their FooW equivalents, since WinCE doesn't provide the ASCII versions
Libevent needs to be useful by lots of different projects. I think it makes more sense to use the generic versions with the TCHAR and TEXT macros, and build happily either with unicode or without.
I'll try doing this today to see how hard it is.
VERS) Use GetVersionEx instead of GetVersion.
Seems okay; WinCE doesn't have GetVersionEx?
Also, what did you need wcecompat for? I see these uses of posix-style file IO on Windows in the library proper (not counting the unit tests):
evbuffer_add_file() in buffer.c
evutil_read_file() in evutil.c
If there are only two places that need wcecompat, it might make more sense simply to use CreateFile and ReadFile there instead.
Oh, and two quick notes on the patch formatting:
1) You should probably set the "name" field in your Git configuration to your full name, capitalized however you want to appear in the Libevent credits
2) Git lets you do lots of little patches in a single branch, and use format-patch to send them all separately. It's easier to review patches that only make one change at a time.
Adding your other patch as an attachment here. Please put related patches on a single tracker entry.
[Reposting with permission from email]
hi nick,
i checked yesterday and i didn't have time yet to fix it. looking into that now!
>CRIT) Conditionally use InitializeCriticalSection rather than
>InitializeCriticalSectionAndSpinCount on WINCE.
>
>This wants to be a function, or even just a define in evutil-internal.h
ok!
>DEF2) Replace some (but not all) _MSC_VER checks with defined(_MSC_VER) ||
>defined(WINCE)
>
>This confuses me; _MSC_VER is supposed to be defined whenever the compiler
>is Visual C.
right. there's only one needed, in evutil.c : compiling on wince fails since you force __MSC_VER < 1300 here (and wince/wcecompat do not have _strtoi64):
ev_int64_t
evutil_strtoll(const char *s, char **endptr, int base)
{
#ifdef _EVENT_HAVE_STRTOLL
return (ev_int64_t)strtoll(s, endptr, base);
#elif _EVENT_SIZEOF_LONG == 8
return (ev_int64_t)strtol(s, endptr, base);
#elif defined(WIN32) && defined(_MSC_VER) && _MSC_VER < 1300 || defined (WINCE)
/* XXXX on old versions of MS APIs, we only support base
* 10. */
ev_int64_t r;
if (base != 10)
return 0;
r = (ev_int64_t) _atoi64(s);
while (isspace(*s))
++s;
while (isdigit(*s))
++s;
if (endptr)
*endptr = (char*) s;
return r;
#elif defined(WIN32)
return (ev_int64_t) _strtoi64(s, endptr, base);
#else
#error "I don't know how to parse 64-bit integers."
#endif
}
>PROJ) Add a project file
>
>This is a non-starter for Libevent. We had project files long ago, and
>nobody ever maintained them, We now have nmake Makefiles: See
>makefile.nmake.
ok ... will look into that!
>INCL) Add a winsock2.h include to include/event2/event.h when building
>with WinCE.
>
>Why?
i do not see this .... maybe i've sent you an older patch ? looking into that .....
>WCHAR) Replace lots of FooA functions with their FooW equivalents, since
>WinCE doesn't provide the ASCII versions
>
>Libevent needs to be useful by lots of different projects. I think it
>makes more sense to use the generic versions with the TCHAR and TEXT
>macros, and build happily either with unicode or without.
>
>I'll try doing this today to see how hard it is.
are you going to fix it yourself so ?
>VERS) Use GetVersionEx instead of GetVersion.
>Seems okay; WinCE doesn't have GetVersionEx?
yep, the same patch is in tor too.
regards,
valerio
Re CRIT: it looks like your patch fixes that.
Re DEF2: It looks like you fixed some of that too, but maybe it would make more sense just to have an _EVENT_HAVE_STRTOI64 macro ?
Re INCL: Oops, I meant include/event2/event_struct.h. But still , why?
Re WCHAR: I checked in a patch that I think may solve this; I'm not sure whether it's a complete solution. If you can try it out, that would be great.
Also, do you have an answer to my question about wcecompat?
>Re DEF2: It looks like you fixed some of that too, but maybe it would make
>more sense just to have an _EVENT_HAVE_STRTOI64 macro ?
uhm .... yep, that seems reasonable since you already use HAVE_blabla to exclude/include parts of code.
>Re INCL: Oops, I meant include/event2/event_struct.h. But still , why?
i've cheked now. it's because of the timeval struct. i've included <winsock2.h> coz it defines that, else its not defined in that place when compiling on wince. it causes errors like this everywhere :
1>z:\torce\tor\contrib\levent\include\event2/event_struct.h(93) : error C2079: 'ev_timeout' uses undefined struct 'timeval'
>Re WCHAR: I checked in a patch that I think may solve this; I'm not sure
>whether it's a complete solution. If you can try it out, that would be
>great.
looked at the patch, seems ok to me (you just forgot to remove an useless mb-to-wcs conversion in config_nameserver_from_reg_key. how do i attach a patch here ?!)
one thing : for this and the related tor ansi/unicode patches : i'm not 100% sure about win9x support of unicode of these routines (do you really mind about w9x support ?!?!?).
what's the question about wcecompat ?
btw ... i still have to do a proper .nmake makefile, i know :)
regards,
valerio
To attach a patch, go to near the bottom of the page and click on "attached files". It will expand into a list of attached files, plus controls for adding more.
For Win9x support, as long as we call the generic version of the routine (e.g. "Foo" rather than FooW or FooA), we should be fine, I think. It's our policy not to do anything deliberately to stop Win9x from working, but we don't test on win9x, so who knows if it works. We try to fix it when somebody notices that it broke.
The wcecompat question was: "Also, what did you need wcecompat for? I see these uses of posix-style
file IO on Windows in the library proper (not counting the unit tests):
evbuffer_add_file() in buffer.c
evutil_read_file() in evutil.c
If there are only two places that need wcecompat, it might make more sense
simply to use CreateFile and ReadFile there instead. "
i can't see controls for attaching more files, i just see the attached files on bottom of page. weird.
anwyay, about wcecompat :
from a quick notice, compiling without wcecompat it complains about not finding
io.h,errno.h,sys/types.h . but that's the minor point i think, since most of those includes are just a bunch of defs to just keep the compiler happy tricking it you're using a "real" libc.
plus, its not only the fileio wcecompat was developed for : the wince libc miss many stuff. many strings and time functions are not implemented in wince but exists in wcecompat. we should check through the code and see if it's reasonable work to maybe, strip the missing functions from wcecompat to something like wince_funcs.c or just leave it using the whole wcecompat.
imho, this is not of much advantage spending time on this ....
Oh, oops. Apparently you can only attach files if you opened the bug yourself, and since you opened this as "nobody", it won't let anybody but a project admin attach more files. :p
If you don't think it's worthwhile investigating how hard it would be to remove the wsecompat dependency, let's ignore that for now, since right now the only person who's interested in doing it (me) is the person with the least WinCE experience or inclination to get any. ;)
From what I can see, the only things blocking a merge here are now: DEF2 and the rest of WCHAR?
It also looks like your original patch no longer applies to Libevent HEAD because of the changes to get the wchar stuff working; do you have a version that applies well?
Still no word here. If you still care about this -- or anybody else does-- we're going to need to work on updating the patch set per earlier comments.