Download OSProcessPluginV4-2-6.sar. Supports both 64 bit and 32 bit image and VM on both 64 bit and 32 bit hardware.
UnixOSProcessPlugin.bundle is the carbon based OSX plugin, it is bundled with the Squeak 3.8.18beta1U.app OSX carbon VM. Built with help from Eliot Miranda and John McIntosh
OSProcessPlugin (OSPP) provides access to Unix/Linux and Windows operating system functions. OSPP is used by OSProcess for low level system access. Stub classes are provided for other operating systems (help welcome here).
OSProcessPlugin contains the complete source code for the Unix and Windows OSProcessPlugin (OSPP). Generate the plugin with VMMaker. No external support code is required.
See also XDisplayControlPlugin, which contains the X display support primitives previously included in OSPP, and AioPlugin, which contains the asynchronous I/O event forwarding primitives previously included in OSPP.
Changes in OSPP 4.2.4 since 4.2.5:
Fix variable declaration in Win32OSProcessPlugin>>handleFromSQFile:
Implement primitiveSetPGrp as setpgid(0,0) rather than setpgrp() for compatibility between Linux and OS X (thanks to Josh Gargus for the fix).
Fixed #primitiveIsAtEndOfFile, restoring its original correct return value. Several versions of OSPP in the 4.x series have this wrong. This primitive has been deprecated and replaced with #primitiveTestEndOfFileFlag.
Version 4.2.3
Add support for setsid(), setpgrp(), getpgrp(), setpgid(), getpgid() session management functions.
Add primitiveKillOnExit, which arranges for child processes to be signalled when the VM exits, even if normal shutdown processing did not occur.
Miscellaneous cosmetic updates, and add some missing signal functions for consistency.
Version 4.2.2
Fixed pthread_t declaration in #isVmThread method. This resolves a problem with signal handlers on 64 bit hosts with 32 bit images.
Version 4.2.1
Fix underscores. No functional changes.
Version 4.2
Declare some (FILE ) casts to address compiler warnings reported by Steve Elkins.
Eliminate as many #cCode: calls as possible. Reorganize and simplify many methods.
Add #shouldBeTranslatedFor: to support VMM cross generation.
#primitiveIsAtEndOfFile gives wrong result (true/false reversed). Therefore marked #primitiveIsAtEndOfFile as deprecated, replacing it with new #primitiveTestEndOfFileFlag. OSProcess will work around this by using the new prim if available, else use old prim with result negated. Note that the original prim is not fixed, as this would cause backward compatibility issues with e.g. new OSP running on old OSPP.
Version 4.0.2
Add pthread access primitive.
Add pthread signal masking to ensure that forwarded signals are delivered to the interpreter thread. This is required for OS X. Strategy: Signal handler checks to see if it is executing in the context of the interpreter pthread. If yes, signal the Squeak semaphore, otherwise mask this pthread to prevent future delivery if this signum and resend the signal to the interpreter pthread.
Provide 64-bit compatibility. The OSPP plugin now compiles and runs for both 32 bit and 64 bit Unix VMs and executes on 32 or 64 bit hardware. The Win32 OSPP remains 32 bit based and has not been tested on 64 bit Windows or 64 bit hardware.
The plugin can now obtain the session ID from the interpreter for newer versions of the VMMaker and support code. Previously this required either a customized VM, or it required OSProcess to deduce the session ID from an existing open file.
Unnecessary subclasses of UnixOSProcessPlugin and Win32OSProcessPlugin have been eliminated.
Add fix for missing Win32 method (error in earlier refactoring). Some recent versions of this package had left the Win32 OSPP untested, with errors that prevented compilation. This is now fixed.
Many changes and additions to Win32OSProcessPlugin. These are a merge of my development image changes intended for a future release of OSProcess. Backward compatibility has (hopefully) been maintained.
Added primitiveForkExec, which will replace the now deprecated method primitiveForkAndExecInDirectory. The new primitive does not attempt to handle SIGPIPE. Instead the caller is expected to have set up a signal handler using the generalized signal forwarding mechanism.
Added primitiveCreatePipe, which will replace the now deprecated method primitiveMakePipe. The new primitive does not attempt to handle SIGPIPE. Instead the caller is expected to have set up a signal handler using the generalized signal forwarding mechanism.
Various primitives and methods have been moved to category 'deprecated'. These will be removed in some future release of OSPP after corresponding image side changes in OSProcess have been in place for a while.
Various minor refactorings.
Version 3.2OSProcessPluginV3-2.sar(January 6, 2004. Latest version, including Unix file locking primitives)
Version 3.2 adds file locking primitives for Unix, and removes remaining dependencies on X window.
Version 3.1.1OSProcessPluginV3-1-1.sar+ (August 13, 2003)
Version 3.1.1 adds OSProcessPlugin>>initialiseModule (left out of 3.1 change set).
Changes in version 3.1 since version 3.1.7:
Moved all X display management from OSPP to a separate XDisplayControlPlugin
Removed X display references from primitiveForkSqueak methods
Fix OSPP code generation so it works without OSProcess loaded
Fix transentCStringFromString: to be GC safe.
Removed primitiveRename (obsolete)
Fix primitiveRealPath so it does not get scrambled by GC.
Prior to version 3.0.6, OSProcessPlugin was distributed as part of the OSProcess change set.
Changes in OSProcessPlugin since the prior version released in OSProcess 3.0.5:
Fixed an error in the Unix signal handler (due to a typo by yours truly in the last patch release, version 3.0.5). Without this fix, it is possible for the VM to exit without any error message or stack trace (this is the 'normal' behavior of the VM on receipt of a SIGPIPE signal). I am not aware of this happening in practice for any current OSProcess users, but it did happen to me in the course of reimplement some new CommandShell pipeline methods, so I consider this an important fix.
Made various fixes to maintain compatibility with VMMaker code generation.
Fixed OSProcessPlugin class>>installedModule so it works even if the plugin classes were loaded without VMMaker (in which case InterpreterPlugin does not exist in the image).
