Re: API specification and library hell still not solved.

> > The API (headers) of Linux (kernel and *nix userland) is in C, and C is
> > kind of problematic to convert to an arbitrary format (e.g. a different
> > language).. 
> 
> > Besides being in C (which is hard enough already), they are all different,
> > and use different macros, constructs, defines etc, which pretty much means a
> > custom parser for each set of headers (package), and even that isn't fully
> > automatic. (and handconversions are costly from a time perspective, and
> > therefore will nearly permanently be out of date)
>  
> And the same thing goes for Windows. 

Partially true. As said before, while it is basically true for Windows also,
there are a lot of mitigating factors for Windows. (semi-)Automated
conversion is a lot more doable for the Windows Platform SDK, (headers more
uniform and 1/3 in IDL) and the number of libraries is lower. Also the one
third that is originally in IDL is substantially better convertable.

Moreover, there are simply less versions of the windows API than the avg
Unix apps. Each new version means checking what changed, and/or redoing
the entire conversion. 

> That's why we program in C, although C has some drawbacks.

Maybe you. However that has nothing to do with the _origin_ of the header
files. 

> I did
> hand-convert some Windows header files into Visual Basic at a time. If you
> program in Java, you get an abstract unified Operating System API.

Yes, but I don't like Java that much. Non native feel, slowlyness in desktop
apps (though serverside that is said to be less).
 
> The real trouble with the various Unices is that they all have slightly 
> different API's and header files.

Which is no problem, as long as they provide those different API's in a
format (something IDLish) that can be automatically processed. (and probably
it would be best to generate the C headers from that new format).

It would also make it a lot more easier to introduce a different C compiler
into Linux, that requires a few different switches etc, and maybe some
marshalling code. Simply hide it in the converter etc.