From zettabyte at gmail.com  Tue Feb  2 14:39:23 2010
From: zettabyte at gmail.com (Kendall Gifford)
Date: Tue, 2 Feb 2010 12:39:23 -0700
Subject: [Win32utils-devel] win32-dir broken (and windows-pr's limits.rb
	issues warnings) in ruby 1.9
Message-ID: <86ba954f1002021139o25b0ff5bn437827120487df54@mail.gmail.com>

Hi everyone, I'm pretty new to the win32-utils project: looks pretty cool!

Anyhow, for my development I'm using ruby 1.9.1 (p243) on Windows XP
Pro, SP3 (I download the ruby installer project's zip and development
kit).

I installed the win32-dir gem (which pulled in windows-pr too) and I'm
trying to use a few of the constants it adds to the Dir class.
However, on my first try on a very simple program, I got and error. I
then literally simplified my test script to:

---- D:\dir_test.rb
# Test win32-dir gem...
require 'win32/dir'
#
# just see if the parser can handle this gem at all; no actual code in file...
#
----

executing this yielded the following error and warning:

D:\>ruby dir_test.rb
D:/ruby/lib/ruby/gems/1.9.1/gems/windows-pr-1.0.8/lib/windows/limits.rb:17:
warning: variable $KCODE is no longer effective
D:/ruby/lib/ruby/gems/1.9.1/gems/win32-dir-0.3.5/lib/win32/dir.rb:38:in
`block in <class:Dir>': undefined method `split' for
:CSIDL_DESKTOP:Symbol (NoMethodError)
    from D:/ruby/lib/ruby/gems/1.9.1/gems/win32-dir-0.3.5/lib/win32/dir.rb:36:in
`each'
    from D:/ruby/lib/ruby/gems/1.9.1/gems/win32-dir-0.3.5/lib/win32/dir.rb:36:in
`<class:Dir>'
    from D:/ruby/lib/ruby/gems/1.9.1/gems/win32-dir-0.3.5/lib/win32/dir.rb:13:in
`<top (required)>'
    from dir_test.rb:2:in `require'
    from dir_test.rb:2:in `<main>'

The error in win32-dir's dir.rb file was an easy fix. I just changed:
dir.rb:38:      nconst = constant.split('CSIDL_').last
to:
dir.rb:38:      nconst = constant.to_s.split('CSIDL_').last

This makes the extra to_s redundant in ruby 1.8 but is needed for 1.9.
However, the $KCODE warning from above isn't as simple for me. I see
what the problem is, windows-pr gem's limits.rb file (line 17 on gem
version 1.0.8) uses $KCODE in a condition. The idea is to have a
larger value set for MAXPATH if using 'UTF8' encoding, otherwise set
MAXPATH to 256. Since $KCODE isn't used in 1.9 it is (I'm guessing)
nil (at least in my case) so it will always issue the warning and set
MAXPATH to 256.

Now, my simple code will likely still work but I'd like to resolve the
warning (I'm OCD) and have it work the "right" way for 1.8 <---> 1.9
compatibility. So, I guess this is a "feature request" as it were.

So, is Window's MAXPATH constant based on whether you use the ANSI vs.
their UNICODE version of an API call generally or is it more
complicated than that? Do win32-utils delegate to the ANSI ("A") or
UNICODE ("W") version of an API call based on the $KCODE value
globally? I'll dig into some code and try to answer my own question
but, if someone just knows this stuff well off the top of their head,
I'd appreciate the help. I've done a fair amount of C-based Win32
coding in the past and would like to help with these various projects
(to do my part); especially to get everything working smoothly on 1.9.

Anyhow, thanks everyone for your hard work making these gems!

-- 
Kendall Gifford
zettabyte at gmail.com

From djberg96 at gmail.com  Tue Feb  2 22:18:33 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Tue, 2 Feb 2010 20:18:33 -0700
Subject: [Win32utils-devel] win32-api on Windows 7
In-Reply-To: <71166b3b1001301106m6ce38d52vf4128362bbd5e45b@mail.gmail.com>
References: <6037b70c1001291953u41369ee6v99a722bd630d6d9b@mail.gmail.com>
	<aea95bc51001292054r855645aob4a1526af6937e5@mail.gmail.com>
	<6037b70c1001300810w33fa833fl9e0b3214813466d4@mail.gmail.com>
	<71166b3b1001301106m6ce38d52vf4128362bbd5e45b@mail.gmail.com>
Message-ID: <6037b70c1002021918u14f895c1p47289581203ae426@mail.gmail.com>

On Sat, Jan 30, 2010 at 12:06 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Sat, Jan 30, 2010 at 4:10 PM, Daniel Berger <djberg96 at gmail.com> wrote:
>>
>> Forgive me if I'm being dumb:
>>
>> // gcc 3.4.5 on Win7
>> #include <stdio.h>
>>
>> int main(){
>> ?printf("Size of void* : %i\n", sizeof(void*)); // 4
>> ?printf("Size of long: %i\n", sizeof(long)); // 4
>> ?return 0;
>> }
>>
>> They both show 4 for me.
>>
>> Is there anything we can do to make win32-api work on 64 bit windows?
>>
>> There is check_sizeof in mkmf.rb, if that helps at all.
>>
>
> GCC 3.4.5 is 32bits application, even when running on 64bits OS.
> (yeah, the joys of WOW64)
>
> I think mkmf one will work for you, since will use the same compiler
> used by Ruby in the same compilation mode, so will generate the
> expected sizeof.

Actually, I'm seeing this on my XP VM as well, so I don't think it's a
64 bit issue.

And I'm seeing rm.exe segfault there as well.

Can you confirm?

Regards,

Dan

PS - What's happened to mingw.org?

From phasis at gmail.com  Tue Feb  2 23:25:47 2010
From: phasis at gmail.com (Heesob Park)
Date: Wed, 3 Feb 2010 13:25:47 +0900
Subject: [Win32utils-devel] win32-api on Windows 7
In-Reply-To: <6037b70c1002021918u14f895c1p47289581203ae426@mail.gmail.com>
References: <6037b70c1001291953u41369ee6v99a722bd630d6d9b@mail.gmail.com> 
	<aea95bc51001292054r855645aob4a1526af6937e5@mail.gmail.com> 
	<6037b70c1001300810w33fa833fl9e0b3214813466d4@mail.gmail.com> 
	<71166b3b1001301106m6ce38d52vf4128362bbd5e45b@mail.gmail.com> 
	<6037b70c1002021918u14f895c1p47289581203ae426@mail.gmail.com>
Message-ID: <aea95bc51002022025n70ed5c54he4a45c0deb007930@mail.gmail.com>

Hi,

2010/2/3 Daniel Berger <djberg96 at gmail.com>:
> On Sat, Jan 30, 2010 at 12:06 PM, Luis Lavena <luislavena at gmail.com> wrote:
>> On Sat, Jan 30, 2010 at 4:10 PM, Daniel Berger <djberg96 at gmail.com> wrote:
>>>
>>> Forgive me if I'm being dumb:
>>>
>>> // gcc 3.4.5 on Win7
>>> #include <stdio.h>
>>>
>>> int main(){
>>> ?printf("Size of void* : %i\n", sizeof(void*)); // 4
>>> ?printf("Size of long: %i\n", sizeof(long)); // 4
>>> ?return 0;
>>> }
>>>
>>> They both show 4 for me.
>>>
>>> Is there anything we can do to make win32-api work on 64 bit windows?
>>>
>>> There is check_sizeof in mkmf.rb, if that helps at all.
>>>
>>
>> GCC 3.4.5 is 32bits application, even when running on 64bits OS.
>> (yeah, the joys of WOW64)
>>
>> I think mkmf one will work for you, since will use the same compiler
>> used by Ruby in the same compilation mode, so will generate the
>> expected sizeof.
>
> Actually, I'm seeing this on my XP VM as well, so I don't think it's a
> 64 bit issue.
>
> And I'm seeing rm.exe segfault there as well.
>
> Can you confirm?
>
I cannot confirm. The rm.exe works fine.

> PS - What's happened to mingw.org?

"The domain name mingw.org was bought by some idiot."

Refer to http://sourceforge.net/projects/mingw/

Regards,

Park Heesob

From djberg96 at gmail.com  Wed Feb  3 20:22:32 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Wed, 3 Feb 2010 18:22:32 -0700
Subject: [Win32utils-devel] win32-dir broken (and windows-pr's limits.rb
	issues warnings) in ruby 1.9
In-Reply-To: <86ba954f1002021139o25b0ff5bn437827120487df54@mail.gmail.com>
References: <86ba954f1002021139o25b0ff5bn437827120487df54@mail.gmail.com>
Message-ID: <6037b70c1002031722p384029fbp6302abb1c64be74f@mail.gmail.com>

On Tue, Feb 2, 2010 at 12:39 PM, Kendall Gifford <zettabyte at gmail.com> wrote:
> Hi everyone, I'm pretty new to the win32-utils project: looks pretty cool!

Thanks!

> Anyhow, for my development I'm using ruby 1.9.1 (p243) on Windows XP
> Pro, SP3 (I download the ruby installer project's zip and development
> kit).
>
> I installed the win32-dir gem (which pulled in windows-pr too) and I'm
> trying to use a few of the constants it adds to the Dir class.
> However, on my first try on a very simple program, I got and error.

<snip>

Thanks, I'll look into it and try to get a fix out soon.

> However, the $KCODE warning from above isn't as simple for me. I see
> what the problem is, windows-pr gem's limits.rb file (line 17 on gem
> version 1.0.8) uses $KCODE in a condition. The idea is to have a
> larger value set for MAXPATH if using 'UTF8' encoding, otherwise set
> MAXPATH to 256. Since $KCODE isn't used in 1.9 it is (I'm guessing)
> nil (at least in my case) so it will always issue the warning and set
> MAXPATH to 256.
>
> Now, my simple code will likely still work but I'd like to resolve the
> warning (I'm OCD) and have it work the "right" way for 1.8 <---> 1.9
> compatibility. So, I guess this is a "feature request" as it were.

Ok.

> So, is Window's MAXPATH constant based on whether you use the ANSI vs.
> their UNICODE version of an API call generally or is it more
> complicated than that? Do win32-utils delegate to the ANSI ("A") or
> UNICODE ("W") version of an API call based on the $KCODE value
> globally? I'll dig into some code and try to answer my own question
> but, if someone just knows this stuff well off the top of their head,
> I'd appreciate the help. I've done a fair amount of C-based Win32
> coding in the past and would like to help with these various projects
> (to do my part); especially to get everything working smoothly on 1.9.
>
> Anyhow, thanks everyone for your hard work making these gems!

It used to be that the wide character function would be used if $KCODE
was set, but it caused too much confusion in practice. By default, it
will use the ansi version.

The MAXPATH value currently does look at $KCODE. Obviously, this will
not work for 1.9. I'll have to check encoding or something. I don't
use 1.9 in practice, so that's why these errors creep up from time to
time.

Thanks for the report.

Regards,

Dan

From djberg96 at gmail.com  Fri Feb  5 04:49:39 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Fri, 5 Feb 2010 02:49:39 -0700
Subject: [Win32utils-devel] windows-pr and 1.9.x test failures
Message-ID: <001501caa648$8a3314a0$9e993de0$@com>

Hi all,

I'm trying to get windows-pr compliant with Ruby 1.9.x. I've fixed a few
issues that Kendall brought up, but I'm still seeing 4 test failures in
tc_unicode.rb:

c:\Users\djberge\Repositories\windows-pr>c:\ruby19\bin\rake test:unicode
(in c:/Users/djberge/Repositories/windows-pr)
c:/ruby19/bin/ruby -w -Ic:/Users/djberge/Repositories/windows-pr/lib
"c:/ruby19/lib/ruby/1.9.1/rake/rake_test_loader.rb"
 "test/tc_unicode.rb"
Warning:c:/ruby19/lib/ruby/1.9.1/tmpdir.rb:14: Win32API is deprecated after
Ruby 1.9.1; use dl directly instead
Loaded suite c:/ruby19/lib/ruby/1.9.1/rake/rake_test_loader
Started
.E.E.E.E

  1) Error:
test_multi_to_wide(TC_Windows_Unicode):
ArgumentError: invalid byte sequence in UTF-8
    c:/ruby19/lib/ruby/1.9.1/pp.rb:287:in `pretty_print'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `block in pp'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block (2 levels) in
