[Win32utils-devel] win32-daemon 0.6.1 problem

Heesob Park phasis at gmail.com
Thu Jan 22 22:09:59 EST 2009


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
>> threads.
>> 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

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 [1].
What's your thought about implementing ruby-ffi windows version? Is it
worthwhile or meaningless?

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 = [256].pack('L')
p Foo.GetUserName(buf,size)
len = size.unpack('L').first
puts buf[0,len]

[1] http://sourceforge.net/project/showfiles.php?group_id=71702&package_id=71318


Park Heesob

More information about the win32utils-devel mailing list