DCC version 1.2.34

Carl Stehle webmaster@instantservers.com
Wed Mar 10 22:21:57 UTC 2004

> > DCC 1.2.35 (dcclib, cdcc, and dccproc) compiles on Windows
> > using MSVC with only these changes:
> > (and of course a new project file and/or makefile)
> What is wrong with the win32.mak files?
> The Borland FreeCommandLineTools.exe `make` has a Microsoft compatibility
> mode, but my guess from the Borland documentation was that it is not
> needed for those simple makefiles.

'nmake' does not like the '!include ...' line, and perhaps other things.
I am trying to use purely MSVC tools.

> > Also, dcclib/ck.c and dccproc/dccproc.c do not use
> > dcc_defs.h but call strncasecmp (strnicmp on MSVC).
> If that were true, then I would not have been able to compile those
> files with the Borland tools.
> In fact they include dcc_ck.h which includes dcc_clnt.h which includes
> dcc_defs.h.

You are quite right. It was a problem with dependencies; these
files were not recompiled after I made the dcc_defs.h mods.
Should have seen this in the build output.

> > 2. dcclib/get_port.c (dcc_get_host_ipv4)
> > Changed:
> >  struct hostent * WSAAPI (fnc)(const char *))
> > to
> >  struct hostent * (WSAAPI fnc)(const char *))
> >
> > Not sure what 'WSAAPI' was intended for but as it is null by
> > default, I thought perhaps it was for this purpose.
> Are you sure that declaration needs __stdcall?
> I threw the WSAAPI because you mentioned problems nearby,
> the WINSOCK 2 documentation seems to use WSAAPI as a particle
> for resolving idiosyncratic linking hassles,
> and the Borland copy of winsock2.c says
>     struct hostent FAR *
>     WSAAPI
>     gethostbyname(
>         const char FAR * name
>         );
> How is gethostbyname() declared in the Microsoft SDK?

gethostbyname() is declared exactly as above.
Also, from winsock2.h:
#define WSAAPI                  FAR PASCAL

The documentation states that 'PASCAL' is now obsolete.
Looks like backward compatibility to me.

But I think the problem is not in the declaration of
gethostbyname() but rather in the declaration of 'fnc':
the compiler appears incapable of assuming __stdcall with
the function referenced by 'fnc' without __stdcall appearing
in the actual argument declaration. This is the case even if
the compiler switch which sets __stdcall as the default calling
convention is used; I had previously thought it was possible to
work around this with the compiler switch but other errors
apparently masked the fact that this did not work. So, I do not
see a way around an MSVC-specific preprocessor switch to declare
__stdcall as the calling convention used with 'fnc'.

Carl Stehle

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.