If it is at all technically feasible, it would be useful (or rather: user-friendlier) if mathlink.h
did not include windows.h
on Windows systems.
Recently I had a very frustrating experience where a C++ library wouldn't work on Windows when used in conjunction with MathLink. The problem turned out to be that the C++ library uses the names IN
and OUT
internally, but windows.h
defines these as macros. It also defines many other macros which have a potential for conflict and difficult to debug situations.
It took quite a while to debug because the code was working fine on OS X / Linux, so at first I thought that the problem was with the Microsoft compiler. Then I realized that it was related to including mathlink.h
, but it took some more time before I managed to find the relationship to windows.h
and the unexpected IN
/OUT
macros.
I am not experienced with Windows programming, and it is not clear to me if it is feasible to drop the windows.h
dependency from mathlink.h
for a future version ... I noticed two places where it was actually needed:
- For the
WinMain
function that mprep
generates. This is not an issue as the #include <windows.h>
can be moved to mprep
's output.
- For the
FAR
macro. But this has been obsolete for many many years now anyway.
@John Fultz, do you think it would be possible to remove the #include <windows.h>
from a future version of mathlink.h
/wstp.h
? Or are there still-relevant technical reasons to keep it?
Does anyone else see a reason why doing this is not technically feasible?