MSVC Portability

[Zoltán Sólyom]

On 13/03/31 0:06, Elliott Sales de Andrade wrote:
> FYI, it would be better to send a patch file instead of a list of changes like this.

I just wrote that list up in case somebody is interested and I'm a 
complete beginner when it comes to such things. I'm in the middle of 
making this library work with .NET (learning C# along the way... I'm 
mainly used to C++) so it's not my priority to learn how to make a patch 
file, but I'll eventually get there if it's still needed.

I've made Visual Studio project files (tell me if you need them) that 
will work if you copy things from Pidgin source to the right path. 
(After making all the posted changes of course.) I don't want to meddle 
with the code yet, these are just fast changes to make the library 
compile with VS.

> libpurple/protocols/bonjour/mdns_common.h:
> // Add at the top:
> #ifdef _MSC_VER
> #include "config.h"
> #endif
> libpurple/protocols/irc/irc.h:
> // Add to the top:
> #ifdef _MSC_VER
> #include "config.h"
> #endif
> Why?

Because it works. :) I just searched a bit online and found that for 
someone including config.h "randomly" in sources made it work for them, 
so I tried. This is probably not the correct way to do things, but I 
needed a fast solution. There are a lot of additional defines (also 
defined in "config.h") in \libpurple\win32\global.mak which MinGW uses 
and which were missing. Unfortunately the MinGW make file contains 
"shell" commands to get some values (i.e. version numbers) from other 
files, and that probably needs Cygwin. The correct solution would 
probably be to write some batch file that runs by Visual Studio before 
it starts compiling. Maybe later.

>> libpurple/plugins/ssl/ssl-nss.c:
>> // Add after the includes. I copied this out from a different source
>> // file in libpurple, so hopefully this is what it should be.
>> #ifdef _MSC_VER
>> #ifndef _SSIZE_T_DEFINED
>> #ifdef  _WIN64
>> typedef __int64    ssize_t;
>> #else
>> typedef _W64 int   ssize_t;
>> #endif
>> #define _SSIZE_T_DEFINED
>> #endif
>> #endif
> I don't seem to see that code existing in libpurple. I'm not sure it's
> right either, as ssize_t could be 32-bit depending on the platform
> (though it may always be 64-bit on Windows, I don't know).
>

Oops. You are right, it is not in libpurple. I probably found it online, 
on a site such as this: 
http://permalink.gmane.org/gmane.comp.compilers.llvm.devel/30696 (This 
is not the place where I originally found it.)
I don't know the correct size of the type, just believed what I've read 
from several sources.

> libpurple/protocols/mxit/protocol.c:
> // Add after the includes.
> #ifdef _MSC_VER
> #include "cipher.h"
> #define strtoll _strtoi64;
> #endif
> Again, should use GLib's g_ascii_strtoll. (Plus, you shouldn't have a
> semicolon in a #define.) Also, why would you only need cipher.h on
> MSVC?
>

If I comment out the include I get: "warning C4013: 
'mxit_decrypt_message' undefined; assuming extern returning int"
It is just a warning but I'm not used to missing function calls causing 
mere warnings (not having programmed in C) so I included it just in 
case. It might not be needed, but I don't know what is the standard C 
behavior in this case.

> [...]
>
> #ifdef _MSC_VER
>          free(data);
> #endif
> This looks like a C99-ism or GNU extension and should be removed in
> all cases. But you should use g_malloc and g_free instead. The mxit
> guys do like to use g_alloca though.
>

I'll let anyone who know what they are doing fix this. I don't want to 
break something.

> unistd.h not found in:
> libpurple/protocols/gg/lib/
>      dcc7.c
>      *sha1.c
>      resolver.c
>      pubdir.c
>      libgadu.c
>      handlers.c
>      events.c
>      dcc.c
>      common.c
>      dcc7.c (already mentioned above)
>      http.c
> inttypes.h not found in:
> libpurple/protocols/gg/
>      lib.message.h
> unistd.h is included in internal.h, so the logic for whether to use
> io.h should probably be in there. However, these GG files are part of
> the external GG library, so I'm not sure how Tomasz wants to handle
> it.
>
>> unistd.h not found in:
>> libpurple/protocols/novell/
>>      *nmconn.c:
> See note above.
>

Creating an empty unistd.h file which merely includes io.h and putting 
it in any include path just for VS should fix things. Same with an empty 
inttypes.h. That way no source has to be modified.