harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Khaschansky" <oleg.v.khaschan...@gmail.com>
Subject Re: [general] platform support
Date Wed, 09 Aug 2006 16:42:23 GMT
> It has a building
> cost, but the major overhead is not building, but testing. If we were to
> support a platform, we would need to test on it anyway.
Good point! So, "common denominator" approach has at least that
advantage that it needs less testing - on one platform.

On 8/9/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> On 8/9/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >
> >
> > >Yes, it is the question you also pose elsewhere -- can we have a binary
> > t>hat either (a) uses the lowest common denominator of the different
> > >windows platforms API without incurring an undue penalty performance, or
> > >(b) performs runtime checks and picks the best available APIs.
> >
> > There are distinct approaches as I understand it.
>
>
> One option is a single binary image that contains code that supports
> > multiple platforms seperately by doing a dynamic check for platform. Though
> > less pernicious than a least common denominator approach,  these runtime
> > checks are not healthy for a binary image that targets performance. So if
> > our ideal platform were XinXP, we would incur a penalty repeatedly when
> > running with it to accomodate the fact that this binary could have also run
> > on W2k.
>
>
>  The second option is to use a least common denominator approach where we
> use code/functionality that is only available on the least platform. This is
> not a good idea for obvious reasons. For example it is not a good idea not
> to use the excellent vectored exception handling on WinXP and Win2003( which
> intentionally sharethe same debug and kernel codebases )If this were not, we
> would be writing code for DOS only.
>
>  The third is to have a single codebase with the right _WIN32_WINNT guards
> to distinguish platform specific code, and build seperate distributions for
> seperate platforms. This is the most performance friendly. It has a building
> cost, but the major overhead is not building, but testing. If we were to
> support a platform, we would need to test on it anyway.
>
> Thanks,
> Rana
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message