From Daniel.Berger at qwest.com  Thu Jun  1 10:03:03 2006
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Thu, 1 Jun 2006 09:03:03 -0500
Subject: [Win32utils-devel] Getting at MakeOpenFile
Message-ID: <39AA6550E5AA554AB1456707D6E5563D0259E6B0@QTOMAE2K3M01.AD.QINTRA.COM>

> -----Original Message-----
> From: win32utils-devel-bounces at rubyforge.org 
> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of 
> Wayne Vucenic
> Sent: Wednesday, May 31, 2006 4:05 PM
> To: Development and ideas for win32utils projects
> Subject: Re: [Win32utils-devel] Getting at MakeOpenFile
> 
> 
> Hi Dan,
> 
> How's it going?
> 
> Regarding MakeOpenFile... looking in 
> C:\ruby\lib\ruby\1.8\i386-mswin32\rubyio.h, its defined as a macro:
> 
> #define MakeOpenFile(obj, fp) do {\
>     if (RFILE(obj)->fptr) {\
> 	rb_io_close(obj);\
> 	free(RFILE(obj)->fptr);\
> 	RFILE(obj)->fptr = 0;\
>     }\
>     fp = 0;\
>     fp = RFILE(obj)->fptr = ALLOC(OpenFile);\
>     fp->f = fp->f2 = NULL;\
>     fp->mode = 0;\
>     fp->pid = 0;\
>     fp->lineno = 0;\
>     fp->path = NULL;\
>     fp->finalize = 0;\
> } while (0)
> 
> so the only way to access it would be to #include "rubyio.h", 
> which doesn't help much for your pure Ruby solution.
> 
> Wayne

Ah, yes.  It just doesn't look like win32-open3 is a good candidate for
a pure Ruby version.  I've posted a shared object built with VC++ 6 on
the project page, courtesy of Heesob.

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 jpshack at gmail.com  Thu Jun  1 13:14:27 2006
From: jpshack at gmail.com (John-Mason P. Shackelford)
Date: Thu, 1 Jun 2006 12:14:27 -0500
Subject: [Win32utils-devel] Getting at MakeOpenFile
In-Reply-To: <39AA6550E5AA554AB1456707D6E5563D0259E6B0@QTOMAE2K3M01.AD.QINTRA.COM>
References: <39AA6550E5AA554AB1456707D6E5563D0259E6B0@QTOMAE2K3M01.AD.QINTRA.COM>
Message-ID: <83f770ff0606011014i35fc4521heda6757b90260db4@mail.gmail.com>

Dan,

Any chance we could get a VC++6 build of win32-open3 with the patch
for returning Process::Status committed?

-- 
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://pearsonedmeasurement.com

From djberg96 at gmail.com  Thu Jun  1 23:11:10 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Thu, 01 Jun 2006 21:11:10 -0600
Subject: [Win32utils-devel] Getting at MakeOpenFile
In-Reply-To: <83f770ff0606011014i35fc4521heda6757b90260db4@mail.gmail.com>
References: <39AA6550E5AA554AB1456707D6E5563D0259E6B0@QTOMAE2K3M01.AD.QINTRA.COM>
	<83f770ff0606011014i35fc4521heda6757b90260db4@mail.gmail.com>
Message-ID: <447FAC4E.1010206@gmail.com>

John-Mason P. Shackelford wrote:
> Dan,
> 
> Any chance we could get a VC++6 build of win32-open3 with the patch
> for returning Process::Status committed?
> 

John, looks good to me.  Let me check with Heesob.

Heesob, can you test this patch with VC++ 6 please?  It looks good to 
me, but I can't run a sample program without it segfaulting due to 
compiler differences I think.

If it works for you (and you like it), go ahead and commit it please. 
Then, please send me the shared object. :)

Thanks,

Dan

From phasis at gmail.com  Fri Jun  2 01:08:29 2006
From: phasis at gmail.com (Park Heesob)
Date: Fri, 2 Jun 2006 14:08:29 +0900
Subject: [Win32utils-devel] Getting at MakeOpenFile
References: <39AA6550E5AA554AB1456707D6E5563D0259E6B0@QTOMAE2K3M01.AD.QINTRA.COM><83f770ff0606011014i35fc4521heda6757b90260db4@mail.gmail.com>
	<447FAC4E.1010206@gmail.com>
Message-ID: <000701c68602$988f1bd0$6d7ba8c0@2xnm9896kmqn5b9>

Hi,
----- Original Message ----- 
From: "Daniel Berger" <djberg96 at gmail.com>
To: <john-mason at shackelford.org>; "Development and ideas for win32utils 
projects" <win32utils-devel at rubyforge.org>
Sent: Friday, June 02, 2006 12:11 PM
Subject: Re: [Win32utils-devel] Getting at MakeOpenFile


> John-Mason P. Shackelford wrote:
>> Dan,
>>
>> Any chance we could get a VC++6 build of win32-open3 with the patch
>> for returning Process::Status committed?
>>
>
> John, looks good to me.  Let me check with Heesob.
>
> Heesob, can you test this patch with VC++ 6 please?  It looks good to
> me, but I can't run a sample program without it segfaulting due to
> compiler differences I think.
>
I have tested the patch and add some additional codes and committed it.

> If it works for you (and you like it), go ahead and commit it please.
> Then, please send me the shared object. :)
>
Here goes

Regards,

Park Heesob


