Mailing List Archive

This is something that alot of people want to do - we are looking at several
options as to the best mechanism for this.

fork() is a b*tch in NT, and we are looking at an implementation of it, but
it would be quite limited.

Keeping in mind that threads are very "cheap" in NT, and processes are not,
another approach would be to take full advantage of the NT architecture and
implement a call back mechanism based on socket I/O completion ports or
somthing.

Anyones comments on these ideas would be appreciated.

-- Dick

At 10:11 PM 12/6/95 GMT, Duncan Harris wrote:
>
>Will it ever be possible to write a multi-threaded server for Perl on
>Win32? I presume fork() will never work, but will it be possible to use
>the NT spawn to similar effect? I guess that sockets cannot be shared
>between processes on NT, so does this mean no?
>
>Duncan Harris
>Sapio Design Ltd
>Manchester, U.K.
>
>
>
--~--~--~--~-- hi mom! -~--~--~--~--~--~--~--~--~
mailto:Dick_Hardt@hip.com fax: 604.654.9881
http://info.hip.com/info me: 604.685.0124
hip communications inc.
350 - 1122 Mainland Street, Vancouver BC, V6B 5L1

>>>>> "dick" == Dick Hardt <Dick_Hardt@hip.com> writes:

dick> This is something that alot of people want to do - we are
dick> looking at several options as to the best mechanism for this.

dick> fork() is a b*tch in NT, and we are looking at an implementation
dick> of it, but it would be quite limited.

dick> Keeping in mind that threads are very "cheap" in NT, and
dick> processes are not, another approach would be to take full
dick> advantage of the NT architecture and implement a call back
dick> mechanism based on socket I/O completion ports or somthing.

dick> Anyones comments on these ideas would be appreciated.

My main concern is that the NT version of Perl be as close as possible
to the UNIX version, this includes the form and functionality of
fork(). Looking at the real fork(), CreateProcess() and
CreateThread(), I can see it being difficult, but how about handing
this off to Microsoft?

People have been asking for an NT version of fork() from day
one. Can't someone from Microsoft with the where-with-all spend some
time and make many, many people happy?

Sarir "using spoon() 'cause I ain't got no fork()" Khamsi

--
Sarir (Riri) Khamsi
khamsi@mathworks.com
w:508-647-4338
h:617-641-3013

YES! Let's get this done right! Are you listening, Microsoft?