group'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:225:in `nest'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block in group'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:210:in `group_sub'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:197:in `group'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `pp'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `block in pp'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:121:in `guard_inspect_key'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `pp'
    test/tc_unicode.rb:49:in `test_multi_to_wide'

  2) Error:
test_multi_to_wide_with_encoding(TC_Windows_Unicode):
ArgumentError: invalid byte sequence in UTF-8
    c:/ruby19/lib/ruby/1.9.1/pp.rb:287:in `pretty_print'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `block in pp'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block (2 levels) in
group'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:225:in `nest'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block in group'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:210:in `group_sub'
    c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:197:in `group'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `pp'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `block in pp'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:121:in `guard_inspect_key'
    c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `pp'
    test/tc_unicode.rb:54:in `test_multi_to_wide_with_encoding'

  3) Error:
test_wide_to_multi(TC_Windows_Unicode):
ArgumentError: invalid byte sequence in US-ASCII
    c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
`[]'
    c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
`wide_to_multi'
    test/tc_unicode.rb:66:in `test_wide_to_multi'

  4) Error:
test_wide_to_multi_with_encoding(TC_Windows_Unicode):
ArgumentError: invalid byte sequence in US-ASCII
    c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
`[]'
    c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
`wide_to_multi'
    test/tc_unicode.rb:71:in `test_wide_to_multi_with_encoding'

Finished in 0.035 seconds.

8 tests, 38 assertions, 0 failures, 4 errors, 0 pendings, 0 omissions, 0
notifications
50% passed
rake aborted!
Command failed with status (1): [c:/ruby19/bin/ruby -w
-Ic:/Users/djberge/R...]

(See full trace by running task with --trace)

What's the proper fix for multi_to_wide and wide_to_multi for Ruby 1.9.x?

Regards,

Dan


From phasis at gmail.com  Sat Feb  6 00:00:35 2010
From: phasis at gmail.com (Heesob Park)
Date: Sat, 6 Feb 2010 14:00:35 +0900
Subject: [Win32utils-devel] windows-pr and 1.9.x test failures
In-Reply-To: <001501caa648$8a3314a0$9e993de0$@com>
References: <001501caa648$8a3314a0$9e993de0$@com>
Message-ID: <aea95bc51002052100o1e1d4b18x8382eaf4d106e82d@mail.gmail.com>

Hi,

2010/2/5 Daniel Berger <djberg96 at gmail.com>:
> Hi all,
>
> I'm trying to get windows-pr compliant with Ruby 1.9.x. I've fixed a few
> issues that Kendall brought up, but I'm still seeing 4 test failures in
> tc_unicode.rb:
>
> c:\Users\djberge\Repositories\windows-pr>c:\ruby19\bin\rake test:unicode
> (in c:/Users/djberge/Repositories/windows-pr)
> c:/ruby19/bin/ruby -w -Ic:/Users/djberge/Repositories/windows-pr/lib
> "c:/ruby19/lib/ruby/1.9.1/rake/rake_test_loader.rb"
> ?"test/tc_unicode.rb"
> Warning:c:/ruby19/lib/ruby/1.9.1/tmpdir.rb:14: Win32API is deprecated after
> Ruby 1.9.1; use dl directly instead
> Loaded suite c:/ruby19/lib/ruby/1.9.1/rake/rake_test_loader
> Started
> .E.E.E.E
>
> ?1) Error:
> test_multi_to_wide(TC_Windows_Unicode):
> ArgumentError: invalid byte sequence in UTF-8
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:287:in `pretty_print'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `block in pp'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block (2 levels) in
> group'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:225:in `nest'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block in group'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:210:in `group_sub'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:197:in `group'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `pp'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `block in pp'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:121:in `guard_inspect_key'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `pp'
> ? ?test/tc_unicode.rb:49:in `test_multi_to_wide'
>
> ?2) Error:
> test_multi_to_wide_with_encoding(TC_Windows_Unicode):
> ArgumentError: invalid byte sequence in UTF-8
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:287:in `pretty_print'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `block in pp'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block (2 levels) in
> group'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:225:in `nest'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:198:in `block in group'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:210:in `group_sub'
> ? ?c:/ruby19/lib/ruby/1.9.1/prettyprint.rb:197:in `group'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:154:in `pp'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `block in pp'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:121:in `guard_inspect_key'
> ? ?c:/ruby19/lib/ruby/1.9.1/pp.rb:77:in `pp'
> ? ?test/tc_unicode.rb:54:in `test_multi_to_wide_with_encoding'
>
> ?3) Error:
> test_wide_to_multi(TC_Windows_Unicode):
> ArgumentError: invalid byte sequence in US-ASCII
> ? ?c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
> `[]'
> ? ?c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
> `wide_to_multi'
> ? ?test/tc_unicode.rb:66:in `test_wide_to_multi'
>
> ?4) Error:
> test_wide_to_multi_with_encoding(TC_Windows_Unicode):
> ArgumentError: invalid byte sequence in US-ASCII
> ? ?c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
> `[]'
> ? ?c:/Users/djberge/Repositories/windows-pr/lib/windows/unicode.rb:146:in
> `wide_to_multi'
> ? ?test/tc_unicode.rb:71:in `test_wide_to_multi_with_encoding'
>
> Finished in 0.035 seconds.
>
> 8 tests, 38 assertions, 0 failures, 4 errors, 0 pendings, 0 omissions, 0
> notifications
> 50% passed
> rake aborted!
> Command failed with status (1): [c:/ruby19/bin/ruby -w
> -Ic:/Users/djberge/R...]
>
> (See full trace by running task with --trace)
>
> What's the proper fix for multi_to_wide and wide_to_multi for Ruby 1.9.x?
>
My suggestion is to insert "# encoding: ascii-8bit" on the first line of each
/windows-pr/lib/windows/unicode.rb and /windows-pr/test/tc_unicode.rb file.

That would reduce error messages.

Regards,
Park Heesob

From djberg96 at gmail.com  Sun Feb  7 13:09:02 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 7 Feb 2010 11:09:02 -0700
Subject: [Win32utils-devel] Need a second pair of eyes for controls_accepted
	in win32-service
Message-ID: <001b01caa820$a200c620$e6025260$@com>

Hi,

I'm getting bad results for the controls_accepted results in win32-service
for the ServiceInfo struct, and I'm not sure why, even after I thought I
fixed this (previously it always returned nil). Please checkout the latest
code from github.

For example:

require 'win32/service'
include Win32

Service.services{ |s|
  next unless s.service_name == 'W32Time'
  p s.controls_accepted
}

That returns:

["netbind change", "param change", "pause continue", "shutdown", "stop",
"hardware profile change", "power event", "interrogate"]

However, W32Time cannot be paused/resumed, so the 'pause continue' result
(among others I suspect) is bogus.

Any ideas why? It's probably something simple, but I'm not getting it.

Regards,

Dan


From phasis at gmail.com  Sun Feb  7 20:16:21 2010
From: phasis at gmail.com (Heesob Park)
Date: Mon, 8 Feb 2010 10:16:21 +0900
Subject: [Win32utils-devel] Need a second pair of eyes for
	controls_accepted in win32-service
In-Reply-To: <001b01caa820$a200c620$e6025260$@com>
References: <001b01caa820$a200c620$e6025260$@com>
Message-ID: <aea95bc51002071716q523c5e6bmd64cc681aa3c9934@mail.gmail.com>

Hi Dan,

2010/2/8 Daniel Berger <djberg96 at gmail.com>:
> Hi,
>
> I'm getting bad results for the controls_accepted results in win32-service
> for the ServiceInfo struct, and I'm not sure why, even after I thought I
> fixed this (previously it always returned nil). Please checkout the latest
> code from github.
>
> For example:
>
> require 'win32/service'
> include Win32
>
> Service.services{ |s|
> ?next unless s.service_name == 'W32Time'
> ?p s.controls_accepted
> }
>
> That returns:
>
> ["netbind change", "param change", "pause continue", "shutdown", "stop",
> "hardware profile change", "power event", "interrogate"]
>
> However, W32Time cannot be paused/resumed, so the 'pause continue' result
> (among others I suspect) is bogus.
>
> Any ideas why? It's probably something simple, but I'm not getting it.
>
You must need some sleep :)

You should use SERVICE_ACCEPT_PAUSE_CONTINUE instead of SERVICE_PAUSE_CONTINUE.
The line #1220
      if controls & SERVICE_PAUSE_CONTINUE> 0
should be
      if controls & SERVICE_ACCEPT_PAUSE_CONTINUE > 0

Also, the line #1548 - 1550
      if controls & SERVICE_CONTROL_INTERROGATE > 0
        array << 'interrogate'
      end
shoud be removed.

Regards,

Park Heesob

From djberg96 at gmail.com  Mon Feb  8 00:39:39 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 7 Feb 2010 22:39:39 -0700
Subject: [Win32utils-devel] Need a second pair of eyes for
	controls_accepted in win32-service
In-Reply-To: <aea95bc51002071716q523c5e6bmd64cc681aa3c9934@mail.gmail.com>
References: <001b01caa820$a200c620$e6025260$@com>
	<aea95bc51002071716q523c5e6bmd64cc681aa3c9934@mail.gmail.com>
Message-ID: <6037b70c1002072139k64037b45pab598019769e78ba@mail.gmail.com>

On Sun, Feb 7, 2010 at 6:16 PM, Heesob Park <phasis at gmail.com> wrote:
> Hi Dan,
>
> 2010/2/8 Daniel Berger <djberg96 at gmail.com>:
>> Hi,
>>
>> I'm getting bad results for the controls_accepted results in win32-service
>> for the ServiceInfo struct, and I'm not sure why, even after I thought I
>> fixed this (previously it always returned nil). Please checkout the latest
>> code from github.
>>
>> For example:
>>
>> require 'win32/service'
>> include Win32
>>
>> Service.services{ |s|
>> ?next unless s.service_name == 'W32Time'
>> ?p s.controls_accepted
>> }
>>
>> That returns:
>>
>> ["netbind change", "param change", "pause continue", "shutdown", "stop",
>> "hardware profile change", "power event", "interrogate"]
>>
>> However, W32Time cannot be paused/resumed, so the 'pause continue' result
>> (among others I suspect) is bogus.
>>
>> Any ideas why? It's probably something simple, but I'm not getting it.
>>
> You must need some sleep :)
>
> You should use SERVICE_ACCEPT_PAUSE_CONTINUE instead of SERVICE_PAUSE_CONTINUE.
> The line #1220
> ? ? ?if controls & SERVICE_PAUSE_CONTINUE> 0
> should be
> ? ? ?if controls & SERVICE_ACCEPT_PAUSE_CONTINUE > 0

Thanks! Silly me.

> Also, the line #1548 - 1550
> ? ? ?if controls & SERVICE_CONTROL_INTERROGATE > 0
> ? ? ? ?array << 'interrogate'
> ? ? ?end
> shoud be removed.

Ok. It's not really a control and pretty much every service can be
interrogated anyway, right?

Changes applied in git.

Thanks,

Dan

From djberg96 at gmail.com  Mon Feb  8 22:06:48 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 08 Feb 2010 20:06:48 -0700
Subject: [Win32utils-devel] rm.exe stackdump
Message-ID: <4B70D148.1080108@gmail.com>

For anyone interested, here's the stackdump for rm.exe that I'm seeing 
with msys on my Windows XP VM:

C:\Repositories\win32-api\ext>type rm.exe.stackdump
MSYS-1.0.11 Build:2009-05-12 18:47
Exception: STATUS_ACCESS_VIOLATION at eip=3000A973
eax=00000774 ebx=7109972C ecx=00000000 edx=71111E34 esi=711100D4 
edi=71083EC0
ebp=0022FEE0 esp=0022FE9C program=c:\Program Files\Git\bin\rm.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022FEE0  3000A973  (711100D4, 00000774, 00000003, 30004E25)
0022FF30  3000500A  (00000000, 879F0000, 0000228F, 00000008)
0022FF50  300056D5  (00008000, 00000000, 0022FF90, 0040F2C8)
0022FF60  30005722  (00000000, 00000000, 8054B49A, 8054B944)
0022FF90  0040F2C8  (004016E4, 00000000, 00000001, 00000006)
0022FFC0  0040103D  (71083EC0, 0022E7F8, 7FFDB000, 8054B6ED)
0022FFF0  7C817077  (00401000, 00000000, 78746341, 00000020)
End of stack trace

Is there a dedicated msys/mingw google group? I couldn't find it, and I 
really don't want to subscribe to the mailing list.

Regards,

Dan

From luislavena at gmail.com  Tue Feb  9 05:14:05 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 9 Feb 2010 11:14:05 +0100
Subject: [Win32utils-devel] rm.exe stackdump
In-Reply-To: <4B70D148.1080108@gmail.com>
References: <4B70D148.1080108@gmail.com>
Message-ID: <71166b3b1002090214l3fd9e38amc75073627485726b@mail.gmail.com>

On Tue, Feb 9, 2010 at 4:06 AM, Daniel Berger <djberg96 at gmail.com> wrote:
> For anyone interested, here's the stackdump for rm.exe that I'm seeing with
> msys on my Windows XP VM:
>
> C:\Repositories\win32-api\ext>type rm.exe.stackdump
> MSYS-1.0.11 Build:2009-05-12 18:47
> Exception: STATUS_ACCESS_VIOLATION at eip=3000A973
> eax=00000774 ebx=7109972C ecx=00000000 edx=71111E34 esi=711100D4
> edi=71083EC0
> ebp=0022FEE0 esp=0022FE9C program=c:\Program Files\Git\bin\rm.exe
> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> Stack trace:
> Frame ? ? Function ?Args
> 0022FEE0 ?3000A973 ?(711100D4, 00000774, 00000003, 30004E25)
> 0022FF30 ?3000500A ?(00000000, 879F0000, 0000228F, 00000008)
> 0022FF50 ?300056D5 ?(00008000, 00000000, 0022FF90, 0040F2C8)
> 0022FF60 ?30005722 ?(00000000, 00000000, 8054B49A, 8054B944)
> 0022FF90 ?0040F2C8 ?(004016E4, 00000000, 00000001, 00000006)
> 0022FFC0 ?0040103D ?(71083EC0, 0022E7F8, 7FFDB000, 8054B6ED)
> 0022FFF0 ?7C817077 ?(00401000, 00000000, 78746341, 00000020)
> End of stack trace
>
> Is there a dedicated msys/mingw google group? I couldn't find it, and I
> really don't want to subscribe to the mailing list.

There is no group in Google, but what you can do is subscribe to
mingw-users, and use GMail power to assign a label and archive it
directly.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From djberg96 at gmail.com  Tue Feb  9 12:36:50 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Tue, 09 Feb 2010 10:36:50 -0700
Subject: [Win32utils-devel] rm.exe stackdump
In-Reply-To: <71166b3b1002090214l3fd9e38amc75073627485726b@mail.gmail.com>
References: <4B70D148.1080108@gmail.com>
	<71166b3b1002090214l3fd9e38amc75073627485726b@mail.gmail.com>
Message-ID: <4B719D32.3010903@gmail.com>

Luis Lavena wrote:
> On Tue, Feb 9, 2010 at 4:06 AM, Daniel Berger <djberg96 at gmail.com> wrote:
>> For anyone interested, here's the stackdump for rm.exe that I'm seeing with
>> msys on my Windows XP VM:
>>
>> C:\Repositories\win32-api\ext>type rm.exe.stackdump
>> MSYS-1.0.11 Build:2009-05-12 18:47
>> Exception: STATUS_ACCESS_VIOLATION at eip=3000A973
>> eax=00000774 ebx=7109972C ecx=00000000 edx=71111E34 esi=711100D4
>> edi=71083EC0
>> ebp=0022FEE0 esp=0022FE9C program=c:\Program Files\Git\bin\rm.exe
>> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
>> Stack trace:
>> Frame     Function  Args
>> 0022FEE0  3000A973  (711100D4, 00000774, 00000003, 30004E25)
>> 0022FF30  3000500A  (00000000, 879F0000, 0000228F, 00000008)
>> 0022FF50  300056D5  (00008000, 00000000, 0022FF90, 0040F2C8)
>> 0022FF60  30005722  (00000000, 00000000, 8054B49A, 8054B944)
>> 0022FF90  0040F2C8  (004016E4, 00000000, 00000001, 00000006)
>> 0022FFC0  0040103D  (71083EC0, 0022E7F8, 7FFDB000, 8054B6ED)
>> 0022FFF0  7C817077  (00401000, 00000000, 78746341, 00000020)
>> End of stack trace
>>
>> Is there a dedicated msys/mingw google group? I couldn't find it, and I
>> really don't want to subscribe to the mailing list.
> 
> There is no group in Google, but what you can do is subscribe to
> mingw-users, and use GMail power to assign a label and archive it
> directly.
> 

Actually, I just realized it was the rm.exe that came with the git 
bundle. I removed that so that it uses the one from msys instead. That 
one works fine.

Regards,

Dan

From luislavena at gmail.com  Tue Feb  9 13:04:36 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 9 Feb 2010 19:04:36 +0100
Subject: [Win32utils-devel] rm.exe stackdump
In-Reply-To: <4B719D32.3010903@gmail.com>
References: <4B70D148.1080108@gmail.com>
	<71166b3b1002090214l3fd9e38amc75073627485726b@mail.gmail.com> 
	<4B719D32.3010903@gmail.com>
Message-ID: <71166b3b1002091004k2cdd70a6p94a8dd15952a3b3f@mail.gmail.com>

On Tue, Feb 9, 2010 at 6:36 PM, Daniel Berger <djberg96 at gmail.com> wrote:
>
> Actually, I just realized it was the rm.exe that came with the git bundle. I
> removed that so that it uses the one from msys instead. That one works fine.
>

That is one of the reasons I only have the git.cmd stub instead of the
full git in my PATH.

Glad you sorted it out, don't hesitate in share any issue you may have
with MSYS so we can work together in solve them
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From charley.baker at gmail.com  Thu Feb 11 13:40:23 2010
From: charley.baker at gmail.com (Charley Baker)
Date: Thu, 11 Feb 2010 11:40:23 -0700
Subject: [Win32utils-devel] Win32-api 1.4.6 release and mswin32 binary?
Message-ID: <f96821861002111040q2f0a4d53h81514a87d319a969@mail.gmail.com>

Hey all,


Before this starts to bite us too much. It looks like there's a new release
of win32-api gem - 1.4.6, which only has a mingw precompiled binary, as
opposed the mswin binaries for the previous versions. Is there a mswin
binary in the works, otherwise projects depending on this and people using
the one click installer are going to, and are getting errors trying to
compile.


Cheers,

Charley Baker
Lead Developer, Watir, http://watir.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20100211/7e580dec/attachment.html>

From luislavena at gmail.com  Thu Feb 11 14:57:38 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 11 Feb 2010 20:57:38 +0100
Subject: [Win32utils-devel] Win32-api 1.4.6 release and mswin32 binary?
In-Reply-To: <f96821861002111040q2f0a4d53h81514a87d319a969@mail.gmail.com>
References: <f96821861002111040q2f0a4d53h81514a87d319a969@mail.gmail.com>
Message-ID: <71166b3b1002111157i41a13c46k82305527b011c6cb@mail.gmail.com>

On Thu, Feb 11, 2010 at 7:40 PM, Charley Baker <charley.baker at gmail.com> wrote:
> Hey all,
>
>
> Before this starts to bite us too much. It looks like there's a new release
> of win32-api gem - 1.4.6, which only has a mingw precompiled binary, as
> opposed the mswin binaries for the previous versions. Is there a mswin
> binary in the works, otherwise projects depending on this and people using
> the one click installer are going to, and are getting errors trying to
> compile.
>

If the project used rake-compiler, release of binary versions for both
gem platforms will only take change:

ext.platform = "i386-mingw32"

to

ext.platform = ["i386-mingw32", "i386-mswin32-60"]

Also, if the gem was built using rake-compiler, installation process
should work smoothly with either VC6 or MinGW, as long you have all
the headers in place and extconf.rb do not do weird things.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From djberg96 at gmail.com  Fri Feb 12 06:18:54 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Fri, 12 Feb 2010 04:18:54 -0700
Subject: [Win32utils-devel] Win32-api 1.4.6 release and mswin32 binary?
In-Reply-To: <f96821861002111040q2f0a4d53h81514a87d319a969@mail.gmail.com>
References: <f96821861002111040q2f0a4d53h81514a87d319a969@mail.gmail.com>
Message-ID: <4B75391E.10507@gmail.com>

Charley Baker wrote:
> Hey all,
> 
> 
> Before this starts to bite us too much. It looks like there's a new 
> release of win32-api gem - 1.4.6, which only has a mingw precompiled 
> binary, as opposed the mswin binaries for the previous versions. Is 
> there a mswin binary in the works, otherwise projects depending on this 
> and people using the one click installer are going to, and are getting 
> errors trying to compile.

Ok, I've pushed an x86-mswin32 binary.

Regards,

Dan

From charley.baker at gmail.com  Fri Feb 12 13:22:37 2010
From: charley.baker at gmail.com (Charley Baker)
Date: Fri, 12 Feb 2010 11:22:37 -0700
Subject: [Win32utils-devel] Win32-api 1.4.6 release and mswin32 binary?
In-Reply-To: <4B75391E.10507@gmail.com>
References: <f96821861002111040q2f0a4d53h81514a87d319a969@mail.gmail.com>
	<4B75391E.10507@gmail.com>
Message-ID: <f96821861002121022w6365aesb1431bd0f2790baf@mail.gmail.com>

Cool, thanks for that Dan.

Cheers,

Charley

On Fri, Feb 12, 2010 at 4:18 AM, Daniel Berger <djberg96 at gmail.com> wrote:

> Charley Baker wrote:
>
>> Hey all,
>>
>>
>> Before this starts to bite us too much. It looks like there's a new
>> release of win32-api gem - 1.4.6, which only has a mingw precompiled binary,
>> as opposed the mswin binaries for the previous versions. Is there a mswin
>> binary in the works, otherwise projects depending on this and people using
>> the one click installer are going to, and are getting errors trying to
>> compile.
>>
>
> Ok, I've pushed an x86-mswin32 binary.
>
> Regards,
>
> Dan
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20100212/606cdb8e/attachment.html>

From djberg96 at gmail.com  Sat Feb 13 11:27:36 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sat, 13 Feb 2010 09:27:36 -0700
Subject: [Win32utils-devel] pr-win32ole crash
Message-ID: <000101caacc9$753e46a0$5fbad3e0$@com>

I noticed that, with both mingw and mswin, after running "rake test" for
pr-win32ole, the interpreter crashes on my Vista laptop.

Anyone else seeing that?

http://github.com/djberg96/pr-win32ole

Regards,

Dan


From djberg96 at gmail.com  Mon Feb 15 11:41:54 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 15 Feb 2010 09:41:54 -0700
Subject: [Win32utils-devel] pr-win32ole crash
In-Reply-To: <000101caacc9$753e46a0$5fbad3e0$@com>
References: <000101caacc9$753e46a0$5fbad3e0$@com>
Message-ID: <6037b70c1002150841y55f9c87ahc075b23217de0248@mail.gmail.com>

On Sat, Feb 13, 2010 at 9:27 AM, Daniel Berger <djberg96 at gmail.com> wrote:
> I noticed that, with both mingw and mswin, after running "rake test" for
> pr-win32ole, the interpreter crashes on my Vista laptop.
>
> Anyone else seeing that?
>
> http://github.com/djberg96/pr-win32ole

For a more concrete example, I tried running this code from irb:

http://rubyonwindows.blogspot.com/2010/02/ruby-powerpoint-inserting-hyperlinks.html

It was working ok, but then just crashed.

Regards,

Dan

From noreply at rubyforge.org  Sat Feb 20 13:05:54 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 20 Feb 2010 13:05:54 -0500 (EST)
Subject: [Win32utils-devel] [ win32utils-Bugs-27862 ] win32-taskscheduler
	segfault on Windows 7
Message-ID: <20100220180554.B493F18582CC@rubyforge.org>

Bugs item #27862, was opened at 2010-02-20 11:05
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=411&aid=27862&group_id=85

Category: win32-taskscheduler
Group: Code
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Berger (djberg96)
Assigned to: Nobody (None)
Summary: win32-taskscheduler segfault on Windows 7

Initial Comment:
win32-taskscheduler 0.2.0
Windows 7 Ultimate

Here's the segfault with some caller and api information:

["C:/Ruby/lib/ruby/gems/1.8/gems/windows-pr-1.0.9/lib/windows/msvcrt/buffer.rb:39:in `memcpy'", "./lib/win32/taskscheduler.rb:842:in `new_work_item'", "./
n32/taskscheduler.rb:195:in `initialize'", "./test/test_taskscheduler.rb:34:in `new'", "./test/test_taskscheduler.rb:34:in `setup'", "C:/Ruby/lib/ruby/gem
gems/test-unit-2.0.6/lib/test/unit/fixture.rb:163:in `send'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/fixture.rb:163:in `run_fixture
:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/fixture.rb:159:in `each'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/fixtu
159:in `run_fixture'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/fixture.rb:168:in `run_setup'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-
.0.6/lib/test/unit/testcase.rb:311:in `run'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/testsuite.rb:38:in `run'", "C:/Ruby/lib/ruby/g
8/gems/test-unit-2.0.6/lib/test/unit/testsuite.rb:37:in `each'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/testsuite.rb:37:in `run'",
by/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/testsuite.rb:38:in `run'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/testsuite
:in `each'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/testsuite.rb:37:in `run'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/
nit/ui/testrunnermediator.rb:48:in `run_suite'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/ui/console/testrunner.rb:81:in `start_media
 "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/ui/console/testrunner.rb:51:in `start'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/li
