https://bugs.winehq.org/show_bug.cgi?id=49193
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- I spent some time trying to compile the source, and also some time trying to port things to C. It may be too early to say this, but I'm leaning in favour of porting it all to C (or, really, rewriting it from scratch using the source as a reference).
In particular:
* There's quite a lot of internal headers missing, mostly around the area of the loader / glue to the public definitions. It doesn't seem to hard to reverse-engineer these bits, but the problem is that there are quite a lot of them.
* Lots of missing pieces in mingw headers (or worse, Wine headers...) that would have to be filled in.
* At least one WDF header (fxirp.h) is badly broken due to (accidentally?) deleted lines.
* The C++ source depends on wdmlib, which would have to be reverse-engineered. I don't think this is a huge task, though.
* Despite the obsessive versioning, I suspect that new updates aren't going to change the source for existing functions very much if at all. A brief look at the last update commit shows not a lot of functional change...
I guess there's danger in thinking that a rewrite is less work just because I can get it to successfully call WdfDriverCreate() and return with relatively little effort, but when you combine that with the ugliness that maintaining that much C++ would imply...
(In reply to Paul Gofman from comment #3)
Did you have a chance to see what kernel functions MS implementation depends on? I. e., how hard will it be to implement missing ones if we integrate that?
I did a quick grep for Io*, Ex*, Ke* functions used in the source. There don't actually seem to be a lot that we don't have already, and I wouldn't particularly expect there to be—inasmuch as WDF is a replacement for WDM but also built on top of it.
Plus, if we do a source port/rewrite, we don't necessarily have to implement everything (or do it all at once), and we don't have to worry about things like bug-check callbacks or tracing...