MSVC Portability

[Elliott Sales de Andrade]

On 1 April 2013 12:56, Zoltán Sólyom <z-ismeretlen at freemail.hu> wrote:
> On 13/04/01 6:11, Elliott Sales de Andrade wrote:
>>
>>
>> CC Andrew and Tomasz, who can look at the mxit and GG stuff more closely.
>>
>> >> 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.
>>
>
> When I made these edits I have only seen the code for the first time, and
> didn't understood most of the MinGW make files either. After correctly
> setting up the Visual Studio project, now even If I remove all config.h
> includes that I added, the DLLs compile normally. There is no need to add
> internal.h to libpurple/protocols/gg/lib/libgadu.h either.
> The include "io.h" line in libpurple/protocols/gg/lib/sha1.c is unnecessary
> as well, but it is still needed in protocols/novell/nmconn.c
> MinGW compiles gg by adding the compiler option to include win32dep.h. I can
> add io.h to novell this way and then it doesn't have to be added to the
> code.
>
>
>> >>> 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.
>>
>
> Changed the above code to:
> #ifdef _MSC_VER
> #define ssize_t SSIZE_T
> #endif
> Is there a better place to put this?
>

It looks like ssize_t is not even the correct return type for those
function calls. I have changed it to PRInt32.

>
>> >> 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.
>>
>
> It is not needed to add io.h includes in "phantom files" with the compiler
> option I mentioned above. But it is still an issue that there is no unistd.h
> and inttypes.h in MSVC (and no need for them either).
>

unistd.h is the "Unix Standard", so I don't expect it to exist in
MSVC. inttypes.h appears to be C99 though, so maybe we shouldn't be
using it.

-- 
Elliott aka QuLogic
Pidgin developer