/*----------------------------------------------------------------------*/
/* Bob Kline Stream International */
/* bob_kline@stream.com formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311 fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

On Thu, 7 Dec 1995, Sarir Khamsi wrote:

> >>>>> "dick" == Dick Hardt <Dick_Hardt@hip.com> writes:
>
> dick> This is something that alot of people want to do - we are
> dick> looking at several options as to the best mechanism for this.
>
> dick> fork() is a b*tch in NT, and we are looking at an implementation
> dick> of it, but it would be quite limited.
>
> dick> Keeping in mind that threads are very "cheap" in NT, and
> dick> processes are not, another approach would be to take full
> dick> advantage of the NT architecture and implement a call back
> dick> mechanism based on socket I/O completion ports or somthing.
>
> dick> Anyones comments on these ideas would be appreciated.
>
> My main concern is that the NT version of Perl be as close as possible
> to the UNIX version, this includes the form and functionality of
> fork(). Looking at the real fork(), CreateProcess() and
> CreateThread(), I can see it being difficult, but how about handing
> this off to Microsoft?
>
> People have been asking for an NT version of fork() from day
> one. Can't someone from Microsoft with the where-with-all spend some
> time and make many, many people happy?
>
> Sarir "using spoon() 'cause I ain't got no fork()" Khamsi
>
> --
> Sarir (Riri) Khamsi
> khamsi@mathworks.com
> w:508-647-4338
> h:617-641-3013
>

YES! Let's get this done right! Are you listening, Microsoft?

/*----------------------------------------------------------------------*/
/* Bob Kline Stream International */
/* bob_kline@stream.com formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311 fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

On Thu, 7 Dec 1995, Sarir Khamsi wrote:

> >>>>> "dick" == Dick Hardt <Dick_Hardt@hip.com> writes:
>
> dick> This is something that alot of people want to do - we are
> dick> looking at several options as to the best mechanism for this.
>
> dick> fork() is a b*tch in NT, and we are looking at an implementation
> dick> of it, but it would be quite limited.
>
> dick> Keeping in mind that threads are very "cheap" in NT, and
> dick> processes are not, another approach would be to take full
> dick> advantage of the NT architecture and implement a call back
> dick> mechanism based on socket I/O completion ports or somthing.
>
> dick> Anyones comments on these ideas would be appreciated.
>
> My main concern is that the NT version of Perl be as close as possible
> to the UNIX version, this includes the form and functionality of
> fork(). Looking at the real fork(), CreateProcess() and
> CreateThread(), I can see it being difficult, but how about handing
> this off to Microsoft?
>
> People have been asking for an NT version of fork() from day
> one. Can't someone from Microsoft with the where-with-all spend some
> time and make many, many people happy?
>
> Sarir "using spoon() 'cause I ain't got no fork()" Khamsi
>
> --
> Sarir (Riri) Khamsi
> khamsi@mathworks.com
> w:508-647-4338
> h:617-641-3013
>

>YES! Let's get this done right! Are you listening, Microsoft?

I doubt it. Remember: these are the people who gave us a nominal POSIX
system that you can't use for crap. At least in VMS, they gave you POSIX
access that didn't preclude also accessing normal system functions in
VMS. NT should have given you the ability to do a real posix call (like
open, fork, etc) and yet also get at normal OLE calls, etc. But they
obvious don't care about usefulness, or they'd have done it right. They
only care about checkboxes for government specs, even though those checked
boxes don't buy you anything more than a pig in a poke.

--tom

DH> fork() is a b*tch in NT, and we are looking at an implementation of it, but
DH> it would be quite limited.

Have you talked to the people porting gcc and much more to NT/W'95 at
Cygnus? I think they've an emulation of fork.

On Thu, 7 Dec 1995, Sarir Khamsi wrote:

>
> My main concern is that the NT version of Perl be as close as possible
> to the UNIX version, this includes the form and functionality of
> fork(). Looking at the real fork(), CreateProcess() and
> CreateThread(), I can see it being difficult, but how about handing
> this off to Microsoft?
>

This is real important, IMHO. I have found that I have been unable to use
certain modules from CPAN because of a lack of fork(), bell(), etc. I'd
really hate to see the NT Perl users get cut off from "mainstream" Perl
modules because of incompatibilities. If we can avoid as many
platform-specific idiosyncrasies as possible, it will make sharing modules
a lot easier. And I think the fact that so many modules are freely shared
is just one more thing that makes Perl so much more attractive as a tool.

AFAIK, the folks at Cygnus have had fork() working in the GNU toolchain
since beta-9. If there is some intention to merge the Perl-win32 effort
into the standard distribution, wouldn't it be easier to use the GNU
toolchain, thus making fork() available and reducing the number of
platform differences? I hope I haven't unwittingly stumbled into trouble
here; am I oversimplifying things?

Brian Jepson (bjepson@conan.ids.net)
Director of Advanced Technology, Prosoft Systems International, Inc.

At 09:39 AM 12/7/95 -0500, you wrote:
>>>>>> "dick" == Dick Hardt <Dick_Hardt@hip.com> writes:
>
>dick> This is something that alot of people want to do - we are
>dick> looking at several options as to the best mechanism for this.
>
>dick> fork() is a b*tch in NT, and we are looking at an implementation
>dick> of it, but it would be quite limited.
>
>dick> Keeping in mind that threads are very "cheap" in NT, and
>dick> processes are not, another approach would be to take full
>dick> advantage of the NT architecture and implement a call back
>dick> mechanism based on socket I/O completion ports or somthing.
>
>dick> Anyones comments on these ideas would be appreciated.
>
>My main concern is that the NT version of Perl be as close as possible
>to the UNIX version, this includes the form and functionality of
>fork(). Looking at the real fork(), CreateProcess() and
>CreateThread(), I can see it being difficult, but how about handing
>this off to Microsoft?
>
>People have been asking for an NT version of fork() from day
>one. Can't someone from Microsoft with the where-with-all spend some
>time and make many, many people happy?
>
>Sarir "using spoon() 'cause I ain't got no fork()" Khamsi
>
>--
>Sarir (Riri) Khamsi
>khamsi@mathworks.com
>w:508-647-4338
>h:617-641-3013
>
>

Sound like a great idea, and make sure it works on 95 too.


Win

Okay, time for my periodic fork() message.

As many people point out, providing useful and robust fork() functionality
in Perl would require OS support.

I certainly respect the Perl community's desire to maximize script
compatibility and portability across platforms -- it is extremely expensive
and time consuming to maintain several code bases.

Hip has investigated emulating some fork() functionality in Perl, but we are
not comfortable exposing limited support that will not address some of the
more interesting scenarios.

Microsoft does not currently plan to add this infrastructure into NT or
Win9x for several reasons, including:

1) The fork() functionality does not follow the threading model very well.
We want to move forward toward more efficient code.

2) Most of the requests for fork() are for compatibility with UNIX legacy
code. While this compatibility is important, the amount of work needed to
change most applications from relying on fork() behavior to using threads is
relatively small compared to other porting issues (Yes, I know there are
many exceptions :).

3) We also need to spend time and energy on other issues requested from our
customer and ISV community -- OS performance, network OLE, enhancing the
interface and shell, etc. Many other interesting features are just at a
lower priority.

As always, we continue to evaluate our decisions as customer needs evolve,
so please send comments and complaints re: OS issues directly to me.

Tim Davis
NT Program Managemt

<timda@microsoft.com>

I'm with Tim. It sounds like exposing efficient threading through Win32 perl is something that can actually happen without waiting for something that isn't going to change on the OS side. Adding "compatible fork" later by hook, crook, or grace would be a valuable compatibility enhancement, but multithreading capability is a necessity, compatibility notwithstanding.

So, God bless the NT Perl team, please expose Win32 threading, and if somebody figures out a compatible fork(), that would be nice, too.
Jim Mackraz
Maxis/CTG

----------
From: Tim Davis (Exchange)[SMTP:TimDa@EXCHANGE.MICROSOFT.com]
Sent: Thursday, December 07, 1995 12:40 PM
To: perl-win32@mail.hip.com
Cc: djah@cix.compulink.co.uk
Subject: RE: Multi-threaded server

Okay, time for my periodic fork() message.

As many people point out, providing useful and robust fork() functionality
in Perl would require OS support.

I certainly respect the Perl community's desire to maximize script
compatibility and portability across platforms -- it is extremely expensive
and time consuming to maintain several code bases.

Hip has investigated emulating some fork() functionality in Perl, but we are
not comfortable exposing limited support that will not address some of the
more interesting scenarios.

Microsoft does not currently plan to add this infrastructure into NT or
Win9x for several reasons, including:

1) The fork() functionality does not follow the threading model very well.
We want to move forward toward more efficient code.

2) Most of the requests for fork() are for compatibility with UNIX legacy
code. While this compatibility is important, the amount of work needed to
change most applications from relying on fork() behavior to using threads is
relatively small compared to other porting issues (Yes, I know there are
many exceptions :).

3) We also need to spend time and energy on other issues requested from our
customer and ISV community -- OS performance, network OLE, enhancing the
interface and shell, etc. Many other interesting features are just at a
lower priority.

As always, we continue to evaluate our decisions as customer needs evolve,
so please send comments and complaints re: OS issues directly to me.

Tim Davis
NT Program Managemt

<timda@microsoft.com>

How about define(develop) a new Perl5 package which encapsulate these kind
of functions(forks, alarm etc.) so that the scripts needs no change but
only replace the corresponding packages for a given platform ?

----------
From: Dick Hardt[SMTP:Dick_Hardt@hip.com]
Sent: Thursday, December 07, 1995 9:46 AM
To: djah@cix.compulink.co.uk; perl-win32@mail.hip.com
Cc: djah@cix.compulink.co.uk
Subject: Re: Multi-threaded server

This is something that alot of people want to do - we are looking at
several
options as to the best mechanism for this.

fork() is a b*tch in NT, and we are looking at an implementation of it, but
it would be quite limited.

Keeping in mind that threads are very "cheap" in NT, and processes are not,
another approach would be to take full advantage of the NT architecture and
implement a call back mechanism based on socket I/O completion ports or
somthing.

Anyones comments on these ideas would be appreciated.

-- Dick

At 10:11 PM 12/6/95 GMT, Duncan Harris wrote:
>
>Will it ever be possible to write a multi-threaded server for Perl on
>Win32? I presume fork() will never work, but will it be possible to use
>the NT spawn to similar effect? I guess that sockets cannot be shared
>between processes on NT, so does this mean no?
>
>Duncan Harris
>Sapio Design Ltd
>Manchester, U.K.
>
>
>
--~--~--~--~-- hi mom! -~--~--~--~--~--~--~--~--~
mailto:Dick_Hardt@hip.com fax: 604.654.9881
http://info.hip.com/info me: 604.685.0124
hip communications inc.
350 - 1122 Mainland Street, Vancouver BC, V6B 5L1




begin 600 WINMAIL.DAT
M>)\^(B\"`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$%@ ,`
M#@```,L'# `(``H`'@`M``4`0 $!"8 !`"$````V.3 T-$8S-S1!,S%#1C$Q
M0D-#03 P,C!!1C)%-#$R, `+!P$@@ ,`#@```,L'# `(``H`'@`N``4`00$!
M"( '`!@```!)4$TN36EC<F]S;V9T($UA:6PN3F]T90`Q" $$@ $`&@```%)%
M.B!-=6QT:2UT:')E861E9"!S97)V97(`(0D!#8 $``(````"``(``0.0!@`T
M!P``$@```$ `.0"@`UPM%<6Z`1X`< `!````%@```$UU;'1I+71H<F5A9&5D
M('-E<G9E<@````(!<0`!````&P````&ZQ%UO"7P3U>LOJ1'/O-4`(*\L,_0`
M+; &0@`#``80L:%A+ ,`!Q#-! ``'@`($ $```!E````2$]704)/551$149)
M3D4H1$5614Q/4"E!3D574$523#5004-+04=%5TA)0TA%3D-!4%-53$%4151(
M15-%2TE.1$]&1E5.0U1)3TY3*$9/4DM3+$%,05)-151#*5-/5$A!5%1(10``
M```#`! 0``````,`$1 ``````@$)$ $```"(!0``A 4``(@)``!,6D9UPK1G
M?O\`"@$/`A4"J 7K`H,`4 +R"0(`8V@*P'-E=#(W!@`&PP*#,@/%`@!P<D)Q
M$>)S=&5M`H,SMP+D!Q,"@S0#QA3%?0J BPC/"=D[.%S\R-34"@ <*@0VQ"V!N
M9S$P,R\44 L*%%$+\F,`0"!(?F\'X &@"& %0 VQ"X!EDB@-L'9E%M!P*1Q0
M%B =``?@4 20;#4@`0JP8VMA9V4@=Q1H:1%P( GP8V%PC'-U"V 3T"!T: >0
M!1[.@:PN 9"!O9B D9G4?<'1I`B!S*&$"$')K<RP<4 M@<B)M'U!T8RX=H'-O
M_R 1'^ @$B+ !0,$(!T`"8#?(_$BX!%Q&D >X&(<D0(@V&QY(!= "U%C( ,D
MD%,%L!= <W "(&0+@&?/'G8$("&A';%G:1U0`Z!O"U$`, 6P(E _"H4*BVP0
M:3$X, +1:2TQ/#0T#? ,T"L3"UDQ-L\*H -@$] A," M+3<*A]<KZPPP++9&
M`V$Z+CXLMFD,@B!$'R!K'! +$71 6U--5% Z,?)?)3)#0!\0<"X%H&U=/RW?
M+NT&8 (P,!\Q*U1HH0AP<V1A>2'P1 6011/@8@20(# W(? QA#DY'F Y.C0V
M%+!F330O+NU4;S9O,2MD@&IA:$!C:7@STA9P'\ +@&LST2YU:Q8[.'G >,2T#
M\&XS,G9 `, #$"XSI3I_+NU#?F,\GSVO/K\_P4&/-3YUG&)J+/%#KS$K4F5)
M<+9-'\ A0"T@(!= 80VP:R"P$;!R'5!R*3\J0S/^-BNW%6(,`3OW'Q $(% !
M_R+0!X @("<"(P,'0"S0(,)[0! =@&P>X0!P(S$BX&1](N M'O >X K 'N 6
MT&__(($G(",A$;!,L0= "H4=@'\A0QQ0!"!2D2-2.3 3P" _!X DH@0`(E G
MTE"A<RX[3.PAHB@=H% !'<!B*N\B@!] "X 'L%0A\2"A4Q__6A%0(#\@4A '
M@ (P'^ A4?D@PFET(? E$0J%7- >\(T(8&P@L#DP('%U7-!74V$'<%Z19%>M
M2PG@</\G`EFQ7O @H2,%3!)5<5-1FTRQ)8 B$7!,(' B6:K_++$E\ 00!Y%3
M0B1P7. *A>\`<"S0(# G\7 LL0#0'T"S7>=5PF%K'N A`&P#(/U,,'9241[."
M(-$C4EG@4S'_$7!>D2$P"'!:<2"@749;QO<=L1^ 9Y%B'I%6>6N $; ?(+$#
MH"+0'J 1P"!)+_Y/)E%;PEQ3)L `( 0@!;"/"H5085"C5ZU!;GD"(+\'D3/A
M7 )NH0.@("1I#;#_59%=YV72!9 ',%\?+2$QXR=O[05 &F Z,1P`4$VA.: R
M+S8O.=%',K!_.,$A$0.1,D$%$'*A+,(Z]0J%/GD65P,0`R!=L51"]UXR)L $
M$&D"8&;3>+!>DOT=P&U+KWJB)](>(FS">9C=0($_;6!CL0>0=0> 6(;_`_!G
MD1T`>J)=X"' 7/. 9'M=L7KM=2!1>19HE2:P8?YW<>$BX "07O B(1]0#=#[
M+/%_0F<*4 01(P-M!'$A]P!P9*%>,G,1@4Q1>18Y,/YT6F H8F/77'%9XB+1
M4L#_!Y%78E9Q`Y$D<"DF>8=WV[]Y%@808& BX#C@`)!G`Z#D3'1I]CY-`'!B
MH1/!XG(A\%4N2U>F>8=Y'74M,'Z2>2 ?$%9P`W A_RT@DIJ46PJ%0,)2D#+O
M`W!B()>"9F%X27!.4#2(+C8UF$ Y.#@<`(4*A6@"0' Z+R\+@'\"$$$&F<.7
M@Y> !X"8!3CH-2XP=P`TF/8%('$S7R$0'R!<0U 1'W N*98S[#4P4N%VH#(1
MX(^ "X"S&B$@L%-T"=%<X5:/D1,(8'JB0D.@439"(/@U3#%,[TW^&W4LM@J%
M!19A`*5P`P`F```````+`",```````L`*0```````P`V```````"`4<``0``
M`#L```!C/553.V$](#MP/5=I;D-L:65N="!/<F=A;FD[;#U0<FEV871E($U$
M0BTY-3$R,#@P,C,P-#5:+30W``! ``<PH(-:+17%N@% ``@P(&_Y+17%N@$>
M`#T``0````4```!213H@``````(!%#0!````$ ```%24H< I?Q ;I8<(`"LJ
$)1=%0@``
`
end

> From: "Tim Davis (Exchange)" <TimDa@EXCHANGE.MICROSOFT.com>
>
> I certainly respect the Perl community's desire to maximize script
> compatibility and portability across platforms -- it is extremely expensive
> and time consuming to maintain several code bases.

It would be a tragedy if scripts were not compatible.

> Hip has investigated emulating some fork() functionality in Perl, but we are
> not comfortable exposing limited support that will not address some of the
> more interesting scenarios.
>
> Microsoft does not currently plan to add this infrastructure into NT or
> Win9x for several reasons, including:
>
> 1) The fork() functionality does not follow the threading model very well.
> We want to move forward toward more efficient code.

Perl internals are still a quite a long way from being able to support
threads.

Malcolm Beattie <mbeattie@sable.ox.ac.uk> has done a great deal of work
in this area and hopefully his (substantial) patches will start working
their way into the standard distribution after 5.002.

I recommend that HIP don't spend (waste) time on attempting threading till
that work has been integrated.

> 2) Most of the requests for fork() are for compatibility with UNIX legacy
> code. While this compatibility is important, the amount of work needed to
> change most applications from relying on fork() behavior to using threads is
> relatively small compared to other porting issues (Yes, I know there are
> many exceptions :).

That assumes that threading is available, which it isn't in perl yet - and
even then I could argue with it :-)

> 3) We also need to spend time and energy on other issues requested from our
> customer and ISV community -- OS performance, network OLE, enhancing the
> interface and shell, etc. Many other interesting features are just at a
> lower priority.

I believe that this is where HIP and Microsoft can work best for Perl.

I'd like to reach a point where it's as easy for extensions to be built
for Perl-Win32 as it is for unix. Having well designed and implemented
extensions for Win32 services (register, network OLE etc etc) will be of
*huge* value to windows users (and ultimately Microsoft).

I also think it's enevitable that a gcc-win32 port based strongly on the
standard perl distribution will happen. That port will almost certainly
have few, if any, Win32 extensions. It'll just be 'perl'.

It's important that the two ports are compatible at both the script level
and XS+Makefile.PL level and for the two sets of porters (and their users)
to avoid getting into futile religious wars over any issues which crop up.

Perhaps we'll end up with a gcc-win32 port based strongly on the
standard distribution with a range of HIP produced Win32 extensions.

That sounds like an amicable arrangement. I hope that both camps will
be far sighed enough to ensure that this is at least possible.

> As always, we continue to evaluate our decisions as customer needs evolve,
> so please send comments and complaints re: OS issues directly to me.
>
> Tim Davis
> NT Program Managemt

Thanks for clarifying Microsoft's position.

Tim.

|| From: Tim Davis (Exchange)[SMTP:TimDa@EXCHANGE.MICROSOFT.com]
|| Subject: RE: Multi-threaded server
||
|| Okay, time for my periodic fork() message.
[ ... ]
|| Microsoft does not currently plan to add this infrastructure into NT or=20
|| Win9x for several reasons, including:
||
|| 2) Most of the requests for fork() are for compatibility with UNIX legacy
|| code. While this compatibility is important, the amount of work needed to
|| change most applications from relying on fork() behavior to using threads is
|| relatively small compared to other porting issues (Yes, I know there are
|| many exceptions :).
[ ... ]
|| Tim Davis
|| NT Program Managemt

I object to the phrase "legacy code" here. A legacy is
something you inherit from a dead ancestor. Legacy code is code
that you have had for a long time, depend upon, and can't afford
to re-write.

Code which happens to involve "fork" is generally not in this
category, but rather still live and being maintained and
developed, but by someone who isn't working on NT. Unix is not
buried yet, and few customers of NT are totally replacing all of
their other platforms and going to a NT-only status - implying
these things sounds more like a marketing viewpoint than a
technical one.

The desire here is to be able to write portable code that is
usable on multiple systems, not just to continue to use old Unix
code on NT systems.

--
Maybe we can fix reality one of these days. | John Macdonald
<- Larry Wall Carl Dichter -> | jmm@Elegant.COM
I'd be happy if we could just index it. |

>>>>> <Tim Davis> writes:

> Microsoft does not currently plan to add this infrastructure
> into NT or Win9x for several reasons, including:

> 1) The fork() functionality does not follow the threading
> model very well. We want to move forward toward more
> efficient code.

Please correct me if I am wrong, but fork() does not appear to be a
multi-"threaded" approach, but instead, a multi-process approach. I'm
not surprised it does not follow the threading model well and I'm
NOT sleeping worse as a result.

> 2) Most of the requests for fork() are for compatibility
> with UNIX legacy code. While this compatibility is
> important, the amount of work needed to change most
> applications from relying on fork() behavior to using
> threads is relatively small compared to other porting issues
> (Yes, I know there are many exceptions :).

With great humility and respect, I must say that this is a very
Microsoft-centric view of the world. Some of us (developers) have to
support more than one platform that does not include a Microsoft
OS. Please understand that I'm not trying to be sarcastic, just
honest. From the outside, there is at least the "appearance" that
Microsoft is forcing users/developers to do things their way.

Also, fork() appears in C/C++ code AS WELL as Perl code. All
Microsoft has to do is write a fork() and existing (and future) code
should work. What's our other option? Microsoft and the major UNIX
players all sit down and see how to work out a "better" threading
model? I don't think so.

As for fork() being used for "UNIX legacy code", some of by best
friends are writing such code TODAY in real world applications. :-)

> 3) We also need to spend time and energy on other issues
> requested from our customer and ISV community -- OS
> performance, network OLE, enhancing the interface and shell,
> etc. Many other interesting features are just at a lower
> priority.

Microsoft doesn't have the resources to do a decent port of fork()? Am
I reading too much into this? Hire a contractor for 6 months, have
s/he do a wonderful job and make 100's or developers happy and later,
thousands of users happy. You folks have a pretty handsome profit
margin and seem to be interested in making customers happy.

Well...let's do it and bury this issue once and for all. Heck, don't
even support it, give it do me and I'll tell my boss I did it! :-)

> As always, we continue to evaluate our decisions as customer
> needs evolve, so please send comments and complaints re: OS
> issues directly to me.

This need has not evolved - it's always been there, right up there
with a decent telnet server, but don't get me started on that.

Sorry if this sounds harsh, I'm just feeling left 'cause we have
fork() on UNIX and I can't use it on NT 'cause it ain't there. Thanks
for listening/reading.

Sarir

--
Sarir (Riri) Khamsi
khamsi@mathworks.com
w:508-647-4338
h:617-641-3013

John Macdonald <jmm@Elegant.COM> writes:

>The desire here is to be able to write portable code that is
>usable on multiple systems, not just to continue to use old Unix
>code on NT systems.

Programmers who are truly concerned about portable code should
avoid the use of fork() (or Win32 threads for that matter),
instead of complaining when an OS doesn't support every UNIXism
(or Whateverism).

Perl is the closest thing I'm familiar with that provides a
platform-independent scripting language. It could have been
better if it was *designed* for multiple platforms, then fork()
would be a UNIX extension, just as OLE is a WIN32 extension.
If you use an extension, then you give up portability.

- Chet Ciechanowski
cjc@dsc.com

>Programmers who are truly concerned about portable code should
>avoid the use of fork() (or Win32 threads for that matter),
>instead of complaining when an OS doesn't support every UNIXism
>(or Whateverism).

>Perl is the closest thing I'm familiar with that provides a
>platform-independent scripting language. It could have been
>better if it was *designed* for multiple platforms, then fork()
>would be a UNIX extension, just as OLE is a WIN32 extension.
>If you use an extension, then you give up portability.

Perhaps it would have been more effective if WindowsNT, a POSIX-compliant
systme by legal dictum, would in fact actually run POSIX-compliant code, of
which fork() is but one such call.

That's why POSIX exists: as a portable operatings sytems interface. That
Microsoft has played legal games to avoid the spirit of of the law should
not cause you to disparage POSIX calls for portablility -- THAT'S WHAT IT
WAS DESIGNED FOR!@

--tom

At 01:58 PM 12/8/95 -0500, Sarir Khamsi wrote:
>>>>>> <Tim Davis> writes:
>
>> Microsoft does not currently plan to add this infrastructure
>> into NT or Win9x for several reasons, including:
>
>> 1) The fork() functionality does not follow the threading
>> model very well. We want to move forward toward more
>> efficient code.
>
>Please correct me if I am wrong, but fork() does not appear to be a
>multi-"threaded" approach, but instead, a multi-process approach. I'm
>not surprised it does not follow the threading model well and I'm
>NOT sleeping worse as a result.
>
>> 2) Most of the requests for fork() are for compatibility
>> with UNIX legacy code. While this compatibility is
>> important, the amount of work needed to change most
>> applications from relying on fork() behavior to using
>> threads is relatively small compared to other porting issues
>> (Yes, I know there are many exceptions :).
>
>With great humility and respect, I must say that this is a very
>Microsoft-centric view of the world. Some of us (developers) have to
>support more than one platform that does not include a Microsoft
>OS. Please understand that I'm not trying to be sarcastic, just
>honest. From the outside, there is at least the "appearance" that
>Microsoft is forcing users/developers to do things their way.

Micorsoft forcing users/developers to do things thier way is what I got from
this too. Which taking it further means they aren't listening to thier
customers. Perhaps thier feelings are it is only the developers that want
fork, and the developers will continue to support nt/windows because the
money is there. If that is the case, then they have it wrong. I am not a
developer, but a user. I do know a very little C/C++ and Perl. With
support for fork() it would be much easier for me to port files for my use.
Perhaps Microsoft has underestimated the amount of thier customers that
would appreciate that power? The other alternative is they aren't willing
to listen to thier customer's needs and wants, which is true to the way many
people view Microsoft now.

>Also, fork() appears in C/C++ code AS WELL as Perl code. All
>Microsoft has to do is write a fork() and existing (and future) code
>should work. What's our other option? Microsoft and the major UNIX
>players all sit down and see how to work out a "better" threading
>model? I don't think so.
>
>As for fork() being used for "UNIX legacy code", some of by best
>friends are writing such code TODAY in real world applications. :-)
>
>> 3) We also need to spend time and energy on other issues
>> requested from our customer and ISV community -- OS
>> performance, network OLE, enhancing the interface and shell,
>> etc. Many other interesting features are just at a lower
>> priority.

Why can't fork fit in with these other issues? Seems to me that making you
OS more compatible with C/C++ and Perl alone is a big benefit to your users,
not just an interesting feature.


>Microsoft doesn't have the resources to do a decent port of fork()? Am
>I reading too much into this? Hire a contractor for 6 months, have
>s/he do a wonderful job and make 100's or developers happy and later,
>thousands of users happy. You folks have a pretty handsome profit
>margin and seem to be interested in making customers happy.
>
>Well...let's do it and bury this issue once and for all. Heck, don't
>even support it, give it do me and I'll tell my boss I did it! :-)
>
>> As always, we continue to evaluate our decisions as customer
>> needs evolve, so please send comments and complaints re: OS
>> issues directly to me.

The need is evolving and growing. Case in point, a year ago I didn't have a
clue what the internet was, and didn't care if I could port Unix Perl
scripts, Unix C/C++. I do now, and I doubt I am all that unique in this
respect. More and more users are getting on the Internet everyday. Think
that through.

>This need has not evolved - it's always been there, right up there
>with a decent telnet server, but don't get me started on that.
>
>Sorry if this sounds harsh, I'm just feeling left 'cause we have
>fork() on UNIX and I can't use it on NT 'cause it ain't there. Thanks
>for listening/reading.
>
>Sarir
>
>--
>Sarir (Riri) Khamsi
>khamsi@mathworks.com
>w:508-647-4338
>h:617-641-3013

Win

Oh please. Let's lighten up on the "Evil MS is unresponsive to users and is
forcing people to do things they don't want to do" slant this thread is
taking. Every OS has features that other OS's don't have. NT doesn't
support fork() in the Win32 subsystem. Neither does Win31 or Win95 or OS/2
or MAC OS or DOS or any other OS that's not Unix. Know what? All of these
have Perl implementations. It's also NOT Unix (repeat that phrase until you
understand what it means), not OS/2, not MAC OS, not Linix, etc.

What happens if you write an perl script that uses NT's registry API's? or
OLE? Or the Event viewer? Are you going to go whining to the people who
port Perl to some flavor of Unix and complain that they don't support it?
Do you call up your friendly Unix vendor and demand that they support those
features in the OS or you'll go complain publicly that they're
"unresponsive" to your needs? Is this just an incredibly stupid thread or
what?

Bryan

P.S. No I don't speak officially for MS. I just work here.
----------
From: win[SMTP:win@msilink.com]
Sent: Friday, December 08, 1995 3:42 PM
To: Sarir Khamsi
Cc: Tim Davis (Exchange); perl-win32@mail.hip.com; djah@cix.compulink.co.uk
Subject: Re: Multi-threaded server

At 01:58 PM 12/8/95 -0500, Sarir Khamsi wrote:
>>>>>> <Tim Davis> writes:
>
>> Microsoft does not currently plan to add this infrastructure
>> into NT or Win9x for several reasons, including:
>
>> 1) The fork() functionality does not follow the threading
>> model very well. We want to move forward toward more
>> efficient code.
>
>Please correct me if I am wrong, but fork() does not appear to be a
>multi-"threaded" approach, but instead, a multi-process approach. I'm
>not surprised it does not follow the threading model well and I'm
>NOT sleeping worse as a result.
>
>> 2) Most of the requests for fork() are for compatibility
>> with UNIX legacy code. While this compatibility is
>> important, the amount of work needed to change most
>> applications from relying on fork() behavior to using
>> threads is relatively small compared to other porting issues
>> (Yes, I know there are many exceptions :).
>
>With great humility and respect, I must say that this is a very
>Microsoft-centric view of the world. Some of us (developers) have to
>support more than one platform that does not include a Microsoft
>OS. Please understand that I'm not trying to be sarcastic, just
>honest. From the outside, there is at least the "appearance" that
>Microsoft is forcing users/developers to do things their way.

Micorsoft forcing users/developers to do things thier way is what I got from
this too. Which taking it further means they aren't listening to thier
customers. Perhaps thier feelings are it is only the developers that want
fork, and the developers will continue to support nt/windows because the
money is there. If that is the case, then they have it wrong. I am not a
developer, but a user. I do know a very little C/C++ and Perl. With
support for fork() it would be much easier for me to port files for my use.
Perhaps Microsoft has underestimated the amount of thier customers that
would appreciate that power? The other alternative is they aren't willing
to listen to thier customer's needs and wants, which is true to the way many
people view Microsoft now.

>Also, fork() appears in C/C++ code AS WELL as Perl code. All
>Microsoft has to do is write a fork() and existing (and future) code
>should work. What's our other option? Microsoft and the major UNIX
>players all sit down and see how to work out a "better" threading
>model? I don't think so.
>
>As for fork() being used for "UNIX legacy code", some of by best
>friends are writing such code TODAY in real world applications. :-)
>
>> 3) We also need to spend time and energy on other issues
>> requested from our customer and ISV community -- OS
>> performance, network OLE, enhancing the interface and shell,
>> etc. Many other interesting features are just at a lower
>> priority.

Why can't fork fit in with these other issues? Seems to me that making you
OS more compatible with C/C++ and Perl alone is a big benefit to your users,
not just an interesting feature.


>Microsoft doesn't have the resources to do a decent port of fork()? Am
>I reading too much into this? Hire a contractor for 6 months, have
>s/he do a wonderful job and make 100's or developers happy and later,
>thousands of users happy. You folks have a pretty handsome profit
>margin and seem to be interested in making customers happy.
>
>Well...let's do it and bury this issue once and for all. Heck, don't
>even support it, give it do me and I'll tell my boss I did it! :-)
>
>> As always, we continue to evaluate our decisions as customer
>> needs evolve, so please send comments and complaints re: OS
>> issues directly to me.

The need is evolving and growing. Case in point, a year ago I didn't have a
clue what the internet was, and didn't care if I could port Unix Perl
scripts, Unix C/C++. I do now, and I doubt I am all that unique in this
respect. More and more users are getting on the Internet everyday. Think
that through.

>This need has not evolved - it's always been there, right up there
>with a decent telnet server, but don't get me started on that.
>
>Sorry if this sounds harsh, I'm just feeling left 'cause we have
>fork() on UNIX and I can't use it on NT 'cause it ain't there. Thanks
>for listening/reading.
>
>Sarir
>
>--
>Sarir (Riri) Khamsi
>khamsi@mathworks.com
>w:508-647-4338
>h:617-641-3013

Win

>Oh please. Let's lighten up on the "Evil MS is unresponsive to users and is
>forcing people to do things they don't want to do" slant this thread is
>taking. Every OS has features that other OS's don't have. NT doesn't
>support fork() in the Win32 subsystem. Neither does Win31 or Win95 or OS/2
>or MAC OS or DOS or any other OS that's not Unix. Know what? All of these
>have Perl implementations. It's also NOT Unix (repeat that phrase until you
>understand what it means), not OS/2, not MAC OS, not Linix, etc.

I will agree that turning this thread (no pun intended) towards an anti-MS
bias is counter-productive and steers it away from the main focus. But the
base fact remains, as Tom pointed out: WinNT is *supposed* to be a POSIX-
compliant O/S. Being able to claim that gains MS certain inroads. But the
reality is that it isn't, since fork() is part of the POSIX base that NT
claims.

>What happens if you write an perl script that uses NT's registry API's? or
>OLE? Or the Event viewer? Are you going to go whining to the people who
>port Perl to some flavor of Unix and complain that they don't support it?
> Do you call up your friendly Unix vendor and demand that they support those
>features in the OS or you'll go complain publicly that they're
>"unresponsive" to your needs? Is this just an incredibly stupid thread or
>what?

Well, I would hope that those porting the registry API and OLE have the
presence of mind to put them into seperate modules (dynamically loadable even)
rather than into the core. The core perl should be as close to consistent
across all platforms as those platforms can manage. I don't ever want to see
the Tk module interwoven into Perl, nor a particular DB/DBM implementation.
The idea is to have a basic language, that can take advantage of other
functionality as platform permits.

>>As for fork() being used for "UNIX legacy code", some of by best
>>friends are writing such code TODAY in real world applications. :-)

This was a very good point the other fellow made. The reference to UNIX code
as "legacy code" (and I know how tough that can be, most of the phone
companies are choking on their legacy systems) was simply not at all on target.
UNIX as an O/S is not going away anytime soon. The goal should be to bring
these different O/S types closer, not push them further apart.

Randy
--
^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS Phone: (303)595-2869
Denver, CO rjray@lookout.ecte.uswc.uswest.com

I don't suffer from insanity. I enjoy every minute of it.

At 04:11 PM 12/8/95 -0800, Bryan Tuttle (Exchange) wrote:
>Oh please. Let's lighten up on the "Evil MS is unresponsive to users and is
>forcing people to do things they don't want to do" slant this thread is
>taking. Every OS has features that other OS's don't have. NT doesn't
>support fork() in the Win32 subsystem. Neither does Win31 or Win95 or OS/2
>or MAC OS or DOS or any other OS that's not Unix. Know what? All of these
>have Perl implementations. It's also NOT Unix (repeat that phrase until you
>understand what it means), not OS/2, not MAC OS, not Linix, etc.
>
>What happens if you write an perl script that uses NT's registry API's? or
>OLE? Or the Event viewer? Are you going to go whining to the people who
>port Perl to some flavor of Unix and complain that they don't support it?
> Do you call up your friendly Unix vendor and demand that they support those
>features in the OS or you'll go complain publicly that they're
>"unresponsive" to your needs? Is this just an incredibly stupid thread or
>what?
>
>Bryan
>
>P.S. No I don't speak officially for MS. I just work here.
>----------
You also have poor customer service skills too Bryan. While you may not
agree with what we are saying, we are the people that buy the product
Microsoft sells. I deserve respect as a customer, and I have a right to
voice my opinions on what a product I buy or am considering buying supports.

If I went into a retail establishment and asked them to provide a product
which they weren't, I would be offended if they were to reply along the
lines you did. While they may not respond to my needs, as a customer they
should treat me with respect when they decline.

Look at the points we are making, argue for or against, but give us respect.


Win



>From: win[SMTP:win@msilink.com]
>Sent: Friday, December 08, 1995 3:42 PM
>To: Sarir Khamsi
>Cc: Tim Davis (Exchange); perl-win32@mail.hip.com; djah@cix.compulink.co.uk
>Subject: Re: Multi-threaded server
>
>At 01:58 PM 12/8/95 -0500, Sarir Khamsi wrote:
>>>>>>> <Tim Davis> writes:
>>
>>> Microsoft does not currently plan to add this infrastructure
>>> into NT or Win9x for several reasons, including:
>>
>>> 1) The fork() functionality does not follow the threading
>>> model very well. We want to move forward toward more
>>> efficient code.
>>
>>Please correct me if I am wrong, but fork() does not appear to be a
>>multi-"threaded" approach, but instead, a multi-process approach. I'm
>>not surprised it does not follow the threading model well and I'm
>>NOT sleeping worse as a result.
>>
>>> 2) Most of the requests for fork() are for compatibility
>>> with UNIX legacy code. While this compatibility is
>>> important, the amount of work needed to change most
>>> applications from relying on fork() behavior to using
>>> threads is relatively small compared to other porting issues
>>> (Yes, I know there are many exceptions :).
>>
>>With great humility and respect, I must say that this is a very
>>Microsoft-centric view of the world. Some of us (developers) have to
>>support more than one platform that does not include a Microsoft
>>OS. Please understand that I'm not trying to be sarcastic, just
>>honest. From the outside, there is at least the "appearance" that
>>Microsoft is forcing users/developers to do things their way.
>
>Micorsoft forcing users/developers to do things thier way is what I got from
>this too. Which taking it further means they aren't listening to thier
>customers. Perhaps thier feelings are it is only the developers that want
>fork, and the developers will continue to support nt/windows because the
>money is there. If that is the case, then they have it wrong. I am not a
>developer, but a user. I do know a very little C/C++ and Perl. With
>support for fork() it would be much easier for me to port files for my use.
>Perhaps Microsoft has underestimated the amount of thier customers that
>would appreciate that power? The other alternative is they aren't willing
>to listen to thier customer's needs and wants, which is true to the way many
>people view Microsoft now.
>
>>Also, fork() appears in C/C++ code AS WELL as Perl code. All
>>Microsoft has to do is write a fork() and existing (and future) code
>>should work. What's our other option? Microsoft and the major UNIX
>>players all sit down and see how to work out a "better" threading
>>model? I don't think so.
>>
>>As for fork() being used for "UNIX legacy code", some of by best
>>friends are writing such code TODAY in real world applications. :-)
>>
>>> 3) We also need to spend time and energy on other issues
>>> requested from our customer and ISV community -- OS
>>> performance, network OLE, enhancing the interface and shell,
>>> etc. Many other interesting features are just at a lower
>>> priority.
>
>Why can't fork fit in with these other issues? Seems to me that making you
>OS more compatible with C/C++ and Perl alone is a big benefit to your users,
>not just an interesting feature.
>
>
>>Microsoft doesn't have the resources to do a decent port of fork()? Am
>>I reading too much into this? Hire a contractor for 6 months, have
>>s/he do a wonderful job and make 100's or developers happy and later,
>>thousands of users happy. You folks have a pretty handsome profit
>>margin and seem to be interested in making customers happy.
>>
>>Well...let's do it and bury this issue once and for all. Heck, don't
>>even support it, give it do me and I'll tell my boss I did it! :-)
>>
>>> As always, we continue to evaluate our decisions as customer
>>> needs evolve, so please send comments and complaints re: OS
>>> issues directly to me.
>
>The need is evolving and growing. Case in point, a year ago I didn't have a
>clue what the internet was, and didn't care if I could port Unix Perl
>scripts, Unix C/C++. I do now, and I doubt I am all that unique in this
>respect. More and more users are getting on the Internet everyday. Think
>that through.
>
>>This need has not evolved - it's always been there, right up there
>>with a decent telnet server, but don't get me started on that.
>>
>>Sorry if this sounds harsh, I'm just feeling left 'cause we have
>>fork() on UNIX and I can't use it on NT 'cause it ain't there. Thanks
>>for listening/reading.
>>
>>Sarir
>>
>>--
>>Sarir (Riri) Khamsi
>>khamsi@mathworks.com
>>w:508-647-4338
>>h:617-641-3013
>
>Win
>
>
>
>
>

My apologies if I stepped on toes or appeared unresponsive to your opinion.
However, you're asking for something that is fundementally non-trivial to
do and are unwilling to take the our word for it. It's not something as
simple as setting an intern on it for a couple of months. If it were, don't
you think we would have done so? The semantics of fork() are that the new
process inherits the entire state of the existing process. This is a very
Unix-centric way ot looking at the world and as I tried to state in my post
below, NT/Win32 is not Unix. It was never designed to be a Unix clone.

Now, if the NT perl implementation were to be written as a POSIX app that
only worked with the POSIX subsytem in NT, it could call fork() all day
long. However, you'd lose access to the rest of Win32. No OLE, no Event
Viewer, no Registry, no access to the rest of the Win32 API set, etc. This
is just the way it is. If the Perl developers were to implement some other
more OS neutral method for creating new threads/processes and it didn't
depend on the Unix way of doing things, there would be no problems for
non-UNIX implementations. fork() is no more OS neutral than CreateWindow()
is and to jump all over MS for not supporting it is not right.

Bryan
----------
From: win[SMTP:win@msilink.com]

At 04:11 PM 12/8/95 -0800, Bryan Tuttle (Exchange) wrote:
>Oh please. Let's lighten up on the "Evil MS is unresponsive to users and
is
>forcing people to do things they don't want to do" slant this thread is
>taking. Every OS has features that other OS's don't have. NT doesn't
>support fork() in the Win32 subsystem. Neither does Win31 or Win95 or OS/2

>or MAC OS or DOS or any other OS that's not Unix. Know what? All of these

>have Perl implementations. It's also NOT Unix (repeat that phrase until
you
>understand what it means), not OS/2, not MAC OS, not Linix, etc.
>
>What happens if you write an perl script that uses NT's registry API's? or
>OLE? Or the Event viewer? Are you going to go whining to the people who
>port Perl to some flavor of Unix and complain that they don't support it?
> Do you call up your friendly Unix vendor and demand that they support
those
>features in the OS or you'll go complain publicly that they're
>"unresponsive" to your needs? Is this just an incredibly stupid thread or
>what?
>
>Bryan
>
>P.S. No I don't speak officially for MS. I just work here.
>----------
You also have poor customer service skills too Bryan. While you may not
agree with what we are saying, we are the people that buy the product
Microsoft sells. I deserve respect as a customer, and I have a right to
voice my opinions on what a product I buy or am considering buying supports.

If I went into a retail establishment and asked them to provide a product
which they weren't, I would be offended if they were to reply along the
lines you did. While they may not respond to my needs, as a customer they
should treat me with respect when they decline.

Look at the points we are making, argue for or against, but give us
respect.


Win



>From: win[SMTP:win@msilink.com]
>Sent: Friday, December 08, 1995 3:42 PM
>To: Sarir Khamsi
>Cc: Tim Davis (Exchange); perl-win32@mail.hip.com;
djah@cix.compulink.co.uk
>Subject: Re: Multi-threaded server
>
>At 01:58 PM 12/8/95 -0500, Sarir Khamsi wrote:
>>>>>>> <Tim Davis> writes:
>>
>>> Microsoft does not currently plan to add this infrastructure
>>> into NT or Win9x for several reasons, including:
>>
>>> 1) The fork() functionality does not follow the threading
>>> model very well. We want to move forward toward more
>>> efficient code.
>>
>>Please correct me if I am wrong, but fork() does not appear to be a
>>multi-"threaded" approach, but instead, a multi-process approach. I'm
>>not surprised it does not follow the threading model well and I'm
>>NOT sleeping worse as a result.
>>
>>> 2) Most of the requests for fork() are for compatibility
>>> with UNIX legacy code. While this compatibility is
>>> important, the amount of work needed to change most
>>> applications from relying on fork() behavior to using
>>> threads is relatively small compared to other porting issues
>>> (Yes, I know there are many exceptions :).
>>
>>With great humility and respect, I must say that this is a very
>>Microsoft-centric view of the world. Some of us (developers) have to
>>support more than one platform that does not include a Microsoft
>>OS. Please understand that I'm not trying to be sarcastic, just
>>honest. From the outside, there is at least the "appearance" that
>>Microsoft is forcing users/developers to do things their way.
>
>Micorsoft forcing users/developers to do things thier way is what I got
from
>this too. Which taking it further means they aren't listening to thier
>customers. Perhaps thier feelings are it is only the developers that want
>fork, and the developers will continue to support nt/windows because the
>money is there. If that is the case, then they have it wrong. I am not a
>developer, but a user. I do know a very little C/C++ and Perl. With
>support for fork() it would be much easier for me to port files for my use.
>Perhaps Microsoft has underestimated the amount of thier customers that
>would appreciate that power? The other alternative is they aren't willing
>to listen to thier customer's needs and wants, which is true to the way
many
>people view Microsoft now.
>
>>Also, fork() appears in C/C++ code AS WELL as Perl code. All
>>Microsoft has to do is write a fork() and existing (and future) code
>>should work. What's our other option? Microsoft and the major UNIX
>>players all sit down and see how to work out a "better" threading
>>model? I don't think so.
>>
>>As for fork() being used for "UNIX legacy code", some of by best
>>friends are writing such code TODAY in real world applications. :-)
>>
>>> 3) We also need to spend time and energy on other issues
>>> requested from our customer and ISV community -- OS
>>> performance, network OLE, enhancing the interface and shell,
>>> etc. Many other interesting features are just at a lower
>>> priority.
>
>Why can't fork fit in with these other issues? Seems to me that making you
>OS more compatible with C/C++ and Perl alone is a big benefit to your
users,
>not just an interesting feature.
>
>
>>Microsoft doesn't have the resources to do a decent port of fork()? Am
>>I reading too much into this? Hire a contractor for 6 months, have
>>s/he do a wonderful job and make 100's or developers happy and later,
>>thousands of users happy. You folks have a pretty handsome profit
>>margin and seem to be interested in making customers happy.
>>
>>Well...let's do it and bury this issue once and for all. Heck, don't
>>even support it, give it do me and I'll tell my boss I did it! :-)
>>
>>> As always, we continue to evaluate our decisions as customer
>>> needs evolve, so please send comments and complaints re: OS
>>> issues directly to me.
>
>The need is evolving and growing. Case in point, a year ago I didn't have
a
>clue what the internet was, and didn't care if I could port Unix Perl
>scripts, Unix C/C++. I do now, and I doubt I am all that unique in this
>respect. More and more users are getting on the Internet everyday. Think
>that through.
>
>>This need has not evolved - it's always been there, right up there
>>with a decent telnet server, but don't get me started on that.
>>
>>Sorry if this sounds harsh, I'm just feeling left 'cause we have
>>fork() on UNIX and I can't use it on NT 'cause it ain't there. Thanks
>>for listening/reading.
>>
>>Sarir
>>
>>--
>>Sarir (Riri) Khamsi
>>khamsi@mathworks.com
>>w:508-647-4338
>>h:617-641-3013
>
>Win
>
>
>
>
>

Message-ID: red-35-msg951209023101MTP[01.51.00]000000ad-31912

If I understand Tom's position here, the Win32 API and the POSIX API
should be simultaneously available to the same program. Otherwise,
"Microsoft has played legal games to avoid the spirit of of the law".

Balderdash!

Perhaps this is too hasty, since I'm assuming he knows fork() is
available to POSIX processes. (That is, processes which interact
with the Windows NT kernel via the POSIX subsystem.) If he was
ignorant of this fact, perhaps his polemics have some basis, in his
own world-view. But I must presume that he is not spouting off on
something he knows so little about.

If I can articulate the complaint more clearly, it is that fork() is not
available to Win32 processes, (and this constitutes "legal games").
And of course, one should substitute all the other POSIX system
calls for "fork()" and thereby compound the complaint.

As a heavy user of and developer for Windows NT, I'd like to
thank its designers for knowing better. As a user, I'm thankful to
not pay the cost in memory footprint and reduced robustnest that
would result from conglomerating the API's. As a developer, I'm
glad that the Win32 API documentation does not have to mention
the multitude of subtle interactions that would occur between the
two (or more!) API's, or that might be expected or desired, but do
not or cannot occur. I'm especially glad that signal() and friends
are becoming a dim memory and that I can make things happen
concurrently without having to replicate my whole process image
or use cumbersome, slow IPC methods to communicate between
tasks that are supposed to be closely coupled.

If you want a POSIX version of Perl, adjust the makefile and build
it. You'll find that it's pretty painless. Just be sure to switch out any
Win32 API calls. (And please, don't complain on this alias about
having to do so.) Then, you can run it under Windows NT and fork(),
exec(), and all those fun things, or even launch Win32 processes
and communicate with them, if you so desire. Of course you'll pay
the above-mentioned penalties that the fork() strategy exacts.

I can imagine fork() being added to the Win32 API, in response
to user requests. I can also imagine millions of users studying
the actual consequences of such a thing in practise, and then
electing to forego the compromise that it would represent. Since
the issue will never get that much attention, the product managers
and technical experts at Microsoft have to decide what is right
based on many factors, including the expressed and estimated
desires of present and future customers.

If you have some new thought to contribute to that process, do it.
If you direct your input properly, (to ntwish@microsoft.com, or your
local Windows NT sales representative, perhaps), and put some
thought into it, after considering the whole issue carefully, you have
an excellent chance of being listened to. But, since we are people
too, try to filter out any negative, non-factual, ill-reasoned innuendo;
this will help your message to get the consideration it deserves.

I am not an authorized Microsoft spokesman, but I am sure I
speak for many of us who work for Microsoft when I say that the
"big bad heartless Microsoft" theme gets wearisome. Having
personally participated in the process of trying to determine
what will please customers, and having read voluminous
customer comment on existing and potential features, I can
honestly say that the "Microsoft does not listen" harangue is
far removed from reality. To assume and allege such because
particular features are present or absent from some Microsoft
product is to display a misunderstanding of the high-volume
software business. (It displays some personal characteristics
also, but those are of little general interest.) Before leaping
to defamatory conclusions, consider the whole problem and
give the people trying to solve it credit for being, on average,
as decent as your neighbors probably are. Try to overcome
the temptation to vilify whole groups of people. It will never do
any good, and will usually be wrong and counterproductive.
----------
| From: Tom Christiansen <tchrist@mox.perl.com>
| To: "Ciechanowski, Chet" <cjc@dsc.com>
| Cc: perl-win32 <perl-win32@mail.hip.com>; <tchrist@mox.perl.com>
| Subject: Re: Multi-threaded server
| Date: Friday, December 08, 1995 3:33PM
|
| >Programmers who are truly concerned about portable code should
| >avoid the use of fork() (or Win32 threads for that matter),
| >instead of complaining when an OS doesn't support every UNIXism
| >(or Whateverism).
|
| >Perl is the closest thing I'm familiar with that provides a
| >platform-independent scripting language. It could have been
| >better if it was *designed* for multiple platforms, then fork()
| >would be a UNIX extension, just as OLE is a WIN32 extension.
| >If you use an extension, then you give up portability.
|
| Perhaps it would have been more effective if WindowsNT, a POSIX-compliant
| systme by legal dictum, would in fact actually run POSIX-compliant code, of
| which fork() is but one such call.
|
| That's why POSIX exists: as a portable operatings sytems interface. That
| Microsoft has played legal games to avoid the spirit of of the law should
| not cause you to disparage POSIX calls for portablility -- THAT'S WHAT IT
| WAS DESIGNED FOR!@
|
| --tom
|

"Tim Davis (Exchange)" <TimDa@EXCHANGE.MICROSOFT.com> wrote:

> Okay, time for my periodic fork() message.

Honestly, this read more like propaganda to me.

[snip]
> Microsoft does not currently plan to add this infrastructure into NT or
> Win9x for several reasons, including:
>
> 1) The fork() functionality does not follow the threading model very well.
> We want to move forward toward more efficient code.
>
> 2) Most of the requests for fork() are for compatibility with UNIX legacy
> code. While this compatibility is important, the amount of work needed to
> change most applications from relying on fork() behavior to using threads is
> relatively small compared to other porting issues (Yes, I know there are
> many exceptions :).

How can your company *honestly* purport to be offering POSIX compliant
operating systems when in fact your operating systems don't even
support the fork() system call in a *useful* manner?

fork() is a POSIX call; anybody who clings to the notion that this
call is Unix specific is at best misguided.

IMHO, if perl uses the POSIX subsystem of an OS and something breaks
because of this, the problem clearly lies within the OS, not perl.

I am not speaking for my company.

-kevin

PS I would just like to thank everyone who made perl into such a such
a great language.

On Fri, 8 Dec 1995, Bryan Tuttle (Exchange) wrote:

> My apologies if I stepped on toes or appeared unresponsive to your opinion.
> However, you're asking for something that is fundementally non-trivial to
> do and are unwilling to take the our word for it. It's not something as
> simple as setting an intern on it for a couple of months. If it
> were, don't you think we would have done so? The semantics of fork()
> are that the new process inherits the entire state of the existing
> process. This is a very Unix-centric way ot looking at the world and
> as I tried to state in my post below, NT/Win32 is not Unix. It was
> never designed to be a Unix clone.
[...]

Hasn't Cygnus already incorporated a working fork() into the gnu-win32
toolchain?

Quoting from the gnu-win32 FAQ
(ftp://ftp.cygnus.com/pub/sac/gnu-win32-b10/faq.html):

" fork and exec are provided."

If this is the case, then I don't see what the problem is.

(I've added the gnu-win32 mailing list to the CC: because I think this
discussion is relevant.)

Brian Jepson (bjepson@conan.ids.net)
Director of Advanced Technology, Prosoft Systems International, Inc.