From phasis at gmail.com Sun Nov 2 10:52:26 2008 From: phasis at gmail.com (Heesob Park) Date: Mon, 3 Nov 2008 00:52:26 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: Hi, 2008/11/1 Berger, Daniel : > > Anyway, still no luck with running the Daemon itself. Now that we have > callbacks working better in win32-api, I'm hoping to revisit the pure > Ruby Win32::Daemon class again. :) > I struggled with the callback and service control whole weekend :) I made the pure Ruby Win32::Daemon class as you expected. Here are two patches and two ruby code. First patch is trivial for callback support. Second patch is a little messy. I added address attribute to callback class. As you know, Win32 thread is not working well with Ruby. So I implemented pure Ruby version as two separate processes without thread. The daemon.rb and daemon0.rb must be in the same folder. Some code cleanup and adding close handle code are required. I think the startup argument notification need to reform. I tried mmap and pipe but both failed with segment fault. Patch for windows-pr/lib/windows/service.rb --- service.rb.bak 2008-11-03 00:24:35.000000000 +0900 +++ service.rb 2008-11-03 00:24:35.000000000 +0900 @@ -128,7 +128,7 @@ API.new('QueryServiceLockStatus', 'LPLP', 'B', 'advapi32') API.new('QueryServiceStatus', 'LP', 'B', 'advapi32') API.new('QueryServiceStatusEx', 'LLPLP', 'B', 'advapi32') - API.new('RegisterServiceCtrlHandler', 'PL', 'L', 'advapi32') + API.new('RegisterServiceCtrlHandler', 'PK', 'L', 'advapi32') API.new('RegisterServiceCtrlHandlerEx', 'PPP', 'L', 'advapi32') API.new('SetServiceBits', 'LLII', 'B', 'advapi32') API.new('SetServiceStatus', 'LP', 'B', 'advapi32') Patch for win32-api/ext/win32/api.c --- api.c.old 2008-11-03 00:25:46.000000000 +0900 +++ api.c 2008-11-03 00:25:05.000000000 +0900 @@ -12,6 +12,7 @@ #define _T_STRING 5 VALUE cAPIError, cCallbackError; +static VALUE ActiveCallback = Qnil; typedef struct { HANDLE library; @@ -109,6 +110,7 @@ */ static VALUE callback_init(int argc, VALUE* argv, VALUE self) { + extern void *CallbackTable[]; VALUE v_proto, v_return, v_proc; int i; @@ -131,6 +133,8 @@ rb_iv_set(self, "@function", v_proc); rb_iv_set(self, "@prototype", v_proto); rb_iv_set(self, "@return_type", v_return); + rb_iv_set(self, "@address", ULONG2NUM((LPARAM)CallbackTable[RSTRING(v_proto) + ActiveCallback = self; return self; } @@ -473,7 +477,6 @@ DWORD params[16]; } CALLPARAM; -static VALUE ActiveCallback; DWORD CallbackFunction(CALLPARAM param) { @@ -811,6 +814,7 @@ rb_define_attr(cCallback, "return_type", 1, 0); /* The numeric address of the function pointer */ + rb_define_attr(cCallback, "address", 1, 0); rb_define_attr(cFunction, "address", 1, 0); /* Constants */ ======================= start daemon0.rb ======================= require 'windows/service' require 'windows/thread' require 'windows/synchronize' require 'windows/handle' require 'windows/error' require 'windows/msvcrt/buffer' require 'windows/msvcrt/string' require 'win32/api' include Windows::Service include Windows::Thread include Windows::Synchronize include Windows::Handle include Windows::Error include Windows::MSVCRT::Buffer include Windows::MSVCRT::String # Wraps SetServiceStatus. def set_the_service_statue(curr_state, exit_code, check_point, wait_hint) service_status = 0.chr * 28 # sizeof(SERVICE_STATUS) # Disable control requests until the service is started. if curr_state == SERVICE_START_PENDING val = 0 else val = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_SHUTDOWN | SERVICE_ACCEPT_PAUSE_CONTINUE | SERVICE_ACCEPT_SHUTDOWN end service_status[8,4] = [val].pack('L') # Initialize service_status struct service_status[0,4] = [SERVICE_WIN32_OWN_PROCESS].pack('L') service_status[4,4] = [curr_state].pack('L') service_status[12,4] = [exit_code].pack('L') service_status[20,4] = [check_point].pack('L') service_status[24,4] = [wait_hint].pack('L') service_state = curr_state # Send status of the service to the Service Controller. unless SetServiceStatus(@status_handle, service_status) SetEvent(@stop_event) end end begin @arg_event = OpenEvent(EVENT_ALL_ACCESS, 0, "arg_event_#{ARGV[0]}") if @arg_event == 0 raise Error, get_last_error end @end_event = OpenEvent(EVENT_ALL_ACCESS, 0, "end_event_#{ARGV[0]}") if @end_event == 0 raise Error, get_last_error end @stop_event = OpenEvent(EVENT_ALL_ACCESS, 0, "stop_event_#{ARGV[0]}") if @stop_event == 0 raise Error, get_last_error end @pause_event = OpenEvent(EVENT_ALL_ACCESS, 0, "pause_event_#{ARGV[0]}") if @pause_event == 0 raise Error, get_last_error end @resume_event = OpenEvent(EVENT_ALL_ACCESS, 0, "resume_event_#{ARGV[0]}") if @resume_event == 0 raise Error, get_last_error end service_ctrl = Win32::API::Callback.new('L', 'V') do |ctrl_code| state = SERVICE_RUNNING case ctrl_code when SERVICE_CONTROL_STOP state = SERVICE_STOP_PENDING when SERVICE_CONTROL_PAUSE state = SERVICE_PAUSED SetEvent(@pause_event) when SERVICE_CONTROL_CONTINUE state = SERVICE_RUNNING SetEvent(@resume_event) end # Set the status of the service. set_the_service_statue(state, NO_ERROR, 0, 0) # Tell service_main thread to stop. if [SERVICE_CONTROL_STOP].include?(ctrl_code) wait_result = WaitForSingleObject(@end_event, INFINITE) if wait_result != WAIT_OBJECT_0 set_the_service_statue(SERVICE_STOPPED,GetLastError(),0,0) else set_the_service_statue(SERVICE_STOPPED,NO_ERROR,0,0) end SetEvent(@stop_event) sleep 3 end end svc_main = Win32::API::Callback.new('LL', 'I') do |argc, lpszargv| argv = [] argc.times do |i| ptr = 0.chr * 4 buf = 0.chr * 256 memcpy(ptr,lpszargv+i*4,4) strcpy(buf,ptr.unpack('L').first) argv << buf.strip end service_name = argv[0] f = File.new(ENV['TEMP']+"\\daemon#{ARGV[0]}","w") f.print(argv.join(';')) f.close SetEvent(@arg_event) # Register the service ctrl handler. @status_handle = RegisterServiceCtrlHandler( service_name,service_ctrl ) # No service to stop, no service handle to notify, nothing to do # but exit at this point. return false if @status_handle == 0 #The service has started. set_the_service_statue(SERVICE_RUNNING, NO_ERROR, 0, 0) true end dispatch_table = [""].pack('p') + [svc_main.address].pack('L') + "\0"*8 if(!StartServiceCtrlDispatcher(dispatch_table)) File.open("c:\\test.txt","a+") {|f| f.puts("StartServiceCtrlDispatcher Fail") } end rescue Exception => err File.open("c:\\test.txt","a+") {|f| f.puts(err.inspect) } end ======================= end daemon0.rb ======================= ======================= start daemon.rb ======================= require 'windows/service' require 'windows/thread' require 'windows/synchronize' require 'windows/handle' require 'windows/error' require 'windows/msvcrt/buffer' require 'windows/msvcrt/string' require 'win32/api' require 'win32/process' require 'win32/service' module Win32 class Daemon class Error < StandardError; end include Windows::Service include Windows::Thread include Windows::Synchronize include Windows::Handle include Windows::Error include Windows::MSVCRT::Buffer include Windows::MSVCRT::String VERSION = '0.6.1' # The Daemon has received a resume signal, but is not yet running CONTINUE_PENDING = 0x00000005 # The Daemon is in an idle state IDLE = 0 # The Daemon is stopped, i.e. not running STOPPED = 0x00000001 # The Daemon has received a start signal, but is not yet running START_PENDING = 0x00000002 # The Daemon has received a sto signal but is not yet stopped. STOP_PENDING = 0x00000003 # The Daemon is running normally RUNNING = 0x00000004 # The Daemon has received a pause signal, but is not yet paused PAUSE_PENDING = 0x00000006 # The Daemon is in a paused state PAUSED = 0x00000007 # The current state of the service, e.g. RUNNING, PAUSED, etc. attr_reader :state def initialize @critical_section = [0].pack('L') @service_state = nil @start_event = nil @stop_event = nil @control_code = 0 @event_hooks = {} @status_handle = 0 end def mainloop @arg_event = CreateEvent(0, 0, 0, "arg_event_#{Process.pid}") if @arg_event == 0 raise Error, get_last_error end @end_event = CreateEvent(0, 0, 0, "end_event_#{Process.pid}") if @end_event == 0 raise Error, get_last_error end @stop_event = CreateEvent(0, 0, 0, "stop_event_#{Process.pid}") if @stop_event == 0 raise Error, get_last_error end @pause_event = CreateEvent(0, 0, 0, "pause_event_#{Process.pid}") if @pause_event == 0 raise Error, get_last_error end @resume_event = CreateEvent(0, 0, 0, "resume_event_#{Process.pid}") if @resume_event == 0 raise Error, get_last_error end service_init() if defined?(service_init) tmpfile = ENV['TEMP']+"\\daemon#{Process.pid}" File.delete(tmpfile) if File.exist?(tmpfile) ruby = File.join(CONFIG['bindir'], 'ruby ').tr('/', '\\') path = File.dirname(__FILE__) + "//daemon0.rb #{Process.pid}" Process.create( :app_name => ruby + path, :creation_flags => Process::CREATE_NO_WINDOW ) wait_result = WaitForSingleObject(@arg_event, INFINITE) if wait_result == WAIT_FAILED error = 'WaitForSingleObject() failed: ' + get_last_error raise Error, error elsif File.exist?(tmpfile) && File.size(tmpfile)>0 f = File.open(tmpfile) data = f.gets f.close else data = '' end data = data || '' argv = data.split(';') @service_name = argv[0] handles = [@stop_event, at pause_event, at resume_event] t = Thread.new { while(true) do wait = WaitForMultipleObjects( handles.size, handles.pack('L*'), 0, 10 ) if wait >= WAIT_OBJECT_0 && wait <= WAIT_OBJECT_0 + handles.size - 1 index = wait - WAIT_OBJECT_0 case handles[index] when @stop_event service_stop() if defined?(service_stop) return when @pause_event service_pause() if defined?(service_pause) when @resume_event service_resume() if defined?(service_resume) end end end } service_main(argv) if defined?(service_main) SetEvent(@end_event) t.join end def running? true if [RUNNING,START_PENDING].include?(state) end def state case Win32::Service.status(@service_name).current_state when 'running' return RUNNING when 'start pending' return START_PENDING when 'stopped' return STOPPED when 'paused' return PAUSED end return 0 end # Shortcut for Daemon.new#mainloop def self.mainloop new.mainloop end end end ======================= end daemon.rb ======================= Regards, Park Heesob From Daniel.Berger at qwest.com Mon Nov 3 11:23:15 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 3 Nov 2008 10:23:15 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> Hi, > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Heesob Park > Sent: Sunday, November 02, 2008 8:52 AM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > Hi, > > 2008/11/1 Berger, Daniel : > > > > Anyway, still no luck with running the Daemon itself. Now > that we have > > callbacks working better in win32-api, I'm hoping to > revisit the pure > > Ruby Win32::Daemon class again. :) > > > I struggled with the callback and service control whole > weekend :) I made the pure Ruby Win32::Daemon class as you expected. > Here are two patches and two ruby code. Oh, excellent! > First patch is trivial for callback support. > Second patch is a little messy. I added address attribute to > callback class. > > As you know, Win32 thread is not working well with Ruby. > So I implemented pure Ruby version as two separate processes > without thread. > The daemon.rb and daemon0.rb must be in the same folder. > Some code cleanup and adding close handle code are required. > I think the startup argument notification need to reform. > I tried mmap and pipe but both failed with segment fault. > > Patch for windows-pr/lib/windows/service.rb > --- service.rb.bak 2008-11-03 00:24:35.000000000 +0900 > +++ service.rb 2008-11-03 00:24:35.000000000 +0900 > @@ -128,7 +128,7 @@ > API.new('QueryServiceLockStatus', 'LPLP', 'B', 'advapi32') > API.new('QueryServiceStatus', 'LP', 'B', 'advapi32') > API.new('QueryServiceStatusEx', 'LLPLP', 'B', 'advapi32') > - API.new('RegisterServiceCtrlHandler', 'PL', 'L', 'advapi32') > + API.new('RegisterServiceCtrlHandler', 'PK', 'L', 'advapi32') > API.new('RegisterServiceCtrlHandlerEx', 'PPP', 'L', 'advapi32') > API.new('SetServiceBits', 'LLII', 'B', 'advapi32') > API.new('SetServiceStatus', 'LP', 'B', 'advapi32') Ok, I've updated both RegisterServiceCtrlHandler and RegisterServiceCtrlHandlerEx in CVS. That update will be part of the 0.9.6 release of windows-pr. > Patch for win32-api/ext/win32/api.c > --- api.c.old 2008-11-03 00:25:46.000000000 +0900 > +++ api.c 2008-11-03 00:25:05.000000000 +0900 > @@ -12,6 +12,7 @@ > #define _T_STRING 5 > > VALUE cAPIError, cCallbackError; > +static VALUE ActiveCallback = Qnil; > > typedef struct { > HANDLE library; > @@ -109,6 +110,7 @@ > */ > static VALUE callback_init(int argc, VALUE* argv, VALUE self) { > + extern void *CallbackTable[]; > VALUE v_proto, v_return, v_proc; > int i; > > @@ -131,6 +133,8 @@ > rb_iv_set(self, "@function", v_proc); > rb_iv_set(self, "@prototype", v_proto); > rb_iv_set(self, "@return_type", v_return); > + rb_iv_set(self, "@address", > ULONG2NUM((LPARAM)CallbackTable[RSTRING(v_proto) Whoops. I think something got cut off here. What should that be? > + ActiveCallback = self; > > return self; > } > @@ -473,7 +477,6 @@ > DWORD params[16]; > } CALLPARAM; > > -static VALUE ActiveCallback; > > DWORD CallbackFunction(CALLPARAM param) { @@ -811,6 +814,7 @@ > rb_define_attr(cCallback, "return_type", 1, 0); > > /* The numeric address of the function pointer */ > + rb_define_attr(cCallback, "address", 1, 0); > rb_define_attr(cFunction, "address", 1, 0); > > /* Constants */ Looks good. It may be a little while before I can get back to it, since I'm getting swamped at work. Many thanks! Dan PS - Maybe it's time to revisit http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id=85 &atid=413, too. This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Mon Nov 3 19:55:42 2008 From: phasis at gmail.com (Heesob Park) Date: Tue, 4 Nov 2008 09:55:42 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2008/11/4 Berger, Daniel : > Hi, > >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Heesob Park >> Sent: Sunday, November 02, 2008 8:52 AM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> >> Hi, >> >> 2008/11/1 Berger, Daniel : >> > >> > Anyway, still no luck with running the Daemon itself. Now >> that we have >> > callbacks working better in win32-api, I'm hoping to >> revisit the pure >> > Ruby Win32::Daemon class again. :) >> > >> I struggled with the callback and service control whole >> weekend :) I made the pure Ruby Win32::Daemon class as you expected. >> Here are two patches and two ruby code. > > Oh, excellent! > >> First patch is trivial for callback support. >> Second patch is a little messy. I added address attribute to >> callback class. >> >> As you know, Win32 thread is not working well with Ruby. >> So I implemented pure Ruby version as two separate processes >> without thread. >> The daemon.rb and daemon0.rb must be in the same folder. >> Some code cleanup and adding close handle code are required. >> I think the startup argument notification need to reform. >> I tried mmap and pipe but both failed with segment fault. >> >> Patch for windows-pr/lib/windows/service.rb >> --- service.rb.bak 2008-11-03 00:24:35.000000000 +0900 >> +++ service.rb 2008-11-03 00:24:35.000000000 +0900 >> @@ -128,7 +128,7 @@ >> API.new('QueryServiceLockStatus', 'LPLP', 'B', 'advapi32') >> API.new('QueryServiceStatus', 'LP', 'B', 'advapi32') >> API.new('QueryServiceStatusEx', 'LLPLP', 'B', 'advapi32') >> - API.new('RegisterServiceCtrlHandler', 'PL', 'L', 'advapi32') >> + API.new('RegisterServiceCtrlHandler', 'PK', 'L', 'advapi32') >> API.new('RegisterServiceCtrlHandlerEx', 'PPP', 'L', 'advapi32') >> API.new('SetServiceBits', 'LLII', 'B', 'advapi32') >> API.new('SetServiceStatus', 'LP', 'B', 'advapi32') > > Ok, I've updated both RegisterServiceCtrlHandler and > RegisterServiceCtrlHandlerEx in CVS. That update will be part of the > 0.9.6 release of windows-pr. > >> Patch for win32-api/ext/win32/api.c >> --- api.c.old 2008-11-03 00:25:46.000000000 +0900 >> +++ api.c 2008-11-03 00:25:05.000000000 +0900 >> @@ -12,6 +12,7 @@ >> #define _T_STRING 5 >> >> VALUE cAPIError, cCallbackError; >> +static VALUE ActiveCallback = Qnil; >> >> typedef struct { >> HANDLE library; >> @@ -109,6 +110,7 @@ >> */ >> static VALUE callback_init(int argc, VALUE* argv, VALUE self) { >> + extern void *CallbackTable[]; >> VALUE v_proto, v_return, v_proc; >> int i; >> >> @@ -131,6 +133,8 @@ >> rb_iv_set(self, "@function", v_proc); >> rb_iv_set(self, "@prototype", v_proto); >> rb_iv_set(self, "@return_type", v_return); >> + rb_iv_set(self, "@address", >> ULONG2NUM((LPARAM)CallbackTable[RSTRING(v_proto) > > Whoops. I think something got cut off here. What should that be? > + rb_iv_set(self, "@address", ULONG2NUM((LPARAM)CallbackTable[RSTRING(v_proto) Should be one line. >> + ActiveCallback = self; >> >> return self; >> } >> @@ -473,7 +477,6 @@ >> DWORD params[16]; >> } CALLPARAM; >> >> -static VALUE ActiveCallback; >> >> DWORD CallbackFunction(CALLPARAM param) { @@ -811,6 +814,7 @@ >> rb_define_attr(cCallback, "return_type", 1, 0); >> >> /* The numeric address of the function pointer */ >> + rb_define_attr(cCallback, "address", 1, 0); >> rb_define_attr(cFunction, "address", 1, 0); >> >> /* Constants */ > > > > Looks good. It may be a little while before I can get back to it, since > I'm getting swamped at work. > > > PS - Maybe it's time to revisit > http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id=85 > &atid=413, too. > Yes. The inter process communication with the socket might a good choice. I will test it. Regards, Park Heesob From Daniel.Berger at qwest.com Tue Nov 4 08:38:15 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 4 Nov 2008 07:38:15 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> Hi, > > PS - Maybe it's time to revisit > > > http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= > > 85 > > &atid=413, too. > > > Yes. The inter process communication with the socket might a > good choice. > I will test it. 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. :) Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Tue Nov 4 09:22:36 2008 From: phasis at gmail.com (Park Heesob) Date: Tue, 4 Nov 2008 23:22:36 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: ----- Original Message ----- From: "Berger, Daniel" To: "Development and ideas for win32utils projects" Sent: Tuesday, November 04, 2008 10:38 PM Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > Hi, > > > >> > PS - Maybe it's time to revisit >> > >> http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= >> > 85 >> > &atid=413, too. >> > >> Yes. The inter process communication with the socket might a >> good choice. >> I will test it. > > 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. I have read Programming in Lua recently and I am playing with Lua nowadays. I think Lua is a powerful and potential language. Lua uses alien module which is based on the libffi. Regards, Park Heesob From Daniel.Berger at qwest.com Tue Nov 4 11:21:00 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 4 Nov 2008 10:21:00 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Park Heesob > Sent: Tuesday, November 04, 2008 7:23 AM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > > ----- Original Message ----- > From: "Berger, Daniel" > To: "Development and ideas for win32utils projects" > > Sent: Tuesday, November 04, 2008 10:38 PM > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > > > Hi, > > > > > > > >> > PS - Maybe it's time to revisit > >> > > >> > http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= > >> > 85 > >> > &atid=413, too. > >> > > >> Yes. The inter process communication with the socket might a > >> good choice. > >> I will test it. > > > > 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. > I have read Programming in Lua recently and I am playing with > Lua nowadays. > I think Lua is a powerful and potential language. > Lua uses alien module which is based on the libffi. I've heard good things about Lua, but mostly I've only ever heard of it being used for games. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From luislavena at gmail.com Tue Nov 4 12:10:12 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 4 Nov 2008 14:10:12 -0300 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <71166b3b0811040910n2ed33c3aofbfe7033a5281090@mail.gmail.com> On Tue, Nov 4, 2008 at 1:21 PM, Berger, Daniel wrote: > > >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Park Heesob >> Sent: Tuesday, November 04, 2008 7:23 AM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> >> >> ----- Original Message ----- >> From: "Berger, Daniel" >> To: "Development and ideas for win32utils projects" >> >> Sent: Tuesday, November 04, 2008 10:38 PM >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> >> >> > Hi, >> > >> > >> > >> >> > PS - Maybe it's time to revisit >> >> > >> >> >> http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= >> >> > 85 >> >> > &atid=413, too. >> >> > >> >> Yes. The inter process communication with the socket might a >> >> good choice. >> >> I will test it. >> > >> > 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. > libffi builds "better" with GCC than with VC* I got libffi built while working with Rubinius, but dunno if the version used is the same (I think it includes some hardcoded stuff in the makefiles). >> I have read Programming in Lua recently and I am playing with >> Lua nowadays. >> I think Lua is a powerful and potential language. >> Lua uses alien module which is based on the libffi. > > I've heard good things about Lua, but mostly I've only ever heard of it > being used for games. > Lua is awesome, small, fast and easy to integrate to other applications, which AFAIK was the primary goal. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From phasis at gmail.com Tue Nov 4 21:15:11 2008 From: phasis at gmail.com (Heesob Park) Date: Wed, 5 Nov 2008 11:15:11 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <71166b3b0811040910n2ed33c3aofbfe7033a5281090@mail.gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0811040910n2ed33c3aofbfe7033a5281090@mail.gmail.com> Message-ID: 2008/11/5 Luis Lavena : > On Tue, Nov 4, 2008 at 1:21 PM, Berger, Daniel wrote: >> >> >>> -----Original Message----- >>> From: win32utils-devel-bounces at rubyforge.org >>> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >>> Park Heesob >>> Sent: Tuesday, November 04, 2008 7:23 AM >>> To: Development and ideas for win32utils projects >>> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >>> >>> >>> ----- Original Message ----- >>> From: "Berger, Daniel" >>> To: "Development and ideas for win32utils projects" >>> >>> Sent: Tuesday, November 04, 2008 10:38 PM >>> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >>> >>> >>> > Hi, >>> > >>> > >>> > >>> >> > PS - Maybe it's time to revisit >>> >> > >>> >> >>> http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= >>> >> > 85 >>> >> > &atid=413, too. >>> >> > >>> >> Yes. The inter process communication with the socket might a >>> >> good choice. >>> >> I will test it. >>> > >>> > 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. >> > > libffi builds "better" with GCC than with VC* > > I got libffi built while working with Rubinius, but dunno if the > version used is the same (I think it includes some hardcoded stuff in > the makefiles). > I noticed the FFI 0.1.1 (http://kenai.com/projects/ruby-ffi/pages/Home) is actually the extension library of libffi. There are needs of more work on Windows, but it's only a matter of time. I feel the end of Win32-API is close at hand and the FFI will unify ruby/DL and Win32-API. Regards, Park Heesob From phasis at gmail.com Wed Nov 5 10:55:59 2008 From: phasis at gmail.com (Park Heesob) Date: Thu, 6 Nov 2008 00:55:59 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: ----- Original Message ----- From: "Berger, Daniel" To: "Development and ideas for win32utils projects" Sent: Tuesday, November 04, 2008 1:23 AM Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > PS - Maybe it's time to revisit > http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id=85 > &atid=413, too. > Here is the new version using TCP protocal. ======================= start daemon0.rb ======================= require 'windows/service' require 'windows/thread' require 'windows/synchronize' require 'windows/handle' require 'windows/error' require 'windows/msvcrt/buffer' require 'windows/msvcrt/string' require 'win32/api' require 'socket' include Windows::Service include Windows::Thread include Windows::Synchronize include Windows::Handle include Windows::Error include Windows::MSVCRT::Buffer include Windows::MSVCRT::String # Wraps SetServiceStatus. def set_the_service_statue(curr_state, exit_code, check_point, wait_hint) service_status = 0.chr * 28 # sizeof(SERVICE_STATUS) # Disable control requests until the service is started. if curr_state == SERVICE_START_PENDING val = 0 else val = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_SHUTDOWN | SERVICE_ACCEPT_PAUSE_CONTINUE | SERVICE_ACCEPT_SHUTDOWN end service_status[8,4] = [val].pack('L') # Initialize service_status struct service_status[0,4] = [SERVICE_WIN32_OWN_PROCESS].pack('L') service_status[4,4] = [curr_state].pack('L') service_status[12,4] = [exit_code].pack('L') service_status[20,4] = [check_point].pack('L') service_status[24,4] = [wait_hint].pack('L') service_state = curr_state # Send status of the service to the Service Controller. unless SetServiceStatus(@status_handle, service_status) SetEvent(@stop_event) end end begin @end_event = OpenEvent(EVENT_ALL_ACCESS, 0, "end_event_#{ARGV[0]}") if @end_event == 0 raise Error, get_last_error end @stop_event = OpenEvent(EVENT_ALL_ACCESS, 0, "stop_event_#{ARGV[0]}") if @stop_event == 0 raise Error, get_last_error end @pause_event = OpenEvent(EVENT_ALL_ACCESS, 0, "pause_event_#{ARGV[0]}") if @pause_event == 0 raise Error, get_last_error end @resume_event = OpenEvent(EVENT_ALL_ACCESS, 0, "resume_event_#{ARGV[0]}") if @resume_event == 0 raise Error, get_last_error end service_ctrl = Win32::API::Callback.new('L', 'V') do |ctrl_code| state = SERVICE_RUNNING case ctrl_code when SERVICE_CONTROL_STOP state = SERVICE_STOP_PENDING when SERVICE_CONTROL_PAUSE state = SERVICE_PAUSED SetEvent(@pause_event) when SERVICE_CONTROL_CONTINUE state = SERVICE_RUNNING SetEvent(@resume_event) end # Set the status of the service. set_the_service_statue(state, NO_ERROR, 0, 0) # Tell service_main thread to stop. if [SERVICE_CONTROL_STOP].include?(ctrl_code) wait_result = WaitForSingleObject(@end_event, INFINITE) if wait_result != WAIT_OBJECT_0 set_the_service_statue(SERVICE_STOPPED,GetLastError(),0,0) else set_the_service_statue(SERVICE_STOPPED,NO_ERROR,0,0) end SetEvent(@stop_event) sleep 3 end end svc_main = Win32::API::Callback.new('LL', 'I') do |argc, lpszargv| argv = [] argc.times do |i| ptr = 0.chr * 4 buf = 0.chr * 256 memcpy(ptr,lpszargv+i*4,4) strcpy(buf,ptr.unpack('L').first) argv << buf.strip end service_name = argv[0] s = TCPSocket.open('127.0.0.1', ARGV[0]) s.write(argv.join(';')) s.close # Register the service ctrl handler. @status_handle = RegisterServiceCtrlHandler( service_name,service_ctrl ) # No service to stop, no service handle to notify, nothing to do # but exit at this point. return false if @status_handle == 0 #The service has started. set_the_service_statue(SERVICE_RUNNING, NO_ERROR, 0, 0) true end dispatch_table = [""].pack('p') + [svc_main.address].pack('L') + "\0"*8 if(!StartServiceCtrlDispatcher(dispatch_table)) File.open("c:\\test.txt","a+") {|f| f.puts("StartServiceCtrlDispatcher Fail") } end rescue Exception => err File.open("c:\\test.txt","a+") {|f| f.puts(err.inspect) } end ======================= end daemon0.rb ======================= ======================= start daemon.rb ======================= require 'windows/service' require 'windows/thread' require 'windows/synchronize' require 'windows/handle' require 'windows/error' require 'windows/msvcrt/buffer' require 'windows/msvcrt/string' require 'win32/api' require 'win32/process' require 'win32/service' require 'socket' module Win32 class Daemon class Error < StandardError; end include Windows::Service include Windows::Thread include Windows::Synchronize include Windows::Handle include Windows::Error include Windows::MSVCRT::Buffer include Windows::MSVCRT::String VERSION = '0.6.1' # The Daemon has received a resume signal, but is not yet running CONTINUE_PENDING = 0x00000005 # The Daemon is in an idle state IDLE = 0 # The Daemon is stopped, i.e. not running STOPPED = 0x00000001 # The Daemon has received a start signal, but is not yet running START_PENDING = 0x00000002 # The Daemon has received a sto signal but is not yet stopped. STOP_PENDING = 0x00000003 # The Daemon is running normally RUNNING = 0x00000004 # The Daemon has received a pause signal, but is not yet paused PAUSE_PENDING = 0x00000006 # The Daemon is in a paused state PAUSED = 0x00000007 # The current state of the service, e.g. RUNNING, PAUSED, etc. attr_reader :state def mainloop gs = TCPserver.open(0) @end_event = CreateEvent(0, 0, 0, "end_event_#{gs.addr[1]}") if @end_event == 0 raise Error, get_last_error end @stop_event = CreateEvent(0, 0, 0, "stop_event_#{gs.addr[1]}") if @stop_event == 0 raise Error, get_last_error end @pause_event = CreateEvent(0, 0, 0, "pause_event_#{gs.addr[1]}") if @pause_event == 0 raise Error, get_last_error end @resume_event = CreateEvent(0, 0, 0, "resume_event_#{gs.addr[1]}") if @resume_event == 0 raise Error, get_last_error end service_init() if defined?(service_init) ruby = File.join(CONFIG['bindir'], 'ruby ').tr('/', '\\') path = File.dirname(__FILE__) + "//daemon0.rb #{gs.addr[1]}" Process.create( :app_name => ruby + path, :creation_flags => Process::CREATE_NO_WINDOW ) nsock = select([gs]) s = gs.accept data = s.gets s.close data = data || '' argv = data.split(';') @service_name = argv[0] handles = [@stop_event, at pause_event, at resume_event] t = Thread.new { while(true) do wait = WaitForMultipleObjects( handles.size, handles.pack('L*'), 0, 10 ) if wait >= WAIT_OBJECT_0 && wait <= WAIT_OBJECT_0 + handles.size - 1 index = wait - WAIT_OBJECT_0 case handles[index] when @stop_event service_stop() if defined?(service_stop) return when @pause_event service_pause() if defined?(service_pause) when @resume_event service_resume() if defined?(service_resume) end end end } service_main(argv) if defined?(service_main) SetEvent(@end_event) t.join end def running? true if [RUNNING,START_PENDING].include?(state) end def state case Win32::Service.status(@service_name).current_state when 'running' return RUNNING when 'start pending' return START_PENDING when 'stopped' return STOPPED when 'paused' return PAUSED end return 0 end # Shortcut for Daemon.new#mainloop def self.mainloop new.mainloop end end end ======================= end daemon.rb ======================= Regards, Park Heesob From Daniel.Berger at qwest.com Wed Nov 5 11:04:21 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 5 Nov 2008 10:04:21 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Park Heesob > Sent: Wednesday, November 05, 2008 8:56 AM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > > ----- Original Message ----- > From: "Berger, Daniel" > To: "Development and ideas for win32utils projects" > > Sent: Tuesday, November 04, 2008 1:23 AM > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > > > PS - Maybe it's time to revisit > > > http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= > > 85 > > &atid=413, too. > > > Here is the new version using TCP protocal. Wow, excellent. Thanks for all your hard work! Do you prefer this implementation to the other one? The _only_ downside I see here is the socket/runtime issue with the one click installer. If we ship this version, I think we must ship our own socket.so, too. That, or we rewrite the socket library using win32-api or ffi, and make that a dependency, but I think that's a last resort. Anyway, thanks again! Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Wed Nov 5 20:08:34 2008 From: phasis at gmail.com (Heesob Park) Date: Thu, 6 Nov 2008 10:08:34 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2008/11/6 Berger, Daniel : > > >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Park Heesob >> Sent: Wednesday, November 05, 2008 8:56 AM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> >> >> ----- Original Message ----- >> From: "Berger, Daniel" >> To: "Development and ideas for win32utils projects" >> >> Sent: Tuesday, November 04, 2008 1:23 AM >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> > >> > PS - Maybe it's time to revisit >> > >> http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= >> > 85 >> > &atid=413, too. >> > >> Here is the new version using TCP protocal. > > > > Wow, excellent. Thanks for all your hard work! > > Do you prefer this implementation to the other one? > > The _only_ downside I see here is the socket/runtime issue with the one > click installer. If we ship this version, I think we must ship our own > socket.so, too. That, or we rewrite the socket library using win32-api > or ffi, and make that a dependency, but I think that's a last resort. > The socket/runtime issue is a ruby-core win32.c issue related with the USE_WINSOCK2 macro. The current quick workaround is running configure.bat without --with-winsock2 option. Is there any special reason One-Click Ruby Installer team built Ruby with --with-winsock2 option? Regards, Park Heesob From luislavena at gmail.com Wed Nov 5 22:52:53 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 6 Nov 2008 00:52:53 -0300 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <71166b3b0811051952x11540162w3945edd9ee25d5ee@mail.gmail.com> On Wed, Nov 5, 2008 at 10:08 PM, Heesob Park wrote: > 2008/11/6 Berger, Daniel : >> >> >>> -----Original Message----- >>> From: win32utils-devel-bounces at rubyforge.org >>> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >>> Park Heesob >>> Sent: Wednesday, November 05, 2008 8:56 AM >>> To: Development and ideas for win32utils projects >>> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >>> >>> >>> ----- Original Message ----- >>> From: "Berger, Daniel" >>> To: "Development and ideas for win32utils projects" >>> >>> Sent: Tuesday, November 04, 2008 1:23 AM >>> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >>> > >>> > PS - Maybe it's time to revisit >>> > >>> http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= >>> > 85 >>> > &atid=413, too. >>> > >>> Here is the new version using TCP protocal. >> >> >> >> Wow, excellent. Thanks for all your hard work! >> >> Do you prefer this implementation to the other one? >> >> The _only_ downside I see here is the socket/runtime issue with the one >> click installer. If we ship this version, I think we must ship our own >> socket.so, too. That, or we rewrite the socket library using win32-api >> or ffi, and make that a dependency, but I think that's a last resort. >> > The socket/runtime issue is a ruby-core win32.c issue related with the > USE_WINSOCK2 macro. The current quick workaround is running > configure.bat without --with-winsock2 option. Is there any special > reason One-Click Ruby Installer team built Ruby with --with-winsock2 > option? > Actually the binaries bundled with One-Click Ruby Installer are from japanesse site garbagecollect: http://www.garbagecollect.jp/ruby/mswin32/en/ We don't have the control over the build or the dependencies and we need to "find" which one was the proper one :-P Another reason we are working on the MinGW version. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From Daniel.Berger at qwest.com Thu Nov 6 09:09:52 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Thu, 6 Nov 2008 08:09:52 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E49@ITOMAE2KM01.AD.QINTRA.COM> Hi, > Patch for win32-api/ext/win32/api.c > --- api.c.old 2008-11-03 00:25:46.000000000 +0900 > +++ api.c 2008-11-03 00:25:05.000000000 +0900 > @@ -12,6 +12,7 @@ > #define _T_STRING 5 > > VALUE cAPIError, cCallbackError; > +static VALUE ActiveCallback = Qnil; > > typedef struct { > HANDLE library; > @@ -109,6 +110,7 @@ > */ > static VALUE callback_init(int argc, VALUE* argv, VALUE self) { > + extern void *CallbackTable[]; > VALUE v_proto, v_return, v_proc; > int i; > > @@ -131,6 +133,8 @@ > rb_iv_set(self, "@function", v_proc); > rb_iv_set(self, "@prototype", v_proto); > rb_iv_set(self, "@return_type", v_return); > + rb_iv_set(self, "@address", > ULONG2NUM((LPARAM)CallbackTable[RSTRING(v_proto) > + ActiveCallback = self; > > return self; > } > @@ -473,7 +477,6 @@ > DWORD params[16]; > } CALLPARAM; > > -static VALUE ActiveCallback; > > DWORD CallbackFunction(CALLPARAM param) { @@ -811,6 +814,7 @@ > rb_define_attr(cCallback, "return_type", 1, 0); > > /* The numeric address of the function pointer */ > + rb_define_attr(cCallback, "address", 1, 0); > rb_define_attr(cFunction, "address", 1, 0); > > /* Constants */ Park, can you please commit this change? Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Thu Nov 6 09:19:50 2008 From: phasis at gmail.com (Heesob Park) Date: Thu, 6 Nov 2008 23:19:50 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E49@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E49@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2008/11/6 Berger, Daniel : > Hi, > >> Patch for win32-api/ext/win32/api.c >> --- api.c.old 2008-11-03 00:25:46.000000000 +0900 >> +++ api.c 2008-11-03 00:25:05.000000000 +0900 >> @@ -12,6 +12,7 @@ >> #define _T_STRING 5 >> >> VALUE cAPIError, cCallbackError; >> +static VALUE ActiveCallback = Qnil; >> >> typedef struct { >> HANDLE library; >> @@ -109,6 +110,7 @@ >> */ >> static VALUE callback_init(int argc, VALUE* argv, VALUE self) { >> + extern void *CallbackTable[]; >> VALUE v_proto, v_return, v_proc; >> int i; >> >> @@ -131,6 +133,8 @@ >> rb_iv_set(self, "@function", v_proc); >> rb_iv_set(self, "@prototype", v_proto); >> rb_iv_set(self, "@return_type", v_return); >> + rb_iv_set(self, "@address", >> ULONG2NUM((LPARAM)CallbackTable[RSTRING(v_proto) >> + ActiveCallback = self; >> >> return self; >> } >> @@ -473,7 +477,6 @@ >> DWORD params[16]; >> } CALLPARAM; >> >> -static VALUE ActiveCallback; >> >> DWORD CallbackFunction(CALLPARAM param) { @@ -811,6 +814,7 @@ >> rb_define_attr(cCallback, "return_type", 1, 0); >> >> /* The numeric address of the function pointer */ >> + rb_define_attr(cCallback, "address", 1, 0); >> rb_define_attr(cFunction, "address", 1, 0); >> >> /* Constants */ > > Park, can you please commit this change? > OK. I did it. Regards, Park Heesob From Daniel.Berger at qwest.com Thu Nov 6 14:16:57 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Thu, 6 Nov 2008 13:16:57 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E49@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E55@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Heesob Park > Sent: Thursday, November 06, 2008 7:20 AM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > 2008/11/6 Berger, Daniel : > > Hi, > > > >> Patch for win32-api/ext/win32/api.c > >> --- api.c.old 2008-11-03 00:25:46.000000000 +0900 > >> +++ api.c 2008-11-03 00:25:05.000000000 +0900 > >> @@ -12,6 +12,7 @@ > >> #define _T_STRING 5 > >> > >> VALUE cAPIError, cCallbackError; > >> +static VALUE ActiveCallback = Qnil; > >> > >> typedef struct { > >> HANDLE library; > >> @@ -109,6 +110,7 @@ > >> */ > >> static VALUE callback_init(int argc, VALUE* argv, VALUE self) { > >> + extern void *CallbackTable[]; > >> VALUE v_proto, v_return, v_proc; > >> int i; > >> > >> @@ -131,6 +133,8 @@ > >> rb_iv_set(self, "@function", v_proc); > >> rb_iv_set(self, "@prototype", v_proto); > >> rb_iv_set(self, "@return_type", v_return); > >> + rb_iv_set(self, "@address", > >> ULONG2NUM((LPARAM)CallbackTable[RSTRING(v_proto) > >> + ActiveCallback = self; > >> > >> return self; > >> } > >> @@ -473,7 +477,6 @@ > >> DWORD params[16]; > >> } CALLPARAM; > >> > >> -static VALUE ActiveCallback; > >> > >> DWORD CallbackFunction(CALLPARAM param) { @@ -811,6 +814,7 @@ > >> rb_define_attr(cCallback, "return_type", 1, 0); > >> > >> /* The numeric address of the function pointer */ > >> + rb_define_attr(cCallback, "address", 1, 0); > >> rb_define_attr(cFunction, "address", 1, 0); > >> > >> /* Constants */ > > > > Park, can you please commit this change? > > > OK. I did it. Excellent. I wanted you do to do it so I could see what was getting chopped off in my email for line 136: ")->len]));" I figured that was it, but didn't want to take any chances. I'm not sure if it's an Outlook formatting issue or what. Anyway, thanks for doing that. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Sun Nov 9 23:05:57 2008 From: phasis at gmail.com (Heesob Park) Date: Mon, 10 Nov 2008 13:05:57 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2008/11/6 Berger, Daniel : > > >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Park Heesob >> Sent: Wednesday, November 05, 2008 8:56 AM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> >> >> ----- Original Message ----- >> From: "Berger, Daniel" >> To: "Development and ideas for win32utils projects" >> >> Sent: Tuesday, November 04, 2008 1:23 AM >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> > >> > PS - Maybe it's time to revisit >> > >> http://rubyforge.org/tracker/index.php?func=detail&aid=16627&group_id= >> > 85 >> > &atid=413, too. >> > >> Here is the new version using TCP protocal. > > > > Wow, excellent. Thanks for all your hard work! > > Do you prefer this implementation to the other one? > > The _only_ downside I see here is the socket/runtime issue with the one > click installer. If we ship this version, I think we must ship our own > socket.so, too. That, or we rewrite the socket library using win32-api > or ffi, and make that a dependency, but I think that's a last resort. > > Anyway, thanks again! > I did reported the socket bug and a patch and the ruby-core accepted the patch. http://redmine.ruby-lang.org/issues/show/714 http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8/win32/win32.c?view=log The next binary release will don't have socket bug any more :) Regards, Park Heesob From Daniel.Berger at qwest.com Mon Nov 10 09:42:46 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 10 Nov 2008 08:42:46 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E5F@ITOMAE2KM01.AD.QINTRA.COM> Hi, > I did reported the socket bug and a patch and the ruby-core > accepted the patch. > > http://redmine.ruby-lang.org/issues/show/714 > http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8/ win32/win32.c?view=log > > The next binary release will don't have socket bug any more :) Excellent, thanks! Does this mean you prefer this implementation? Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Daniel.Berger at qwest.com Mon Nov 10 17:29:39 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 10 Nov 2008 16:29:39 -0600 Subject: [Win32utils-devel] PathFindExtension and wide strings Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E6B@ITOMAE2KM01.AD.QINTRA.COM> Hi, What's happening here? require 'windows/path' require 'windows/unicode' include Windows::Path include Windows::Unicode file_a = 'bar.txt' file_w = multi_to_wide(file_a) p PathFindExtensionA(file_a) # '.txt' => OK p PathFindExtensionW(file_w) # '.' => WRONG Is Ruby chopping the result because of an embedding null? How do we deal with it? Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Mon Nov 10 20:10:14 2008 From: phasis at gmail.com (Heesob Park) Date: Tue, 11 Nov 2008 10:10:14 +0900 Subject: [Win32utils-devel] PathFindExtension and wide strings In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E6B@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E6B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2008/11/11 Berger, Daniel : > Hi, > > What's happening here? > > require 'windows/path' > require 'windows/unicode' > > include Windows::Path > include Windows::Unicode > > file_a = 'bar.txt' > file_w = multi_to_wide(file_a) > > p PathFindExtensionA(file_a) # '.txt' => OK > p PathFindExtensionW(file_w) # '.' => WRONG > > Is Ruby chopping the result because of an embedding null? How do we deal > with it? > The result is chopped by this code in api.c: case _T_STRING: v_return = rb_str_new2((TCHAR*)return_value); break; In case of Unicode something like this would be possible: case _T_STRING: v_return = rb_str_new((TCHAR*)return_value, wcslen((wchar_t*)return_value)); break; Regards, Park Heesob From djberg96 at gmail.com Mon Nov 10 20:25:20 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Mon, 10 Nov 2008 18:25:20 -0700 Subject: [Win32utils-devel] PathFindExtension and wide strings In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E6B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <4918DF00.4050904@gmail.com> Heesob Park wrote: > 2008/11/11 Berger, Daniel : >> Hi, >> >> What's happening here? >> >> require 'windows/path' >> require 'windows/unicode' >> >> include Windows::Path >> include Windows::Unicode >> >> file_a = 'bar.txt' >> file_w = multi_to_wide(file_a) >> >> p PathFindExtensionA(file_a) # '.txt' => OK >> p PathFindExtensionW(file_w) # '.' => WRONG >> >> Is Ruby chopping the result because of an embedding null? How do we deal >> with it? >> > The result is chopped by this code in api.c: > > case _T_STRING: > v_return = rb_str_new2((TCHAR*)return_value); > break; > > In case of Unicode something like this would be possible: > > case _T_STRING: > v_return = rb_str_new((TCHAR*)return_value, > wcslen((wchar_t*)return_value)); > break; Ah, yes, thanks. That will work for ANSI, too, won't it? I don't have my C dev environment setup on this laptop yet (I've been lazy), so I can't test. If it will work for both Unicode and ANSI then please test and commit the change if all goes well. If not, what do you recommend? Thanks, Dan From phasis at gmail.com Mon Nov 10 20:26:43 2008 From: phasis at gmail.com (Heesob Park) Date: Tue, 11 Nov 2008 10:26:43 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E5F@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E3D@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E5F@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: Hi, 2008/11/10 Berger, Daniel : > Hi, > > > >> I did reported the socket bug and a patch and the ruby-core >> accepted the patch. >> >> http://redmine.ruby-lang.org/issues/show/714 >> http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8/ > win32/win32.c?view=log >> >> The next binary release will don't have socket bug any more :) > > Excellent, thanks! > > Does this mean you prefer this implementation? > No, I don't prefer anything. I don't mind whichever method if it is stable and reliable. Regards, Park Heesob From phasis at gmail.com Mon Nov 10 21:19:44 2008 From: phasis at gmail.com (Heesob Park) Date: Tue, 11 Nov 2008 11:19:44 +0900 Subject: [Win32utils-devel] PathFindExtension and wide strings In-Reply-To: <4918DF00.4050904@gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6B@ITOMAE2KM01.AD.QINTRA.COM> <4918DF00.4050904@gmail.com> Message-ID: 2008/11/11 Daniel Berger : > Heesob Park wrote: >> >> 2008/11/11 Berger, Daniel : >>> >>> Hi, >>> >>> What's happening here? >>> >>> require 'windows/path' >>> require 'windows/unicode' >>> >>> include Windows::Path >>> include Windows::Unicode >>> >>> file_a = 'bar.txt' >>> file_w = multi_to_wide(file_a) >>> >>> p PathFindExtensionA(file_a) # '.txt' => OK >>> p PathFindExtensionW(file_w) # '.' => WRONG >>> >>> Is Ruby chopping the result because of an embedding null? How do we deal >>> with it? >>> >> The result is chopped by this code in api.c: >> >> case _T_STRING: >> v_return = rb_str_new2((TCHAR*)return_value); >> break; >> >> In case of Unicode something like this would be possible: >> >> case _T_STRING: >> v_return = rb_str_new((TCHAR*)return_value, >> wcslen((wchar_t*)return_value)); >> break; > > Ah, yes, thanks. > > That will work for ANSI, too, won't it? I don't have my C dev environment > setup on this laptop yet (I've been lazy), so I can't test. > > If it will work for both Unicode and ANSI then please test and commit the > change if all goes well. If not, what do you recommend? > That is not working for ANSI. Though there might be a better way to detect unicode string, I recommend this code: case _T_STRING: { VALUE v_proc = rb_iv_get(self, "@effective_function_name"); char *proc = RSTRING(v_proc)->ptr; if(proc[strlen(proc)-1]=='W') v_return = rb_str_new((TCHAR*)return_value, wcslen((wchar_t*)return_value)*2); else v_return = rb_str_new2((TCHAR*)return_value); } Regards, Park Heesob From Daniel.Berger at qwest.com Tue Nov 11 10:08:03 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 11 Nov 2008 09:08:03 -0600 Subject: [Win32utils-devel] PathFindExtension and wide strings In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E6B@ITOMAE2KM01.AD.QINTRA.COM><4918DF00.4050904@gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E6D@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Heesob Park > Sent: Monday, November 10, 2008 7:20 PM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] PathFindExtension and wide strings > > 2008/11/11 Daniel Berger : > > Heesob Park wrote: > >> > >> 2008/11/11 Berger, Daniel : > >>> > >>> Hi, > >>> > >>> What's happening here? > >>> > >>> require 'windows/path' > >>> require 'windows/unicode' > >>> > >>> include Windows::Path > >>> include Windows::Unicode > >>> > >>> file_a = 'bar.txt' > >>> file_w = multi_to_wide(file_a) > >>> > >>> p PathFindExtensionA(file_a) # '.txt' => OK > >>> p PathFindExtensionW(file_w) # '.' => WRONG > >>> > >>> Is Ruby chopping the result because of an embedding null? > How do we > >>> deal with it? > >>> > >> The result is chopped by this code in api.c: > >> > >> case _T_STRING: > >> v_return = rb_str_new2((TCHAR*)return_value); > >> break; > >> > >> In case of Unicode something like this would be possible: > >> > >> case _T_STRING: > >> v_return = rb_str_new((TCHAR*)return_value, > >> wcslen((wchar_t*)return_value)); > >> break; > > > > Ah, yes, thanks. > > > > That will work for ANSI, too, won't it? I don't have my C dev > > environment setup on this laptop yet (I've been lazy), so I > can't test. > > > > If it will work for both Unicode and ANSI then please test > and commit > > the change if all goes well. If not, what do you recommend? > > > That is not working for ANSI. > Though there might be a better way to detect unicode string, > I recommend this code: > > case _T_STRING: > { > VALUE v_proc = rb_iv_get(self, "@effective_function_name"); > char *proc = RSTRING(v_proc)->ptr; > if(proc[strlen(proc)-1]=='W') > v_return = rb_str_new((TCHAR*)return_value, > wcslen((wchar_t*)return_value)*2); > else > v_return = rb_str_new2((TCHAR*)return_value); > } Ok, thanks. I implemented that for both T_STRING and T_POINTER. Hope that was ok. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From djberg96 at gmail.com Wed Nov 12 00:19:57 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Tue, 11 Nov 2008 22:19:57 -0700 Subject: [Win32utils-devel] File.readlink for Vista? Message-ID: <491A677D.60409@gmail.com> Hi, I've implemented File.symlink and File.symlink? in the win32-file library, but I'm not sure how to implement File.readlink. I searched Google for a while but found nothing. Any suggestions? Thanks, Dan From phasis at gmail.com Wed Nov 12 07:47:16 2008 From: phasis at gmail.com (Heesob Park) Date: Wed, 12 Nov 2008 21:47:16 +0900 Subject: [Win32utils-devel] File.readlink for Vista? In-Reply-To: <491A677D.60409@gmail.com> References: <491A677D.60409@gmail.com> Message-ID: Hi, 2008/11/12 Daniel Berger : > Hi, > > I've implemented File.symlink and File.symlink? in the win32-file library, > but I'm not sure how to implement File.readlink. I searched Google for a > while but found nothing. > > Any suggestions? > Here is File.readlink implementation def readlink(file) hFile = CreateFile(file, GENERIC_READ, FILE_SHARE_READ, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nil) path = 0.chr * 256 GetFinalPathNameByHandle(hFile,path,256,0) CloseHandle(hFile) path.strip[4..-1] # get rid of prepending "\\?\" end Regards, Park Heesob From djberg96 at gmail.com Wed Nov 12 20:52:23 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 12 Nov 2008 18:52:23 -0700 Subject: [Win32utils-devel] File.readlink for Vista? In-Reply-To: References: <491A677D.60409@gmail.com> Message-ID: <491B8857.7000807@gmail.com> Heesob Park wrote: > Hi, > > 2008/11/12 Daniel Berger : >> Hi, >> >> I've implemented File.symlink and File.symlink? in the win32-file library, >> but I'm not sure how to implement File.readlink. I searched Google for a >> while but found nothing. >> >> Any suggestions? >> > Here is File.readlink implementation > > def readlink(file) > hFile = CreateFile(file, > GENERIC_READ, > FILE_SHARE_READ, > nil, > OPEN_EXISTING, > FILE_ATTRIBUTE_NORMAL, > nil) > path = 0.chr * 256 > GetFinalPathNameByHandle(hFile,path,256,0) > CloseHandle(hFile) > path.strip[4..-1] # get rid of prepending "\\?\" > end > > Regards, > > Park Heesob Excellent, thank you! I've committed to CVS. Regards, Dan From Daniel.Berger at qwest.com Thu Nov 13 09:50:14 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Thu, 13 Nov 2008 08:50:14 -0600 Subject: [Win32utils-devel] Making multi_to_wide and wide_to_multi smarter Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E7A@ITOMAE2KM01.AD.QINTRA.COM> Hi, I noticed this: require 'windows/unicode' include Windows::Unicode s = "hello" s2 = multi_to_wide(s) # => "h\000e\000l\000l\000o\000\000\000" s3 = multi_to_wide(s2) # => "h\000\000\000" I think it would be better to modify multi_to_wide so that it returns the string as-is if it's already a wide string. Looks like the same issue exists for multiple calls of wide_to_multi, too. The case I hit was with win32-file and win32-file-stat, where passing a wide string to File::Stat.new failed because it was doing its own multi_to_wide call. The double call caused File::Stat.new to fail. I _could_ call wide_to_multi before passing the argument on, but I would rather not have to remember when and where it's necessary. Modifying multi_to_wide feels more elegant. Suggestions? Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Thu Nov 13 20:22:19 2008 From: phasis at gmail.com (Heesob Park) Date: Fri, 14 Nov 2008 10:22:19 +0900 Subject: [Win32utils-devel] Making multi_to_wide and wide_to_multi smarter In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E7A@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E7A@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2008/11/13 Berger, Daniel : > Hi, > > I noticed this: > > require 'windows/unicode' > include Windows::Unicode > > s = "hello" > s2 = multi_to_wide(s) # => "h\000e\000l\000l\000o\000\000\000" > s3 = multi_to_wide(s2) # => "h\000\000\000" > > I think it would be better to modify multi_to_wide so that it returns > the string as-is if it's already a wide string. Looks like the same > issue exists for multiple calls of wide_to_multi, too. > > The case I hit was with win32-file and win32-file-stat, where passing a > wide string to File::Stat.new failed because it was doing its own > multi_to_wide call. The double call caused File::Stat.new to fail. > > I _could_ call wide_to_multi before passing the argument on, but I would > rather not have to remember when and where it's necessary. Modifying > multi_to_wide feels more elegant. > > Suggestions? > In multi_to_wide, you can use IsTextUnicode(str,str.size,nil) to detect it is unicode or not. Regards, Park Heesob From djberg96 at gmail.com Fri Nov 14 18:54:40 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Fri, 14 Nov 2008 16:54:40 -0700 Subject: [Win32utils-devel] Making multi_to_wide and wide_to_multi smarter In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E7A@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <491E0FC0.3070306@gmail.com> Heesob Park wrote: > 2008/11/13 Berger, Daniel : >> Hi, >> >> I noticed this: >> >> require 'windows/unicode' >> include Windows::Unicode >> >> s = "hello" >> s2 = multi_to_wide(s) # => "h\000e\000l\000l\000o\000\000\000" >> s3 = multi_to_wide(s2) # => "h\000\000\000" >> >> I think it would be better to modify multi_to_wide so that it returns >> the string as-is if it's already a wide string. Looks like the same >> issue exists for multiple calls of wide_to_multi, too. >> >> The case I hit was with win32-file and win32-file-stat, where passing a >> wide string to File::Stat.new failed because it was doing its own >> multi_to_wide call. The double call caused File::Stat.new to fail. >> >> I _could_ call wide_to_multi before passing the argument on, but I would >> rather not have to remember when and where it's necessary. Modifying >> multi_to_wide feels more elegant. >> >> Suggestions? >> > In multi_to_wide, you can use IsTextUnicode(str,str.size,nil) to > detect it is unicode or not. Ok, I've added that check to multi_to_wide, thanks. I've left wide_to_multi alone for now because of some failures that cropped up in tests for win32-file. I think they happen because I've stripped out the nulls in one or two places, causing IsTextUnicode to return false unexpectedly. I'll look into it in a future release. Anyway, the updated multi_to_wide is now part of the windows-pr 0.9.6 release, which I put out tonight. I've also put out win32-api-1.2.1 finally (got my old laptop back). Regards, Dan From luislavena at gmail.com Sat Nov 15 10:07:54 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 15 Nov 2008 12:07:54 -0300 Subject: [Win32utils-devel] Binaries dependencies (shared_libraries) for Windows. Message-ID: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> Hello Guys, This issue was raised originally back in 2007: http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html And raised again by Charlie Savage in July 2008: http://rubyforge.org/pipermail/rubygems-developers/2008-July/003978.html I've explored the different alternatives under several environments and the following are my findings: 1) Alteration of PATH to prepend the DLL location. This was one of the proposed alternatives, and I believe is the one implemented in libxml package. This was also mimicked due the lack of this functionality for DataObjects SQLite3 adapter during the Merb 1.0 release. While this has proven to work, activation of several gems that bundle binaries using this technique make this PATH alteration to child processes, thus could end with alteration of the expected environment for those processes. As example, I bundled libmySQL.dll from MySQL 5.0.51a in mysql gem, while system wide I have installed 5.1.29. The gem executed and connected properly to the 5.1 server, but executing of command line application "mysql" (common practice found in several projects) generated segfaults for these applications and failure due worng exported symbols (and missing ones). There is another issue in relation to PATH size limititations. PATH under XP and 2003 can be up to 2048 bytes, under certains circumstances, this PATH get mangled and only 1024 bytes get copied to spawned child process or by the the process altering the PATH too. There is a patch for 2003 and XP: http://support.microsoft.com/kb/906469 In any case, the folder structure used by rubygems and the location where users install ruby will generate, after activation of 3 or 4 gems compromise the PATH integrity. As example, I have 450 bytes used for my PATH, with ruby Installed in C:\Ruby\bin. Adding "c:/rubylib/ruby/1.8/gems/gem_name-version/lib" to the PATH for each gem activated. 2) Usage of SetDllDirectory Another solution proposed was the usage of Win32API in combination with SetDllDirectory to append the path for the dll, altering the LoadLibrary search order to be able to pick the specified dll. SetDllDirectory was introduced in XP SP1 and with Windows 2003, so has no presence previous in Windows 2000 or NT. Moreover, SetDllDirectory can only add ONE path a time, and doesn't allow concatenation like PATH as search. This means you can SetDllDirectory and inmediately after you're required to load the extension that depend on the DLL. You need to repeat those steps for each binary that depends on external DLLs. It seems SetDllDirectory considered multiple paths in their specs, but no implementation can be used for it right now. RubyGems is not designed to produce that kind of modification or awareness of the dependencies, rendering this method useless for our purposes. 3) LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH The last technique involves explicitly loading the DLL dependency at runtime into the process, instead of waiting for the extension to fire the sequence. The usage of LOAD_WITH_ALTERED_SEARCH_PATH option allow explicit call to a DLL without affecting the PATH and without being affected by SetDllLibrary limitations. The only drawback is that these dlls will be loaded into the process at gem activation and not when the extensions get loaded, making your process a big heavier from startup. This similar approach is being used by Google Chrome to locate and load plugins and by other projects with small differences. === Those are the scenarios I've evaluated. I'm CC'ing win32utils list since I believe Park and Daniel can provide some feedback on these findings prior me hacking something for RubyGems. Thanks in advance for any feedback provided to this. Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From djberg96 at gmail.com Sat Nov 22 03:17:52 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 22 Nov 2008 01:17:52 -0700 Subject: [Win32utils-devel] GetFinalPathNameByHandle for XP and earlier Message-ID: <4927C030.2020002@gmail.com> Hi all, How's this look? I based it on http://msdn.microsoft.com/en-us/library/aa366789(VS.85).aspx. I'm undecided as to when I should raise an error versus when I should just let it fall through, but this is how it is for now. You'll need the latest windows-pr from CVS, btw. Regards, Dan PS - Where should I put it? In Windows::File directly? In a separate helper module? require 'windows/file' require 'windows/file_mapping' require 'windows/volume' require 'windows/process' require 'windows/limits' require 'windows/handle' require 'windows/error' require 'windows/memory' include Windows::File include Windows::FileMapping include Windows::Volume include Windows::Process include Windows::Limits include Windows::Handle include Windows::Error include Windows::Memory # The buf, buf_size, and flags arguments are ignored, but are # present in order to keep the function parameters identical # to the function defined for Windows Vista and later. # def GetFinalPathNameByHandle(handle, buf, buf_size, flags) size_ptr = [0].pack('Q') unless GetFileSizeEx(handle, size_ptr) raise get_last_error end if size_ptr.unpack('Q')[0] <= 0 raise 'file size must be greater than zero' end map = CreateFileMapping(handle, nil, PAGE_READONLY, 0, 1, nil) final_path = nil if map && map > 0 pmem = MapViewOfFile(map, FILE_MAP_READ, 0, 0, 1) if pmem begin buf = 0.chr * MAXPATH # Buf will contain the full path, but with the device name instead # of the drive letter that we ultimately want. if GetMappedFileName(GetCurrentProcess(), pmem, buf, MAXPATH) > 0 buf.strip! dbuf = 0.chr * 512 # Get a list of logical devices if GetLogicalDriveStrings(dbuf.size, dbuf) > 0 devices = dbuf.split("\0") devices.delete_if{ |d| d.empty? || d.size > 3 } # Match the drive letter to a device. Once we find a match to # the device returned by GetMappedFileName, replace the device # name from our original buffer with the drive letter. devices.each{ |device| name = 0.chr * MAXPATH device.chop! # Remove trailing slash if QueryDosDevice(device, name, name.size) > 0 name.strip! if buf.include?(name) final_path = device << buf[name.length..-1] break end end } end else raise get_last_error end ensure UnmapViewOfFile(pmem) end end else raise get_last_error end final_path end # Test program file = File.join(Dir.pwd, 'test.txt') handle = CreateFile( file, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, nil, OPEN_ALWAYS, nil, nil ) if handle == INVALID_HANDLE_VALUE raise get_last_error end p GetFinalPathNameByHandle(handle, nil, nil, nil) CloseHandle(handle) From phasis at gmail.com Mon Nov 24 21:06:28 2008 From: phasis at gmail.com (Heesob Park) Date: Tue, 25 Nov 2008 11:06:28 +0900 Subject: [Win32utils-devel] GetFinalPathNameByHandle for XP and earlier In-Reply-To: <4927C030.2020002@gmail.com> References: <4927C030.2020002@gmail.com> Message-ID: Hi, 2008/11/22 Daniel Berger : > Hi all, > > How's this look? I based it on > http://msdn.microsoft.com/en-us/library/aa366789(VS.85).aspx. > > I'm undecided as to when I should raise an error versus when I should just > let it fall through, but this is how it is for now. > > You'll need the latest windows-pr from CVS, btw. > I remembered that this issue was discussed at May, 2008. Why not use my code in http://rubyforge.org/pipermail/win32utils-devel/2008-May/001091.html ? Regards, Park Heesob From djberg96 at gmail.com Mon Nov 24 23:45:46 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Mon, 24 Nov 2008 21:45:46 -0700 Subject: [Win32utils-devel] GetFinalPathNameByHandle for XP and earlier In-Reply-To: References: <4927C030.2020002@gmail.com> Message-ID: <492B82FA.7030602@gmail.com> Heesob Park wrote: > Hi, > > 2008/11/22 Daniel Berger : >> Hi all, >> >> How's this look? I based it on >> http://msdn.microsoft.com/en-us/library/aa366789(VS.85).aspx. >> >> I'm undecided as to when I should raise an error versus when I should just >> let it fall through, but this is how it is for now. >> >> You'll need the latest windows-pr from CVS, btw. >> > I remembered that this issue was discussed at May, 2008. > > Why not use my code in > http://rubyforge.org/pipermail/win32utils-devel/2008-May/001091.html ? You know, I thought we had talked about it, but when I searched I couldn't find it. Obviously I didn't try hard enough. Thanks. I like your implementation better. :) Regards, Dan From Daniel.Berger at qwest.com Wed Nov 26 09:34:17 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 26 Nov 2008 08:34:17 -0600 Subject: [Win32utils-devel] Question about FindFirstVolumeMountPoint Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514ED0@ITOMAE2KM01.AD.QINTRA.COM> Hi, I can't seem to get FindFirstVolumeMountPoint to work. What am I doing wrong? require 'windows/volume' require 'windows/handle' require 'windows/error' include Windows::Volume include Windows::Handle include Windows::Error vol = 0.chr * 512 handle = FindFirstVolume(vol, vol.length) if handle == INVALID_HANDLE_VALUE raise get_last_error end vol.strip! p vol # => \\\\?\\Volume{b4379d44-726d-11dc-87ec-806d6112693f}\\ FindVolumeClose(handle) mp = 0.chr * 260 mhandle = FindFirstVolumeMountPoint(vol, mp, mp.length) if mhandle == INVALID_HANDLE_VALUE raise get_last_error # ERROR => There are no more files. (RuntimeError) end p mp.strip FindVolumeMountPointClose(mhandle) I've probably misread the directions somewhere. Any suggestions? Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From phasis at gmail.com Wed Nov 26 20:36:00 2008 From: phasis at gmail.com (Heesob Park) Date: Thu, 27 Nov 2008 10:36:00 +0900 Subject: [Win32utils-devel] Question about FindFirstVolumeMountPoint In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514ED0@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514ED0@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: Hi, 2008/11/26 Berger, Daniel : > Hi, > > I can't seem to get FindFirstVolumeMountPoint to work. What am I doing > wrong? > > require 'windows/volume' > require 'windows/handle' > require 'windows/error' > > include Windows::Volume > include Windows::Handle > include Windows::Error > > vol = 0.chr * 512 > handle = FindFirstVolume(vol, vol.length) > > if handle == INVALID_HANDLE_VALUE > raise get_last_error > end > > vol.strip! > p vol # => \\\\?\\Volume{b4379d44-726d-11dc-87ec-806d6112693f}\\ > > FindVolumeClose(handle) > > mp = 0.chr * 260 > mhandle = FindFirstVolumeMountPoint(vol, mp, mp.length) > > if mhandle == INVALID_HANDLE_VALUE > raise get_last_error # ERROR => There are no more files. > (RuntimeError) > end > > p mp.strip > > FindVolumeMountPointClose(mhandle) > > I've probably misread the directions somewhere. Any suggestions? > That is a normal result for no mounted folders. Refer to http://msdn.microsoft.com/en-us/library/aa365733(VS.85).aspx First, you can create mounted folders like this c:\> mkdir c:\mnt\cdrive c:\> mountvol c:\mnt\cdrive \\?\Volume{b4379d44-726d-11dc-87ec-806d6112693f}\ Next, If you run the ruby code, the result is "mnt\\cdrive\\" Regards, Park Heesob From djberg96 at gmail.com Sun Nov 30 21:40:31 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 30 Nov 2008 19:40:31 -0700 Subject: [Win32utils-devel] [Fwd: [ruby-core:20176] Unable to build from source on Vista, VC++ 9] Message-ID: <49334E9F.8050301@gmail.com> Whoops, forgot to cc this. Regards, Dan -------------- next part -------------- An embedded message was scrubbed... From: Daniel Berger Subject: [ruby-core:20176] Unable to build from source on Vista, VC++ 9 Date: Sun, 30 Nov 2008 22:42:36 +0900 Size: 4476 URL: From phasis at gmail.com Sun Nov 30 22:03:38 2008 From: phasis at gmail.com (Heesob Park) Date: Mon, 1 Dec 2008 12:03:38 +0900 Subject: [Win32utils-devel] [Fwd: [ruby-core:20176] Unable to build from source on Vista, VC++ 9] In-Reply-To: <49334E9F.8050301@gmail.com> References: <49334E9F.8050301@gmail.com> Message-ID: Hi, 2008/12/1 Daniel Berger : > Whoops, forgot to cc this. > > Regards, > > Dan > > Hi, > > Windows Vista (Home Premium) > MS VC++ 9 (cl 15) > Ruby 1.8.6-p114 and Ruby 1.8.6-p237 > > eval.c > ... > eval.c(9839) : fatal error C1189: #error : unsupported platform > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio > 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2 > ' > Stop. > > Where the relevant code is: > > #if !defined SAVE_WIN32_EXCEPTION_LIST && !defined _WIN32_WCE > # error unsupported platform > #endif > #endif > I guess your vista is 64bit version. Modify #9797 of eval.c # ifdef _M_IX86 to # if defined _M_IX86 || defined _M_X64 will work for you. Regards, Park Heesob From djberg96 at gmail.com Sun Nov 30 22:16:28 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 30 Nov 2008 20:16:28 -0700 Subject: [Win32utils-devel] [Fwd: [ruby-core:20176] Unable to build from source on Vista, VC++ 9] In-Reply-To: References: <49334E9F.8050301@gmail.com> Message-ID: <4933570C.8030902@gmail.com> Heesob Park wrote: > Hi, > > 2008/12/1 Daniel Berger : >> Whoops, forgot to cc this. >> >> Regards, >> >> Dan >> >> Hi, >> >> Windows Vista (Home Premium) >> MS VC++ 9 (cl 15) >> Ruby 1.8.6-p114 and Ruby 1.8.6-p237 >> >> eval.c >> ... >> eval.c(9839) : fatal error C1189: #error : unsupported platform >> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio >> 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2 >> ' >> Stop. >> >> Where the relevant code is: >> >> #if !defined SAVE_WIN32_EXCEPTION_LIST && !defined _WIN32_WCE >> # error unsupported platform >> #endif >> #endif >> > > I guess your vista is 64bit version. > > Modify #9797 of eval.c > # ifdef _M_IX86 > to > # if defined _M_IX86 || defined _M_X64 > will work for you. Yes, 64 bit Vista. With your change it got further along this time (with p114), but hit another snag: eval.c eval.c(962) : warning C4018: '>=' : signed/unsigned mismatch eval.c(1157) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(1286) : warning C4244: '=' : conversion from '__int64' to 'long', possible loss of data eval.c(1488) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(2717) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(4412) : warning C4646: function declared with __declspec(noreturn) has non-void return type eval.c(4985) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(6312) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(6316) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(6456) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(6993) : warning C4244: '=' : conversion from '__int64' to 'long', possible loss of data eval.c(6994) : warning C4267: '=' : conversion from 'size_t' to 'long', possible loss of data eval.c(6997) : warning C4267: '=' : conversion from 'size_t' to 'long', possible loss of data eval.c(7160) : warning C4244: 'function' : conversion from '__int64' to 'long', possible loss of data eval.c(8790) : warning C4267: 'initializing' : conversion from 'size_t' to 'long', possible loss of data eval.c(8795) : warning C4267: '+=' : conversion from 'size_t' to 'long', possible loss of data eval.c(8799) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(8806) : warning C4267: '=' : conversion from 'size_t' to 'long', possible loss of data eval.c(9553) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(9553) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(9803) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture eval.c(9803) : error C2065: 'mov' : undeclared identifier eval.c(9803) : error C2146: syntax error : missing ';' before identifier 'eax' eval.c(9803) : error C2065: 'eax' : undeclared identifier eval.c(9803) : error C2065: 'fs' : undeclared identifier eval.c(9803) : error C2143: syntax error : missing ';' before ':' eval.c(9804) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture eval.c(9804) : error C2065: 'mov' : undeclared identifier eval.c(9804) : error C2146: syntax error : missing ';' before identifier 'p' eval.c(9804) : error C2065: 'eax' : undeclared identifier eval.c(10708) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data eval.c(10709) : warning C4244: '=' : conversion from 'double' to 'long', possible loss of data eval.c(10820) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(12138) : warning C4293: '<<' : shift count negative or too big, undefined behavior eval.c(12678) : warning C4267: 'function' : conversion from 'size_t' to 'long', possible loss of data eval.c(12680) : warning C4267: '=' : conversion from 'size_t' to 'long', possible loss of data eval.c(13200) : warning C4646: function declared with __declspec(noreturn) has non-void return type eval.c(13228) : warning C4645: function declared with __declspec(noreturn) has a return statement NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2 ' Stop. Not sure what happened. Any idea? Regards, Dan From phasis at gmail.com Sun Nov 30 23:22:46 2008 From: phasis at gmail.com (Heesob Park) Date: Mon, 1 Dec 2008 13:22:46 +0900 Subject: [Win32utils-devel] [Fwd: [ruby-core:20176] Unable to build from source on Vista, VC++ 9] In-Reply-To: <4933570C.8030902@gmail.com> References: <49334E9F.8050301@gmail.com> <4933570C.8030902@gmail.com> Message-ID: 2008/12/1 Daniel Berger : > Heesob Park wrote: >> >> Hi, >> >> 2008/12/1 Daniel Berger : >>> >>> Whoops, forgot to cc this. >>> >>> Regards, >>> >>> Dan >>> >>> Hi, >>> >>> Windows Vista (Home Premium) >>> MS VC++ 9 (cl 15) >>> Ruby 1.8.6-p114 and Ruby 1.8.6-p237 >>> >>> eval.c >>> ... >>> eval.c(9839) : fatal error C1189: #error : unsupported platform >>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual >>> Studio >>> 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2 >>> ' >>> Stop. >>> >>> Where the relevant code is: >>> >>> #if !defined SAVE_WIN32_EXCEPTION_LIST && !defined _WIN32_WCE >>> # error unsupported platform >>> #endif >>> #endif >>> >> >> I guess your vista is 64bit version. >> >> Modify #9797 of eval.c >> # ifdef _M_IX86 >> to >> # if defined _M_IX86 || defined _M_X64 >> will work for you. > > Yes, 64 bit Vista. > > With your change it got further along this time (with p114), but hit another > snag: > > eval.c > eval.c(962) : warning C4018: '>=' : signed/unsigned mismatch > eval.c(1157) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(1286) : warning C4244: '=' : conversion from '__int64' to 'long', > possible loss of data > eval.c(1488) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(2717) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(4412) : warning C4646: function declared with __declspec(noreturn) > has non-void return type > eval.c(4985) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(6312) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(6316) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(6456) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(6993) : warning C4244: '=' : conversion from '__int64' to 'long', > possible loss of data > eval.c(6994) : warning C4267: '=' : conversion from 'size_t' to 'long', > possible loss of data > eval.c(6997) : warning C4267: '=' : conversion from 'size_t' to 'long', > possible loss of data > eval.c(7160) : warning C4244: 'function' : conversion from '__int64' to > 'long', possible loss of data > eval.c(8790) : warning C4267: 'initializing' : conversion from 'size_t' to > 'long', possible loss of data > eval.c(8795) : warning C4267: '+=' : conversion from 'size_t' to 'long', > possible loss of data > eval.c(8799) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(8806) : warning C4267: '=' : conversion from 'size_t' to 'long', > possible loss of data > eval.c(9553) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(9553) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(9803) : error C4235: nonstandard extension used : '__asm' keyword not > supported on this architecture > eval.c(9803) : error C2065: 'mov' : undeclared identifier > eval.c(9803) : error C2146: syntax error : missing ';' before identifier > 'eax' > eval.c(9803) : error C2065: 'eax' : undeclared identifier > eval.c(9803) : error C2065: 'fs' : undeclared identifier > eval.c(9803) : error C2143: syntax error : missing ';' before ':' > eval.c(9804) : error C4235: nonstandard extension used : '__asm' keyword not > supported on this architecture > eval.c(9804) : error C2065: 'mov' : undeclared identifier > eval.c(9804) : error C2146: syntax error : missing ';' before identifier 'p' > eval.c(9804) : error C2065: 'eax' : undeclared identifier > eval.c(10708) : warning C4244: '=' : conversion from 'double' to 'long', > possible loss of data > eval.c(10709) : warning C4244: '=' : conversion from 'double' to 'long', > possible loss of data > eval.c(10820) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(12138) : warning C4293: '<<' : shift count negative or too big, > undefined behavior > eval.c(12678) : warning C4267: 'function' : conversion from 'size_t' to > 'long', possible loss of data > eval.c(12680) : warning C4267: '=' : conversion from 'size_t' to 'long', > possible loss of data > eval.c(13200) : warning C4646: function declared with __declspec(noreturn) > has non-void return type > eval.c(13228) : warning C4645: function declared with __declspec(noreturn) > has a return statement > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio > 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2 > ' > Stop. > > Not sure what happened. Any idea? > The __asm inline assembler is not supported in 64bit compiler. You must compile ruby source code with 32bit environment on 32-bit command prompt. To start and open a 32-bit command prompt, follow these steps: Click Start. Type %windir%\SysWoW64\cmd.exe in Start Search box. Alternatively, press Win + R keys (or type Run in Start Search) to open Run dialog, and type %windir%\SysWoW64\cmd.exe. Press Enter. Regards, Park Heesob From djberg96 at gmail.com Sun Nov 30 23:36:38 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 30 Nov 2008 21:36:38 -0700 Subject: [Win32utils-devel] [Fwd: [ruby-core:20176] Unable to build from source on Vista, VC++ 9] In-Reply-To: References: <49334E9F.8050301@gmail.com> <4933570C.8030902@gmail.com> Message-ID: <493369D6.2070903@gmail.com> Heesob Park wrote: > 2008/12/1 Daniel Berger : >> Heesob Park wrote: >>> Hi, >>> >>> 2008/12/1 Daniel Berger : >>>> Whoops, forgot to cc this. >>>> >>>> Regards, >>>> >>>> Dan >>>> >>>> Hi, >>>> >>>> Windows Vista (Home Premium) >>>> MS VC++ 9 (cl 15) >>>> Ruby 1.8.6-p114 and Ruby 1.8.6-p237 >>>> >>>> eval.c >>>> ... >>>> eval.c(9839) : fatal error C1189: #error : unsupported platform >>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual >>>> Studio >>>> 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2 >>>> ' >>>> Stop. >>>> >>>> Where the relevant code is: >>>> >>>> #if !defined SAVE_WIN32_EXCEPTION_LIST && !defined _WIN32_WCE >>>> # error unsupported platform >>>> #endif >>>> #endif >>>> >>> I guess your vista is 64bit version. >>> >>> Modify #9797 of eval.c >>> # ifdef _M_IX86 >>> to >>> # if defined _M_IX86 || defined _M_X64 >>> will work for you. >> Yes, 64 bit Vista. >> >> With your change it got further along this time (with p114), but hit another >> snag: >> >> eval.c >> eval.c(962) : warning C4018: '>=' : signed/unsigned mismatch >> eval.c(1157) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(1286) : warning C4244: '=' : conversion from '__int64' to 'long', >> possible loss of data >> eval.c(1488) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(2717) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(4412) : warning C4646: function declared with __declspec(noreturn) >> has non-void return type >> eval.c(4985) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(6312) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(6316) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(6456) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(6993) : warning C4244: '=' : conversion from '__int64' to 'long', >> possible loss of data >> eval.c(6994) : warning C4267: '=' : conversion from 'size_t' to 'long', >> possible loss of data >> eval.c(6997) : warning C4267: '=' : conversion from 'size_t' to 'long', >> possible loss of data >> eval.c(7160) : warning C4244: 'function' : conversion from '__int64' to >> 'long', possible loss of data >> eval.c(8790) : warning C4267: 'initializing' : conversion from 'size_t' to >> 'long', possible loss of data >> eval.c(8795) : warning C4267: '+=' : conversion from 'size_t' to 'long', >> possible loss of data >> eval.c(8799) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(8806) : warning C4267: '=' : conversion from 'size_t' to 'long', >> possible loss of data >> eval.c(9553) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(9553) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(9803) : error C4235: nonstandard extension used : '__asm' keyword not >> supported on this architecture >> eval.c(9803) : error C2065: 'mov' : undeclared identifier >> eval.c(9803) : error C2146: syntax error : missing ';' before identifier >> 'eax' >> eval.c(9803) : error C2065: 'eax' : undeclared identifier >> eval.c(9803) : error C2065: 'fs' : undeclared identifier >> eval.c(9803) : error C2143: syntax error : missing ';' before ':' >> eval.c(9804) : error C4235: nonstandard extension used : '__asm' keyword not >> supported on this architecture >> eval.c(9804) : error C2065: 'mov' : undeclared identifier >> eval.c(9804) : error C2146: syntax error : missing ';' before identifier 'p' >> eval.c(9804) : error C2065: 'eax' : undeclared identifier >> eval.c(10708) : warning C4244: '=' : conversion from 'double' to 'long', >> possible loss of data >> eval.c(10709) : warning C4244: '=' : conversion from 'double' to 'long', >> possible loss of data >> eval.c(10820) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(12138) : warning C4293: '<<' : shift count negative or too big, >> undefined behavior >> eval.c(12678) : warning C4267: 'function' : conversion from 'size_t' to >> 'long', possible loss of data >> eval.c(12680) : warning C4267: '=' : conversion from 'size_t' to 'long', >> possible loss of data >> eval.c(13200) : warning C4646: function declared with __declspec(noreturn) >> has non-void return type >> eval.c(13228) : warning C4645: function declared with __declspec(noreturn) >> has a return statement >> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio >> 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2 >> ' >> Stop. >> >> Not sure what happened. Any idea? >> > The __asm inline assembler is not supported in 64bit compiler. Ah, thanks. Do we absolutely have to have this bit of assembler code to begin with? I don't really know assembler so I don't know what that code is needed for. > You must compile ruby source code with 32bit environment on 32-bit > command prompt. > > To start and open a 32-bit command prompt, follow these steps: > > Click Start. > Type %windir%\SysWoW64\cmd.exe in Start Search box. > Alternatively, press Win + R keys (or type Run in Start Search) to > open Run dialog, and type %windir%\SysWoW64\cmd.exe. Got it, thanks. Regards, Dan