Am Dienstag 05 Juni 2007 11:36 schrieb Christian W. Zuckschwerdt:
> I'm still testing your patches for win32. Here are some early
> suggestions and questions:
>
> Winsock2 has a somewhat different approach to bt addresses than all the
> unix stacks. I.e. the unix stacks use a pointer to some anonymous memory
> for BTADDR_ANY (and alike). Winsock2 on the other hand handles all this
> with long ints.
>
> That requires this definition in bluez_compat.h:
> #define BDADDR_ANY (&(BTH_ADDR) {BTH_ADDR_NULL})
> rather than just:
> #define BDADDR_ANY BTH_ADDR_NULL
>
> (think: bacpy(&bdaddr, BDADDR_ANY); using BTH_ADDR_NULL will pass a null
> pointer)
ACK
> The socket() call from winsock2 return a SOCKET type and those are not
> suitable for read/write...
> Some sources claim that you can get away with read/write if you are
> careful. With bt this is not the case. You will need to use recv/send
> for bt sockets.
>
> There are only two occurences, in obex_transport.c:
>
> +#ifdef _WIN32
> + actual = send(fd, msg->data, size, 0);
> +#else
> actual = write(fd, msg->data, size);
> +#endif
>
> and
>
> +#ifdef _WIN32
> + actual = recv(self->fd, buf_reserve_end(msg, max), max, 0);
> +#else
> actual = read(self->fd, buf_reserve_end(msg, max), max);
> +#endif
>
> as well as:
>
> -static int do_write(int fd, buf_t *msg, int mtu)
> +static int do_write(socket_t fd, buf_t *msg, int mtu)
>
> Using a define for read/write is not ok as recv/send will not work on
> regular fds (sic!).
> I assume that using recv/send breaks the OBEX_TRANS_FD case. It should
> be noted to be broken on win32 an perhaps investigate at a later time.
Christian, see the 600_win32_inet.patch for this, it is already handled for
_all_ cases and without ifdefs.
> The select() on winsock2 will not work if you add undefined fds to the
> set. And since fds are unsigned on win32 the test for < 0 will not work.
> This is needed in obex_transport.c:
>
> /* Check of we have any fd's to do select on. */
> - if(self->fd < 0 && self->serverfd < 0) {
> + if(self->fd != INVALID_SOCKET && self->serverfd !=
> INVALID_SOCKET) {
> DEBUG(0, "No valid socket is open\n");
>
> - if(self->fd >= 0) {
> + if(self->fd != INVALID_SOCKET) {
> FD_SET(self->fd, &fdset);
>
> - if(self->serverfd >= 0) {
> + if(self->serverfd != INVALID_SOCKET) {
> FD_SET(self->serverfd, &fdset);
>
> and then the returned fds too:
>
> - if( (self->fd >= 0) && FD_ISSET(self->fd, &fdset)) {
> + if( (self->fd != INVALID_SOCKET) && FD_ISSET(self->fd,
> &fdset)) {
> DEBUG(4, "Data available on client socket\n");
>
> - else if( (self->serverfd >= 0) &&
> FD_ISSET(self->serverfd, &fdset)) {
> + else if( (self->serverfd != INVALID_SOCKET) &&
> FD_ISSET(self->serverfd, &fdset)) {
This is what 500_win32_socket.patch already does.
> Last issue: I can see that using dll import/export decorators is the
> right thing to do. But is it necessary, won't auto-export /-import do?
> Auto-import should work reliable. If auto-export is not ok, or if we
> want to hide certain symbols we could use the SYM file (it's called
> .DEF-file on win32 i gather). Can you explain a bit further why this
> rather big decorator patch is needed?
Either you are using hacks or you do it right. You have a gain from this on
linux, too, as you can dump the .sym file.
You need the changes in the header files, anyway. Additionally, do other
compilers have the auto-export stuff? At least on windows, the patch will
theoretically work with other compilers, too.
> Again, thank you very much for the thorough and useful work on this.
> (Just today I used obexftpd on win32 with obexfs on linux to make samba
> blush!)
Tease: I posted code for obex authentication some time ago. I'd like to get
this tested and integrated, too :)
File services without auth are... ähm... wide-open ;)
HS
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Openobex-users mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/openobex-users
