[Win32utils-devel] Making win32-api better?

Heesob Park phasis at gmail.com
Thu Apr 30 20:35:34 EDT 2009

2009/5/1 Daniel Berger <djberg96 at gmail.com>:
> Heesob Park wrote:
>> Hi,
>> 2009/4/30 Daniel Berger <djberg96 at gmail.com>:
>>> Hi all,
>>> During a conversation with 'flexo' on IRC (not sure of his real name), he
>>> complained that win32-api was unstable. He wrote his own interface and
>>> maintains that it is very stable and works better with multi-threaded
>>> apps.
>>> Please take a look and tell me what you think (below the C code is the
>>> Ruby
>>> interface):
>> <snip code>
>> Great work indeed.
>> The code seems to consist of the intensive use of inline assembly and
>> thread manipulations.
>> I guess it will not work for ruby 1.9.x 64bit version.
> I didn't think x64 Windows was supported anyway. Has that changed?
What do you mean by that?
I think we can support x64 Windows.
The x64 Windows version of Ruby is available at
and x64 windows version of win32-api is at

Refer to http://www.ruby-forum.com/topic/180322

>> And it has some superfluous overheads in thread handling and sleeping
>> delay.
> The author says that it was a bit of a hack. He says one of the problems is
> that there's a problem with that code - w32thunk.rb syncs with native by
> those sleep 0.02 busy waiting loops and it therefore can't dispatch more
> than 100 (in reality even less) callbacks into ruby per second.
>> Anyway, I expect it will work on ruby 1.8.6 in most cases.
>> But, here are some issue.
>> W32Thunk.call('user32','MessageBeep',1,-1) failed with the message
>> ./w32thunk.rb:146:in `_start_call': strtoul("-1", ...) failed (fatal)
>>        from ./w32thunk.rb:146:in `call'
>> This callback test blocks on GetWindowTextA calling.
>> call = W32Thunk.callback {|handle,param|
>>        buf = 0.chr * 200
>>        W32Thunk.call('user32','GetWindowTextA',1,handle,buf,200)
>>        buf.index(param).nil? ? 1 : 0
>> }
>> W32Thunk.call('user32','EnumWindows',1,call,'UEDIT32')
> Ok, so there are some issues. Is there anything we can borrow?
First, let me know what is the issues of the current win32-api?


Park Heesob

More information about the win32utils-devel mailing list