<div>Hi,<br></div><div><br></div><div>For me it does something sensbile on MacOS 10.15.7 and on Windows.  Both with Squeak 6.0.</div><div ><br></div><div >cheers<br></div><div ><br></div><div >bruce<br></div><div ><br></div><div class="ik_mail_quote answerContentMessage" ><div>On 2023-03-31T04:06:12.000+02:00, David T. Lewis <lewis@mail.msen.com> wrote:</div><blockquote class="ws-ng-quote"><pre style="white-space: normal;">On Wed, Mar 29, 2023 at 06:13:55PM -0700, tim Rowledge wrote:<br/><blockquote class="ws-ng-quote">  We've had a few discussions about this issue over the years and never really decided on anything more certain than "er, well..."<br/> <br/> There's certainly a bigger discussion around moving to the 'new networking' setting but for this one particular query it seems to me that using the code currently in NetNameResolver class>>#localHostName that gets ignored by the #useOldNetwork option is a good option. That is, <br/> <br/> localHostName<br/>  "Return the local name of this host."<br/>  "NetNameResolver localHostName"<br/> <br/>  | host |<br/>  host := String new: NetNameResolver primHostNameSize.<br/>  NetNameResolver primHostNameResult: host.<br/>  ^host<br/> <br/> returns a value that seems to be helpful, and that is retrieved via the unix function gethostname(), which is used by the hostname command. Are there any problems with the idea of using this?<br/><br/></blockquote> <br/>Could someone please test this on Windows and Mac? To test it,<br/>use Tim's change above, then find the 'Enable IPv6 and new network<br/>support' preference in category 'General' in the preference browser.<br/><br/>Turn the preference on and off, and see if the localHostName method<br/>answers something sensible in both cases.<br/><br/>It looks right to me on Linux but results may be different on other<br/>platforms.<br/><br/>Thanks,<br/>Dave</pre></blockquote></div>