Hi All,
I would  like to add 3 points

1/ please add to the list Windows CE >= 5.0 / Windows Mobile >= 6

2/ MAY add a compatibility statement as this, for ANY platform  :

- compile with THOSE "development environmentS",
- run on THOSE "runtime platforms" (hardware/ Os / emulators)
- run on some standard predefined/automated basic scenarii in real life (HTTPS/SMTPS/POPS/IMAPS), pass NONE/PARTIALLY/COMPLETELY some standardized automated test suite : or say it as "success in 28 tests on 132 + list of tests with YES/NO success flag", etc...

- supported by dev/core team  YES/NO
OR by the community AFTER committment/validation of fixes BY the dev/core team.

What I mean is that :
1/ some partially working openssl can help on some platforms : for example if a crypto algorithm that is not used on WCE is NOT working, that does not mean that the lib cannot be used at all on WCE. We can imagine also a statement like this for some UNTESTED / UNVALIDATED code
"users use this at their OWN risk".

2/ If the community produces code to maintain in life some platform compatibility, then a reliable and standardized mean to include that code in the mainstream is necessary... because, personnally, I already faced to produce many minor bug fixes (some #include for WCE for example),
that were not included, in a reasonable time, to the main code stream.

And at a time, some time and info are lost...on any platform, not only exotic ones...

Yours sincerely
Pierre Delaage



Le 01/06/2014 13:04, Matt Caswell a écrit :
On 01/06/14 08:28, Janpopan wrote:
Hi all,

is there a list of currently supported platforms?

Which platforms are deprecaded an could/should be removed in the
sourcecode?
MS-DOS?
Windows 16 Bit?
OS/2?
Windows 95/98/ME?
Windows NT/2000/XP?
Hi Jan

You raise an interesting and important topic.

In answer to your first question, I think the answer is "no". However I
believe there should be.

Deciding which platforms though is a bit more tricky and contentious as
invariably, whichever platforms you decide are no longer supported,
there is going to be someone who is going to be upset with that decision!

In my personal opinion (not necessarily that of the rest of dev team),
we should have:
  * A core list of supported platforms
  * An extended list of platforms where support is provided by the community
  * We should seek to remove from the source code anything that does not
exist in the core list
  * Anything we remove from the code to support the first list can be
added back in, in platform specific repositories, by the community for
the extended list

Necessary criteria for a platform to be included in the first list would be:
  * Currency, i.e. a platform is widely deployed and in current use
  * Vendor support, i.e. if a platform is no longer supported by its
vendor - why should we continue to support it?
  * Available to the dev team, i.e. the dev team have access to a
suitable environment in which to be able to test builds and deal with
tickets and issues

Applying these tests to your list of platforms I think they all fail the
first test (with the exception of XP). They all fail the second test.

I don't know what access the rest of the team have, but certainly for me
all of those platforms also fail the third test. That isn't necessarily
a good guide though as there's probably a number of platforms that
should be considered core that I don't have access to. Probably we
should work out which platforms are core first, and then worry about
ensuring the dev team have access.

On the above basis I would say all of your listed platforms should be
removed from the code (again in my personal opinion).

Matt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to