Hacker News Reader

Comment by akoeplinger | Hacker News Reader

I just wanted to point out that there's nothing that inherently ties PowerShell to Windows (as expected, it's just a shell after all).

> PowerShell provides direct access to [nearly?] the entire Windows OS

PS has access to the .NET Framework which abstracts the OS APIs, not really to Windows directly.

There's also chatter that MS is already working on porting PowerShell to CoreCLR/.NET Core (the cross-plat, open-source version of .NET).

View on HN

The abstraction layer is 'thinner' with Windows. With *nix we're dealing with serializing text with regexes or parsers or both coming in and deserializing to text on the way out.

It's a bit of a Turing tarpit when it comes to non-inherency.

Couple of points:

1. PowerShell reimplements older commands as aliases, e.g. ls is an alias for Get-ChildItem. You'd not be relying on existing shell functionality.

2. I don't know much about it, but wouldn't the upcoming Linux IPC improvements being made to support kdbus do away with needing to handle message passing in the way you describe?

PowerShell's get-childItem returns something on which get-methods can be called. How will the improved IPC create an easy systematic way of creating meaningful responses to "get-methods" system-wide?

dbus makes use of a type system to describe messages passed over it. kdbus is an implementation of dbus at the lowest level of the OS. The IPC improvements to support kdbus will be made at the kernel level. At a higher level, systemd will make use of these same processes, so it's not purely internal to the kernel. Therefore, there's no restriction on building an object-oriented approach to interfacing with the OS, which is what PowerShell uses.

Perhaps my logic is off, or my view is missing key information, but from my novice perspective it seems to make sense.

If you're interested, this page has more information on the type system used in dbus: http://dbus.freedesktop.org/doc/dbus-specification.html#type...

I think it would require rewriting a lot of existing 'nix code to achieve the level of OS integration that PowerShell provides for Windows, that's aside from the level of integration PowerShell has with many Windows applications [e.g. Office].

Microsoft has been integrating interprocess communication into Windows since DDE in version 2.0 almost 30 years ago. Then more than a decade of OLE. Then more than a decade of .NET. At this point it and the reflection it enables are baked into the toolchain and pretty much comes along for free on a project. *nix has many advantages but everybody rowing in the same direction is not among them.

Reply on news.ycombinator.com