Actually, as someone who is using pjsip on 64-bit linux, Windows, and OSX, only the last change mentioned by Mr. Mahajan is necessary (the one in sock_bsd.c). I did *not* change pj_ssize_t to be 8 bytes wide (I left it 4 bytes wide in 64-bit Windows) and the only downside was lots of warning messages and that strings couldn't be longer than 2^31 characters (which didn't bother me). Changing pj_ssize_t to be 8 bytes wide in 64-bit Windows gave me a whole different set of warning messages (and used more memory), so I left it alone. The only *real* solution is to stop using the "long" type altogether, but that would require massive code changes I wasn't willing to make (I still want to get updates after all). BTW, Mr. Mahajan missed one, the definition of pj_sock_t in types.h. In 64-bit Windows, a SOCKET is 8 bytes wide and pj_sock_t is only 4 bytes wide. The word on the street is that 64-bit Windows isn't using the upper 32 bits of a SOCKET right now (which is why it appears to work), but that could change tomorrow. Also, 3 or 4 small changes need to be made to ioqueue_winnt.c to make it work in 64-bit Windows, but since pjsip isn't using that anymore, I won't go into it. If you really care, let me know. John Ridges P.S. Benny, I found a somewhat kludgy but relatively simple way to not have to constantly poll IOQueues and timer heaps, which really helped in my Android port. It's probably not the kind of re-write you're thinking of in changelist #1125, but if you're interested let me know and I'll outline it for you. On 9/23/2011 10:00 AM, pjsip-request at lists.pjsip.org wrote: > Unfortunately that's not correct for Win64. According to: > http://technet.microsoft.com/en-us/library/bb496995.aspx, sizeof(long) > is just 4. So maybe it requires that much changes indeed, although I > think the patch still has few issues with it. > > Benny
