Alexandre Julliard wrote:
Jon Griffiths tntjpgriff@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