Windows Interop

[Howard Chu]

Henry B. Hotz wrote:
>
> On Jan 11, 2007, at 3:22 PM, Howard Chu wrote:
>> For a number of reasons (anyone following the embrace/extend/ 
>> extinguish testimony on groklaw?) even when a native Windows API 
>> exists, we've chosen to only support portable APIs if the parallel 
>> exists. Thus, our Windows builds of software use Cyrus libsasl and 
>> OpenSSL, not Windows SSPI. We use OpenLDAP's libldap, not the we- 
>> claim-it's-LDAP-honest API that Windows provides. In general I think 
>> this is the wiser course of action because it lessens our support 
>> burden, among other things.
>
> Doesn't that make it harder to build your products?

Once, maybe. But it's a sunk cost we invested into our build system 7 
years ago. In the end it makes support easier.
>
> In the Postgres case wouldn't that mean that you need to first build/ 
> install/configure KfW, and Cyrus SASL before you could build Postgres 
> for a native Windows client?  That seems like a pretty tall order.  I 
> chose SASL instead of GSSAPI for this project because I (mistakenly?) 
> thought SASL was natively available on all the target platforms.  
> Granted I don't do Windows myself, but I didn't want to create those 
> kinds of problems.
>
> For an open source project I would think the support burden of 
> requiring lots of ancillary installs would be significant.
We create our own build of OpenSSL, BerkeleyDB, libtool, Cyrus SASL, 
Heimdal Kerberos, and OpenLDAP on all of our supported platforms. It's 
essential to allowing us to provide commercial support for our packages 
in a cost-effective manner. All of our software installs in an isolated 
filesystem hierarchy, so we have no interference from or dependency on 
obsolete versions that may already be present on the host system. It 
means we only have to worry about one version of each package, and we 
know exactly what build options were used with each package, and we know 
that each package was built correctly, and that everything plays 
together. (We also offer support to customers using their own builds, or 
platform-vendor-supplied builds, but our support rate is double in that 
case, because it costs us more time to deal with their unknown environment.)

We have a single master-Makefile that builds everything identically 
across Solaris, AIX, HPUX, Linux, Windows, MacOSX, and even z/OS. Our 
test suites also run identically on each platform. It would be a pain to 
recreate all of it from scratch today, but obviously we've been at this 
for a long time.

The burden of requiring lots of ancillary installs is nothing, compared 
to the burden of tracking these projects' ongoing development. But since 
we depend on all of their functionality, it's what we have to do. I'm an 
active contributor on all of these projects, and I know them all inside 
and out. That's the real challenge, and our expertise is the real 
value-add in our offerings.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/