Thoughts on Port Suppliers

I get a lot of questions about port suppliers from people who are attempting to write a debug engine. There appears to be a lot of confusion on the subject.
IMHO, the concept of Port, and PortSupplier is one of the most confusing aspects of the AD7 architecture, mostly because the names are confusing.

A Port is really a process provider. It's job is to examine a machine, or device, or runtime and provide the "processes" running in that environment. For instance, the default port for windows returns the windows processes running on the machine. A port for a cell phone would return the apps running on that cell phone. A script port might return the scripts running on the interpretor. I believe the name port came from the old kernel debugger concept that a null-modem cable was attached to a serial ports between two machines (debugger machine and debugee machine) and processes could be provided through that port. Yes, the name is confusing but we're stuck with it.

Now that the definition of port is out of the way, let's tackle Port Supplier. A port supplier is a component that generally runs on the debugger machine and knows how to connect to a runtime environment and return a port (process provider) for that system.  So, when does a debug engine implementor need to implement a port supplier and a port? If they want to support Attach-to-Process AND if their processes not win32 processes running on a win32 machine.

Engine implementors that only want to support F5 (launch) for devices or no windows architectures only need to implement "Engine-Launch" which means the debug engine itself is responsible for connecting to the target device, launching the debug target, and returning an IDebugProcess2 to the debugger. Engines wishing to perform an engine launch should implement the IDebugEngineLaunch2 interface