Thanks Ben,

On Sun, Jan 11, 2015 at 12:36:14PM +0800, Ben Coman wrote:
> On Windows 7, trying to execute a non-existent program as follows...
>     OSProcess command: 'notepadXX.exe'
> 
> ...causes an MNU in ExternalWindowsOSProcess>>value. This is due to writing
> to stderr where "self initialStdErr" returns nil, seemingly due to
> ExternalWindowsOSProcess missing the #initialize and #setDefaults of E
> xternalUnixOSProcess.

I made the change to prevent this error, and committed it to the OSProcess
repository.

> 
> Now I understand that stderr is problematic in general on Windows.
> The following statements...
>     OSProcess thisOSProcess stdErr nextPutAll: 'test'.
>    FileStream stderr nextPutAll: 'test'.
> 
> ...both work fine on OSX, but fail on Windows with the error
> "FileWriteError: File stderr is closed"
> The result is the same on both Pharo 4 and Squeak 4.5.
> (Squeak also brings up a bottom message bar saying... "# To disable: F2 ->
> 'debug options' -> 'show console on errors' WARNING: Manufactured file
> handle detected!")

A word of explanation is in order here. There is a handle registry in the
Windows support code for FilePlugin that was added specifically to prevent
use of "manufactured" file handles. I think that the idea was enhance
security, although in practice the only effect is to prevent OSProcess
from attaching to pipes and stdio streams.

A workaround would be to provide an external FilePlugin dll with the
handle registry disabled.

> 
> Pharo has a workaround for the general issue by creating a disk file
> named 'stderr'
> as follows...
>     FileStream class >> standardIOStreamNamed: moniker forWrite: forWrite
> self flag: #todo. "This is an ugly hack, while waiting for a real fix for
> windows. There  several problems with this approach, but it allow us to run
> tests, etc."
> Smalltalk os isWin32
> ifTrue: [
> [ ^ MultiByteFileStream forceNewFileNamed: moniker asString ]
> on: CannotDeleteFileException do: [
> "HACK: if the image is opened a second time windows barks about the already
> opened locked file"
> ^ MultiByteFileStream forceNewFileNamed: moniker asString, '_', (Random new
> nextInt: SmallInteger maxVal) asString   ]].
> 
> So to address the MNU for OSProcess?
> 1. wrap the "self initialStdErr" with an #ifNil: check
> 2. Squeak adopt the Pharo workaround, then lean on that to define
> #initialize and #setDefaults for ExternalWindowsOSProcess
> 3. real fix for stderr (outside of OSProcess?)
> 4. wont fix
> 5. other?
> 
> 
> Note that this is not a burning issue for me. I am just cleaning out old
> issues that I logged in the Pharo bug tracker.  If the answer if (4.)  I'll
> just close the issue [1].

I did #1, and hopefully that will take care of the issue.

> 
> 
> For both Squeak and Pharo, I
> loaded ConfigurationOfOSProcess-ThierryGoubier.33 from...
>     MCHttpRepository
> location: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main'
> (Perhaps someone with access can copy that to the main repo)
> 

I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess
repository. An update to ConfigurationOfOSProcess will be needed to
get the latest version (Thierry, can you do this?).

For Squeak, no ConfigurationOfOSProcess is needed, just use the latest
version (with SqueakMap, or currently it OSProcess-dtl.93 in the repo).

Pharo should also use the latest version if possible, although the
Metacello configurations are needed to make things work on various older
Pharo versions. The versions for a current spec would be:

  OSProcess-Base-dtl.46
  OSProcess-Unix-dtl.20
  OSProcess-Win32-dtl.12
  OSProcess-Mac-dtl.2
  OSProcess-OS2-dtl.2
  OSProcess-RiscOS-dtl.2
  OSProcess-AIO-dtl.8
  Tests-OSProcess-dtl.21

> 
> cheers -ben
> 
> [1] https://pharo.fogbugz.com/default.asp?11615

Thanks a lot for reporting this!

Dave