[Win32utils-devel] win32-daemon 0.6.1 problem
jftucker at gmail.com
Fri Jan 23 12:38:40 EST 2009
On 23 Jan 2009, at 03:09, Heesob Park wrote:
> 2008/11/5 Berger, Daniel <Daniel.Berger at qwest.com>:
>>>> Another thing to consider, now that Jruby's FFI is now bundled with
>>>> Jruby itself and supports callbacks, is whether or not we want to
>>>> declare Jruby as the preferred platform for creating Ruby
>>> services since
>>>> it supports native threads.
>>>> Of course, this means finishing the port of win32-api. :)
>>> I consider that there are three ways to go to support of the
>>> Windows native
>>> 1. Use Jruby
>>> 2. Use Ruby 1.9.x
>>> 3. Implement the Sapphire :)
>>> If you dislike Ruby's dl library, using
>>> libffi(http://sourceware.org/libffi/) is also possible.
>> Well, FFI is supposed to be universal now, though I can't get it to
>> build on Windows at the moment. So it would be the same code for MRI
>> (1.8 and 1.9) and Jruby.
> In my thought, the current ruby ffi implementation don't care of the
> Windows support. As far as I know, the ffi developers have no definite
> plan about releasing of Windows binary. If it were built to binary
> with mingw compiler, It cannot work with Windows API. It uses
> dlopen,dlsym and dlclose instead of LoadLibrary,GetProcAddress and
The current hg repo seems to build under mingw with some patches
(removing unused (under win32) functionality), however, I have been
unable to get the gem install to work (i need to do some more reading
in rake-compiler). Until I have some more time to debug I won't know
much detail on that. iirc most or all of the ffi test suite passes,
from a repo build.
> I managed to build MSVC version of ruby ffi-0.2.0 using win32 libffi
> source ported by the Python's ctypes library. You can download ctypes
> at sourceforge .
> What's your thought about implementing ruby-ffi windows version? Is it
> worthwhile or meaningless?
FFI is slower, but provides significant implementation flexibility
(namely portability). It could be harder to stub out in some cases,
A bigger problem with this is that under mingw we don't get the SEH
stuff. GCC doesn't support it, and by the looks of the various
documentation / mailing list messages around, there is no really solid
implementation at this point (although this may be old/stale
information). From what I can see, it appears that the strongest
implementation can be found in the Wine project, but may take a lot of
work to get it where ruby would want / need it.
This means that _try, _finalize (both used in win32-services / win32-
api (i can't remember which - may be both)) don't work as expected.
My solution to date (using mingw), in order to maintain some semblance
of error handling, is to simply gem inst --platform=x86-mswin32-60
win32-services, however this is far from ideal.
I am doubtful that simply omitting these lines (_try, _finalize) is a
good idea, and more than this, I am not sure there is any way at all
to implement them whilst using the FFI.
> At now the callback function support is not working but the others
> work fine.
> I succeeded following test code:
> require 'ffi'
> module Foo
> extend FFI::Library
> attach_function("GetUserName", "GetUserNameA",
> [:string, :pointer], :int)
> buf = 0.chr * 256
> size = .pack('L')
> p Foo.GetUserName(buf,size)
> len = size.unpack('L').first
> puts buf[0,len]
>  http://sourceforge.net/project/showfiles.php?group_id=71702&package_id=71318
> Park Heesob
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
More information about the win32utils-devel