keith Reply To eliz
The prototype of IsProcessInJob, as it is provided by winbase.h in the w32api MinGW package seems to be incorrect:
WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL);
I think it should instead be this:
WINBASEAPI BOOL WINAPI IsProcessInJob (HANDLE, HANDLE, PBOOL);
I found this because the existing prototype causes link error, since the linker is looking for the wrong symbol in the libraries.
I suspect that you are correct. Microsoft's (woeful) documentation neither supports, nor refutes your conjecture, but if your proposed prototype adjustment both resolves the linking issue, and exhibits correct run-time behaviour, that would seem to be sufficient justification for making the change.
keith In winbase.h I also see one other declaration, which appears to be similarly malformed:
$ hg grep WINBASEAPI | grep -v WINAPI ... snip ... w32api/include/winbase.h:WINBASEAPI HLOCAL LocalDiscard (HLOCAL); w32api/include/winbase.h:WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL);
Although the declaration of LocalDiscard here has every appearance of being similarly malformed, the issue is different. Microsoft's documentation, in this case, suggests that LocalDiscard should be defined as a macro, (but offers no hint as to how it should be defined). Indeed, there does not appear to be any symbol, exported from kernel32.dll, which could possibly resolve any reference to LocalDiscard.
I have no idea how to fix this.
Reply To keith
Reply To eliz
The prototype of IsProcessInJob, as it is provided by winbase.h in the w32api MinGW package seems to be incorrect:
WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL);
I think it should instead be this:
WINBASEAPI BOOL WINAPI IsProcessInJob (HANDLE, HANDLE, PBOOL);
I found this because the existing prototype causes link error, since the linker is looking for the wrong symbol in the libraries.I suspect that you are correct. Microsoft's (woeful) documentation neither supports, nor refutes your conjecture, but if your proposed prototype adjustment both resolves the linking issue, and exhibits correct run-time behaviour, that would seem to be sufficient justification for making the change.
Yes, the change I propose definitely solved linking errors in a program where I needed this function.
Reply To keith
In winbase.h I also see one other declaration, which appears to be similarly malformed: {{{ $ hg grep WINBASEAPI | grep -v WINAPI ... snip ... w32api/include/winbase.h:WINBASEAPI HLOCAL LocalDiscard (HLOCAL); w32api/include/winbase.h:WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL); }}} Although the declaration of LocalDiscard here has every appearance of being similarly malformed, the issue is different. Microsoft's documentation, in this case, suggests that LocalDiscard should be defined as a macro, (but offers no hint as to how it should be defined). Indeed, there does not appear to be any symbol, exported from kernel32.dll, which could possibly resolve any reference to LocalDiscard. I have no idea how to fix this.
Are we allowed to take ideas from what MinGW64 did in this case?
keith Reply To eliz
Are we allowed to take ideas from what MinGW64 did in this case?
Presumably you mean by reading their header files? Sorry, but I consider that to be a poisoned chalice, so I'd have to say "no". I'd be more inclined to accept ideas gleaned from the (doxygen format) ReactOS reference documentation — at least that offers something akin to a "chinese wall", and doesn't involve directly reading header files, which we suspect may have been plagiarized from Microsoft's copyrighted sources.
Reply To keith
Reply To eliz
Are we allowed to take ideas from what MinGW64 did in this case?
Presumably you mean by reading their header files? Sorry, but I consider that to be a poisoned chalice, so I'd have to say "no". I'd be more inclined to accept ideas gleaned from the (doxygen format) ReactOS reference documentation — at least that offers something akin to a "chinese wall", and doesn't involve directly reading header files, which we suspect may have been plagiarized from Microsoft's copyrighted sources.
I don't think it matters where we take the idea for the implementation, ReactOS is as good a source as any.
(My alternative suggestion would be that I describe in prose what MinGW64 did, and you use that description to write the code. AFAIU, this works around the copyright restriction, since ideas cannot be copyrighted. But it's an academic issue now.)
Fork
The prototype of IsProcessInJob, as it is provided by winbase.h in the w32api MinGW package seems to be incorrect:
I think it should instead be this:
I found this because the existing prototype causes link error, since the linker is looking for the wrong symbol in the libraries.