On 1/26/06, Eric House <[EMAIL PROTECTED]> wrote: > I finally had an equivalently good idea. My main dev machine is > dual-boot, but hasn't been booted into W2000 in two or three years. > I just remembered that it still has an old evc3 dev system on it and > mounted the msdos partition to look at the .lib and .h files there. > DialogBoxParam is not in coredll.dll, as you suspected. Rather, > it's #defined in winuser.h in terms of DialogBoxIndirectParam. > Similarly, GetCurrentThreadId is defined in a different .h file as > an inline dereference of some global called PUserKData. I'm quite > confident that all the missing APIs are missing for similar reasons.
Excellent! I'm glad you've found the root of the issue and a solution. > There's enough information here that I'll be able to get my app > running by replacing my calls to missing functions with > implementations informed by the .h file rewrites. (I probably won't > have time until the weekend after next, but that's a different > issue.) A bigger question, though, is what to do with the > pocketpc-sdk package. These functions *are* in the desktop windows > .dlls, so MinGW is correct in including them in its .def files. Is The .def files in pocketpc-sdk are original works. They are not derived from MinGW. > there a mechanism for the pocketpc-sdk package to deviate from MinGW > while still using its .h files for the bulk of what it does? If MinGW is used only as a source of header files. pocketpc-sdk doesn't use anything else from the project. > not, it could require recasting much of how the package works, and > perhaps providing an entire set of .h files (and doing away with the > dependency on MinGW). That's certainly not going to happen > upstream, so it'd basically mean taking over the project. Adding Pocket PC support to the MinGW headers is a possibility. The other possibility is adding some header files to pocketpc-sdk -- which currently doesn't include any -- that override the MinGW headers where the Pocket PC platform differs, and use the rest of the MinGW headers as they are. > (EVC3 has a different set of .h files for each target processor. At > least that problem's gone away with the ascendence of ARM.) Thank goodness! > I'd be happy to chat about this if we reach the point where it's > inconvenient to use email. I divide my time between the SF Bay Area > and northern Oregon, BTW; you in either place? I currently live in Calgary, Canada and make regular trips to Vancouver, Canada. Vancouver is somewhat close to northern Oregon. However, we should be able to resolve most of these issues through email. If, coincidentally, we ever find ourselves in the same city, I'm always up for a friendly beer. Have you had your GnuPG key signed by a Debian developer? > Thanks for sticking with me through this. No worries at all. I'm glad it's coming to a resolution. > PS This does mean the recent patch should be backed out. I can do > that and submit with you as sponsor, but I can guarantee I won't > have a chance until the first weekend in Feb. I've submitted a new bug (#350058) for this issue. Since the fix is trivial, I'll probably just upload the package myself, but feel free to fix it yourself as well. It's a good task for your first Debian package. Cheers, Shaun
