Ok.  I thought I had done this as you asked, but perhaps I regenerated and 
it overwrote this again.  I'll check tonight, after work.

Thanks,
Rob

--------------------------------------------------
From: "David T. Lewis" <lewis at mail.msen.com>
Sent: Tuesday, July 27, 2010 9:09 AM
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog

> This is probably because of the Windows handle registry that I mentioned
> earlier in this thread. You will need to disable the handle check.
>
> What is happening here is that the FilePlugin (on Windows) is maintaining
> a registry of valid handles, and it only recognizes handles created
> by itself as valid. When OSProcess gives it some other handle (e.g.
> the handle for standard output or for an OS pipe handle) the primitives
> in FilePlugin will fail. This is a feature that was added to Windows
> FilePlugin some time after I wrote the Windows OSProcess stuff (long
> ago), and for now the workaround is just to disable the registry check.
>
> Dave
>
> On Tue, Jul 27, 2010 at 03:47:02AM -0400, Rob Withers wrote:
>> Thanks, David, I was able to generate unix plugins on Windows and build
>> them on unix.
>>
>> I am still having problems outputting to stdOut on both unix and Windows.
>> I cannot tell the issue on unix since I am headless.  On Windows it
>> complains that stdOut accessor is closed.   Here is the script I am using
>> in both cases:
>>
>> ThisOSProcess thisOSProcess stdOut
>>        nextPutAll: 'hello world';
>>        flush.
>>
>> Is the something I need to be doing to open the accessors before using 
>> them?
>>
>> Thanks,
>> Rob
>>
>> --------------------------------------------------
>> From: "David T. Lewis" <lewis at mail.msen.com>
>> Sent: Monday, July 26, 2010 11:31 PM
>> To: "The general-purpose Squeak developers list"
>> <squeak-dev at lists.squeakfoundation.org>
>> Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
>>
>> >On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
>> >>
>> >>On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis <lewis at mail.msen.com>
>> >>wrote:
>> >>
>> >>> On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
>> >
>> ><snip>
>> >
>> >>> > Third, I set self halts in UnixOSProcessPlugin
>> >>> > class>>#shouldBeTranslated
>> >>> > and Win32OSProcessPlugin class>>#shouldBeTranslated.   The unix 
>> >>> > side
>> >>> > eventually calls:
>> >>> >
>> >>> > UnixOSProcessPlugin class>>#isResponsibleForThisPlatform
>> >>> >       "Answer true is this is an instance of the class which is
>> >>> >       responsible for representing
>> >>> >       the OS process for the Squeak VM running on the current
>> >>> > platform. A
>> >>> >       false answer is
>> >>> >       usually the result of running the image on a different 
>> >>> > platform
>> >>> > and
>> >>> >       VM.
>> >>> >       Note: Keep this method is sync with OSProcess>>isUnix."
>> >>> >
>> >>> >       | numericOsVersion |
>> >>> >
>> >>> >       ^ (self platformName = 'unix') or:
>> >>> >               [numericOsVersion := self osVersion asInteger ifNil:
>> >>> > [0].
>> >>> >               (self platformName = 'Mac OS') and: [numericOsVersion
>> >>> >  >=
>> >>> >               1000]]
>> >>> >
>> >>> > and this calls:
>> >>> >
>> >>> > OSProcessPlugin class>>#platformName
>> >>> >       "After Squeak version 3.6, #platformName was moved to
>> >>> SmalltalkImage
>> >>> >       "
>> >>> >
>> >>> >       ^ ((Smalltalk classNamed: 'SmalltalkImage')
>> >>> >               ifNil: [^ Smalltalk platformName]) current 
>> >>> > platformName
>> >>> >
>> >>> > which kills any hope of being a cross-compiled source.
>> >>>
>> >>> No worries there. The C source is not supposed to be cross-compiled.
>> >>> The
>> >>> implementations in Slang/Smalltalk are completely different for Unix
>> >>> and
>> >>> Windows, and the resulting generated code (UnixOSProcessPlugin.c and
>> >>> Win32OSProcessPlugin.c respectively) are completely different as 
>> >>> well.
>> >>> When building a VM to run on Unix/Linux/OSX you would be compiling 
>> >>> the
>> >>> UnixOSProcessPlugin.c, and when compiling a VM for Windows you would
>> >>> compile Win32OSProcessPlugin.c.
>> >>>
>> >>>
>> >>Cross-compilation is quite separate from generation.  Cog is
>> >>intentionally
>> >>modified to spit out exactly the same source tree irrespective of
>> >>platform.
>> >
>> >Understood.
>> >
>> >> Needing a different VMMaker generation step for each platform is IMO 
>> >> an
>> >>absurdity.  Whether a plugin is compiled or not then depends on the
>> >>plugins.int and plugins.ext files in each build directory.  So the 
>> >>intent
>> >>is
>> >>to always spit out the UnixOSProcessPlugin source but only compile it 
>> >>on
>> >>Unix platforms, as selected by plugins.int & plugins.ext.
>> >>
>> >>I notice I've not included my version of Win32OSProcessPlugin in Cog.
>> >>I'll
>> >>rectify that this evening.
>> >
>> >I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work
>> >properly with CrossPlatformVMMaker, and to continue working as before
>> >with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce
>> >the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin,
>> >and should result in all of these being generated when running Squeak
>> >on Windows.
>> >
>> >
>> >www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23
>> > www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10
>> >
>> >www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8
>> >
>> >Dave
>> >
>> >
>