Re: Beta-test version of NSMessagePort on windows (mingw32) ready

[Richard Frith-Macdonald]

I got zero response to my announcement of NSMessagePort/ 
NSMessagePortNameServer for mingw32 last Thursday.

So ... I removed the GSMailslot user default I had added to turn the  
new messageport support on, and made the system use the new code by  
default.

You can still use NSSocketPort by setting the NSPortIsMessagePort  
user default (as on unix where the NSMessagePort implementation is  
completely different from the mingw32 one, and well tested), but the  
new code will be used unless you specifically set the default to use  
the old code.  Hopefully this will get me some bug reports ... but  
not leave anyone stuck with broken applications (because they can  
just set the user default to get the old behavior).

For anyone who's not aware of this ... the next release (the current  
CVS code) of the base library will see the default behavior of  
distributed objects connections changed to use ports which are host- 
local and private to the current user (the NSMessagePort and  
NSMessagePortNameServer classes) rather than allowing connections to  
be established across the LAN (the NSSocketPort and  
NSSocketPortNameServer classes) as in NeXTstep/OpenStep.  This new  
behavior is MacOS-X compatible, makes inter-process communications  
fairly secure by default, and avoids the need to run a nameserver  
daemon (gdomap) unless you really want to have public inter-host  
communications.

Setting the user default NSPortIsMessagePort to NO will revert to the  
old behavior, using NSSocketPort for default connections, but I  
anticipate that we will remove this option some time in the future  
when we can expect all applications to be explicitly using  
NSSocketPort if they want inter-host/inter-user connections.