begin 666 open3.so
M35J0``,````$````__\``+@`````````0 ``````````````````````````
M````````````````````Z ````X?N at X`M G-(;@!3,TA5&AI<R!P<F]G<F%M
M(&-A;FYO="!B92!R=6X@:6X at 1$]3(&UO9&4N#0T*) ````````#MTPS9J;)B
MBJFR8HJILF**RZUQBJNR8HHJKFR*J+)BBL:M:(JLLF**QJUFBJNR8HJILF.*
MF+)BBI^4:(JHLF**5I)FBJVR8HI2:6-HJ;)BB@``````````````````````
M`````````%!%``!,`00`'\9_1 ``````````X `.(0L!!@``( ```# `````
M``!*'P```! ````P```````0`! ````0```$``````````0``````````& `
M```0`````````@``````$ ``$ `````0```0````````$ ```" U``!&````
M[# ``% `````````````````````````````````````4 ``/ $``- P```<
M```````````````````````````````````````````````````````````P
M``#(````````````````````````````````````+G1E>'0````.$ ```! `
M```@````$ ``````````````````( ``8"YR9&%T80``9 at 4````P````$ ``
M`# ``````````````````$ ``$ N9&%T80```+0#````0 ```! ```! ````
M``````````````! ``# +G)E;&]C``"0`0```% ````0````4 ``````````
M````````0 ``0@``````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`%6+[(/L",=%_ ````"+10B*"(A-^(!]^&%T)(!]^')T"(!]^'=T#>LABU7\
M@\H!B57\ZRR+1?R#R *)1?SK(8M-_(/)`HE-_.L6BU4(4F at 40 `0H;PP`!"+
M"%'HE T``(M5" ^^0@&#^&)U$HM-_(/)!(E-_(M5"(/"`8E5"(M%" ^^2 &#
M^2MU&(M5_(/*`XE5_(M%" ^^2 *%R70"ZZKK#8M5" ^^0@&%P'0"ZYN+1?R+
MY5W#S,S,S,S,S,S,S%6+[(/L"%?'1?P`````:@!J`(U%_%!H``0``(M-"%%J
M`&@`$P``_Q4L, `0B47X at WWX`'43:"Q `!"+%;@P`!"+`E#H[ P``+F ````
M,\"_H$$`$/.KBTWX@^D"48M5_%)HH$$`$/\56# `$(/$#(M%_%#_%3 P`!"X
MH$$`$%^+Y5W#S,S,S,S,S,S,S,S,S%6+[(/L"&AD0 `0Z* ,``"#Q 2)1?AH
M7$ `$.B0# ``@\0$B47\:O]HL!$`$&A40 `0BT7X4.AO# ``@\00:O]HL!$`
M$&A,0 `0BTW\4>A7# ``@\00B^5=P\S,S,S,S%6+[(/L',=%\ ````#'1?@`
M````QT7DE$ `$(U%\%"-3?11C57\4FB00 `0BT4,4(M-"%'H-0P``(/$&(-]
M] 1T,(M5](/B`872=!>-1>Q0BTWTT?E1Z*4```"#Q B)1>3K#XU5]%+H_ L`
M`(/$!(E%Y(M%Y ^^"(/Y='4)QT7X`$ ``.LEBU7D#[X"@_AB=!-H;$ `$(L-
MO# `$(L14NB@"P``QT7X`( ``(M%\%"+3?A1C57\4NBL"P``@\0$4.A[`0``
M@\0,B47HZ)(+``"%P'0ABT7H4&AP$P`0BTWH46@,'@`0Z&L+``"#Q!"A$$ `
M$.L#BT7HB^5=P\S,S,Q5B^R#[ B+10R)1?R+30B#X0.)3?B#??@`= Z#??@!
M=!F#??@"="3K0(M5_,8"<HM%_(/ `8E%_.LOBTW\Q@%WBU7\@\(!B57\ZQZ+
M1?S&`'*+3?R#P0&)3?R+5?S&`BN+1?R#P &)1?R+3?S&`0"+5?R#P@&)5?R+
M10 at E`( ``(7 =#&+30P/OE$!@_HK=1>+10S&0 %BBTT,QD$"*XM5#,9"`P#K
M#HM%#,9 `6*+30S&00(`BT4,B^5=P\S,S,Q5B^Q1QT7\`````.L)BT7\@\ !
MB47\@WW\`WU0:@!HH$ `$.B2"@``@\0$4(M-"(M1$(M%_(L, at E'H=@H``(/$
M#(7 =25J`&B80 `0Z&D*``"#Q 10BU4(BT(0BTW\BQ2(4NA-"@``@\0,ZZ&X
M! ```(OE7</,S,S,S,S,S,S,S%6+[(/L>,=%M P```#'1;P!````QT6X````
M`&H`C46T4(U-T%&-59A2_Q4<, `0A<!U$FC at 0 `0H7 at P`!"+"%'HOPD``&H"
M:@!J`(U5I%+_%2 P`!!0BT704/\5(# `$%#_%20P`!")19R#?9P`=1-HT$ `
M$(L-># `$(L14NB!"0``BT704/\5*# `$&H`C4VT48U5]%*-18A0_Q4<, `0
MA<!U$VC$0 `0BPUX, `0BQ%2Z$P)``!J`FH`:@"-1>A0_Q4@, `04(M-B%'_
M%2 P`!!0_Q4D, `0B46<@WV<`'43:-! `!"+%7 at P`!"+`E#H#@D``(M-B%'_
M%2 at P`!!J`(U5M%*-1>10C4WL4?\5'# `$(7 =1-HQ$ `$(L5># `$(L"4.C9
M" ``:@)J`&H`C4WP4?\5(# `$%"+5>Q2_Q4@, `04/\5)# `$(E%G(-]G !U
M$FC00 `0H7 at P`!"+"%'HG @``(M5[%+_%2 at P`!"+10PE`$ ``(7 =!#'1;# 
M0 `0QT6 at O$ `$.L.QT6PN$ `$,=%H+1 `!"+30Q1BU6D4O\53# `$(/$"(E%
MR(M%H%"+3<A1_Q50, `0@\0(B46,BU4,4HM%Z%#_%4PP`!"#Q B)1<"+3;!1
MBU7 4O\54# `$(/$"(E%_(M%#%"+3?!1_Q5,, `0@\0(B46HBU6P4HM%J%#_
M%5 P`!"#Q B)1?C'1> #````BTT048U5W%*-1=10BTWD48M5]%*+19A0BTT(
M4>C$! ``@\0<A<!U"K@$````Z3 $``"#?=P`?0B+5=SWVHE5W(M%H%#HK/G_
M_X/$!(E%K(L-?# `$(L14N at 8! ``@\0$B478BT78 at W@(`'0FBTW84>C(!P``
M@\0$BU78BT((4/\55# `$(/$!(M-V,=!" ````#'190`````:ASHEP<``(/$
M!(M5V(E""(M%V(M("(E-E(M5E,="! ````"+193'``````"+393'00@`````
MBU64QT(,`````(M%E,= $ ````"+393'010`````BU64QT(8`````#/ A< /
MA6+___^+393'01@@'0`0BU64BT6LB4((BTV4BU7<B5$,BT6L@^ !A<!T"(M-
ME(M5C(D1BT6L@^ "A<!T*HM-E(,Y`'0+BU64BT6,B4($ZPB+392+58R)$8M%
ME(M("(/)"(M5E(E*"(M%L%#HB?C__X/$!(E%K(L-?# `$(L14NCU`@``@\0$
MB47,BT7, at W@(`'0FBTW,4>BE!@``@\0$BU7,BT((4/\55# `$(/$!(M-S,=!
M" ````#'190`````:ASH= 8``(/$!(M5S(E""(M%S(M("(E-E(M5E,="! ``
M``"+193'``````"+393'00@`````BU64QT(,`````(M%E,= $ ````"+393'
M010`````BU64QT(8`````#/ A< /A6+___^+393'01@@'0`0BU64BT6LB4((
MBTV4BU7<B5$,BT6L@^ !A<!T"(M-E(M5_(D1BT6L@^ "A<!T*HM-E(,Y`'0+
MBU64BT7\B4($ZPB+392+5?R)$8M%E(M("(/)"(M5E(E*"(M%L%#H9O?__X/$
M!(E%K(L-?# `$(L14NC2`0``@\0$B47$BT7$@W@(`'0FBTW$4>B"!0``@\0$
MBU7$BT((4/\55# `$(/$!(M-Q,=!" ````#'190`````:ASH404``(/$!(M5
MQ(E""(M%Q(M("(E-E(M5E,="! ````"+193'``````"+393'00@`````BU64
MQT(,`````(M%E,= $ ````"+393'010`````BU64QT(8`````#/ A< /A6+_
M__^+393'01@@'0`0BU64BT6LB4((BTV4BU7<B5$,BT6L@^ !A<!T"(M-E(M5
M^(D1BT6L@^ "A<!T*HM-E(,Y`'0+BU64BT7XB4($ZPB+392+5?B)$8M%E(M(
M"(/)"(M5E(E*"&H$Z($$``"#Q 2)19"+1=A0BTV04>AH! ``@\0(BU7,4HM%
MD%#H6 0``(/$"(M-Q%&+59!2Z$@$``"#Q B+1=Q0Z#8$``"#Q 10BTV04>@O
M! ``@\0(BU684O\5*# `$(7 =1)HJ$ `$*%X, `0BPA1Z,H#``"+5?12_Q4H
M, `0A<!U$FBH0 `0H7 at P`!"+"%'HJ@,``(M5Y%+_%2 at P`!"%P'42:*A `!"A
M># `$(L(4>B*`P``BT60B^5=P\S,S,S,S,S,S,S,S,S,S%6+[%'HQ0,``(E%
M_(M%_,<`#@```(M-_(M5"(E1!*%T, `0 at S@#?"J+3?R#X0.%R74:BU7\@^+[
MA=)T$(M%_(L(@<D``0``BU7\B0HSP(7 ==8SR87)=;2+5?S'0@@`````BT7\
MB^5=P\S,S,S,S,Q5B^R#['17QT6P=$$`$&H`:@!H;$$`$/\5## `$(E%J(-]
MJ `/A ,!``"+1:B#P .#X/SH2 ,``(EED(M%D(E%_(M-J%&+5?Q2:&Q!`!#_
M%0PP`!")1:R#?:P`=0B+1:SIP0$``(M%_ -%K(E%E(M-E#M-_'(6BU64#[X"
M at _A<= N+392#Z0&)393KXHM5E(/"`8E5E/\5$# `$#T```" <W=H8$$`$(M%
ME%#_%40P`!"#Q B%P'1ABWVP@\G_,\#RKO?1@\'_BU6H`]&+?0B#R?\SP/*N
M]]&#P?^-1 H!B46LBT6L@\ #@^#\Z) "``")98R+38R)3;2+50A2BT6P4(M-
M_%%H6$$`$(M5M%+_%4 at P`!"#Q!3K$F at X00`0H7 at P`!"+"%'HV0$``.L3:/1 
M`!"+%7 at P`!"+`E#HQ $``+D1````,\"-?;CSJ\=%N$0```#'1>0!`0``BTT,
MB4WPBU40B57TBT44B47X9L=%Z ``@WT@`G4&9L=%Z 4`C4V848U5N%)J`&H`
M:@!J`6H`:@"+10A0:@#_%10P`!"%P'0ABTV<4?\5*# `$(M5&(M%F(D"BTT<
MBU6 at B1&X`0```.MCC4684(U-N%%J`&H`:A!J`6H`:@"+5;12:@#_%10P`!"%
MP'0ABT6<4/\5*# `$(M-&(M5F(D1BT4<BTV at B0BX`0```.L>_Q48, `04.B\
M\___@\0$4(L5># `$(L"4.C>````C66(7XOE7</,S%6+[(/L"(M%"(M(#%%J
M`&@`! ``_Q4$, `0B47\@WW\`'0JC57X4HM%_%#_%0 at P`!"!??@#`0``=!.+
M30B+40Q2BT7X4. at 6````@\0(B^5=P\S,S,S,S,S,S,S,S,S,S%6+[(/L"&B(
M00`0Z- ```"#Q 2)1?B+1?A0Z+L```"#Q 2)1?R+30C!X0C1X8/)`5%H@$$`
M$(M5_%+HE0```(/$#(M%#-'@@\@!4&A\00`0BTW\4>A[````@\0,BQ5L, `0
MBT7\B0*+3?R)#1! `!"+Y5W#_R7 , `0_R6T, `0_R6P, `0_R6L, `0_R6H
M, `0_R6D, `0_R6@, `0_R6<, `0_R68, `0_R64, `0_R60, `0_R6,, `0
M_R6(, `0_R6$, `0_R6 , `0_R5P, `0_R5H, `0_R5D, `0_R5@, `0S,S,
MS,S,S,S,S%$]`! ``(U,) AR%('I`! ``"T`$ ``A0$]`! ``'/L*\B+Q(4!
MB^&+"(M !%##BT0D"(7 =0XY!:!#`!!^+O\-H$,`$(L-.# `$(/X`8L)B0VD
M0P`0=3]H@ ```/\5/# `$(7 6:.L0P`0=00SP.MF at R `H:Q#`!!H!$ `$&@`
M0 `0HZA#`!#HZP```/\%H$,`$%E9ZSV%P'4YH:Q#`!"%P'0PBPVH0P`05HUQ
M_#OP<A*+#H7)= ?_T:&L0P`0@^X$Z^I0_Q54, `0 at R6L0P`0`%E>:@%8P at P`
M58OL4XM="%:+=0Q7BWT0A?9U"8,]H$,`$ #K)H/^`70%@_X"=2*AL$,`$(7 
M= E75E/_T(7 = Q75E/H%?___X7 =00SP.M.5U93Z%0```"#_@&)10QU#(7 
M=3=74%/H\?[__X7V= 6#_ at -U)E=64^C at _O__A<!U`R%%#(-]# !T$:&P0P`0
MA<!T"%=64__0B44,BT4,7UY;7<(,`,S_)4 P`!"#?"0(`743 at SVP0P`0`'4*
M_W0D!/\5`# `$&H!6,(,````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````\#0``.(T``#,- ``LC0``*0T``"2- ``@C0``'0T``!@- ``3C0``$ T
M```N- ``(C0````````2- ``"#0``/PS``#D,P``VC,``, at S``"^,P``MC,`
M`*PS````````BC,``'HS``!N,P``7#,``% S```^,P``*C,``" S```2,P``
M`C,``/0R``#F,@``UC(``,HR``"\,@``K#(``)8R``"",@``<#(``&0R``!0
M,@``-#(``" R```0,@``!#(````````````````````````?QG]$``````(`
M```[``````````!@``"<,0````````````":,P``8# ``'0Q````````````
M`/ S```X, ``/#$`````````````##4````P````````````````````````
M`````/ T``#B- ``S#0``+(T``"D- ``DC0``((T``!T- ``8#0``$XT``! 
M- ``+C0``"(T````````$C0```@T``#\,P``Y#,``-HS``#(,P``OC,``+8S
M``"L,P```````(HS``!Z,P``;C,``%PS``!0,P``/C,``"HS```@,P``$C,`
M``(S``#T,@``YC(``-8R``#*,@``O#(``*PR``"6,@``@C(``' R``!D,@``
M4#(``#0R```@,@``$#(```0R````````)0)R8E]R86ES90``" %R8E]E07)G
M17)R;W(``!H!<F)?95-T86YD87)D17)R;W(`^0!R8E]D969I;F5?;6]D=6QE
M7V9U;F-T:6]N`/@`<F)?9&5F:6YE7VUO9'5L90``(@%R8E]E;G-U<F4``0-R
M8E]Y:65L9%]S<&QA= ``E0!R8E]B;&]C:U]G:79E;E]P``!\`G)B7W-T<FEN
M9U]V86QU95]P='(`1 )R8E]S8V%N7V%R9W,``$\!<F)?9G5N8V%L; ``A0%R
M8E]I;G1E<FX`MP)R8E]U:6YT,FEN=6T``&X`<F)?87)Y7W!U<V@`:0!R8E]A
M<GE?;F5W,@!*`W)U8GE?>&UA;&QO8P``C@%R8E]I;U]C;&]S90"B`')B7V-)
M3P``%@%R8E]E4G5N=&EM945R<F]R```Q`W)U8GE?<V%F95]L979E; #I`7)B
M7VYE=V]B:@"Q`7)B7VQA<W1?<W1A='5S``"K`7)B7VEV7W-E= #W`7)B7V]B
M:E]A;&QO8P``% )R8E]P871H,F-L87-S`&US=F-R="UR=6)Y,3 at N9&QL`,$"
M<W1R;F-P>0!>`F9R964``-<`7V9D;W!E;@"(`5]O<&5N7V]S9FAA;F1L90"R
M`G-P<FEN=&8`P0%?<W1R:6-M< ``35-60U)4+F1L; ``#P%?:6YI='1E<FT`
MD0)M86QL;V,``)T`7V%D:G5S=%]F9&EV``#,`4QO8V%L1G)E90"O`$9O<FUA
M=$UE<W-A9V5!```;`$-L;W-E2&%N9&QE`&,`1'5P;&EC871E2&%N9&QE`/<`
M1V5T0W5R<F5N=%!R;V-E<W,`0P!#<F5A=&50:7!E```:`4=E=$QA<W1%<G)O
M<@``1 !#<F5A=&50<F]C97-S00``= %'971697)S:6]N```)`4=E=$5N=FER
M;VYM96YT5F%R:6%B;&5!``L!1V5T17AI=$-O9&50<F]C97-S``#O`4]P96Y0
M<F]C97-S`%T`1&ES86)L951H<F5A9$QI8G)A<GE#86QL<P!+15).14PS,BYD
M;&P````````````````?QG]$`````%(U```!`````0````$```!(-0``3#4`
M`% U``!0$0``6S4`````;W!E;C,N<V\`26YI=%]O<&5N,P``````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````$````:6QL96=A;"!A8V-E<W,@;6]D92 E
M<P``56YA8FQE('1O(&9O<FUA="!E<G)O<B!M97-S86=E``!P;W!E;C0``'!O
M<&5N,P``3W!E;C0```!/<&5N,P```'!O<&5N,R at I(&%R9R R(&UU<W0 at 8F4@
M)W0G(&]R("=B)P```#$R``!T````8VQO<V4```!C;&]S960_`$-L;W-E2&%N
M9&QE`'=B``!R8@``=P```'(```!#<F5A=&50:7!E``!$=7!L:6-A=&5(86YD
M;&4`0W)E871E4&EP92 at I($5R<F]R``!#86YN;W0@;&]C871E(&$@0T]-4U!%
M0R!E;G9I<F]N;65N="!V87)I86)L92!T;R!U<V4 at 87,@=&AE('-H96QL````
M`&YO="!S=7!P;W)T960@;VX@=&AI<R!P;&%T9F]R;0``)7,E<R5S``!C;VUM
M86YD+F-O;0!#3TU34$5#`" O8R `````<&ED`'-T871U<P``4')O8V5S<SHZ
M4W1A='5S````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````$ ``, $``$\P5##H,/8P_# 0,2(Q*#$U,3HQ5S%G,7DQ?C&1,98Q
MQS'8,4(R2#*),I(RGS*/,[@S&S0D-"DT031,-%,T831G-'DTC326-)PTM#2_
M-,8TU#3:-.PT`#4)-0\U)S4R-3DU1S5,-5XU<35X-8$UB#66-:HUOC72->8U
M^C5<-HPV$C=_-Z\W-3BB.-(X6#D0.ADZ'CHP.CDZ/CI0.EDZ7CJ?.OHZ`SL)
M.SH[0#N'.Y,[G3OV.P`\"CP//!X\)#R*/)@\SSS=//H\"CTV/4T]ASVR/<P]
MWCWL/?8]_#T"/@@^#CX4/AH^(#XF/BP^,CXX/CX^1#Y*/E ^5CY</F(^J3ZQ
M/K<^PC[//M<^Y3[J/N\^]#[_/@P_%C\K/S<_/3]?/W$_S3_J/_<_`" ```P`
M```$, ``````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````3D(Q, ````#FO7]$"0```$,Z7'=O<FM<=VEN,S(M;W!E;C-<;W!E
4;C,M:3,X-BUM<W=I;C,R+G!D8@``
`
end


From noreply at rubyforge.org  Thu Jun  1 23:13:14 2006
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  1 Jun 2006 23:13:14 -0400 (EDT)
Subject: [Win32utils-devel] [ win32utils-Patches-4603 ] [open3] set $? and
	return Process::Status with block call
Message-ID: <20060602031314.5BA653CC211@rubyforge.org>

Patches item #4603, was opened at 2006-05-29 14:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=413&aid=4603&group_id=85

Category: win32-open3
Group: Bug Fix
Status: Open
Resolution: None
Priority: 3
Submitted By: John-Mason Shackelford (jpshackelford)
Assigned to: Nobody (None)
Summary: [open3] set $? and return Process::Status with block call

Initial Comment:
This is another version Samuel Tesla's patch which sets $? and also returns the Process::Status when popen3/4 is called with a block (i.e. this patch merges changes from the two patches Samuel submitted).

Note that this implementation is not thread-safe. As the attachment will demonstrate.


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

>Comment By: Daniel Berger (djberg96)
Date: 2006-06-01 20:13

Message:
The patch looks good to me.  I'm not particularly worried about thread safety issues when it comes to running external programs, so I'm not going to worry about it.

I'll have Heesob take a look.

Thanks,

Dan

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

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

From noreply at rubyforge.org  Tue Jun  6 07:30:15 2006
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Jun 2006 07:30:15 -0400 (EDT)
Subject: [Win32utils-devel] [ win32utils-Feature Requests-4677 ] Interface
	to Windows registry
Message-ID: <20060606113015.63D003CC1DE@rubyforge.org>

Feature Requests item #4677, was opened at 2006-06-06 07:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=4677&group_id=85

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: Nobody (None)
Summary: Interface to Windows registry

Initial Comment:
Interface to Windows registry

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

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

From jpshack at gmail.com  Sun Jun 11 04:05:02 2006
From: jpshack at gmail.com (John-Mason P. Shackelford)
Date: Sun, 11 Jun 2006 03:05:02 -0500
Subject: [Win32utils-devel] Getting at MakeOpenFile
In-Reply-To: <000701c68602$988f1bd0$6d7ba8c0@2xnm9896kmqn5b9>
References: <39AA6550E5AA554AB1456707D6E5563D0259E6B0@QTOMAE2K3M01.AD.QINTRA.COM>
	<83f770ff0606011014i35fc4521heda6757b90260db4@mail.gmail.com>
	<447FAC4E.1010206@gmail.com>
	<000701c68602$988f1bd0$6d7ba8c0@2xnm9896kmqn5b9>
Message-ID: <83f770ff0606110105t65039ea2lf0919150c274fa@mail.gmail.com>

Heesob,

I have tried the attached open3.so and while it does not SEGFAULT
under 1.8.4 it also does not appear to have the patch applied for the
Process::Status return. I'd be very grateful for that as I cannot seem
to get my hands on a VC++ 6 compiler. I did a fresh compile of CVS
HEAD against VC++7 and OCI 1.8.2 and your patch appears to work fine
there. If you'll provide this I help see that it gets distributed to
others who need it.

Thanks very much,
-- 
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://pearsonedmeasurement.com

From phasis at gmail.com  Sun Jun 11 04:15:48 2006
From: phasis at gmail.com (Heesob Park)
Date: Sun, 11 Jun 2006 17:15:48 +0900
Subject: [Win32utils-devel] Getting at MakeOpenFile
In-Reply-To: <83f770ff0606110105t65039ea2lf0919150c274fa@mail.gmail.com>
References: <39AA6550E5AA554AB1456707D6E5563D0259E6B0@QTOMAE2K3M01.AD.QINTRA.COM>
	<83f770ff0606011014i35fc4521heda6757b90260db4@mail.gmail.com>
	<447FAC4E.1010206@gmail.com>
	<000701c68602$988f1bd0$6d7ba8c0@2xnm9896kmqn5b9>
	<83f770ff0606110105t65039ea2lf0919150c274fa@mail.gmail.com>
Message-ID: <aea95bc50606110115r77fd4eucad0abdb97a74748@mail.gmail.com>

Hi,

2006/6/11, John-Mason P. Shackelford <jpshack at gmail.com>:
> Heesob,
>
> I have tried the attached open3.so and while it does not SEGFAULT
> under 1.8.4 it also does not appear to have the patch applied for the
> Process::Status return. I'd be very grateful for that as I cannot seem
> to get my hands on a VC++ 6 compiler. I did a fresh compile of CVS
> HEAD against VC++7 and OCI 1.8.2 and your patch appears to work fine
> there. If you'll provide this I help see that it gets distributed to
> others who need it.
>
I'll attach the VC++6 compiled open3.so.
Also you can download it at
http://home.nownuri.net/~phasis/open3.so

> Thanks very much,
> --
> John-Mason Shackelford
>

Regards,

Park Heesob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: open3.so
Type: application/octet-stream
Size: 24635 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060611/8fb0cfeb/attachment-0001.so 

From jpshack at gmail.com  Mon Jun 12 12:22:01 2006
From: jpshack at gmail.com (John-Mason P. Shackelford)
Date: Mon, 12 Jun 2006 11:22:01 -0500
Subject: [Win32utils-devel] CVS layout question
Message-ID: <83f770ff0606120922p3d0ce34fx7d177532f65ce4c@mail.gmail.com>

I notice that open3 exists in both /win32utils/win32-open3/lib/win32
and /win32utils/win32-open3 and that there are recent commits in each
area. What is the intended difference between these two?

-- 
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://pearsonedmeasurement.com

From djberg96 at gmail.com  Mon Jun 12 12:28:11 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 12 Jun 2006 11:28:11 -0500
Subject: [Win32utils-devel] CVS layout question
In-Reply-To: <83f770ff0606120922p3d0ce34fx7d177532f65ce4c@mail.gmail.com>
References: <83f770ff0606120922p3d0ce34fx7d177532f65ce4c@mail.gmail.com>
Message-ID: <448D961B.7050309@gmail.com>

John-Mason P. Shackelford wrote:
> I notice that open3 exists in both /win32utils/win32-open3/lib/win32
> and /win32utils/win32-open3 and that there are recent commits in each
> area. What is the intended difference between these two?
> 

Once upon a time, in a galaxy far, far away, I thought it would be handy 
to create a win32utils toplevel cvs directory and put all the packages 
under there.  My thinking was that it would make packaging easier down 
the road.

However, it's mainly just annoyed me, so I've moved all the projects 
into their own project directory.  Thus, the toplevel projects are the 
most recent ones.  Once I've got everything moved up I'll have Tom 
delete the old directory.

Regards,

Dan

From noreply at rubyforge.org  Sun Jun 18 10:37:59 2006
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Jun 2006 10:37:59 -0400 (EDT)
Subject: [Win32utils-devel] [ win32utils-Patches-4603 ] [open3] set $? and
	return Process::Status with block call
Message-ID: <20060618143759.D41FD3CC1FE@rubyforge.org>

Patches item #4603, was opened at 2006-05-29 14:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=413&aid=4603&group_id=85

Category: win32-open3
Group: Bug Fix
Status: Open
Resolution: None
Priority: 3
Submitted By: John-Mason Shackelford (jpshackelford)
Assigned to: Nobody (None)
Summary: [open3] set $? and return Process::Status with block call

Initial Comment:
This is another version Samuel Tesla's patch which sets $? and also returns the Process::Status when popen3/4 is called with a block (i.e. this patch merges changes from the two patches Samuel submitted).

Note that this implementation is not thread-safe. As the attachment will demonstrate.


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

>Comment By: Daniel Berger (djberg96)
Date: 2006-06-18 07:37

Message:
Hi again,

After reading your post again I realized that $? is only set when the block form is used.  Is there any way to set $? when the non-block form is used?  What does the Unix variant do?

If that doesn't make sense, or is just too difficult, then I won't worry about it.  I thought I would ask, though.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2006-06-01 20:13

Message:
The patch looks good to me.  I'm not particularly worried about thread safety issues when it comes to running external programs, so I'm not going to worry about it.

I'll have Heesob take a look.

Thanks,

Dan

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

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

From djberg96 at gmail.com  Sun Jun 18 12:55:12 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 18 Jun 2006 10:55:12 -0600
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
Message-ID: <44958570.5010806@gmail.com>

Thoughts?

Dan
-------------- next part --------------
An embedded message was scrubbed...
From: "Patrick Hurley" <phurley at gmail.com>
Subject: Ruby Win32-Service
Date: Sun, 18 Jun 2006 12:46:01 -0400
Size: 2863
Url: http://rubyforge.org/pipermail/win32utils-devel/attachments/20060618/cc346796/attachment.eml 

From phurley at gmail.com  Sun Jun 18 13:18:31 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Sun, 18 Jun 2006 13:18:31 -0400
Subject: [Win32utils-devel] Win32-Service and threading
Message-ID: <554ac39c0606181018v400d0869ib3d35e58e1a02f3a@mail.gmail.com>

First off I just want to pass on a big thank you to everyone who has
worked on the win32 packages, they have helped me numerous times. But
(of course you knew it had
to be coming :-)...

I have just started doing some work with win32-service -- I was
creating a wrapper around it and daemon.rb, so I could write one body
of code that depending upon platform would provide a reasonable
interface for both windows and Unix platforms. During my testing I
noticed some odd behavior in my test program. Having written a couple
win32 services before I suspected some threading issues, so I did some
digging first just in Ruby using DL, I created a call to
GetCurrentThreadID and in logging I displayed the Current TID -- and
we are switching system threads in the ruby interpreter.

Looking at service.c, I see you are using RegisterServiceCtrlHandler,
there is no guarantee that it will be called from the main thread
(matter of fact it generally won't). In Service_Ctrl, you make an
rb_funcall using the call back hash, which then calls back into the
interpreter while the main thread is still running under mainloop.

My side effect was some scrambled ruby file handles and some pipe
closed on stopping errors. I would be happy to give back and fix this
issue, but wanted your input on how to proceed.

I have written a few extensions (primarily wrapping in house C/C++
libraries), but have never used ruby threads explicitly in an
extension previously. What I am considering is to create a ruby thread
and have it politely wait for messages in a queue. In Service_Ctrl,
just place entries in the queue. When a message arrives in the queue
have it make the call back (from the Ruby "green" thread).

If you think I am off my rocker and completely misunderstand the
problem, sorry for wasting your time :-); however, if you think I
understand the issue and would like me to take a stab at a patch,
please let me know if my approach sounds reasonable.

Thanks again for all your work
Patrick Hurley

From noreply at rubyforge.org  Sun Jun 18 13:07:52 2006
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Jun 2006 13:07:52 -0400 (EDT)
Subject: [Win32utils-devel] [ win32utils-Bugs-4598 ] possible wrong condition
Message-ID: <20060618170752.11FBD3CC215@rubyforge.org>

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

Category: win32-eventlog
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
Assigned to: Daniel Berger (djberg96)
Summary: possible wrong condition

Initial Comment:
Is this condition right?
(eventlog.rb, line 494

     if flags | EVENTLOG_SEEK_READ > 0
        offset = buf[8,4].unpack('L').first + 1
     end

To me it seems that it is always true as E_S_R == 2.
Maybe this is how it was meant:

     unless flags & EVENTLOG_SEEK_READ > 0

I haven't understood the rest of the code, so I'm not sure about the solution.

Jano Svitok

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

>Comment By: Daniel Berger (djberg96)
Date: 2006-06-18 10:07

Message:
Here was the final patch, applied to CVS:

if flags & EVENTLOG_BACKWARDS_READ > 0
   offset = buf[8,4].unpack('L').first - 1
else
   offset = buf[8,4].unpack('L').first + 1
end

This will be in the next release.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2006-05-29 10:38

Message:
Not only is the code wrong, some testing revealed that code was the source of another bug.  Specifically, a seek + backwards read would loop infinitely.

I believe this is the proper code:

if flags & EVENTLOG_SEEK_READ > 0
   if flags & EVENTLOG_FORWARDS_READ > 0
      offset = buf[8,4].unpack('L').first + 1
   else
      offset = buf[8,4].unpack('L').first - 1
   end
end

I'll add some more tests for this.  Many thanks for the report!

- Dan

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

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

From noreply at rubyforge.org  Sun Jun 18 13:08:14 2006
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Jun 2006 13:08:14 -0400 (EDT)
Subject: [Win32utils-devel] [ win32utils-Bugs-4598 ] possible wrong condition
Message-ID: <20060618170814.130363CC1E0@rubyforge.org>

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

Category: win32-eventlog
>Group: Code
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
Assigned to: Daniel Berger (djberg96)
Summary: possible wrong condition

Initial Comment:
Is this condition right?
(eventlog.rb, line 494

     if flags | EVENTLOG_SEEK_READ > 0
        offset = buf[8,4].unpack('L').first + 1
     end

To me it seems that it is always true as E_S_R == 2.
Maybe this is how it was meant:

     unless flags & EVENTLOG_SEEK_READ > 0

I haven't understood the rest of the code, so I'm not sure about the solution.

Jano Svitok

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

Comment By: Daniel Berger (djberg96)
Date: 2006-06-18 10:07

Message:
Here was the final patch, applied to CVS:

if flags & EVENTLOG_BACKWARDS_READ > 0
   offset = buf[8,4].unpack('L').first - 1
else
   offset = buf[8,4].unpack('L').first + 1
end

This will be in the next release.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2006-05-29 10:38

Message:
Not only is the code wrong, some testing revealed that code was the source of another bug.  Specifically, a seek + backwards read would loop infinitely.

I believe this is the proper code:

if flags & EVENTLOG_SEEK_READ > 0
   if flags & EVENTLOG_FORWARDS_READ > 0
      offset = buf[8,4].unpack('L').first + 1
   else
      offset = buf[8,4].unpack('L').first - 1
   end
end

I'll add some more tests for this.  Many thanks for the report!

- Dan

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

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

From noreply at rubyforge.org  Sun Jun 18 13:09:14 2006
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Jun 2006 13:09:14 -0400 (EDT)
Subject: [Win32utils-devel] [ win32utils-Bugs-4699 ] Service dependencies
	are not being created properly
Message-ID: <20060618170914.5FA043CC1E0@rubyforge.org>

Bugs item #4699, was opened at 2006-06-07 19:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=411&aid=4699&group_id=85

Category: win32-service
Group: Code
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Scott Harper (sharperct)
Assigned to: Park Heesob  (phasis68)
Summary: Service dependencies are not being created properly

Initial Comment:

# The service is being created but fails to start with a dependent service error
# when valid dependent services are being specified using
# s.dependencies = ["Tcpip", "Afd"]

# Sample code:

require 'win32/service'
Win32::Service::VERSION # => 0.5.0
svc = Win32::Service.new()

svc.create_service{ |s|
   s.service_name = "MyApache"
   s.display_name = "MyApacheSvc"
	 s.service_description = "My Apache Svc Description"
   s.binary_path_name = "C:\Apache\2.0.52\bin\Apache.exe -k runservice"
	 s.start_type = Win32::Service::AUTO_START
	 s.dependencies = ["Tcpip", "Afd"] # both are valid
}
svc.close

# REG_MULTI_SZ value created for DependOnService at
# HKLM\SYSTEM\CurrentControlSet\Services\MyApache:
# Tcpip
# ?

# Expected:
# Tcpip
# Afd


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

>Comment By: Daniel Berger (djberg96)
Date: 2006-06-18 10:09

Message:
As Heesob mentioned this was fixed in CVS.  Closing it out...

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2006-06-08 18:59

Message:
Thanks Heesob.  I'll put out an official release once I get back from Minnesota (I'm on a work trip atm).

Dan

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

Comment By: Scott Harper (sharperct)
Date: 2006-06-08 05:50

Message:
Park,

I wasn't able to obtain the binary from your URL but was
able to grab the latest from CVS and rebuild it locally. The
service dependencies are now being created properly.

Thanks for the quick turnaround on the fix.

   - Scott

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

Comment By: Park Heesob  (phasis68)
Date: 2006-06-07 22:49

Message:
Hi,

Bug Fixed in CVS version.
You can download binary file at
http://home.nownuri.net/~phasis/service.so

Thanks for reporting,

Park Heesob
 

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

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

From luislavena at gmail.com  Sun Jun 18 14:34:06 2006
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 18 Jun 2006 15:34:06 -0300
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
In-Reply-To: <44958570.5010806@gmail.com>
References: <44958570.5010806@gmail.com>
Message-ID: <71166b3b0606181134v53a39203x82a6849841226f2@mail.gmail.com>

On 6/18/06, Daniel Berger <djberg96 at gmail.com> wrote:
> Thoughts?

Dan,

I faced the same issue of the guy pointed out.

Calling the EventHash from other native thread (not the one where ruby
interpreter is running) trash everything. Worse is that the
interpreter is currently "looping" in service_main

As I understand the idea of Patrick, we could emulate the threading of
Service_Ctrl in a green thread, something that will not work quite
right without us pulling status in a regular basis.

The second suggestions sounds good, but is far from where I could
understand the impact of implementing that.

I was looking at ruby source (signal.c) and scratching the surface,
IN_MAIN_CONTEXT (which is alias for rb_w32_main_context) offered,
based on conjectures from Nobuyoshi Nakada, could offer some context
switch for the rub interpreter, but couldn't solve if the interpreter
is already running.

I could suggest this:

In Service_Ctrl, set the service status so service_main get the update
and could exit from it. and wait for event "ExitedFromServiceMain".

in the daemon_mainloop, after exiting rb_funcall "service_main",
signal the ExitedFromServiceMain so Service_Ctrl could call the
EventHash and don't trash the ruby interpreter. (Here we could
implemented as IN_MAIN_CONTEXT as a safe-net).

Then signal the EventStop and set the service status as STOPPED.

Hope the "workflow" sounds good, for me it does (but don't have time
to hack it currently now).

Regards,


-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

>
> ---------- Forwarded message ----------
> From: "Patrick Hurley" <phurley at gmail.com>
> To: "Daniel Berger" <djberg96 at gmail.com>
> Date: Sun, 18 Jun 2006 12:46:01 -0400
> Subject: Ruby Win32-Service
> First off I just want to pass on a big thank you, the wonderful win32
> packages have helped me numerous times. But (of course you knew it had
> to be coming :-)...
>
> I have just started doing some work with win32-service -- I was
> creating a wrapper around it and daemon.rb, so I could write one body
> of code that depending upon platform would provide a reasonable
> interface for both windows and Unix platforms. During my testing I
> noticed some odd behavior in my test program. Having written a couple
> win32 services before I suspected some threading issues, so I did some
> digging first just in Ruby using DL, I created a call to
> GetCurrentThreadID and in logging I displayed the Current TID -- and
> we are switching system threads in the ruby interpreter.
>
> Looking at service.c, I see you are using RegisterServiceCtrlHandler,
> there is no guarantee that it will be called from the main thread
> (matter of fact it generally won't). In Service_Ctrl, you make an
> rb_funcall using the call back hash, which then calls back into the
> interpreter while the main thread is still running under mainloop.
>
> My side effect was some scrambled ruby file handles and some pipe
> closed on stopping errors. I would be happy to give back and fix this
> issue, but wanted you input on how to proceed. I see two options:
>
> 1. Only send windows events from Service_Ctrl, and set status flags.
> On calls to status, I could actually call service_stop,
> service_paramchange, etc... This bypasses threading, but trades it for
> a cooperative multi-tasking setup.
>
> 2. (Which I prefer, but have never done before). In the extension
> create a ruby thread (green, not OS) which waits on a call back queue)
> and then have Service_Ctrl maintain that queue. This would ensure that
> the Ruby interpreter only runs in one thread - but does involve mixing
> in ruby threading.
>
> If you think I am off my rocker and completely misunderstand the
> problem, sorry for wasting your time :-); however, if you think I
> understand the issue and would like me to take a stab at a patch,
> please let me know.
>
> Thanks again for all your work
> Patrick Hurley
>
>
>
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
>

From phurley at gmail.com  Sun Jun 18 20:17:41 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Sun, 18 Jun 2006 20:17:41 -0400
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
In-Reply-To: <71166b3b0606181134v53a39203x82a6849841226f2@mail.gmail.com>
References: <44958570.5010806@gmail.com>
	<71166b3b0606181134v53a39203x82a6849841226f2@mail.gmail.com>
Message-ID: <554ac39c0606181717v62e7b49eqce570261198fbc03@mail.gmail.com>

On 6/18/06, Luis Lavena <luislavena at gmail.com> wrote:
> I faced the same issue of the guy pointed out.
>
> Calling the EventHash from other native thread (not the one where ruby
> interpreter is running) trash everything. Worse is that the
> interpreter is currently "looping" in service_main

Exactly, ok so I am not off my rocker :-)


> As I understand the idea of Patrick, we could emulate the threading of
> Service_Ctrl in a green thread, something that will not work quite
> right without us pulling status in a regular basis.

Since I am going to use this for work, I can spend some paid time
tomorrow following up. I went through the C extension docs and it
looks pretty easy to create a green thread attached to an actual C
function. So my plan is as follows:

1. Create a Win32 Semaphore and mutex, that mirrors a simple list of
events (e.g. param change, stop, pause, etc).

2. In ServiceCtrl when ever a ruby call back is required: I will lock
the mutex, place an item in the list, increment the semaphor and
release the mutex.

3. In a green thread I will be waiting on the semaphor -- I am not
sure if this will block ruby's green threads if it does I will have to
spin against the semaphor and a ruby sleep -- ugly, but very doable.

4. When events arrive in the list, I will make the call back into the
main class -- this will occur in the same system thread, but a
different "ruby thread".

The only thing I am unsure of is #3, If a Ruby thread blocks on a
Win32 object, I think it will hang ruby -- if anyone has any
experience with this I would love to hear it -- otherwise I may spend
some time looking through the Ruby source to see if there is an
internal to allow waiting without the spin.

Thanks
pth

From phasis at gmail.com  Sun Jun 18 20:41:48 2006
From: phasis at gmail.com (Heesob Park)
Date: Mon, 19 Jun 2006 09:41:48 +0900
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
In-Reply-To: <554ac39c0606181717v62e7b49eqce570261198fbc03@mail.gmail.com>
References: <44958570.5010806@gmail.com>
	<71166b3b0606181134v53a39203x82a6849841226f2@mail.gmail.com>
	<554ac39c0606181717v62e7b49eqce570261198fbc03@mail.gmail.com>
Message-ID: <aea95bc50606181741y746b3d2av519249bef8792708@mail.gmail.com>

Hi,

2006/6/19, Patrick Hurley <phurley at gmail.com>:
> On 6/18/06, Luis Lavena <luislavena at gmail.com> wrote:
> > I faced the same issue of the guy pointed out.
> >
> > Calling the EventHash from other native thread (not the one where ruby
> > interpreter is running) trash everything. Worse is that the
> > interpreter is currently "looping" in service_main
>
> Exactly, ok so I am not off my rocker :-)
>
As you know, using native thread is not recommended in the current ruby version.

>
> > As I understand the idea of Patrick, we could emulate the threading of
> > Service_Ctrl in a green thread, something that will not work quite
> > right without us pulling status in a regular basis.
>
> Since I am going to use this for work, I can spend some paid time
> tomorrow following up. I went through the C extension docs and it
> looks pretty easy to create a green thread attached to an actual C
> function. So my plan is as follows:
>
> 1. Create a Win32 Semaphore and mutex, that mirrors a simple list of
> events (e.g. param change, stop, pause, etc).
>
> 2. In ServiceCtrl when ever a ruby call back is required: I will lock
> the mutex, place an item in the list, increment the semaphor and
> release the mutex.
>
> 3. In a green thread I will be waiting on the semaphor -- I am not
> sure if this will block ruby's green threads if it does I will have to
> spin against the semaphor and a ruby sleep -- ugly, but very doable.
>
> 4. When events arrive in the list, I will make the call back into the
> main class -- this will occur in the same system thread, but a
> different "ruby thread".
>
> The only thing I am unsure of is #3, If a Ruby thread blocks on a
> Win32 object, I think it will hang ruby -- if anyone has any
> experience with this I would love to hear it -- otherwise I may spend
> some time looking through the Ruby source to see if there is an
> internal to allow waiting without the spin.
>
Although all the above might be possible, it will not work with
SCM(Service Control Manager). Thus you must call
"StartServiceCtrlDispatcher" API to connect with the SCM.
The main problem is "StartServiceCtrlDispatcher" blocks and returns
only when the serivce has terminated.
If you can make StartServiceCtrlDispatcher nonblocking, I guess there
is no problem at all.

Regards,

Park Heesob

From phurley at gmail.com  Sun Jun 18 21:27:14 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Sun, 18 Jun 2006 21:27:14 -0400
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
In-Reply-To: <aea95bc50606181741y746b3d2av519249bef8792708@mail.gmail.com>
References: <44958570.5010806@gmail.com>
	<71166b3b0606181134v53a39203x82a6849841226f2@mail.gmail.com>
	<554ac39c0606181717v62e7b49eqce570261198fbc03@mail.gmail.com>
	<aea95bc50606181741y746b3d2av519249bef8792708@mail.gmail.com>
Message-ID: <554ac39c0606181827k566aae56gcef2d16d1333d28@mail.gmail.com>

On 6/18/06, Heesob Park <phasis at gmail.com> wrote:
> As you know, using native thread is not recommended in the current ruby version.

True, but it is safe to use native threads as long as they don't call
any ruby functions. So my thought was use a native thread to deal with
the blocked StartServiceCtrlDispatcher, but do some sort of ugly spin
in a green ruby thread (unless I can find a better way to interface to
the native thread).

I have dealt with other non-thread safe libraries using similar
techniques in services with a fair degree of success in the past (but
admittedly never with Ruby).

I will give it a try tomorrow and let you know how it goes, if it goes
well, I will provide a patch.

Thanks
pth

From phasis at gmail.com  Sun Jun 18 21:36:56 2006
From: phasis at gmail.com (Heesob Park)
Date: Mon, 19 Jun 2006 10:36:56 +0900
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
In-Reply-To: <554ac39c0606181827k566aae56gcef2d16d1333d28@mail.gmail.com>
References: <44958570.5010806@gmail.com>
	<71166b3b0606181134v53a39203x82a6849841226f2@mail.gmail.com>
	<554ac39c0606181717v62e7b49eqce570261198fbc03@mail.gmail.com>
	<aea95bc50606181741y746b3d2av519249bef8792708@mail.gmail.com>
	<554ac39c0606181827k566aae56gcef2d16d1333d28@mail.gmail.com>
Message-ID: <aea95bc50606181836g4c0bcdbq5d2be0dab4ce5bb2@mail.gmail.com>

2006/6/19, Patrick Hurley <phurley at gmail.com>:
> On 6/18/06, Heesob Park <phasis at gmail.com> wrote:
> > As you know, using native thread is not recommended in the current ruby version.
>
> True, but it is safe to use native threads as long as they don't call
> any ruby functions. So my thought was use a native thread to deal with
> the blocked StartServiceCtrlDispatcher, but do some sort of ugly spin
> in a green ruby thread (unless I can find a better way to interface to
> the native thread).
>
That is just the current win32-service implementation.
When the green ruby thread sleeps, all native threads blocked. and
StartServiceCtrlDispatcher can't accept the service control event.

> I have dealt with other non-thread safe libraries using similar
> techniques in services with a fair degree of success in the past (but
> admittedly never with Ruby).
>
> I will give it a try tomorrow and let you know how it goes, if it goes
> well, I will provide a patch.
>
I hope you will make a good patch.

Thanks
Park Heesob

From djberg96 at gmail.com  Mon Jun 19 05:45:42 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 19 Jun 2006 03:45:42 -0600
Subject: [Win32utils-devel] win32-service cvs - potential issue with
	Service.services
Message-ID: <44967246.7020100@gmail.com>

Hi all,

I'm preparing win32-service for an 0.5.1 release.  I've made a couple 
minor changes and altered the test suite a bit.  It passes on my box 
here, except that about half the time I get this error:

1) Error:
test_services(TC_Win32Service):
Win32::ServiceError: OpenService() call failed: The handle is invalid.
    test/tc_service.rb:227:in `services'
    test/tc_service.rb:227:in `test_services'

45 tests, 145 assertions, 0 failures, 1 errors

If I run this test by itself via -n test_services, it always passes.  Is 
this just an issue with interaction with Test::Unit itself?  Or am I 
leaving a filehandle open somewhere that I've missed?

I'm not going to sweat it too much, but I thought I would ask for 
another pair of eyes.

Regards,

Dan

From phasis at gmail.com  Mon Jun 19 08:17:46 2006
From: phasis at gmail.com (Heesob Park)
Date: Mon, 19 Jun 2006 21:17:46 +0900
Subject: [Win32utils-devel] win32-service cvs - potential issue with
	Service.services
In-Reply-To: <44967246.7020100@gmail.com>
References: <44967246.7020100@gmail.com>
Message-ID: <aea95bc50606190517l12ce97d9o54614eefde288e5f@mail.gmail.com>

Hi,

2006/6/19, Daniel Berger <djberg96 at gmail.com>:
> Hi all,
>
> I'm preparing win32-service for an 0.5.1 release.  I've made a couple
> minor changes and altered the test suite a bit.  It passes on my box
> here, except that about half the time I get this error:
>
> 1) Error:
> test_services(TC_Win32Service):
> Win32::ServiceError: OpenService() call failed: The handle is invalid.
>    test/tc_service.rb:227:in `services'
>    test/tc_service.rb:227:in `test_services'
>
> 45 tests, 145 assertions, 0 failures, 1 errors
>
> If I run this test by itself via -n test_services, it always passes.  Is
> this just an issue with interaction with Test::Unit itself?  Or am I
> leaving a filehandle open somewhere that I've missed?
>
I don't know why, but if I commented out the line #1082 of serivce.c like this:
//         CloseServiceHandle(hSCService);
 the test works without errors.

Regards,

Park Heesob

From john-mason at shackelford.org  Mon Jun 19 12:40:24 2006
From: john-mason at shackelford.org (John-Mason P. Shackelford)
Date: Mon, 19 Jun 2006 11:40:24 -0500
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
In-Reply-To: <44958570.5010806@gmail.com>
References: <44958570.5010806@gmail.com>
Message-ID: <83f770ff0606190940q5375946ey435920add9d523f6@mail.gmail.com>

Patrick,

> I have just started doing some work with win32-service -- I was
> creating a wrapper around it and daemon.rb, so I could write one body
> of code that depending upon platform would provide a reasonable
> interface for both windows and Unix platforms.

I am interested in this work and have been hoping to do something
similiar myself. On the *nix side I have been using the Daemons
library (available as a gem) with an API call like so:

# 1. Create a proc that launches the program you wish to daemonize:
proc = Proc.new do
  SomeClassOfYours.start
end

# 2. Configure (most of this is optional)
options = {
             :app_name   => "myd",
             :dir_mode   => :normal,
             :dir        => config.pid_dir,
             :multiple   => false,
             :ontop      => false,
             :backtrace  => true,
             :log_output => true,
             :monitor    => true,
             :mode       => :proc,
             :proc       => proc
           }

# 3. Create the Daemon process, etc.
controller = Daemons::Controller.new(options, ARGV)
controller.catch_exceptions do
  controller.run
end

In additon to daemonizing the supplied proc this creates a complete
init script with start, stop, restart, and status commands and handles
PID file management, etc. See http://daemons.rubyforge.org/.

But like you I'd like to be able abstract this and creation of the
win32 service away from developer so that we can using a single simple
API that will work across platforms. For the sake of the cross
platform support I'd happily trade some configurability and
flexability (at least in the short run) in the spirit of POpen4
(http://popen4.rubyforge.org/).

If you are interested in working together on this drop me a line.
-- 
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://pearsonedmeasurement.com

From jpshack at gmail.com  Mon Jun 19 12:41:06 2006
From: jpshack at gmail.com (John-Mason P. Shackelford)
Date: Mon, 19 Jun 2006 11:41:06 -0500
Subject: [Win32utils-devel] [Fwd: Ruby Win32-Service]
In-Reply-To: <44958570.5010806@gmail.com>
References: <44958570.5010806@gmail.com>
Message-ID: <83f770ff0606190941h652c683dqba666835eb8b53c7@mail.gmail.com>

Patrick,

> I have just started doing some work with win32-service -- I was
> creating a wrapper around it and daemon.rb, so I could write one body
> of code that depending upon platform would provide a reasonable
> interface for both windows and Unix platforms.

I am interested in this work and have been hoping to do something
similiar myself. On the *nix side I have been using the Daemons
library (available as a gem) with an API call like so:

# 1. Create a proc that launches the program you wish to daemonize:
proc = Proc.new do
 SomeClassOfYours.start
end

# 2. Configure (most of this is optional)
options = {
            :app_name   => "myd",
            :dir_mode   => :normal,
            :dir        => config.pid_dir,
            :multiple   => false,
            :ontop      => false,
            :backtrace  => true,
            :log_output => true,
            :monitor    => true,
            :mode       => :proc,
            :proc       => proc
          }

# 3. Create the Daemon process, etc.
controller = Daemons::Controller.new(options, ARGV)
controller.catch_exceptions do
 controller.run
end

In additon to daemonizing the supplied proc this creates a complete
init script with start, stop, restart, and status commands and handles
PID file management, etc. See http://daemons.rubyforge.org/.

But like you I'd like to be able abstract this and creation of the
win32 service away from developer so that we can using a single simple
API that will work across platforms. For the sake of the cross
platform support I'd happily trade some configurability and
flexability (at least in the short run) in the spirit of POpen4
(http://popen4.rubyforge.org/).

If you are interested in working together on this drop me a line.
--
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://pearsonedmeasurement.com

From phurley at gmail.com  Mon Jun 19 15:23:54 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Mon, 19 Jun 2006 15:23:54 -0400
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
References: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
Message-ID: <554ac39c0606191223r6204626fld416e6ba96441fe7@mail.gmail.com>

This is a second post of this message -- service.c was too big and
caused the list to bounce it. Attached is a patch and my service.c.bz2
if there is any difficulty
applying the patch. I did the following:

1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a
simple integer value (protected by a critical section). I was worried
this would be "expensive"; however, I found the rb_thread_polling
method and it seems to work well.

2. When an event occurs in Service_Ctrl it sets the flag value.

3. If Ruby_Service_Ctrl finds an entry in the call back hash it
invokes it (in its own thread) and goes back to polling

4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally
and then begins to exit, but it first waits for all previously spun
threads to return.

5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that
all threads are stopped before stopping the service (it continues to
update service status politley).

That's it -- in my tests it works perfectly. If I made any fax paus in
my patch creation or summary please let me know.

Thanks again
pth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green_thread.patch
Type: application/octet-stream
Size: 4627 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/6dcb340c/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: service.c.bz2
Type: application/x-bzip2
Size: 9650 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/6dcb340c/attachment-0001.bin 

From phurley at gmail.com  Mon Jun 19 12:30:48 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Mon, 19 Jun 2006 12:30:48 -0400
Subject: [Win32utils-devel] win32-service patch
Message-ID: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>

Attached is a patch and my service.c if there is any difficulty
applying the patch. I did the following:

1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a
simple integer value (protected by a critical section). I was worried
this would be "expensive"; however, I found the rb_thread_polling
method and it seems to work well.

2. When an event occurs in Service_Ctrl it sets the flag value.

3. If Ruby_Service_Ctrl finds an entry in the call back hash it
invokes it (in its own thread) and goes back to polling

4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally
and then begins to exit, but it first waits for all previously spun
threads to return.

5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that
all threads are stopped before stopping the service (it continues to
update service status politley).

That's it -- in my tests it works perfectly. If I made any fax paus in
my patch creation or summary please let me know.

Thanks again
pth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green_thread.patch
Type: application/octet-stream
Size: 4627 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/8cb30214/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: service.c
Type: application/octet-stream
Size: 57877 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/8cb30214/attachment-0003.obj 

From phasis at gmail.com  Mon Jun 19 21:18:57 2006
From: phasis at gmail.com (Heesob Park)
Date: Tue, 20 Jun 2006 10:18:57 +0900
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
References: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
Message-ID: <aea95bc50606191818k1ae1dcfcta1216087769e7dba@mail.gmail.com>

Hi,

2006/6/20, Patrick Hurley <phurley at gmail.com>:
> Attached is a patch and my service.c if there is any difficulty
> applying the patch. I did the following:
>
> 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a
> simple integer value (protected by a critical section). I was worried
> this would be "expensive"; however, I found the rb_thread_polling
> method and it seems to work well.
>
> 2. When an event occurs in Service_Ctrl it sets the flag value.
>
> 3. If Ruby_Service_Ctrl finds an entry in the call back hash it
> invokes it (in its own thread) and goes back to polling
>
> 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally
> and then begins to exit, but it first waits for all previously spun
> threads to return.
>
> 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that
> all threads are stopped before stopping the service (it continues to
> update service status politley).
>
> That's it -- in my tests it works perfectly. If I made any fax paus in
> my patch creation or summary please let me know.
>
> Thanks again
> pth
>
That is a really good pacth!
I confirmed the patch works perfectly.

Thanks,

Park Heesob

From djberg96 at gmail.com  Mon Jun 19 21:23:05 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 19 Jun 2006 19:23:05 -0600
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
References: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
Message-ID: <44974DF9.7050102@gmail.com>

Patrick Hurley wrote:
> Attached is a patch and my service.c if there is any difficulty
> applying the patch. I did the following:
>
> 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a
> simple integer value (protected by a critical section). I was worried
> this would be "expensive"; however, I found the rb_thread_polling
> method and it seems to work well.
>
> 2. When an event occurs in Service_Ctrl it sets the flag value.
>
> 3. If Ruby_Service_Ctrl finds an entry in the call back hash it
> invokes it (in its own thread) and goes back to polling
>
> 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally
> and then begins to exit, but it first waits for all previously spun
> threads to return.
>
> 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that
> all threads are stopped before stopping the service (it continues to
> update service status politley).
>
> That's it -- in my tests it works perfectly. If I made any fax paus in
> my patch creation or summary please let me know.
>
> Thanks again
> pth
> ------------------------------------------------------------------------
>
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
Many thanks Patrick, we'll take a look.  In the meantime I'm going to 
release 0.5.1 (tonight).  Assuming everything looks good with your 
patch, I'm going to save it for 0.5.2.

Regards,

Dan

PS - Sorry for the late approval on this message - I was at work.

From djberg96 at gmail.com  Mon Jun 19 21:34:13 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 19 Jun 2006 19:34:13 -0600
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <aea95bc50606191818k1ae1dcfcta1216087769e7dba@mail.gmail.com>
References: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
	<aea95bc50606191818k1ae1dcfcta1216087769e7dba@mail.gmail.com>
Message-ID: <44975095.7070300@gmail.com>

Heesob Park wrote:
> Hi,
>
> 2006/6/20, Patrick Hurley <phurley at gmail.com>:
>   
>> Attached is a patch and my service.c if there is any difficulty
>> applying the patch. I did the following:
>>
>> 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a
>> simple integer value (protected by a critical section). I was worried
>> this would be "expensive"; however, I found the rb_thread_polling
>> method and it seems to work well.
>>
>> 2. When an event occurs in Service_Ctrl it sets the flag value.
>>
>> 3. If Ruby_Service_Ctrl finds an entry in the call back hash it
>> invokes it (in its own thread) and goes back to polling
>>
>> 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally
>> and then begins to exit, but it first waits for all previously spun
>> threads to return.
>>
>> 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that
>> all threads are stopped before stopping the service (it continues to
>> update service status politley).
>>
>> That's it -- in my tests it works perfectly. If I made any fax paus in
>> my patch creation or summary please let me know.
>>
>> Thanks again
>> pth
>>
>>     
> That is a really good pacth!
> I confirmed the patch works perfectly.
>
> Thanks,
>
> Park Heesob
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
>   
Cool.  The mission of the people on this list, should you choose to 
accept it, is to try your best to break it.

I'd also like to get some feedback from the Mongrel folks (Luis?), since 
they seem to be one of the major users/stress testers.

Regards,

Dan

From djberg96 at gmail.com  Mon Jun 19 21:51:49 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 19 Jun 2006 19:51:49 -0600
Subject: [Win32utils-devel] win32-service cvs - potential issue
	with	Service.services
In-Reply-To: <aea95bc50606190517l12ce97d9o54614eefde288e5f@mail.gmail.com>
References: <44967246.7020100@gmail.com>
	<aea95bc50606190517l12ce97d9o54614eefde288e5f@mail.gmail.com>
Message-ID: <449754B5.9060103@gmail.com>

Heesob Park wrote:
> Hi,
>
> 2006/6/19, Daniel Berger <djberg96 at gmail.com>:
>   
>> Hi all,
>>
>> I'm preparing win32-service for an 0.5.1 release.  I've made a couple
>> minor changes and altered the test suite a bit.  It passes on my box
>> here, except that about half the time I get this error:
>>
>> 1) Error:
>> test_services(TC_Win32Service):
>> Win32::ServiceError: OpenService() call failed: The handle is invalid.
>>    test/tc_service.rb:227:in `services'
>>    test/tc_service.rb:227:in `test_services'
>>
>> 45 tests, 145 assertions, 0 failures, 1 errors
>>
>> If I run this test by itself via -n test_services, it always passes.  Is
>> this just an issue with interaction with Test::Unit itself?  Or am I
>> leaving a filehandle open somewhere that I've missed?
>>
>>     
> I don't know why, but if I commented out the line #1082 of serivce.c like this:
> //         CloseServiceHandle(hSCService);
>  the test works without errors.
>
> Regards,
>
> Park Heesob
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
>   
Hm....maybe this remark has something to do with it:

The *CloseServiceHandle* function does not destroy the service control 
manager object referred to by the handle. A service control manager 
object cannot be destroyed.

My guess is that it's related to Test::Unit's threading somehow.  I'm 
not going to worry about it for now.  Expect a release soon. :)

Regards,

Dan

From phurley at gmail.com  Mon Jun 19 22:15:02 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Mon, 19 Jun 2006 22:15:02 -0400
Subject: [Win32utils-devel] Portable Daemon
Message-ID: <554ac39c0606191915ye20510fs7f8d2ac9de77c60e@mail.gmail.com>

I am wrapping up work on a "PortableDaemon" gem. It is pure Ruby and
wraps win32-service and the daemons gems. Allowing users to write
against a common interface (pretty much the win32-service call back
structure).

Under Linux it captures a couple signals to support the service_stop
(TERM) and service_paramchange (USR1). It also adds a "run" feature to
the win32 implementation with _very_ simple support for debugging at
the console of the wrapped service.

It probably belongs in its own "project" as it is a Linux/Win32
wrapper and written in pure Ruby, but I don't want to step on any
toes, so if anyone feels it belongs as part of the win32 utils please
let me know. I am going to touch base with a few people on the
interface at RailsConf and then setup the gem.

If anyone wants the code (still rough, but working) or just has some
input please let me know.

Thanks
pth

From djberg96 at gmail.com  Mon Jun 19 22:27:40 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 19 Jun 2006 20:27:40 -0600
Subject: [Win32utils-devel] Portable Daemon
In-Reply-To: <554ac39c0606191915ye20510fs7f8d2ac9de77c60e@mail.gmail.com>
References: <554ac39c0606191915ye20510fs7f8d2ac9de77c60e@mail.gmail.com>
Message-ID: <44975D1C.8010104@gmail.com>

Patrick Hurley wrote:
> I am wrapping up work on a "PortableDaemon" gem. It is pure Ruby and
> wraps win32-service and the daemons gems. Allowing users to write
> against a common interface (pretty much the win32-service call back
> structure).
>
> Under Linux it captures a couple signals to support the service_stop
> (TERM) and service_paramchange (USR1). It also adds a "run" feature to
> the win32 implementation with _very_ simple support for debugging at
> the console of the wrapped service.
>
> It probably belongs in its own "project" as it is a Linux/Win32
> wrapper and written in pure Ruby, but I don't want to step on any
> toes, so if anyone feels it belongs as part of the win32 utils please
> let me know. I am going to touch base with a few people on the
> interface at RailsConf and then setup the gem.
>
> If anyone wants the code (still rough, but working) or just has some
> input please let me know.
>
> Thanks
> pth
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
>   
Cool.  No, it doesn't belong on win32-utils because, as you say, it's 
not win32 specific.  Even if it was, it's *your* library, and you can do 
with it as you please. :)

Just an FYI, I released win32-service 0.5.1 tonight.  Please take a look 
at the changes file.

Regards,

Dan

PS - I can help with Solaris testing next week.

From Daniel.Berger at qwest.com  Tue Jun 20 17:03:54 2006
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Tue, 20 Jun 2006 16:03:54 -0500
Subject: [Win32utils-devel] win32-service patch
Message-ID: <39AA6550E5AA554AB1456707D6E5563D0259E6CF@QTOMAE2K3M01.AD.QINTRA.COM>



> -----Original Message-----
> From: win32utils-devel-bounces at rubyforge.org 
> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of 
> Patrick Hurley
> Sent: Monday, June 19, 2006 10:31 AM
> To: Development and ideas for win32utils projects
> Subject: [Win32utils-devel] win32-service patch
> 
> 
> Attached is a patch and my service.c if there is any 
> difficulty applying the patch. I did the following:

<snip>

Do you want to rework this in light of Paul Brannan's suggestion to use
TRAP_BEG and TRAP_END or sem_wait?

In the meantime I should mention that I'd like to move the Service class
(not the Daemon class) over to a pure Ruby solution.

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 phurley at gmail.com  Tue Jun 20 17:45:34 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Tue, 20 Jun 2006 17:45:34 -0400
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <39AA6550E5AA554AB1456707D6E5563D0259E6CF@QTOMAE2K3M01.AD.QINTRA.COM>
References: <39AA6550E5AA554AB1456707D6E5563D0259E6CF@QTOMAE2K3M01.AD.QINTRA.COM>
Message-ID: <554ac39c0606201445v7a37330bgfa50e01931806589@mail.gmail.com>

On 6/20/06, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
>
>
> > -----Original Message-----
> > From: win32utils-devel-bounces at rubyforge.org
> > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of
> > Patrick Hurley
> > Sent: Monday, June 19, 2006 10:31 AM
> > To: Development and ideas for win32utils projects
> > Subject: [Win32utils-devel] win32-service patch
> >
> >
> > Attached is a patch and my service.c if there is any
> > difficulty applying the patch. I did the following:
>
> <snip>
>
> Do you want to rework this in light of Paul Brannan's suggestion to use
> TRAP_BEG and TRAP_END or sem_wait?
>
> In the meantime I should mention that I'd like to move the Service class
> (not the Daemon class) over to a pure Ruby solution.
>
> 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.
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>

The existing solution works and I do not think (although I would love
to find out I am wrong), TRAP_BEG/TRAP_END are magical enough to make
this easy. So I would say put it in as soon as it makes sense as it
fixes easy to reproduce bugs.

If I/we can develop a better solution it can be put in later -- I
personally need to do more testing before I trust threaded code using
an API that is undocumented (except in the source, which does not look
like it does anything more than prevent signals).

As for seperating service from daemon -- that makes a lot of sense it
is a little confusing as implemented -- at least partially because the
docs are describing two completely different types of functionality.

pth

From djberg96 at gmail.com  Wed Jun 21 01:06:49 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Tue, 20 Jun 2006 23:06:49 -0600
Subject: [Win32utils-devel] Yet another data structure + pack/unpack
	question (win32-service)
Message-ID: <4498D3E9.80007@gmail.com>

Hi all,

If you take a look at the service.rb file in the win32-service 
repository (the new one in the toplevel repository path), I've got this 
bit of code, which succeeds, but I can't seem to unpack the data 
structure properly.  Did I pack it wrong to begin with?  I should know 
this but I'm spacing out.

proc_status       = [0,0,0,0,0,0,0,0,0,0].pack('LLLLLLLLLL')
enum_service      = [0.chr, 0.chr].pack('pp') + proc_status
service_buf       = enum_service * 1000
bytes_needed      = [0].pack('L')
services_returned = [0].pack('L')
resume_handle     = [0].pack('L')

bool = EnumServicesStatusEx(
   handle_scm,
   SC_ENUM_PROCESS_INFO,
   SERVICE_WIN32 | SERVICE_DRIVER,
   SERVICE_STATE_ALL,
   service_buf,
   service_buf.size,
   bytes_needed,
   services_returned,
   resume_handle,
   group
)

if bool
   num_services = services_returned.unpack('L').first
   index = 0

   1.upto(num_services){ |num|
      info = service_buf[index, enum_service.size-1]
      service_name = info[0,4].pack('p') # boom!
      index += enum_service.size
   }
end

Regards,

Dan

From phasis at gmail.com  Wed Jun 21 01:59:53 2006
From: phasis at gmail.com (Heesob Park)
Date: Wed, 21 Jun 2006 14:59:53 +0900
Subject: [Win32utils-devel] Yet another data structure + pack/unpack
	question (win32-service)
In-Reply-To: <4498D3E9.80007@gmail.com>
References: <4498D3E9.80007@gmail.com>
Message-ID: <aea95bc50606202259g2d64e9e3k8f38fee7e44e0f85@mail.gmail.com>

Hi,

2006/6/21, Daniel Berger <djberg96 at gmail.com>:
> Hi all,
>
> If you take a look at the service.rb file in the win32-service
> repository (the new one in the toplevel repository path), I've got this
> bit of code, which succeeds, but I can't seem to unpack the data
> structure properly.  Did I pack it wrong to begin with?  I should know
> this but I'm spacing out.
>
> proc_status       = [0,0,0,0,0,0,0,0,0,0].pack('LLLLLLLLLL')
> enum_service      = [0.chr, 0.chr].pack('pp') + proc_status
> service_buf       = enum_service * 1000
> bytes_needed      = [0].pack('L')
> services_returned = [0].pack('L')
> resume_handle     = [0].pack('L')
>
> bool = EnumServicesStatusEx(
>   handle_scm,
>   SC_ENUM_PROCESS_INFO,
>   SERVICE_WIN32 | SERVICE_DRIVER,
>   SERVICE_STATE_ALL,
>   service_buf,
>   service_buf.size,
>   bytes_needed,
>   services_returned,
>   resume_handle,
>   group
> )
>
> if bool
>   num_services = services_returned.unpack('L').first
>   index = 0
>
>   1.upto(num_services){ |num|
>      info = service_buf[index, enum_service.size-1]
>      service_name = info[0,4].pack('p') # boom!
>      index += enum_service.size
>   }
> end
>
I guess you still don't understand the difference of C pointer and
ruby buffer :)

Try this:

Strcpy  = Win32API.new('msvcrt', 'strcpy', 'PL', 'L')

 1.upto(num_services){ |num|
     info = service_buf[index, enum_service.size-1]
     service_name = 0.chr * 256
     Strcpy.call(service_name,info[0,4].unpack('L').first)
     service_name = service_name.strip
     index += enum_service.size
  }

But, the code still segfault for another bug.

Regards,

Park Heesob

From phasis at gmail.com  Wed Jun 21 02:12:36 2006
From: phasis at gmail.com (Heesob Park)
Date: Wed, 21 Jun 2006 15:12:36 +0900
Subject: [Win32utils-devel] Yet another data structure + pack/unpack
	question (win32-service)
In-Reply-To: <aea95bc50606202259g2d64e9e3k8f38fee7e44e0f85@mail.gmail.com>
References: <4498D3E9.80007@gmail.com>
	<aea95bc50606202259g2d64e9e3k8f38fee7e44e0f85@mail.gmail.com>
Message-ID: <aea95bc50606202312g46238b12j49795d3ad28d4609@mail.gmail.com>

2006/6/21, Heesob Park <phasis at gmail.com>:
> Hi,
>
> 2006/6/21, Daniel Berger <djberg96 at gmail.com>:
> > Hi all,
> >
> > If you take a look at the service.rb file in the win32-service
> > repository (the new one in the toplevel repository path), I've got this
> > bit of code, which succeeds, but I can't seem to unpack the data
> > structure properly.  Did I pack it wrong to begin with?  I should know
> > this but I'm spacing out.
> >
> > proc_status       = [0,0,0,0,0,0,0,0,0,0].pack('LLLLLLLLLL')
> > enum_service      = [0.chr, 0.chr].pack('pp') + proc_status
> > service_buf       = enum_service * 1000
> > bytes_needed      = [0].pack('L')
> > services_returned = [0].pack('L')
> > resume_handle     = [0].pack('L')
> >
> > bool = EnumServicesStatusEx(
> >   handle_scm,
> >   SC_ENUM_PROCESS_INFO,
> >   SERVICE_WIN32 | SERVICE_DRIVER,
> >   SERVICE_STATE_ALL,
> >   service_buf,
> >   service_buf.size,
> >   bytes_needed,
> >   services_returned,
> >   resume_handle,
> >   group
> > )
> >
> > if bool
> >   num_services = services_returned.unpack('L').first
> >   index = 0
> >
> >   1.upto(num_services){ |num|
> >      info = service_buf[index, enum_service.size-1]
> >      service_name = info[0,4].pack('p') # boom!
> >      index += enum_service.size
> >   }
> > end
> >
> I guess you still don't understand the difference of C pointer and
> ruby buffer :)
>
> Try this:
>
> Strcpy  = Win32API.new('msvcrt', 'strcpy', 'PL', 'L')
>
>  1.upto(num_services){ |num|
>     info = service_buf[index, enum_service.size-1]
>     service_name = 0.chr * 256
>     Strcpy.call(service_name,info[0,4].unpack('L').first)
>     service_name = service_name.strip
>     index += enum_service.size
>  }
>
> But, the code still segfault for another bug.
>
And I found the bug.

proc_status       = [0,0,0,0,0,0,0,0,0,0].pack('LLLLLLLLLL')
should be
proc_status       = [0,0,0,0,0,0,0,0,0].pack('LLLLLLLLL')

Regards,

Park Heesob

From djberg96 at gmail.com  Wed Jun 21 08:48:59 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Wed, 21 Jun 2006 06:48:59 -0600
Subject: [Win32utils-devel] Yet another data structure +
 pack/unpack	question (win32-service)
In-Reply-To: <aea95bc50606202259g2d64e9e3k8f38fee7e44e0f85@mail.gmail.com>
References: <4498D3E9.80007@gmail.com>
	<aea95bc50606202259g2d64e9e3k8f38fee7e44e0f85@mail.gmail.com>
Message-ID: <4499403B.6060104@gmail.com>

Heesob Park wrote:
> Hi,
>
> 2006/6/21, Daniel Berger <djberg96 at gmail.com>:
>   
>> Hi all,
>>
>> If you take a look at the service.rb file in the win32-service
>> repository (the new one in the toplevel repository path), I've got this
>> bit of code, which succeeds, but I can't seem to unpack the data
>> structure properly.  Did I pack it wrong to begin with?  I should know
>> this but I'm spacing out.
>>
>> proc_status       = [0,0,0,0,0,0,0,0,0,0].pack('LLLLLLLLLL')
>> enum_service      = [0.chr, 0.chr].pack('pp') + proc_status
>> service_buf       = enum_service * 1000
>> bytes_needed      = [0].pack('L')
>> services_returned = [0].pack('L')
>> resume_handle     = [0].pack('L')
>>
>> bool = EnumServicesStatusEx(
>>   handle_scm,
>>   SC_ENUM_PROCESS_INFO,
>>   SERVICE_WIN32 | SERVICE_DRIVER,
>>   SERVICE_STATE_ALL,
>>   service_buf,
>>   service_buf.size,
>>   bytes_needed,
>>   services_returned,
>>   resume_handle,
>>   group
>> )
>>
>> if bool
>>   num_services = services_returned.unpack('L').first
>>   index = 0
>>
>>   1.upto(num_services){ |num|
>>      info = service_buf[index, enum_service.size-1]
>>      service_name = info[0,4].pack('p') # boom!
>>      index += enum_service.size
>>   }
>> end
>>
>>     
> I guess you still don't understand the difference of C pointer and
> ruby buffer :)
>
> Try this:
>
> Strcpy  = Win32API.new('msvcrt', 'strcpy', 'PL', 'L')
>
>  1.upto(num_services){ |num|
>      info = service_buf[index, enum_service.size-1]
>      service_name = 0.chr * 256
>      Strcpy.call(service_name,info[0,4].unpack('L').first)
>      service_name = service_name.strip
>      index += enum_service.size
>   }
>
> But, the code still segfault for another bug.
>
> Regards,
>
> Park Heesob
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
>   
Ok, thanks.  I guess part of the reason I got confused as to why you 
can't do this:

irb(main):016:0> bar = 'hello'
=> "hello"
irb(main):017:0> bar.unpack("l").pack("l").unpack("p")
ArgumentError: no associated pointer

Is Ruby attaching some metadata to the string that can only be gotten to 
if it's packed with 'p'?  I mean, why can't you go from address to object?

Thanks,

Dan

From phasis at gmail.com  Wed Jun 21 09:21:55 2006
From: phasis at gmail.com (Heesob Park)
Date: Wed, 21 Jun 2006 22:21:55 +0900
Subject: [Win32utils-devel] Yet another data structure + pack/unpack
	question (win32-service)
In-Reply-To: <4499403B.6060104@gmail.com>
References: <4498D3E9.80007@gmail.com>
	<aea95bc50606202259g2d64e9e3k8f38fee7e44e0f85@mail.gmail.com>
	<4499403B.6060104@gmail.com>
Message-ID: <aea95bc50606210621od3d8378w49e06a4fb1f1b7c8@mail.gmail.com>

Hi,

2006/6/21, Daniel Berger <djberg96 at gmail.com>:
> Heesob Park wrote:
> > Hi,
> >
> > 2006/6/21, Daniel Berger <djberg96 at gmail.com>:
> >
> >> Hi all,
> >>
> >> If you take a look at the service.rb file in the win32-service
> >> repository (the new one in the toplevel repository path), I've got this
> >> bit of code, which succeeds, but I can't seem to unpack the data
> >> structure properly.  Did I pack it wrong to begin with?  I should know
> >> this but I'm spacing out.
> >>
> >> proc_status       = [0,0,0,0,0,0,0,0,0,0].pack('LLLLLLLLLL')
> >> enum_service      = [0.chr, 0.chr].pack('pp') + proc_status
> >> service_buf       = enum_service * 1000
> >> bytes_needed      = [0].pack('L')
> >> services_returned = [0].pack('L')
> >> resume_handle     = [0].pack('L')
> >>
> >> bool = EnumServicesStatusEx(
> >>   handle_scm,
> >>   SC_ENUM_PROCESS_INFO,
> >>   SERVICE_WIN32 | SERVICE_DRIVER,
> >>   SERVICE_STATE_ALL,
> >>   service_buf,
> >>   service_buf.size,
> >>   bytes_needed,
> >>   services_returned,
> >>   resume_handle,
> >>   group
> >> )
> >>
> >> if bool
> >>   num_services = services_returned.unpack('L').first
> >>   index = 0
> >>
> >>   1.upto(num_services){ |num|
> >>      info = service_buf[index, enum_service.size-1]
> >>      service_name = info[0,4].pack('p') # boom!
> >>      index += enum_service.size
> >>   }
> >> end
> >>
> >>
> > I guess you still don't understand the difference of C pointer and
> > ruby buffer :)
> >
> > Try this:
> >
> > Strcpy  = Win32API.new('msvcrt', 'strcpy', 'PL', 'L')
> >
> >  1.upto(num_services){ |num|
> >      info = service_buf[index, enum_service.size-1]
> >      service_name = 0.chr * 256
> >      Strcpy.call(service_name,info[0,4].unpack('L').first)
> >      service_name = service_name.strip
> >      index += enum_service.size
> >   }
> >
> > But, the code still segfault for another bug.
> >
> > Regards,
> >
> > Park Heesob
> > _______________________________________________
> > win32utils-devel mailing list
> > win32utils-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/win32utils-devel
> >
> >
> Ok, thanks.  I guess part of the reason I got confused as to why you
> can't do this:
>
> irb(main):016:0> bar = 'hello'
> => "hello"
> irb(main):017:0> bar.unpack("l").pack("l").unpack("p")
> ArgumentError: no associated pointer
>
> Is Ruby attaching some metadata to the string that can only be gotten to
> if it's packed with 'p'?  I mean, why can't you go from address to object?
>
Yes, you're right.
According to Ruby source pack.c and string.c,
Ruby make the string associated with "rb_str_associate".
And when unpacking 'p', ruby check the string with "rb_str_associated"
I mean it is almost impossible you go from address to object.

Regards,

Park Heesob

From luislavena at gmail.com  Thu Jun 22 01:34:13 2006
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 22 Jun 2006 02:34:13 -0300
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <554ac39c0606191223r6204626fld416e6ba96441fe7@mail.gmail.com>
References: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
	<554ac39c0606191223r6204626fld416e6ba96441fe7@mail.gmail.com>
Message-ID: <71166b3b0606212234x1a2eee83kbb93708af9287f12@mail.gmail.com>

On 6/19/06, Patrick Hurley <phurley at gmail.com> wrote:
> This is a second post of this message -- service.c was too big and
> caused the list to bounce it. Attached is a patch and my service.c.bz2
> if there is any difficulty
> applying the patch. I did the following:
>
[snip]
> That's it -- in my tests it works perfectly. If I made any fax paus in
> my patch creation or summary please let me know.
>

Hello Patrick.

The patch sounds and look good, but I cannot build it here.

This is the output of building 0.5.0:
Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

        C:\ruby\bin\ruby -e "puts 'EXPORTS', 'Init_service'"  >
service-i386-mswin32.def
        cl -nologo -MD -Zi -O2b2xg- -G6 -I.
-IC:/ruby/lib/ruby/1.8/i386-mswin32
-IC:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_ENUMSERVICESSTATUSEX
-DHAVE_QUERYSERVICESTATUSEX -c -Tcservice.cservice.c
        cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib
oldnames.lib user32.lib advapi32.lib wsock32.lib  -link
-incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib"
-def:service-i386-mswin32.def -implib:service-i386-mswin32.lib
-pdb:service-i386-mswin32.pdb
   Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp


And this is with your service.c file replacing the original:
Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

        cl -nologo -MD -Zi -O2b2xg- -G6 -I.
-IC:/ruby/lib/ruby/1.8/i386-mswin32-IC:/ruby/lib/ruby/1.8/i386-mswin32
-I. -DHAVE_ENUMSERVICESSTATUSEX -DHAVE_QUERYSERVICESTATUSEX -c
-Tcservice.cservice.c
        cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib
oldnames.lib user32.lib advapi32.lib wsock32.lib  -link
-incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib"
-def:service-i386-mswin32.def -implib:service-i386-mswin32.lib
-pdb:service-i386-mswin32.pdb
   Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp

service.obj : error LNK2019: unresolved external symbol
_rb_get_dependencies referenced in function _service_services
service.obj : error LNK2019: unresolved external symbol
_rb_get_error_control referenced in function _service_services
service.obj : error LNK2019: unresolved external symbol
_rb_get_start_type referenced in function _service_services
service.so : fatal error LNK1120: 3 unresolved externals
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.

What I'm missing? Maybe is because I'm tired, but couldn't see why
this is happening...

Thank you for your time,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From phasis at gmail.com  Thu Jun 22 01:49:45 2006
From: phasis at gmail.com (Heesob Park)
Date: Thu, 22 Jun 2006 14:49:45 +0900
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <71166b3b0606212234x1a2eee83kbb93708af9287f12@mail.gmail.com>
References: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
	<554ac39c0606191223r6204626fld416e6ba96441fe7@mail.gmail.com>
	<71166b3b0606212234x1a2eee83kbb93708af9287f12@mail.gmail.com>
Message-ID: <aea95bc50606212249n26214ce1n439ea6a02a2f611e@mail.gmail.com>

Hi,

2006/6/22, Luis Lavena <luislavena at gmail.com>:
> On 6/19/06, Patrick Hurley <phurley at gmail.com> wrote:
> > This is a second post of this message -- service.c was too big and
> > caused the list to bounce it. Attached is a patch and my service.c.bz2
> > if there is any difficulty
> > applying the patch. I did the following:
> >
> [snip]
> > That's it -- in my tests it works perfectly. If I made any fax paus in
> > my patch creation or summary please let me know.
> >
>
> Hello Patrick.
>
> The patch sounds and look good, but I cannot build it here.
>
> This is the output of building 0.5.0:
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
>
>        C:\ruby\bin\ruby -e "puts 'EXPORTS', 'Init_service'"  >
> service-i386-mswin32.def
>        cl -nologo -MD -Zi -O2b2xg- -G6 -I.
> -IC:/ruby/lib/ruby/1.8/i386-mswin32
> -IC:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_ENUMSERVICESSTATUSEX
> -DHAVE_QUERYSERVICESTATUSEX -c -Tcservice.cservice.c
>        cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib
> oldnames.lib user32.lib advapi32.lib wsock32.lib  -link
> -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib"
> -def:service-i386-mswin32.def -implib:service-i386-mswin32.lib
> -pdb:service-i386-mswin32.pdb
>   Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp
>
>
> And this is with your service.c file replacing the original:
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
>
>        cl -nologo -MD -Zi -O2b2xg- -G6 -I.
> -IC:/ruby/lib/ruby/1.8/i386-mswin32-IC:/ruby/lib/ruby/1.8/i386-mswin32
> -I. -DHAVE_ENUMSERVICESSTATUSEX -DHAVE_QUERYSERVICESTATUSEX -c
> -Tcservice.cservice.c
>        cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib
> oldnames.lib user32.lib advapi32.lib wsock32.lib  -link
> -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib"
> -def:service-i386-mswin32.def -implib:service-i386-mswin32.lib
> -pdb:service-i386-mswin32.pdb
>   Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp
>
> service.obj : error LNK2019: unresolved external symbol
> _rb_get_dependencies referenced in function _service_services
> service.obj : error LNK2019: unresolved external symbol
> _rb_get_error_control referenced in function _service_services
> service.obj : error LNK2019: unresolved external symbol
> _rb_get_start_type referenced in function _service_services
> service.so : fatal error LNK1120: 3 unresolved externals
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
>
All above functions are defined at service.h
I guess you have incorrect version of service.h.

Regards,

Park Heesob

From luislavena at gmail.com  Thu Jun 22 03:06:59 2006
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 22 Jun 2006 04:06:59 -0300
Subject: [Win32utils-devel] win32-service patch
In-Reply-To: <aea95bc50606212249n26214ce1n439ea6a02a2f611e@mail.gmail.com>
References: <554ac39c0606190930j24f75892lf20fd6877cf1e96d@mail.gmail.com>
	<554ac39c0606191223r6204626fld416e6ba96441fe7@mail.gmail.com>
	<71166b3b0606212234x1a2eee83kbb93708af9287f12@mail.gmail.com>
	<aea95bc50606212249n26214ce1n439ea6a02a2f611e@mail.gmail.com>
Message-ID: <71166b3b0606220006p2195401dga9473bd6d173e446@mail.gmail.com>

On 6/22/06, Heesob Park <phasis at gmail.com> wrote:
> Hi,
>
> 2006/6/22, Luis Lavena <luislavena at gmail.com>:
> > On 6/19/06, Patrick Hurley <phurley at gmail.com> wrote:
> > > This is a second post of this message -- service.c was too big and
> > > caused the list to bounce it. Attached is a patch and my service.c.bz2
> > > if there is any difficulty
> > > applying the patch. I did the following:
> > >
> > [snip]
> > > That's it -- in my tests it works perfectly. If I made any fax paus in
> > > my patch creation or summary please let me know.
> > >
> >
> > Hello Patrick.
> >
> > The patch sounds and look good, but I cannot build it here.
> >
> > This is the output of building 0.5.0:
[snip]
> All above functions are defined at service.h
> I guess you have incorrect version of service.h.


Park, you're right. I was replacing service.c in the 0.5.0, instead of 0.5.1.

I'll test this with mongrel (for mongrel win32 services) and chck if
that solved/helped the problem when mixing ruby/native threads.

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From djberg96 at gmail.com  Wed Jun 28 00:10:37 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Tue, 27 Jun 2006 22:10:37 -0600
Subject: [Win32utils-devel] [Fwd: [ruby] win32-service :
	RegisterServiceCtrlHandlerEx]
Message-ID: <44A2013D.3010903@gmail.com>

Thoughts?
-------------- next part --------------
An embedded message was scrubbed...
From: "Romuald du Song" <rdusong at gmail.com>
Subject: [ruby] win32-service : RegisterServiceCtrlHandlerEx
Date: Mon, 26 Jun 2006 00:02:10 +0200
Size: 2587
Url: http://rubyforge.org/pipermail/win32utils-devel/attachments/20060628/8f12e8f1/attachment-0001.mht 

From phasis at gmail.com  Wed Jun 28 00:54:13 2006
From: phasis at gmail.com (Heesob Park)
Date: Wed, 28 Jun 2006 13:54:13 +0900
Subject: [Win32utils-devel] [Fwd: [ruby] win32-service :
	RegisterServiceCtrlHandlerEx]
In-Reply-To: <44A2013D.3010903@gmail.com>
References: <44A2013D.3010903@gmail.com>
Message-ID: <aea95bc50606272154v5b38c6a3r51dc89e2197461fa@mail.gmail.com>

Hi,

2006/6/28, Daniel Berger <djberg96 at gmail.com>:
> Thoughts?
>
>
>
> ---------- ??? ??? ----------
> From: "Romuald du Song" <rdusong at gmail.com>
> To: "Daniel Berger" <djberg96 at gmail.com>, stevetuckner
> <stevetuckner at usfamily.net>, phasis68 at hotmail.com, sdate at everestkc.net
> Date: Mon, 26 Jun 2006 00:02:10 +0200
> Subject: [ruby] win32-service : RegisterServiceCtrlHandlerEx
> Hy,
>
> I am trying to build a ruby service that keep track of log on and log off
>  on windows machine.
> I've no windows specific development knowledge so it was hard
>  for me to find that you could use RegisterServiceCtrlHandlerEx
>  to register an HandlerEx to be notified of SERVICE_CONTROL_SESSIONCHANGE.
>
> My problem is that win32-service does not use this function
>  but RegisterServiceCtrlHandler.
>
> I've no tools and knowledge to extend win32-service to provide this
>  new functionnality.
>
> Is this functionnality interesting enough that a win32-service developper
>  may consider adding it ?
>
> Thanks you for your time.
>
I agree to his proposal to extend win32-service for new functionnality.

But there is one problem. If you use RegisterServiceCtrlHandlerEx in
win32-service, you cannot compile it with VC++ 6.0.

Regards,

Park Heesob

From phurley at gmail.com  Wed Jun 28 07:28:44 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Wed, 28 Jun 2006 07:28:44 -0400
Subject: [Win32utils-devel] [Fwd: [ruby] win32-service :
	RegisterServiceCtrlHandlerEx]
In-Reply-To: <aea95bc50606272154v5b38c6a3r51dc89e2197461fa@mail.gmail.com>
References: <44A2013D.3010903@gmail.com>
	<aea95bc50606272154v5b38c6a3r51dc89e2197461fa@mail.gmail.com>
Message-ID: <554ac39c0606280428m52fa9d66j7659e14d9730278@mail.gmail.com>

On 6/28/06, Heesob Park <phasis at gmail.com> wrote:
> But there is one problem. If you use RegisterServiceCtrlHandlerEx in
> win32-service, you cannot compile it with VC++ 6.0.

That is not completely true. We could dynamically call it out of
advapi32.lib (using LoadLibrary/GetProcAddress). It is a bit of a
pain, but completely doable -- sort of like DL for C.

pth

From phurley at gmail.com  Wed Jun 28 09:54:23 2006
From: phurley at gmail.com (Patrick Hurley)
Date: Wed, 28 Jun 2006 09:54:23 -0400
Subject: [Win32utils-devel] [Fwd: [ruby] win32-service :
	RegisterServiceCtrlHandlerEx]
In-Reply-To: <554ac39c0606280428m52fa9d66j7659e14d9730278@mail.gmail.com>
References: <44A2013D.3010903@gmail.com>
	<aea95bc50606272154v5b38c6a3r51dc89e2197461fa@mail.gmail.com>
	<554ac39c0606280428m52fa9d66j7659e14d9730278@mail.gmail.com>
Message-ID: <554ac39c0606280654s52759560y7e71305ef658c81f@mail.gmail.com>

Since the proof is in the pudding, below is some code to show what I
meant. The down side to this approach is that it requires us to put
some "nasty" constants in our code (stuff that can only be known by
looking in a dev studio header file or some serious reverse
engineering). As there is really no way Microsoft can change these
constants without breaking loads of code it is not a problem, but it
does go against the grain.

If this is a desired approach (it could be a while before we get a
Ruby compiling on a newer tool chain), I would be happy to make a
patch that also softens up the SERVICE_CONTROL_PARAMCHANGE,
SERVICE_CONTROL_NETBINDXXX etc. and HAVE_ENUMSERVICESSTATUSEX. As
these are API (windows version) issues and not really tied to the
compiler we can support them as long as the version of windows does. I
will wait until you complete the revision separating service code from
daemon code, as that is big enough to wreck an easy patch.

pth

#include <stdio.h>
#include <windows.h>

typedef DWORD (WINAPI *LPHANDLER_FUNCTION_EX) (
  DWORD dwControl,     // requested control code
  DWORD dwEventType,   // event type
  LPVOID lpEventData,  // event data
  LPVOID lpContext     // user-defined context data
);

typedef SERVICE_STATUS_HANDLE (WINAPI *REGISTER_SERVICE_CTRL_HANDLER_EX) (
   LPCTSTR lpServiceName,                // name of service
   LPHANDLER_FUNCTION_EX lpHandlerProc,  // handler function
   LPVOID lpContext                      // user data
);

DWORD WINAPI MyCallBack(DWORD dwControl, DWORD dwEventType, LPVOID
lpEventData, LPVOID lpContext)
{
   return 0;
}

int main()
{
   HMODULE hAdvapi32 = NULL;
   REGISTER_SERVICE_CTRL_HANDLER_EX RegisterServiceCtrlHandlerEx = NULL;

   if ((hAdvapi32 = LoadLibrary("Advapi32.dll")) == NULL)
   {
      printf("Unable to load Advapi32.dll\n");
      exit(1);
   }

   if ((RegisterServiceCtrlHandlerEx =
(REGISTER_SERVICE_CTRL_HANDLER_EX)GetProcAddress(hAdvapi32,
"RegisterServiceCtrlHandlerExA")) == NULL)
   {
      printf("Unable to locate RegisterServiceCtrlHandlerEx\n");
      exit(2);
   }

   printf("It's all good\n");
   RegisterServiceCtrlHandlerEx("ServName", MyCallBack, 0);

   return 0;
}