...and absurdly complex.

One of the quick tests I like to do to ascertain the complexity of a codebase is "how long does it take to find the entrypoint" and "how long does it take to find the core functionality"?

In this case, I have been clicking around through nearly empty directories for 15+ minutes and haven't seen anything that looks like an entrypoint yet, nevermind the main loop.

In contrast, I downloaded the Bash source and within 5 minutes found the main loop (eval.c) and entrypoint (shell.c).

Now I'm curious to know what the cmd.exe source is like, but MS seems to have no intention of releasing that.

I did the same exercise, and I found this immediately (straight drilldown through directories from the top level):

https://github.com/PowerShell/PowerShell/blob/master/src/pow...

It's instantiating the execution engine (.NET-speak for the core runtime) getting ready to run Monad (the original codename for PowerShell).

I think part of it is familiarity and context. I knew none of the command bits would be likely to contain an entrypoint. Directories that mentioned native looked useful for finding an entrypoint, because I know that PowerShell is implemented in C# - I reasoned I'd be able to find further managed entrypoints by looking at where it starts out in C++.

You can see that the main object it instantiates is Microsoft.PowerShell.UnmanagedPSEntry. Looks useful.

A search across the repo for UnmanagedPSEntry lead me to https://github.com/PowerShell/PowerShell/tree/master/src/Mic... which seems to contain all the entrypoints you're looking for.

The main loop is in InputLoop in https://github.com/PowerShell/PowerShell/blob/master/src/Mic...

(FTR, this took me about 8 minutes, including finding links that didn't include hashes.)

Some hand-wavily relevant comments:

- I had the exact same problem - "how do I get at the entrypoint and follow this" - only earlier today, with Chromium. I was trying to figure out why sync was broken and thought I'd try and follow the (C++) breadcrumbs. It didn't go very well. https://bugs.chromium.org/p/chromium/issues/detail?id=671498

- AFAIK, cmd.exe is basically a horrible, horrible hack. I'm not 100% sure, but I think an instance of cmd.exe is the only way you can run things with a stdout, as in Windows has no concept of TTYs - the cmd.exe process uses a bunch of undocumented kernel interface APIs to "make it work™". Related: https://github.com/Microsoft/BashOnWindows/issues/111#issuec...

Edit/Update: PSA, if you use a sync passphrase with Chrome your history from other devices doesn't show up in chrome://history. Known bug, will hopefully be rearchitected long-term.

I have to say though, the writeup on that Chromium ticket I filed was absolutely awesome. Did someone here notice...? :P

After clicking that github link, it appears to be in `src/powershell/Program.cs`, along with a readme explaining how the entrypoint works.

I'm not making any statement on the complexity of the general Powershell codebase, but finding the entrypoint at least seems straightforward.

Well, in addition to being huge (850K lines of C# by my count), I would say it's only marginally relevant to someone who wants to write a Unix shell. The parts of the kernel that Unix uses -- fork/exec/wait/pipe/dup -- are exactly the things that Windows does in a completely different manner (whereas the file system is probably more similar).

The shell is almost what distinguishes Unix from Windows, and that is apparent at the lowest levels.