I agree with Tater, to do the job properly is huge task - I've messed with various MS headers in the past and this one is one that I hesitate to start (getting old, brain power is decreasing). Ideally an automated process is needed especially for beginners, plus, as new headers are added the automated process would hopefully deal with the additions.
Absolutely we need to automate the process...
We're talking about 1800+ headers. Granted some will be eliminated as being C++ with no C Interfaces...
But I'm guessing we're still talking about more than 1000 headers.
Moreover it is not enough to simply hack the headers. We're going to have to modify/rebuild all the libs too. We have no idea how many missing imports (linker errors) we will run into if we don't also rework the Libs.
What neither Ralph nor Timo seem to appreciate is that over 500 new functions have been added to the API since Win2000 when the current headers were first created. Nobody actually knows how many are not present in the current Pelles C API.
By piecing the header set into my test bed in blocks of 10 headers I've already counted more than 15,000 errors and warnings... and ... I'm only half way through the process. Granted a lot of these are the same error over and over again, but at this point we have no clue either what's causing them or how to fix them.
One thing I do know for absolute certain.... disabling compiler warnings is NOT the way to do it.
When preparing the original set for Pelles C, Pelle would have had some pretty good idea what the incompatibilities were and how to fix at least most of them. However; none of this is documented anywhere so we're having to learn this as we go.
Take any header for an example. Compare Pelle's version to the SDK version. In most cases these headers are more than slightly different. Defines have been changed, the order of things is different, stuff has been added, stuff has been taken out... It would be enormously helpful to know what and why... Simple things like "We can't do LPCWCHAR so change it to wchar_t*" would make a huge difference in the depth of the effort.
Frankies tool is basically a copier... that isn't even necessary since we can just point our project options at the SDK headers, no matter where they are. What is needed is a *translator*... Perhaps working from a Rules file telling it what do do in each header. With that level of automation, it should be possible to do a transformation that works.
Then we have the problem of what to do with the Libs...
