process.h patch

[David Elliott]

Alexandre Julliard wrote:

> Jon Griffiths <tntjpgriff at tsnxt.co.uk> writes:
>
> > Until we have MS style headers, at least declare msvcrt functions extern "C"
> > so C++ Winelib programs will link.
> >
> > I didn't get any feedback to my headers patch. Alexandre, what do I need
> > to do to get some headers into CVS? Or is that not the plan?
>
> Well, I don't know, I was hoping to get some feedback from the winelib
> experts out there on whether this is better than the approach with
> macros suggested by David.

Hmm, glad to see everyone is alive and well again.

At this point my schedule is pretty full until Thursday.  My parents are getting
remarried this Wednesday (Valentine's Day) so I am busy preparing with them and
working on some songs to sing at the wedding and reception.

My original plan was actually to write the headers along with the implementations
to sort of break up the mundane task of writing headers with some actual coding
and so that neither one would be too far behind the other.  A lot has changed in
Winelib since the original discussion on this.  For one thing, DLLs work as
expected now and imports can actually be resolved to native DLLs.

This is sort of a recap so that we are all on the same page:

There ought to be a full set of headers that is intended for linking with a real
MSVCRT, possibly using a few macros sparingly but only for optimizations.

There also should be the ability to use normal UNIX headers and link with a
normal UNIX libc if desired.  (Which currently would be the only way to do
things).

Francois had also talked about a mixed set of headers using mostly UNIX stuff but
with a few MSVCRT things thrown in.

I had thrown in the idea of being able to prefix the msvcrt functions with
something like MSVCRT_ and then linking against a library which forwarded the
"MSVCRT_function" to "MSVCRT.function".  Thus using MSVCRT_function in the
program would use the MSVCRT implementation, and using just function in the
program would use the normal libc function.  The idea behind this was the some
source files could include header files which #defined function MSVCRT_function,
other source files could include normal libc headers.  Thus the references are
set during compile time and not link time and also would allow you to essentially
link to an MSVCRT and a libc within the same program if desired.

While the idea may not be great for use in Wine itself, it might be nice if the
header files supported a prefix on all function names, somewhat like NEC's SOCKS
headers (except actually working unlike the socks headers).

Part of the reason for rewriting the include files was also for licensing.  If we
rewrite the header files ourselves then it's pretty much guaranteed that they can
be licensed exactly the same as Wine.  If we "borrow" them then who knows.  Most
Windows compilers I have seen have some sort of license on what you can do with
their header files that might not make them fit for inclusion into Wine.

An idea that just popped into my head is maybe seeing if we can get a windows
compiler maker (e.g. Borland) to donate a full set of headers under the Wine
license.  However they may have licensed them with certain terms and be unable to
do that.

This is just the stuff off the top of my head.  I am gonna hit the sack now, long
day tomorrow (tues.) and the next day.

Have a good one,
-Dave