[Freeciv-Dev] Re: (PR#2102) default user name "name"

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=2102 >

Andreas Kemnade wrote:

>>>Please look at the archive why we don't check for win32 functions.
>>>So the WIN32_NATIVE macro has to be used.

> The point is you cannot check for functions of the win32 api easily on 
> mingw32.
> __stdcall is the name of the problem. You do not have a symbol called 
> GetUserName somewhere but you might have GetUserName@8 if GetUserName would a 
> function (It is a macro).
> The 8 is the number of bytes for the parameters on the stack.

I don't think this is a problem with modern autoconfs.  The configure 
check compiles and runs a program that is something like:

int main()
{
   char *foo() = GetUserName;

   return (foo != GetUserName);
}

which should work on any platform I would think.

> The Win32 API is present on every win32 compiler so there is no need to check
> that, especially because checking is not that easy.

The problem is when you mix-and-match options - the 
"one-macro-to-cover-all-cases" paradigm runs into problems.  The Win32 
API may be present on every win32 compiler but it doesn't cover everything.

One example is dontrunasroot().  Here there's an ALWAYS_ROOT macro 
(basically equivalent to WIN32_NATIVE).  But on recent versions of 
Windows ALWAYS_ROOT isn't true.  In this case we'd need a configure 
check for a specific feature (probably a function call) rather than 
using this manually-defined macro.

I've written Win32 support for several other (smallish) programs, and 
never run into problems with configure checks for functions.


An alternative is to add a real configure check for the win32 API.  This 
could be something like

AC_CHECK_HEADER([windows.h winsock.h],
   AC_CHECK_FUNCS([SomeFuncOrOther SomeOtherFunc],
     AC_DEFINE([WIN32_API])))

which, although it covers a whole host of functions and headers, is at 
least a real check (as opposed to the host check currently done).

> That's basically what was our conclusion when the mingw32 support was
> added in common and server code. At that time we had the discussion, too. 
> CLib functions are possible compiler dependant and therefore you should check 
> them.
> Functions in other libs as well. These functions do not have that
> __stdcall attribute. So there are no problems to check for them. 

CLib?

> A few other problems (not mentioned at that time):
> configure is quite restrictive against different
> gcc versions. gcc-2.95 ist not fully supported anymore (the gtk client needs
> 3.X, the win32 client works with both).

Really?  Is this a problem with autoconf or with

> People using M$ VC have to create a config.h by hand. When checks for
> win32 api functions are added, they would have to insert dozens of entries 
> for all the win32 functions by hand into their config.h. 

Ouch.  Note that they also have to edit the Makefiles by hand!  This is 
a major problem any way you look at it.

jason