attempting to build cmdg on windows

Hello All,

I'm new to Golang and to the group so apologies in advance for any
stupid questions. Please don't flame me! :)

I'm attempting to build Thomas Habets' cmdg on my Windows 10 machine.
This is as far as I get:

- - - -

>set "GOOS=windows"

>set "GOARCH=386"

>cd
C:\Users\User\cmdg

>go build .\cmd\cmdg
# github.com/ThomasHabets/cmdg/pkg/input
pkg\input\input.go:129:52: undefined: unix.Timeval
pkg\input\input.go:134:14: undefined: unix.Timeval
pkg\input\input.go:172:14: undefined: unix.FdSet
pkg\input\input.go:173:25: undefined: unix.NFDBITS
pkg\input\input.go:181:17: undefined: unix.Select
pkg\input\input.go:181:42: undefined: unix.FdSet
pkg\input\input.go:397:33: undefined: syscall.SIGWINCH

- - - -

I consulted the Copilot Chatbot and this is its response:

- - - -

The errors you’re seeing—
undefined: unix.Timeval
undefined: unix.FdSet
undefined: unix.NFDBITS
undefined: unix.Select
—occur because the code in pkg/input/input.go uses the
golang.org/x/sys/unix package, which is only available on Unix-like
operating systems. Functions and types like Timeval, FdSet, NFDBITS,
and Select are specific to Unix systems and aren’t defined on Windows.

Below are some approaches to resolving these errors:

---

1. Conditional Compilation with Build Tags

If the functionality in that file isn’t required on Windows, you can
simply exclude it from Windows builds. At the top of your source file
(input.go), add a build constraint that tells Go to compile that file
only on Unix-like systems. For example:

go
// +build linux darwin freebsd

This way, when you build on Windows, this file will be skipped. You’ll
then need to decide what to do for Windows—either provide a stub
implementation or entirely remove the functionality for that build.

---

2. Implementing Windows Alternatives

If the functionality is essential for your app on every platform,
you’ll have to provide Windows-specific code. Windows does have a
select function provided through its Winsock API, and there’s a
corresponding package
[golang.org/x/sys/windows](https://pkg.go.dev/golang.org/x/sys/windows)
that exposes Windows system calls. However, note that:

- Types and Structures : Windows doesn’t use Timeval and FdSet in the
same manner. You might need to map these calls to their Windows
counterparts or re-architect your logic for handling I/O multiplexing.
- API Differences : The Windows API for network/select operations can
differ in both usage and behavior. A direct replacement might not be
trivial.

In this scenario, creating two separate source files is a common approach:
- Create an input_unix.go containing Unix-specific code with a build
tag like // +build !windows.
- Create an input_windows.go with Windows-specific implementations and
the build tag // +build windows.

This method keeps your platform-specific code separate while keeping
the overall API of your module consistent.

---

3. Refactoring Your Code

Examine what the Unix-specific code is trying to achieve. For example:
- If you’re using Select for non-blocking I/O or waiting on file
descriptors , determine if Windows has an equivalent method or if you
can use Go’s higher-level abstractions (like channels or the netpoll
package) to achieve the same behavior.
- For timing out operations or polling , consider whether you can use
Go’s built-in mechanisms (such as time.After) to achieve the desired
effect with cross-platform compatibility.

---

Next Steps

- Evaluate Necessity: Decide whether the Unix-specific functionality
is essential on Windows. If not, stub out or conditionally compile
that part of your code.
- Create Platform-Specific Files: Split your code into two files
(input_unix.go and input_windows.go) with proper build tags to handle
each platform's requirements separately.
- Consult Documentation: Look into
[golang.org/x/sys/windows](https://pkg.go.dev/golang.org/x/sys/windows)
for Windows-specific system call equivalents and the nuances of how
Windows handles I/O and system-level operations.

If you run into further specific issues while restructuring the code
or need guidance with Windows API equivalents, feel free to provide
more details, and I can help brainstorm a solution tailored to your
app's functionality. Happy coding!

- - - -

Sounds like good advice. Just one problem... I don't understand a
word of it. I'm in way over my head.

Would I be better off installing WSL? Would cmdg run "out of the box"
under WSL?

Any help appreciated.

Thanks!

John

--