Re: Start asking the developers pointed questions
remember the value of hiring decent developers in the future - you know, the sort that leave technical documentation and source code behind, instead of only binaries which, "just work".
That is more of a project management issue than a developmental one - what materials are supplied as a deliverable is outside the control of the typical developer. It is great simply demanding documentation and source but you need to take greater care specifying exactly what it is you want.
Personally I would rather not have a copy of the source code in favour of a complete dump of the source code management system for the project, even if it's Visual Sourcesafe or something equally oddball. That (indirectly) gives you the source of course, but also a lot of good documentation either express or implied, i.e. it's easy to identify the revision that introduced a given section of code. Hopefully you have a descriptive log message saying why it was written. You almost certainly do know who introduced it and when. That's a great index into the developer's rough working notes if you are fortunate enough to have copies of those.
In terms of documentation those working notes are valuable but you need things on top to pull everything together, ideally written in hindsight - thumbnail sketches written beforehand are of questionable usefulness.
For an illustration of that consider the work I am doing right now: we are about 18 man months into a development project and supposedly around half way through - although personally I guess we've only written about a third of the code but are two thirds of the way through the overall effort. The fundamental modules all exist in some form - they are either complete or are at least fully explored and exist in some rough state. However they are linked together with rough and ready ad hoc "scaffolding" simply to show each module is working in context. I estimate it'll take me (personally) ten days to replace that with a properly engineered replacement that will form the new innermost core of the application.
Now consider how that impacts on the documentation: put simply, any architectural overview already written will be completely invalidated once this next phase is complete. That kind of overview needs to be written once the code exists in tangible form. That brings me back to the first point, this is a project management rather than a development issue. Right at the end of the project, when the app is out of the door, time and resources need to be given over to creating that documentation. Put simply, many customers are not willing to pay for that even if it saves time and money in the long run.
However, even if you do have all that documentation that is not to say it will be any use. The specific issue here is mixed 16 and 32-bit code. Win16/32 thunks are not elegant and I can't see many devs using them on a whim. The most frequent use case is probably (almost certainly) a 16-bit library in use by a 32-bit application. Probably a third party library - the developer doesn't have the source code, yet alone the customer.