Re: [libvirt] [PATCH] fix WIN64 compatibility bug in external EventImpl API
On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote: While starting to think about Windows compability, I realized the newly exposed API for registering an external EventImpl is not adequate. Currently it's assuming 32-bit unix fds. But Windows uses a pointer (HANDLE) here. So we need to generalize this interface so it can be implemented for 64-bit Windows. The attached patch does this. (I'm sure it conflicts with work Dan B is doing, so I'm hoping he'll just incorporate this into his changes.) I'm not sure whether this is actually required. We're using gnulib for socket stuff, and that wraps the Winsock socket() call so that it returns a real file descriptor rather than a socket handle. It does this calling _open_osfhandle which appears to be declared to accept a 'long' and return an 'int' - at least in MinGW headers. MinGW doesn't implement Win64 though, so its possible the header isn't quite right. If you have a Win64 box available, could you post what you see as the declarations for _open_osfhandle _get_osfhandle Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix WIN64 compatibility bug in external EventImpl API
On Wed, 2008-11-19 at 16:49 +, Daniel P. Berrange wrote: On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote: While starting to think about Windows compability, I realized the newly exposed API for registering an external EventImpl is not adequate. Currently it's assuming 32-bit unix fds. But Windows uses a pointer (HANDLE) here. So we need to generalize this interface so it can be implemented for 64-bit Windows. The attached patch does this. (I'm sure it conflicts with work Dan B is doing, so I'm hoping he'll just incorporate this into his changes.) I'm not sure whether this is actually required. We're using gnulib for socket stuff, and that wraps the Winsock socket() call so that it returns a real file descriptor rather than a socket handle. It does this calling _open_osfhandle which appears to be declared to accept a 'long' and return an 'int' - at least in MinGW headers. That means that the Windows application using libvirt must use gnulib as well. If the Windows version of libvirt actually exports the gnulib bindings and headers, then I guess that's not a problem. But does it export gnulib? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix WIN64 compatibility bug in external EventImpl API
On Wed, Nov 19, 2008 at 01:28:23PM -0500, David Lively wrote: On Wed, 2008-11-19 at 16:49 +, Daniel P. Berrange wrote: On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote: While starting to think about Windows compability, I realized the newly exposed API for registering an external EventImpl is not adequate. Currently it's assuming 32-bit unix fds. But Windows uses a pointer (HANDLE) here. So we need to generalize this interface so it can be implemented for 64-bit Windows. The attached patch does this. (I'm sure it conflicts with work Dan B is doing, so I'm hoping he'll just incorporate this into his changes.) I'm not sure whether this is actually required. We're using gnulib for socket stuff, and that wraps the Winsock socket() call so that it returns a real file descriptor rather than a socket handle. It does this calling _open_osfhandle which appears to be declared to accept a 'long' and return an 'int' - at least in MinGW headers. That means that the Windows application using libvirt must use gnulib as well. If the Windows version of libvirt actually exports the gnulib bindings and headers, then I guess that's not a problem. But does it export gnulib? No, the gnulib stuff is internal only - we don't force any apps to also use gnulib. It does however mean we should document that the 'fd' arg of the the virEventAddHandle callback is an file handle, and not a socket handle on Win32, so apps are clear on what to expect. If they're not using gnulib themselves, they can trivially convert back to a true socket handle if desired. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix WIN64 compatibility bug in external EventImpl API
On Wed, 2008-11-19 at 18:33 +, Daniel P. Berrange wrote: On Wed, Nov 19, 2008 at 01:28:23PM -0500, David Lively wrote: On Wed, 2008-11-19 at 16:49 +, Daniel P. Berrange wrote: On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote: While starting to think about Windows compability, I realized the newly exposed API for registering an external EventImpl is not adequate. Currently it's assuming 32-bit unix fds. But Windows uses a pointer (HANDLE) here. So we need to generalize this interface so it can be implemented for 64-bit Windows. The attached patch does this. (I'm sure it conflicts with work Dan B is doing, so I'm hoping he'll just incorporate this into his changes.) I'm not sure whether this is actually required. We're using gnulib for socket stuff, and that wraps the Winsock socket() call so that it returns a real file descriptor rather than a socket handle. It does this calling _open_osfhandle which appears to be declared to accept a 'long' and return an 'int' - at least in MinGW headers. That means that the Windows application using libvirt must use gnulib as well. If the Windows version of libvirt actually exports the gnulib bindings and headers, then I guess that's not a problem. But does it export gnulib? No, the gnulib stuff is internal only - we don't force any apps to also use gnulib. It does however mean we should document that the 'fd' arg of the the virEventAddHandle callback is an file handle, and not a socket handle on Win32, so apps are clear on what to expect. Does Windows support integer file handles? Or are they a winsock concept - in which case we're assuming the app uses winsock, right? [Sorry - I'm not trying to be thick -- I'm not a Windows guy at all. But I have hazy memories of winsock not being standard WIN32 ...] Dave -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix WIN64 compatibility bug in external EventImpl API
On Wed, Nov 19, 2008 at 03:11:35PM -0500, David Lively wrote: On Wed, 2008-11-19 at 18:33 +, Daniel P. Berrange wrote: On Wed, Nov 19, 2008 at 01:28:23PM -0500, David Lively wrote: On Wed, 2008-11-19 at 16:49 +, Daniel P. Berrange wrote: On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote: While starting to think about Windows compability, I realized the newly exposed API for registering an external EventImpl is not adequate. Currently it's assuming 32-bit unix fds. But Windows uses a pointer (HANDLE) here. So we need to generalize this interface so it can be implemented for 64-bit Windows. The attached patch does this. (I'm sure it conflicts with work Dan B is doing, so I'm hoping he'll just incorporate this into his changes.) I'm not sure whether this is actually required. We're using gnulib for socket stuff, and that wraps the Winsock socket() call so that it returns a real file descriptor rather than a socket handle. It does this calling _open_osfhandle which appears to be declared to accept a 'long' and return an 'int' - at least in MinGW headers. That means that the Windows application using libvirt must use gnulib as well. If the Windows version of libvirt actually exports the gnulib bindings and headers, then I guess that's not a problem. But does it export gnulib? No, the gnulib stuff is internal only - we don't force any apps to also use gnulib. It does however mean we should document that the 'fd' arg of the the virEventAddHandle callback is an file handle, and not a socket handle on Win32, so apps are clear on what to expect. Does Windows support integer file handles? Or are they a winsock concept - in which case we're assuming the app uses winsock, right? It is a complicated situation :-) The standard Winsock API equivalent to socket() is called WSASocket() and returns a datatype SOCKET, which I believe is just an alias for HANDLE. GnuLib's goal is to fix non-POSIX-ness, so it provides a impl called socket() which returns an 'int' as per POSIX. Internally this is implemented by calling WSASocket(), and then using the _open_osfhandle() method to convert the SOCKET into a regular 'int' file handle which is compatible with Windows' UNIX API layer. eg close, ioctl, etc So, yes, you are correct, that regular Winsock is not compatible with int file handles, but by using GNUlib and the compat layer, we do re-gain proper compatability. The compatability works both ways - if an application using libvirt really does want the original SOCKET handle again, it can convert the file handle back. So _open_osfhandle() and _get_osfhandle() are idempotent MicroSoft have some docs on this here http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx http://msdn.microsoft.com/en-us/library/ks2530z6.aspx As an example, we use GNULIB in GTK-VNC too, and need to integrate with GLib event loop. GLib on Win32 is written to assume use of traditional SOCKET handles, so when we register the GTK-VNC socket with GLib, we use _get_osfhandle to convert the file descriptor back into a SOCKET handle. NB, the OSF handles are avialable in Win 98, Win Me, Win NT, Win 2000, Win XP We don't care about Win 95 so Win CE is the only currently existing Windows platform we'd be unable to support in this way. I'm personally not worried by this restriction... Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
