h.g. muller wrote:
So the probem is that the API call SetSystemAffinityMask is not
supported in Win95, and is not a no-op there, but actually makes
Polyglot crash?
To the end user running winboard, it looks like polyglot crashes. In
reality, it never loads, coming back with an error about being linked to
a missing export in kernel32.dll.
The compiler swich does not seem a solution to that, as we are going
to distribute a binary package that should work for people that do not
have any compiler installed. So we either should disable the option
altogether, or we should somehow make Polyglot figure out if it is
running on Win95, and suppress the call if it is. I know next to
nothing of Windows API. Is there a call to find out which OS you are
running on? Or is there some system file whose presence betrays the
fact that we run on Win95?
There is, but it won't help. You'd have to use GetProcAddress() at some
point if you wanted to work in 95, and you can tell by the return value
if the function exists. See below.
Actually, if I look at the code, the situation is not that bad: people
running on Win95 would only crash if thy actually set the affinity
option. Which WinBoard would never do when it invokes Polyglot
automatically. So the existing Polyglots are usable without problems
for th purpose we supply it for, even on Win95. If people are so
foolhardy as to try it for other purposes, and try to use the affinity
option on Win95.... Well, I would say they bring it pretty much on
themselves, whatever happens.
It is possible to work in 95 while having the code present. To do that
you have to not link with the function at all, and instead use the
GetProcAddress() method of invoking it. That's probably a better
solution than my polyglot tree uses, which conditionally excludes that
code-- at least if you don't mind having windows specific code in there.
