P.S.: In retrospect, although I find this extremely cool and potentially very useful to me for my side projects, it's not clear to me how the average NetLogo user would be intended to access this functionality. I've never encountered any mention of named pipes outside of the Win32 API docs. Maybe I misunderstood the intended purpose of this remote control feature?

The idea is that this will be used by an editor plugin so that you can do things like running setup and go without leaving your editor. The plugin would be responsible for discovering these sockets and sending the commands on behalf of the user. In the case that there are multiple sockets, it could use some heuristics to decide which socket to use or just directly ask the user (preferably presenting them as something more user-friendly than just the socket paths). Ideally, the user wouldn't need to know that these sockets exist at all.

@kgmt0 Unfortunately, this new library is even worse on Windows than the last one. I don't get any exception dialogs when toggling the preference or starting up NetLogo, but I am no longer able to connect to the pipe. If I use your solution as is, it says it can't access the file, presumably because pipes are supposed to be created at \\.\pipe\... instead of in an arbitrary location. But if I change the code to create the pipe in the correct location, it fails to create one at all. Am I supposed to use a different method of connecting to the socket with this new library?

Am I supposed to use a different method of connecting to the socket with this new library?

Yes, it turns out Windows supports Unix sockets now, so I just used Unix sockets on all OSes. But since there's no longer any need for platform-specific code, I'm thinking I might as well just use the Java standard library and create the socket myself. I'll update the PR if that goes well.

Ah ok, fantastic! Thanks for the clarification.

It looks like switching to just using the Java standard library would be more work than I thought. For some reason, Unix sockets only work with ServerSocketChannel, and the API is quite a bit lower level than ServerSocket that I'm currently using, so I think it's worth using a library here.