4 ms·

OS X gets this right. Activity Monitor, essentially the OS X equivalent to the Windows Task manager, shows all types of processes. Furthermore, OS X's "Apps Usi

OS X gets this right. Activity Monitor, essentially the OS X equivalent to the Windows Task manager, shows all types of processes. Furthermore, OS X's "Apps Using Significant Energy" list will contain Terminal if an app running within it is eating CPU.

tomsmeding 11y ago
That isn't a fair comparison. OSX is itself a unix system and as such, there isn't any work involved in showing all processes equal (they _are_ equal). In Windows, the subsystem is probably running an entirely different and separate process model, regulated by the kernel. That's way harder to nicely unify in task manager or something like that. (Disclaimer: I know zilch of the new linux subsystem on windows, so please forgive any errors)
- chris_wot 11y ago
  I don't know how bash is running processes, but I do know that there used to be a POSIX subsystem, and processes would show in the task manager.
  - TazeTSchnitzel 11y ago
    IIRC the POSIX subsystem was impure and its apps also used user32.dll and such, which might explain why its processes showed up.
    - chris_wot 11y ago
      Actually, the POSIX subsystem is part of the user mode portion of Windows. It's classed as an environmental subsystem. The portion of Windows that handles processes is in the kernel mode part of Windows, and is part of its executive subsystem - I believe Microsift call it the process manager. Windows just ran POSIX compliant programs in a POSIX environment, so the process manager shouldn't have had any problems. Edit: I researched this years ago whilst studying for the MCP, and documented it on Wikipedia [1] - I even drew a diagram in Word which has since been converted to SVG :-) Since then someone else has written an article about the POSIX subsystem of Windows and it notes: "The runtime environment of the subsystem is provided by two files: psxss.exe and psxdll.dll. A POSIX application uses psxdll.dll to communicate with the subsystem while communicating with posix.exe to provide display capabilities on the Windows desktop." [2] 1. https://en.m.wikipedia.org/wiki/Architecture_of_Windows_NT https://en.m.wikipedia.org/wiki/Architecture_of_Windows_NT 2. https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
manojlds 11y ago
This isn't about cmd or Powershell. Bash on Windows is a whole different beast, and it is early days.
barrkel 11y ago
Can you explain what exactly OS X gets right - which other operating system ABIs are involved?
- mrpippy 11y ago
  On OS X, every process on the system is a Unix process and has a PID, and is visible from the Unix APIs that Activity Monitor uses. Even when OS X had more diversity in binary formats (the Classic environment, Carbon CFM apps, emulated PPC binaries), everything was still a Unix process. I would say that OS X is just simpler, in that it doesn't use multiple subsystems which can each have totally separate process namespaces. What the Windows Task Manager should at least do is have a catch-all entry for a non-Win32 subsystem, so you can see that the Linux Subsystem is taking 100% CPU.

tomsmeding 11y ago

That isn't a fair comparison. OSX is itself a unix system and as such, there isn't any work involved in showing all processes equal (they _are_ equal). In Windows, the subsystem is probably running an entirely different and separate process model, regulated by the kernel. That's way harder to nicely unify in task manager or something like that. (Disclaimer: I know zilch of the new linux subsystem on windows, so please forgive any errors)

chris_wot 11y ago
I don't know how bash is running processes, but I do know that there used to be a POSIX subsystem, and processes would show in the task manager.
- TazeTSchnitzel 11y ago
  IIRC the POSIX subsystem was impure and its apps also used user32.dll and such, which might explain why its processes showed up.
  - chris_wot 11y ago
    Actually, the POSIX subsystem is part of the user mode portion of Windows. It's classed as an environmental subsystem. The portion of Windows that handles processes is in the kernel mode part of Windows, and is part of its executive subsystem - I believe Microsift call it the process manager. Windows just ran POSIX compliant programs in a POSIX environment, so the process manager shouldn't have had any problems. Edit: I researched this years ago whilst studying for the MCP, and documented it on Wikipedia [1] - I even drew a diagram in Word which has since been converted to SVG :-) Since then someone else has written an article about the POSIX subsystem of Windows and it notes: "The runtime environment of the subsystem is provided by two files: psxss.exe and psxdll.dll. A POSIX application uses psxdll.dll to communicate with the subsystem while communicating with posix.exe to provide display capabilities on the Windows desktop." [2] 1. https://en.m.wikipedia.org/wiki/Architecture_of_Windows_NT https://en.m.wikipedia.org/wiki/Architecture_of_Windows_NT 2. https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

manojlds 11y ago

This isn't about cmd or Powershell. Bash on Windows is a whole different beast, and it is early days.

barrkel 11y ago

Can you explain what exactly OS X gets right - which other operating system ABIs are involved?

mrpippy 11y ago
On OS X, every process on the system is a Unix process and has a PID, and is visible from the Unix APIs that Activity Monitor uses. Even when OS X had more diversity in binary formats (the Classic environment, Carbon CFM apps, emulated PPC binaries), everything was still a Unix process. I would say that OS X is just simpler, in that it doesn't use multiple subsystems which can each have totally separate process namespaces. What the Windows Task Manager should at least do is have a catch-all entry for a non-Win32 subsystem, so you can see that the Linux Subsystem is taking 100% CPU.