update docs

README.md

@@ -4,63 +4,26 @@ It's a UDP server that allows you to update your Discord Rich Presence.
 
 ## usage
 
-### Windows via WSL
-
-After invoking the executable for the first time, you'll have to accept the
-Windows Firewall security alert to allow inbound UDP traffic to your Windows
-host.
+Run it:
 
 ```console
-❯ GOOS=windows go build -o rich-presence main.go
-❯ DISCORD_APP_ID=942604338927374438 WSLENV=DISCORD_APP_ID/w ./rich-presence.exe
-❯ jq -cM . example.json | nc -uw1 "$WSL_HOST" 1992
+❯ make run
+go build -o rich-presence.exe main.go
+./rich-presence.exe -verbose
+2022/03/05 10:39:49 Listening on :1992
 ```
 
-### Linux
-
-It hasn't really been tested on Linux desktop, but I imagine it'd work just fine
-since the socket [rich-go](https://github.com/hugolgst/rich-go) expects (e.g.
-`$XDG_RUNTIME_DIR/discord-ipc-0`) would actually exist, if you're running
-Discord for Linux.
+In another shell, send a UDP message to it:
 
 ```console
-❯ go build -o rich-presence main.go
-❯ DISCORD_APP_ID=942604338927374438 ./rich-presence
+❯ jq -cM . example.json > /dev/udp/$WINHOST/1992
 ```
 
-## misc
-
-Some notes on the Windows via WSL invocation:
-
-- Assuming Discord is running on the Windows host, and not within WSL, we must
-  build the binary with `GOOS=windows` so the underlying
-  [rich-go](https://github.com/hugolgst/rich-go) library can read from the
-  named pipe Discord uses on Windows (i.e. `\\.\\pipe\\discord-ipc-0`).
-
-  We can check for the existence of this named pipe as follows:
-
-  ```console
-  ❯ powershell.exe '[System.IO.Directory]::GetFiles("\\.\\pipe\\")' | grep discord
-  ```
-
-- Since we're invoking Windows executables from within WSL, we must also tell
-  WSL to share with Windows any env vars we've set using
-  `WSLENV=DISCORD_APP_ID/w` (see [this blog
-  post](https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/)
-  for more details).
+In the above, I'm running this on Windows via WSL, but it should work just fine
+on desktop Linux too.
 
-- After the server is running, we need a way to send messages to it. However,
-  since we invoked a Windows executable, the server is bound to the host of the
-  WSL instance. We can find that as follows:
+## example
 
-  ```console
-  ❯ powershell.exe "
-          Get-NetAdapter 'vEthernet (WSL)' |
-          Get-NetIPAddress -AddressFamily IPv4 |
-          Select -Expand IPAddress
-  "
-  ```
+Go crazy:
 
-  Note this is rather slow. I'd recommend adding this to the environment vars
-  your login shell sets. I have mine set under `WSL_HOST`, like in the example
-  above.
+![gif of automated rich presence updates via a shell loop](./example.gif)

WSL.md

@@ -0,0 +1,57 @@
+These are just some miscellaneous notes for myself (or whoever else reads
+this) about running this on Windows within WSL.
+
+- Assuming Discord is running on the Windows host, and not within WSL, we
+  also need to run our server on the Windows host so the underying
+  [rich-go](https://github.com/hugolgst/rich-go) library can interface with the
+  named pipe Discord uses on Windows (i.e. `\\.\\pipe\\discord-ipc-0`).
+
+  We can check for the existence of this named pipe as follows:
+
+  ```console
+  ❯ powershell.exe '[System.IO.Directory]::GetFiles("\\.\\pipe\\")' | grep discord
+  ```
+
+- Since we're invoking a Windows executable from within WSL, we must also tell
+  WSL to share with Windows any env vars we've set using
+  `WSLENV=DISCORD_APP_ID/w` (see [this blog
+  post](https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/)
+  for more details).
+
+- After invoking the executable for the first time, we'll have to accept the
+  Windows Firewall security alert to allow inbound UDP traffic to our Windows
+  host.
+
+- Sending messages to our server won't work via `localhost` because the server
+  is bound on the Windows host. We can talk to the Windows host using the
+  default gateway within our WSL instance:
+
+  ```console
+  ❯ ip r show default | awk '{print $3}'
+  172.22.128.1
+  ```
+
+  We could also ask Powershell:
+
+  ```console
+  ❯ powershell.exe '
+          Get-NetIPAddress -AddressFamily IPv4 -InterfaceAlias "vEthernet (WSL)" |
+          Select -ExpandProperty IPAddress
+  '
+  ```
+
+- Once everything is up, we can confirm our binary is actually running
+  within Windows:
+
+  ```console
+  ❯ powershell.exe 'Get-Process -Name rich-presence | Select -ExpandProperty Id'
+  20464
+  ```
+
+  ```console
+  ❯ powershell.exe 'Get-NetUDPEndpoint -OwningProcess 20464'
+
+  LocalAddress                             LocalPort
+  ------------                             ---------
+  ::                                       1992
+  ```