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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [PATCH] Support for Windows Mobile (on device Console)
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: openssl-dev@openssl.org 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Support for Windows Mobile (on device Console)
The approach I took with wcecompat and integration with OpenSSL was to make OpenSSL have as little special knowledge of CE as possible. And my suggestion is to identify unnecessary code in given context and instead of striving for patching holes, just eliminate the redundant code. E.g. [at least] in CE context I figure one can drop Unix-ish open/read/write/close, which are used only in bss_fd.c, which in turn is not used anywhere in OpenSSL. And most stat calls are redundant and can be eliminated. This would elimitate need for suggested wce_lite_compat. This means that wcecompat emulates missing ANSI/Posix functionality so that OpenSSL simply continues to program to the standard interfaces. So does portsdk. Wcecompat should be replaceable with very minor changes to OpenSSL, hopefully only where $WCECOMPAT is referenced in VC-32.pl. They suggest to replace it with PortSDK *and* wce_lite_compat and my suggestion is to replace it with PortSDK *alone*. Well, replace is wrong term. *Choose* between wcecompat and portsdk is more appropraite. The submitted patches referenced in the email below are much larger than I'd expect Yes, the patch is total mess. It's *reverse* diff between configured trees. As mentioned essential chanages to source are tiny and I reckon that they can/should be generalized, most specifically I see no need to tag them with #ifdef THIS_IS_MY_VERY_SPECIAL_TARGET. 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. My suggestion is to select alternative library rather through environment variable, than through separate target lines in config. I think one VC-CE line is enough, at least for now. Cheers. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
