I field many questions from folks trying to containerize messy legacy apps. Some of the more interesting apps have been line-of-business apps with arcane licensing requirements (e.g. physical dongle) and radio communication apps (e.g. those requiring a GPS).
Windows Server does not ship in a configuration that allows for Windows Server containers to access host COM ports.
But you can change that.
Unlike Hyper-V containers, which rely on a special virtual machine for kernel-level isolation, Windows Server containers simply use Windows Server Silos to isolate processes from the host machine. Windows Server ships with a default silo configuration that aligns it with container mantras around container ephemerality, immutability, scability, etc. You can tweak that configuration to meet your needs.
For example, here's a step-by-step to bring in a COM port:
- Take ownership of \Windows\System32\Containers\wsc.def and give yourself write access. (Make a backup copy!)
- Open up wsc.def with your favorite text editor.
- COM port symlinks typically live in the Global?? object directory, so add the appropriate symlink under
<objdir name="GLOBAL??" ...>. (For example, using WinObj, I determined my COM1 is a symlink to
<symlink name="COM1" path="\Device\Serial0" scope="Global" />.)
- Add the appropriate symlink for the device under
<objdir name="Device" ...>. (Continuing the example above, I added
<symlink name="VCP0" path="\Device\VCP0" scope="Global" />)
- Save the file and relaunch your container. (The vmcompute process reads the rules at container startup.)
modeat the command prompt to verify your COM port is now visible.
- Brace yourself for disappointment when updates come down from WU in the far future and blow away your changes.
As you've probably figured out by now, you can expose way more than just COM ports -- almost anything can be exposed to containers. Be careful.
I did some limited testing on my end with a FTDI serial cable connected to a radio. Shoot me an email if this worked (or failed) for you.