This is off-original-topic and can be considered as thread stealing. Therefore it might be appropriate to initiate another thread for follow-up discussion specific to below.
Pierre, > Hello, > Maybe it can help that you find a complete WIN CE successful compile > process for openssl v100a there : http://delaage.pierre.free.fr > Hope you will get some useful answers for what you are looking for. > > See also this page in openssl rt system : > http://rt.openssl.org/index.html?q=2350 > (user guest password guest). > > I confess that my patch still needs to be included in the openssl > mainstream because I have to adapt a few comments to strict C fashion > instead of C++ one. > I will try to do that this year... It would be appreciated. In order to ensure that it goes in desired direction there are several ground rules. First of all, the work-flow is to develop in HEAD and back-port to nearest not-yet-released 1.0.x, 1.0.2 for the time being. Yes, this means that patches to 1.0.0 and 1.0.1 are not necessarily accepted, because those releases are for genuine bug-fixes only, while new platform support is a feature. Well, of course one can argue that failure to build 1.0.1 on CE is a bug, but CE history is too complicated... Note that 1.0.x are [meant to be] binary compatible, so that application developers can switch to newer version without much of a trouble. Now remaining desired directions. Less dependency on Microsoft run-time or compatibility library is better. Less deviations between "normal" Windows and CE is better. Rationale behind latter is to keep code in more active development loop, because exposure to "normal" Windows is much wider (note that Win64 is build with UNICODE defined;-). For example preferred way to solve e_capi.c problem is http://cvs.openssl.org/chngview?cn=20157. (Yes, it should be back-ported to 1.0.2, yes, it *could* have been back-ported to 1.0.1). Same applies to get_current_time. I mean the replacement doesn't have to be specific to CE, it can as well apply to whole Windows family (and I'd go for GetSystemTimeAsFileTime). "Less dependency" implies that we don't necessarily limit ourselves to fixing specific compilation/linking problems, but even examine existing dependencies and evaluate if it's worth eliminating. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
