[Win32utils-devel] Fwd: BUG? Win32::Service.create calling CreateServiceW

Joe Swatosh joe.swatosh at gmail.com
Wed Jan 14 20:39:30 EST 2009

On Wed, Jan 14, 2009 at 5:02 AM, Daniel Berger <djberg96 at gmail.com> wrote:
> Joe Swatosh wrote:
>> Hi Dan,
>> When we upgraded win32-process to 0.6.0, we had to upgrade some
>> dependencies.
>> Now we are getting failures when invoking Win32::Service.create in code
>> that
>> used to work.  After looking in the registry and futzing around with the
>> code,
>> it appears that when Win32::Service.create calls CreateService, ultimately
>> CreateServiceW is being called.
>> I added this to the file before we invoke anything in Win32::Service, and
>> our
>> app seems to be working again:
>>       class Win32::Service
>>        def CreateService(*a)
>>          CreateServiceA(*a)
>>        end
>>        def self.OpenService(*a)
>>          OpenServiceA(*a)
>>        end
>>       end
>> But is obviously not a real solution.
> Thanks for the report. If you're calling the 'W' methods it means you're
> running with $KCODE set to UTF8.
>> As an aside, we seem to be having failures when calling Process.create,
>> but
>> need to do more research (some calls fail while others work).  This is a
>> Rails
>> app, so maybe ActiveSupport require magic could be changing the order of
>> the
>> requires?
>> I think these are the relevant gem versions:
>>      win32-service-0.6.1-x86-mswin32-60
>>      windows-pr-0.9.8
>>      windows-api-0.2.4
>>      win32-api-1.3.0-x86-mswin32-60
>>      win32-process-0.6.0
> Probably caused by $KCODE being set to UTF8.
> What do people think. Should I remove that logic from win32-api altogether?
> It seems to cause more trouble than it's worth.

Thanks for your prompt reply.  Your explanation makes a lot of sense
to me (Rails sets $KCODE).  In what version of win32-api did this
change?  At any rate, we seem to have things working again (with a
similar patch for Windows::Process.CreateProcess).

I can't really answer your question.  If you'd asked before I'd run
into this issue, I think I'd've supported the way it is now.  On the
other hand, we *had* working code, and now after the upgrade not so

Thanks again!

More information about the win32utils-devel mailing list