[Win32utils-devel] win32-daemon 0.6.1 problem

[James Tucker]

On 23 Jan 2009, at 03:09, Heesob Park wrote:

> Hi,
>
> 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
> FreeLibrary.

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 [1].
> 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,  
for users.

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
>  ffi_lib("advapi32.dll")
>  attach_function("GetUserName", "GetUserNameA",  
> [:string, :pointer], :int)
> end
>
> 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
>
> Regards,
>
> Park Heesob
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel