MSVC Portability

Mon Apr 1 00:11:58 EDT 2013

CC Andrew and Tomasz, who can look at the mxit and GG stuff more closely.

On 2013-03-30 8:10 PM, "Zoltán Sólyom" <z-ismeretlen at freemail.hu> wrote:
>
> 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.
>

Maybe it would be best to see what the actual problem was. I really doubt
that config.h is *only* on MSVC.

>>> 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.
>

>From what I've read, you'd use SSIZE_T.

>> 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.
>

Ah, I had not realized that mxit also has a cipher.h. This one is not MSVC
specific.

>> [...]
>>
>>
>> #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.
>

We've already got internal.h that includes the right files, so I don't
think phantom files are the best option.

--
Elliott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130401/4741b564/attachment-0002.html>