From: Martin Kahlert Date: 2001-10-08T16:02:54+09:00 Subject: [ruby-talk:22222] Re: The Windows question still remains... On Fri, Oct 05, 2001 at 10:51:53PM +0900, Aleksei Guzev wrote: > > > # -----Original Message----- > # From: Martin Kahlert [mailto:martin.kahlert@infineon.com] > # Sent: 5 ??????? 2001 ?. 15:52 > # To: ruby-talk ML > # Subject: [ruby-talk:22126] Re: The Windows question still remains... > # > # The only source code problem i see is the availability of up > # to date API headers for the compilers. > # > But why they discuss cygwin or mingw. While there is no need of > portability there was no need of POSIX etc. I use mswin Ruby without > cygwin or mingw installed on computer. This works fine. Moreover I'm > free to use all the Windows features. That's why I started translating > Windows API to Ruby. I do not wish a new API to windows, threads etc, > but I'd like to access the Windows' functions as they were inteded to be > accessed. It's not a good idea to use an additional layer to access > Windows API. You are perfectly right. When you develop for Windows only (e.g. because your extension uses APIs only present on Windows) there is no need for a Posix layer. The problem arises when you want to make for example socket support available generally on Unix and Windows so that the ruby script side has not to be changed a bit. Then you can either use cygwin, which adds a socket function, working like Unix's socket on Windows and just reuse your already present socket implementation (i.e the socket.c file in ruby) for Unix on Windows. The other possibility is to write an abstraction layer for sockets, which can be implemented using Unix/Windows socket functions by your own. Or you tell the users, that socket code has to be changed for use on Windows and on Unix. The binary issues come around, when code of extensions needs a support library, which is not provided by the ruby binary: If you compile an extension using sockets with cygwin, and your ruby was compiled by VC++ or mingw, it might not work. The other way round it should work, though. > Can anybody tell why my module built for mswin Ruby does not work with > cygwin installation? Or it should work? > The module provides access to some Windows API fnctions. AFAIR your module is C only. Then it should work everywhere, even when distributed as a binary. If it was C++ you have to use VC++' support routines, its (undocumented) object layout, its (undocumented) name mangling, it's object initialization scheme ... All this makes binaries incompatible between C++ compilers. The problem is not the access to Windows functions but the access to third party support functions. Mingw/VC++ do only access functions provided by Windows. Cygwin uses a support library, which helps porting Unix source code. -- The early bird catches the worm. If you want something else for breakfast, get up later.