/unit/ui/testrunnerutilities.rb:24:in `run'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit/autorunner.rb:310:in `run'", "C:/Ruby/lib/ruby
1.8/gems/test-unit-2.0.6/lib/test/unit/autorunner.rb:52:in `run'", "C:/Ruby/lib/ruby/gems/1.8/gems/test-unit-2.0.6/lib/test/unit.rb:321", "C:/Ruby/lib/rub
/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5"]
"memcpy"
["\000\000\000\000", 0, 4]
C:/Ruby/lib/ruby/gems/1.8/gems/windows-api-0.4.0/lib/windows/api.rb:494: [BUG] Segmentation fault
ruby 1.8.6 (2009-08-04) [i386-mingw32]

Line 842 of taskscheduler.rb is this:

memcpy(lpVtbl, @pITask, 4)

Regards,

Dan

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=411&aid=27862&group_id=85

From noreply at rubyforge.org  Sat Feb 20 12:43:36 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 20 Feb 2010 12:43:36 -0500 (EST)
Subject: [Win32utils-devel] [ win32utils-Feature Requests-26603 ]
	TaskScheduler creates .job file on 2k3 but does not register
	job with the scheduler
Message-ID: <20100220174336.4206C18582CC@rubyforge.org>

Feature Requests item #26603, was opened at 2009-07-13 14:19
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=26603&group_id=85

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Erik Hollensbe (erikh)
Assigned to: Nobody (None)
Summary: TaskScheduler creates .job file on 2k3 but does not register job with the scheduler

Initial Comment:
Using this code:

require 'rubygems'
require 'win32/taskscheduler'

t = Win32::TaskScheduler.new("task", {
   "start_month"  => 4,
   "start_day"    => 11,
   "start_hour"   => 7,
   "start_minute"	 => 14,
   "trigger_type"	 => Win32::TaskScheduler::DAILY,
   "type"         => { "days_interval" => 2 }
})

t.application_name = "ruby test.rb"
t.save

Which is taken almost verbatim out of:

http://jp.rubyist.net/magazine/?0005-RLR-en

It saves C:\Windows\Tasks\task.job but upon viewing the scheduled tasks list, it does not appear.

I'm not really a windows maven, but here's what I know about the environment:

Windows 2003 Server R2
Ruby mingw32 build of 1.8.6 pl 114 (2008-03-03)

gem list --local reports these gems in use:

win32-api 1.4.3
windows-api 0.3.0
windows-pr 1.0.5
win32-taskscheduler 0.2.0

HTH, Let me know if you require any more information.

Thanks as always,

-Erik

----------------------------------------------------------------------

>Comment By: Daniel Berger (djberg96)
Date: 2010-02-20 10:43

Message:
Is start_year the only required field? My memory is failing.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-09-25 09:16

Message:
Bumping to a feature request.

- Dan

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-07-14 08:31

Message:
We'll add required fields to the next release Erik. Thanks for the report.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Erik Hollensbe (erikh)
Date: 2009-07-14 06:47

Message:
I'll give this a shot, but if I can be granted license to
complain a little, the distinct lack of required fields
checking and documentation has made this library very hard
to work with. If I knew more of what I was doing on windows
I'd gladly contribute patches but I don't think that would
serve you well with my current level of knowledge.

Is there any chance that this lack of information can be
remedied in the next release?

----------------------------------------------------------------------

Comment By: Park Heesob  (phasis68)
Date: 2009-07-14 06:40

Message:
It's not a bug. 
You have ommitted required field 'start_year'. 
The code should be like this:
t = Win32::TaskScheduler.new("task", {
   "start_year"  => 2010,
   "start_month"  => 4,
   "start_day"    => 11,
   "start_hour"   => 7,
   "start_minute"	 => 14,
   "trigger_type"	 => Win32::TaskScheduler::DAILY,
   "type"         => { "days_interval" => 2 }
})

Of course, the missing field checking routine might be helpful.

Regards,

Park Heesob


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=26603&group_id=85

From djberg96 at gmail.com  Sun Feb 21 22:08:28 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 21 Feb 2010 20:08:28 -0700
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
Message-ID: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>

Hi,

Ruby 1.8.6 mingw
Windows 7 Ultimate

Just playing with the ole branch for win32-taskscheduler, but I can't
get it to work. I tried this:

$:.unshift 'lib'
require 'rubygems'
require 'win32/taskscheduler'
include Win32

task = 'test_delete_me'

trigger = {
  'start_year'   => Time.now.year + 1,
  'start_month'  => 4,
  'start_day'    => 1,
  'start_hour'   => 7,
  'start_minute' => 14,
  'trigger_type' => TaskScheduler::DAILY,
  'type'         => { 'days_interval' => 1 }
}

ts = TaskScheduler.new
ts.new_work_item(@task, @trigger)
ts.activate(@task)

But that resulted in this error from RegisterTaskDefinition in new_work_item:

HRESULT error code:0x80020009

Any ideas?

Thanks,

Dan

From phasis at gmail.com  Sun Feb 21 22:18:38 2010
From: phasis at gmail.com (Heesob Park)
Date: Mon, 22 Feb 2010 12:18:38 +0900
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
Message-ID: <aea95bc51002211918s52760878tb082e5be7ce54104@mail.gmail.com>

Hi,

2010/2/22 Daniel Berger <djberg96 at gmail.com>:
> Hi,
>
> Ruby 1.8.6 mingw
> Windows 7 Ultimate
>
> Just playing with the ole branch for win32-taskscheduler, but I can't
> get it to work. I tried this:
>
> $:.unshift 'lib'
> require 'rubygems'
> require 'win32/taskscheduler'
> include Win32
>
> task = 'test_delete_me'
>
> trigger = {
> ?'start_year' ? => Time.now.year + 1,
> ?'start_month' ?=> 4,
> ?'start_day' ? ?=> 1,
> ?'start_hour' ? => 7,
> ?'start_minute' => 14,
> ?'trigger_type' => TaskScheduler::DAILY,
> ?'type' ? ? ? ? => { 'days_interval' => 1 }
> }
>
> ts = TaskScheduler.new
> ts.new_work_item(@task, @trigger)
> ts.activate(@task)
>
> But that resulted in this error from RegisterTaskDefinition in new_work_item:
>
> HRESULT error code:0x80020009
>
> Any ideas?
>
As I mentioned before, the current taskscheduler implementation is not
compatible with Vista and Windows 7.

Refer to http://rubyforge.org/pipermail/win32utils-devel/2009-June/001438.html

Regards,

Park Heesob

From djberg96 at gmail.com  Sun Feb 21 23:24:03 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 21 Feb 2010 21:24:03 -0700
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <aea95bc51002211918s52760878tb082e5be7ce54104@mail.gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
	<aea95bc51002211918s52760878tb082e5be7ce54104@mail.gmail.com>
Message-ID: <6037b70c1002212024u4476edb1k8bb04fe0570a9877@mail.gmail.com>

On Sun, Feb 21, 2010 at 8:18 PM, Heesob Park <phasis at gmail.com> wrote:
> Hi,
>
> 2010/2/22 Daniel Berger <djberg96 at gmail.com>:
>> Hi,
>>
>> Ruby 1.8.6 mingw
>> Windows 7 Ultimate
>>
>> Just playing with the ole branch for win32-taskscheduler, but I can't
>> get it to work. I tried this:
>>
>> $:.unshift 'lib'
>> require 'rubygems'
>> require 'win32/taskscheduler'
>> include Win32
>>
>> task = 'test_delete_me'
>>
>> trigger = {
>> ?'start_year' ? => Time.now.year + 1,
>> ?'start_month' ?=> 4,
>> ?'start_day' ? ?=> 1,
>> ?'start_hour' ? => 7,
>> ?'start_minute' => 14,
>> ?'trigger_type' => TaskScheduler::DAILY,
>> ?'type' ? ? ? ? => { 'days_interval' => 1 }
>> }
>>
>> ts = TaskScheduler.new
>> ts.new_work_item(@task, @trigger)
>> ts.activate(@task)
>>
>> But that resulted in this error from RegisterTaskDefinition in new_work_item:
>>
>> HRESULT error code:0x80020009
>>
>> Any ideas?
>>
> As I mentioned before, the current taskscheduler implementation is not
> compatible with Vista and Windows 7.

Oh, I thought you were only referring to the 0.2.0 version, not the ole branch.

Regards,

Dan

From djberg96 at gmail.com  Mon Feb 22 00:16:21 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 21 Feb 2010 22:16:21 -0700
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <6037b70c1002212024u4476edb1k8bb04fe0570a9877@mail.gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
	<aea95bc51002211918s52760878tb082e5be7ce54104@mail.gmail.com>
	<6037b70c1002212024u4476edb1k8bb04fe0570a9877@mail.gmail.com>
Message-ID: <6037b70c1002212116j72030c24gec9960a8b4669c32@mail.gmail.com>

On Sun, Feb 21, 2010 at 9:24 PM, Daniel Berger <djberg96 at gmail.com> wrote:
> On Sun, Feb 21, 2010 at 8:18 PM, Heesob Park <phasis at gmail.com> wrote:
>> Hi,
>>
>> 2010/2/22 Daniel Berger <djberg96 at gmail.com>:
>>> Hi,
>>>
>>> Ruby 1.8.6 mingw
>>> Windows 7 Ultimate
>>>
>>> Just playing with the ole branch for win32-taskscheduler, but I can't
>>> get it to work. I tried this:
>>>
>>> $:.unshift 'lib'
>>> require 'rubygems'
>>> require 'win32/taskscheduler'
>>> include Win32
>>>
>>> task = 'test_delete_me'
>>>
>>> trigger = {
>>> ?'start_year' ? => Time.now.year + 1,
>>> ?'start_month' ?=> 4,
>>> ?'start_day' ? ?=> 1,
>>> ?'start_hour' ? => 7,
>>> ?'start_minute' => 14,
>>> ?'trigger_type' => TaskScheduler::DAILY,
>>> ?'type' ? ? ? ? => { 'days_interval' => 1 }
>>> }
>>>
>>> ts = TaskScheduler.new
>>> ts.new_work_item(@task, @trigger)
>>> ts.activate(@task)
>>>
>>> But that resulted in this error from RegisterTaskDefinition in new_work_item:
>>>
>>> HRESULT error code:0x80020009
>>>
>>> Any ideas?
>>>
>> As I mentioned before, the current taskscheduler implementation is not
>> compatible with Vista and Windows 7.
>
> Oh, I thought you were only referring to the 0.2.0 version, not the ole branch.

Actually, after looking at
http://www.microsoft.com/technet/scriptcenter/topics/vista/tasks2.mspx,
it sure looks like that code should work. I converted that script to
use Ruby's win32ole and it worked just fine.

git clone git at github.com:djberg96/win32-taskscheduler.git
git checkout -b ole origin/ole

I'll play with it some more later.

Regards,

Dan

From phasis at gmail.com  Mon Feb 22 01:45:32 2010
From: phasis at gmail.com (Heesob Park)
Date: Mon, 22 Feb 2010 15:45:32 +0900
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <6037b70c1002212116j72030c24gec9960a8b4669c32@mail.gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com> 
	<aea95bc51002211918s52760878tb082e5be7ce54104@mail.gmail.com> 
	<6037b70c1002212024u4476edb1k8bb04fe0570a9877@mail.gmail.com> 
	<6037b70c1002212116j72030c24gec9960a8b4669c32@mail.gmail.com>
Message-ID: <aea95bc51002212245o136970d0h63c3d9eaca7e1fdd@mail.gmail.com>

Hi,

2010/2/22 Daniel Berger <djberg96 at gmail.com>:
> On Sun, Feb 21, 2010 at 9:24 PM, Daniel Berger <djberg96 at gmail.com> wrote:
>> On Sun, Feb 21, 2010 at 8:18 PM, Heesob Park <phasis at gmail.com> wrote:
>>> Hi,
>>>
>>> 2010/2/22 Daniel Berger <djberg96 at gmail.com>:
>>>> Hi,
>>>>
>>>> Ruby 1.8.6 mingw
>>>> Windows 7 Ultimate
>>>>
>>>> Just playing with the ole branch for win32-taskscheduler, but I can't
>>>> get it to work. I tried this:
>>>>
>>>> $:.unshift 'lib'
>>>> require 'rubygems'
>>>> require 'win32/taskscheduler'
>>>> include Win32
>>>>
>>>> task = 'test_delete_me'
>>>>
>>>> trigger = {
>>>> ?'start_year' ? => Time.now.year + 1,
>>>> ?'start_month' ?=> 4,
>>>> ?'start_day' ? ?=> 1,
>>>> ?'start_hour' ? => 7,
>>>> ?'start_minute' => 14,
>>>> ?'trigger_type' => TaskScheduler::DAILY,
>>>> ?'type' ? ? ? ? => { 'days_interval' => 1 }
>>>> }
>>>>
>>>> ts = TaskScheduler.new
>>>> ts.new_work_item(@task, @trigger)
>>>> ts.activate(@task)
>>>>
>>>> But that resulted in this error from RegisterTaskDefinition in new_work_item:
>>>>
>>>> HRESULT error code:0x80020009
>>>>
>>>> Any ideas?
>>>>
>>> As I mentioned before, the current taskscheduler implementation is not
>>> compatible with Vista and Windows 7.
>>
>> Oh, I thought you were only referring to the 0.2.0 version, not the ole branch.
>
> Actually, after looking at
> http://www.microsoft.com/technet/scriptcenter/topics/vista/tasks2.mspx,
> it sure looks like that code should work. I converted that script to
> use Ruby's win32ole and it worked just fine.
>
> git clone git at github.com:djberg96/win32-taskscheduler.git
> git checkout -b ole origin/ole
>
> I'll play with it some more later.
>
Sorry, I fogot I made the taskscheduler version 2.0 implementation :)
It should work for vista and windows 7.
I'll look into the source code.

Regards,

Park Heesob

From phasis at gmail.com  Mon Feb 22 07:48:54 2010
From: phasis at gmail.com (Heesob Park)
Date: Mon, 22 Feb 2010 21:48:54 +0900
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
Message-ID: <aea95bc51002220448i3319b176nfd1fad9a9501da9d@mail.gmail.com>

Hi,

2010/2/22 Daniel Berger <djberg96 at gmail.com>:
> Hi,
>
> Ruby 1.8.6 mingw
> Windows 7 Ultimate
>
> Just playing with the ole branch for win32-taskscheduler, but I can't
> get it to work. I tried this:
>
> $:.unshift 'lib'
> require 'rubygems'
> require 'win32/taskscheduler'
> include Win32
>
> task = 'test_delete_me'
>
> trigger = {
> ?'start_year' ? => Time.now.year + 1,
> ?'start_month' ?=> 4,
> ?'start_day' ? ?=> 1,
> ?'start_hour' ? => 7,
> ?'start_minute' => 14,
> ?'trigger_type' => TaskScheduler::DAILY,
> ?'type' ? ? ? ? => { 'days_interval' => 1 }
> }
>
> ts = TaskScheduler.new
> ts.new_work_item(@task, @trigger)
> ts.activate(@task)
>
> But that resulted in this error from RegisterTaskDefinition in new_work_item:
>
> HRESULT error code:0x80020009
>
> Any ideas?
>
You have two wrong constant definitions in taskscheduler.rb.

    TASK_UPDATE = 0x3
    TASK_CREATE_OR_UPDATE = 0x4

should be

    TASK_UPDATE = 0x4
    TASK_CREATE_OR_UPDATE = 0x6


Regards,

Park Heesob

From djberg96 at gmail.com  Mon Feb 22 20:55:05 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 22 Feb 2010 18:55:05 -0700
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <aea95bc51002220448i3319b176nfd1fad9a9501da9d@mail.gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
	<aea95bc51002220448i3319b176nfd1fad9a9501da9d@mail.gmail.com>
Message-ID: <4B833579.7080604@gmail.com>

Heesob Park wrote:
> Hi,
> 
> 2010/2/22 Daniel Berger <djberg96 at gmail.com>:
>> Hi,
>>
>> Ruby 1.8.6 mingw
>> Windows 7 Ultimate
>>
>> Just playing with the ole branch for win32-taskscheduler, but I can't
>> get it to work. I tried this:
>>
>> $:.unshift 'lib'
>> require 'rubygems'
>> require 'win32/taskscheduler'
>> include Win32
>>
>> task = 'test_delete_me'
>>
>> trigger = {
>>  'start_year'   => Time.now.year + 1,
>>  'start_month'  => 4,
>>  'start_day'    => 1,
>>  'start_hour'   => 7,
>>  'start_minute' => 14,
>>  'trigger_type' => TaskScheduler::DAILY,
>>  'type'         => { 'days_interval' => 1 }
>> }
>>
>> ts = TaskScheduler.new
>> ts.new_work_item(@task, @trigger)
>> ts.activate(@task)
>>
>> But that resulted in this error from RegisterTaskDefinition in new_work_item:
>>
>> HRESULT error code:0x80020009
>>
>> Any ideas?
>>
> You have two wrong constant definitions in taskscheduler.rb.
> 
>     TASK_UPDATE = 0x3
>     TASK_CREATE_OR_UPDATE = 0x4
> 
> should be
> 
>     TASK_UPDATE = 0x4
>     TASK_CREATE_OR_UPDATE = 0x6

Oy, thanks.

Dan

From djberg96 at gmail.com  Mon Feb 22 21:05:27 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 22 Feb 2010 19:05:27 -0700
Subject: [Win32utils-devel] taskscheduler api change?
Message-ID: <4B8337E7.4080808@gmail.com>

All,

After going back over the win32-taskscheduler API, I'm leaning towards 
making a significant API change. I'd like to change the constructor.

At the moment it looks like this:

server = TaskScheduler.new(name = nil, trigger = nil)

Which is a shortcut for:

server = TaskScheduler.new
server.new_work_item(name, trigger)

My philosophy at the time was that you typically create one task at a 
time in practice, so this was convenient. However, when I look at that 
code now it makes me think that the +server+ is tied to that particular 
task, which it isn't. The second form is clearer.

On top of that, we don't have a way to set the root folder at the 
moment. Combined with my reasons above, I'd like to change the 
constructor to this:

server = TaskScheduler.new(folder = "\\", force = false)

Internally that would look something like this:

unless service.FolderExists(folder)
   if force
     service.CreateFolder(folder)
   else
     raise ArgumentError, "folder '#{folder}' does not exist"
   end
end

root = service.GetFolder(folder)

I could put in type checks to make sure people coming from 0.2.0 don't 
do something crazy by mistake, along with some warnings.

The alternative is to just leave the constructor alone and add 
TaskScheduler#folder and TaskScheduler#folder= methods that would 
require a separate method call, and reset our @root instance variable. 
The downside, besides feeling clunky, is that it means the end user 
would be making an unnecessary connection in the constructor, and would 
have remember to make that call before making any other calls.

What say you?

Regards,

Dan

From phasis at gmail.com  Mon Feb 22 21:51:47 2010
From: phasis at gmail.com (Heesob Park)
Date: Tue, 23 Feb 2010 11:51:47 +0900
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <4B833579.7080604@gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com> 
	<aea95bc51002220448i3319b176nfd1fad9a9501da9d@mail.gmail.com> 
	<4B833579.7080604@gmail.com>
Message-ID: <aea95bc51002221851g7fcef31an48f0ebede5b39a22@mail.gmail.com>

Hi,

As you know, 0.3.0 is not working on XP and 0.2.x is not working on
Vista and laster.

For now, we have 0.2.x for XP, 2K and 2003 and 0.3.x for Vista, 2008 and 7.

What's your release plan of win32-taskscheduler?

Any idea of the unified version?

Regards,

Park Heesob

From djberg96 at gmail.com  Mon Feb 22 21:53:38 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 22 Feb 2010 19:53:38 -0700
Subject: [Win32utils-devel] Can't get TaskScheduler.new to work for 0.3.0
In-Reply-To: <aea95bc51002221851g7fcef31an48f0ebede5b39a22@mail.gmail.com>
References: <6037b70c1002211908g62f352ebr65754e7e1963b656@mail.gmail.com>
	<aea95bc51002220448i3319b176nfd1fad9a9501da9d@mail.gmail.com>
	<4B833579.7080604@gmail.com>
	<aea95bc51002221851g7fcef31an48f0ebede5b39a22@mail.gmail.com>
Message-ID: <4B834332.2080501@gmail.com>

Heesob Park wrote:
> Hi,
> 
> As you know, 0.3.0 is not working on XP and 0.2.x is not working on
> Vista and laster.
> 
> For now, we have 0.2.x for XP, 2K and 2003 and 0.3.x for Vista, 2008 and 7.
> 
> What's your release plan of win32-taskscheduler?
> 
> Any idea of the unified version?

I was thinking about that last night. My initial idea is to ship 3 files:

taskscheduler.rb
taskscheduler1.rb
taskscheduler2.rb

taskscheduler1.rb would be the current 0.2.0 branch.
taskscheduler2.rb would be the new code.

taskscheduler.rb would then require taskscheduler1.rb or 
taskscheduler2.rb based on the current version of windows. I have some 
helper functions in windows-pr for that.

Does that seem reasonable?

Regards,

Dan