Andy Polyakov wrote:
I send this topic another time adding [PATCH] to the subject
(contribution).
Well, it's not really "[PATCH]" keyword in the subject that makes
magical difference, but rather our ability to audit and test the
submitted code multiplied by degree of common interest for platform in
question. In other words, *if* either of development team members had
access to platform in question or similar one *and* there was commonly
expressed need for CE support, then you would observe better
round-trips. Just to make sure, "*if*" in previous sentence means that
none of us has access to Windows CE platform, which is why we're a bit
reluctant to even *say* something on the matter. We kind of expect other
Windows CE developers on the list to speak up, make some peer review and
put a word for submission.
i'm realy would like to see this patch included in the upstream openssl!
i even volunteer to review the patch or modify to your fit.
about the win ce platform access. all win ce (pocket pc, windows mobile)
development enviroment (eg. eMbedded Visual C++) can be downloaded from
ms for free (which is not usual from ms:-) at the same time you can
download "Emulator Images for Windows Mobile 2003 Second Edition
software for Pocket PC" so you can compile with eVC++ on win32 for CE
and you can also test it on win32 with the pocket pc emulator.
3 OpenSSL 0.9.7f [Not tested with newer versions]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is actually another
reason for us to be reluctant. We don't want to add new platforms to
branch in support-only phase. Note that there is a number of CE-specific
changes in development as well as just released 0.9.8 version and would
rather refine newer version than risk support-only/stable version get
broken. So that if you wish to pursue this, I would really recommend to
switch to development branch or at least 0.9.8.
it'sacceptable, although since the api change a bit, it'd be nice to
backport it to the latest 0.9.7 release too.
And some comments after just scrolling through...
-#if ... !defined(OPENSSL_SYS_WINCE)
+#if ... !defined(OPENSSL_SYS_WINCE) && !defined(PPC2003)
... and similar in different flavors in a lot of other places. Why not
define OPENSSL_SYS_WINCE at command line or by some other means instead?
As far as I understand platform in question *is* Windows CE-based. One
can argue that we should/could have used pre-defined _WIN32_WCE macro
instead of own private OPENSSL_SYS_WINCE, but that's the way things are.
So I'd strongly recommend to find a way to define OPENSSL_SYS_WINCE
instead of "polluting" the code with own private PPC2003 macro.
it's a bit more complicated since not all wince is ppc2003, but all
ppc2003 is wince:-)
These are the kind of things we [at least I] expect to see/hear/find in
submissions we can't directly test. A.
this also means it'd be better to split the patch into smaller patches
and you can accept these patches one-by-one? and we can fix these small
patches more easily.
--
Levente "Si vis pacem para bellum!"
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
