Sven wrote:

OK, that works, thanks.

Pretty straightforward NativeBoost based code, small.

I seem to be missing the platform independence code (but I only care for OS X and Linux for my projects).

How does this relate to OSProcess ? Why did you start it ? What is the goal ?

OSProcess is nice - but it requires a plugin, compilation, etc. It also only covers some basic functions that are sharable for platforms. Using NativeBoost allows for speed and easy changeability in Pharo itself. I started "OS" because I required more and more things from Windows that OSProcess can never cover. Later beside "OS-Windows" I added other platforms like "OS-Unix"/"OS-Ubuntu". The "OS" project tries to provide the same interface for things that are close in each operating system but still includes things that are available on specific platforms only like Windows. For instance in Windows there is the Windows registry - you can access it with this project. It would not make sense to have this for Unix systems. Another example: the OS-Linux-Ubuntu-Environment package includes a class UbuntuShell that you can use the open the gnome system monitor. You can use it if you are on this particular platform by evaluating UbuntuShell systemMonitor If on another platform it would not make sense to use it. Still while allowing to be as much "as native" as possible with the platform it is/should be possible to keep some kind of "platform independence". This could be done by using same naming and compatibility could be enforced by Tests (because of the lack of "interfaces" in Smalltalk) and similar naming: UnixProcess currentProcessId WinProcess currentProcessId Anything other is explained in http://www.smalltalkhub.com/#!/~OS/OS-Windows I hoped other jumped onto the bandwagon to help because at least on Mac I'm currently lost (until I access to an iOS machine). Currently I do not invest too much into it - especially because of this bad feeling that was given that NativeBoost might not be continued and I heard about planes on refocusing back to (slower) FFI later. So far NativeBoost served all my needs well and it would be a pitty if I would have to redo all bindings later. :( Bye T.

Sven wrote:

OK, that works, thanks.

Pretty straightforward NativeBoost based code, small.

I seem to be missing the platform independence code (but I only care for OS X and Linux for my projects).

How does this relate to OSProcess ? Why did you start it ? What is the goal ?

OSProcess is nice - but it requires a plugin, compilation, etc. It also only covers some basic functions that are sharable for platforms. Using NativeBoost allows for speed and easy changeability in Pharo itself. I started "OS" because I required more and more things from Windows that OSProcess does not cover. Later beside "OS-Windows" I added other platforms like "OS-Unix"/"OS-Ubuntu". The "OS" project tries to provide the same interface for things that are close in each operating system but still includes things that are available on specific platforms only like Windows. For instance in Windows there is the Windows registry - you can access it with this project. It would not make sense to have this for Unix systems. Another example: the OS-Linux-Ubuntu-Environment package includes a class UbuntuShell that you can use the open the gnome system monitor. You can use it if you are on this particular platform by evaluating UbuntuShell systemMonitor If on another platform it would not make sense to use it. Still while allowing to be as much "as native" as possible with the platform it is/should be possible to keep some kind of "platform independence". This could be done by using same naming and compatibility could be enforced by Tests (because of the lack of "interfaces" in Smalltalk) and similar naming: UnixProcess currentProcessId WinProcess currentProcessId Anything other is explained in http://www.smalltalkhub.com/#!/~OS/OS-Windows I hoped other jumped onto the bandwagon to help because at least on Mac I'm currently lost (until I access to an iOS machine). Currently I do not invest too much into it - especially because of this bad feeling that was given that NativeBoost might not be continued and I heard about planes on refocusing back to (slower) FFI later. So far NativeBoost served all my needs well and it would be a pitty if I would have to redo all bindings later. :( Bye T.