Hi Andy,
Thank you for the comments and updates.
I will test e_capi.c this week and let you know: in fact I will try to
"port" the suggested modification to my patched v102 snap of 20121213.
I will also check your VC-32.pl script.
About common code : I agree with the objective, the philosophy of that,
but there is a drawback :
for example for WCE and W32 the common code needs some complicated
"tricks" that may obscure the code,
when it would have been good to know that, for some platform, a more
compact and efficient code is possible.
Fro example your e_capi.c is not so easy to understand when you do not
know the story of the code...
But mine is easier as it is clear that some routines_A were not existing
on some platform, but "required" by the openssl code.
Of course I understood you were talking about the C code, I just
mentioned the libs as another platform difference, related to "building"
the code..
Most of C code modifications required for WCE are just some include
files and some #define.
Something else, and I am facing this with stunnel, the common code is
-most often but strangely not always...- the oldest fashioned code, ie
that of WCE...
Well, about e_capi : my proposed substitution of _A routines, rewritten
in WCE as forwarders to _W routines, was much more simple than the code
you want me to test.
Anyway I will do as you requested for e_capi.c.
I will import the new code in my e_capi.c.
About contributions : well, I am here to help...
and I would just like to remind you that, except for e_capi.c, only a
very FEW changes are needed to have a full compilation of openssl under WCE.
We keep in touch about your updates.
Best regards,
Pierre
Le 18/12/2012 11:27, Andy Polyakov a écrit :
Hi,
One of the concern I am involved with is also UNICODE AND ANSI versions
of stunnel...
I want to point out two things in the UNICODE vs. ANSI context. OpenSSL
Win64 builds are actually compiled as UNICODE, and that it's possible to
compile even Win32 build as UNICODE by passing -DUNICODE -D_UNICODE at
configuration stage.
Well, that said, common code is just sometimes NOT possible, for fews
things : a lib named differently (ws2.lib for WCE, ws2_32.lib in
W32...comctl32.lib in W32, commctrl in WCE)...
or type missing, but simple to redefined...
When I referred to "common code" I really referred to C code, not
libraries. Even in this context I'm not saying that common code is
*always* possible, only that it should be preferred/priority option. As
for missing types, the problem is not really WCE (or even Windows)
specific, and we take it on case to case basis, i.e. there is no common
approach.
...
=========
Something else : look at VC-32.pl, my patch is correcting a typo ...:
in the original VC-32, line 125, there is written dbg_cLfags instead of
dbg_cFlags...
So when will this be corrected ?
The typo was corrected (1/2 hour after _ftime replacement). I've also
just committed http://cvs.openssl.org/chngview?cn=23131. Please review.
Note that I've chosen to skip version check and look at compiler name.
As you report eVC has unique compiler names (and recognize /MC), while
later Studio compilers are all called cl (and recognize same options as
x86 compiler). It might appear ad-hoc, but it's not worse than version
check. Whenever you confirm that it appears appropriate, it goes down to
1.0.2 branch. Same applies to _ftime and e_capi.c code (i.e. when you
confirm that it works).
Proceeding with further review...
As for INSTALL.WCE and "openssl team want[ing] people to use full MS
Visual Studio above or equal to 2005". As implied earlier, WCE is not
regularly tested by any of OpenSSL team members and there is no
expressed will. I mean it's not about what "team" wants, it's about
unrelated contributors bringing pieces of information. As contributions
are effectively unrelated, there is no guarantee that they don't
contradict. On the contrary, they tend to be contradicting, and that
actually why we are having this very discussion:-)
Cheers.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
