The approach I took with wcecompat and integration with OpenSSL was to make OpenSSL have as little special knowledge of CE as possible. This means that wcecompat emulates missing ANSI/Posix functionality so that OpenSSL simply continues to program to the standard interfaces. Wcecompat should be replaceable with very minor changes to OpenSSL, hopefully only where $WCECOMPAT is referenced in VC-32.pl. The submitted patches referenced in the email below are much larger than I'd expect and so I suspect that they were either performed on unclean trees or some files were reformatted or saved with different end-of-line encodings (there are hugh diffs to makefile.bak for example). It makes it difficult to see precisely what changes were made.
BTW, I recall that the original version of the CE support in mozilla was using my wcecompat library, although the code looks very different now. So we seem to be talking about integrating two different versions of wcecompat into OpenSSL. Not that there's anything special about my library, but what's the solution should a few more groups want their own CE compatibility layer included? Assuming they all do little more than provide the missing ANSI/Posix functionality then the only changes they should require to OpenSSL (above what have already been made) are to reference the new library in VC-32.pl and select it via config/Configure. Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Wednesday, 2 November 2005 1:03 AM To: [email protected] Subject: Re: [PATCH] Support for Windows Mobile (on device Console) > [Code and binaries can be downloaded from > http://www.it.uc3m.es/pervasive/wce_lite_compat/ ] > > This patch makes some fixes to the last OpenSSL official version 0.9.8a. First of all you have to realize that we're reluctant to accept functional patches to released code. Meaning that if you want to see your submission in official OpenSSL distribution, then you *have to* target HEAD branch, not 0.9.8. When we see it working in HEAD, *then* one can discuss back-port to released code base [if of actual interest by that time]. Now as for submission itself. As far as I can tell it essentially boils down to following things. 1. Tiny patches for missing _IONBF definition, #define ftime _ftime, int _fmode declaration in apps/apps.c, #include <stdlib.h> in couple of places... All in additional #ifdef WCE_ON_DEVICE_CONSOLE/#endif. 2. wce_lite_compat which implements open/read/write/close and stat. 3. Duplicate code in VC-32.pl to allow for extra WCE_ON_DEVICE_CONSOLE and link PortSDK, generate separate makefile for the target. Well, I still fail to see why either is necessary. "Still" refers to the fact I've earlier commented on submission from you, guys, in similar manner, i.e. "why do you want to treat your target so special?" Think in more general terms! As for 1. I'd rather #ifndef _IONBF affected code; implement own ftime on all CE [or use some WIN32 API on all WIN32! say GetSystemTime]; get rid of _fmode altogether; #include <stdlib.h> unconditionally... As for 2. I'd rather eradicate all references to open/read/write/close as well as stat for all Windows CE. It's perfectly possible! As for 3. I'd rather check for an environment variable, say PORTSDK, and emit makefile which would link with it without duplicating code or separate makefile. This way it would be possible to reduce build instructions to "setup either WCECOMPAT or PORTSDK environment variable, but not both, and compile." How does it sound? A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
