4 ms·

Pretty basic Window creation and message loop code, but its nice to see a starting example in Go. For comparison here is a C version: https://github.com/LeZuse

Pretty basic Window creation and message loop code, but its nice to see a starting example in Go. For comparison here is a C version: https://github.com/LeZuse/minimal-win32-app/blob/master/main.cpp https://github.com/LeZuse/minimal-win32-app/blob/master/main... The C code does basically the same thing but ends up being smaller because the Go code doesn't have an equivalent of windows.h with function and data type definitions. The Go code might be a little nicer if it used a Win32 API wrapper, but there doesn't seem to be a well supported and documented one out there. This was all I could find https://github.com/AllenDang/w32 https://github.com/AllenDang/w32.

vvanders 10y ago
Yeah, I wouldn't want to touch this with a 10ft pole due to the lack of windows.h. There's so many constants you need to keep track of you're better off using C# + C FFI than trying to use the core win32 api.
- _ph_ 10y ago
  You can reference C header files from go. If you include a headerfile defining a constant "foo", then C.foo would give the value to the Go program. It is not overly elegant, but the Go-C interface is pretty usable.
  - vvanders 10y ago
    Does that include macro pre-processing as well? There's a lot of stuff like WIN32_LEAN_AND_MEAN in there as well.
    - _ph_ 10y ago
      As far as I am aware, yes. Using "cgo" (by importing "C") you can include C header files, and all c source files are compiled together with the Go files in your package. So if you have a foo.c containing int foo(int) you can just call it from Go by i := C.foo(C.int(j)) Assuming j is a Go int type.
      - vvanders 10y ago
        So just some quick googling points to https://github.com/golang/go/issues/9601 https://github.com/golang/go/issues/9601 which seems like it's still an open issue. Either way if you're going to build UI for Windows C#/QT with an C FFI is the more sane way to go. Back when I worked on game engines most of the time we had the fast code down in native and used C# for the tools since it's such a productive framework compared to win32.
    - vetinari 10y ago
      Yes, it is ran through C preprocessor. You can define for CFLAGS, CPPFLAGS or LDFLAGS in the form of special comment: // #cgo CFLAGS: -DYOUR_DEFINE // #cgo LDFLAGS: -lyourlib // #include <header.h> import "C"
vldo 10y ago
I'd probably use andlabs/ui or lxn/walk. https://github.com/andlabs/ui https://github.com/andlabs/ui https://github.com/lxn/walk https://github.com/lxn/walk
davb 10y ago
There's something elegant about https://github.com/LeZuse/minimal-win32-app/blob/master/main.cpp https://github.com/LeZuse/minimal-win32-app/blob/master/main... I remember just how painful working with the Win32 API could be (a lifetime ago), but I felt like I really understood how it worked. These days, it's layer upon layer of abstractions. Or bindings from my language of choice to an abstraction layer/framework running on the native OS. I couldn't begin to explain how many of the popular UI frameworks work, all the way down to the native OS layer. There was something substantial, concrete in programming at this layer rather than some higher level, fragile abstraction.
- achr2 10y ago
  I think that sentiment is mostly revisionist nostalgia. Yes it was easier to 'know' what was going on between your code and the OS, but to say that modern UI frameworks are more fragile than the hand-coded win32 code of yore is certainly fallacious.
  - davb 10y ago
    I'd argue that it's not "fallacious", it's simply a matter of opinion and taste.
  - maxxxxx 10y ago
    Actually I would agree that win32 is more stable once you get the hang of it. I have worked with WPF, Winforms, MFC and win32. win32 was by far the most complete, predictable and flexible environment. It takes a lot of learning and you can't just let anybody work on the codebase. But once you know what you are doing and maybe have some simple wrappers for routine stuff it's pretty good.
    - pjmlp 10y ago
      Coming from MS-DOS and Amiga as background, I was amazed how Win16 was a productivity changer (for the better). It is funny to see people bashing it nowadays, given how I came to enjoy it. When I started GUI coding on UNIX, Xlib, Xt and Motif on the other hand were anything but productive.

vvanders 10y ago

Yeah, I wouldn't want to touch this with a 10ft pole due to the lack of windows.h. There's so many constants you need to keep track of you're better off using C# + C FFI than trying to use the core win32 api.

_ph_ 10y ago
You can reference C header files from go. If you include a headerfile defining a constant "foo", then C.foo would give the value to the Go program. It is not overly elegant, but the Go-C interface is pretty usable.
- vvanders 10y ago
  Does that include macro pre-processing as well? There's a lot of stuff like WIN32_LEAN_AND_MEAN in there as well.
  - _ph_ 10y ago
    As far as I am aware, yes. Using "cgo" (by importing "C") you can include C header files, and all c source files are compiled together with the Go files in your package. So if you have a foo.c containing int foo(int) you can just call it from Go by i := C.foo(C.int(j)) Assuming j is a Go int type.
    - vvanders 10y ago
      So just some quick googling points to https://github.com/golang/go/issues/9601 https://github.com/golang/go/issues/9601 which seems like it's still an open issue. Either way if you're going to build UI for Windows C#/QT with an C FFI is the more sane way to go. Back when I worked on game engines most of the time we had the fast code down in native and used C# for the tools since it's such a productive framework compared to win32.
  - vetinari 10y ago
    Yes, it is ran through C preprocessor. You can define for CFLAGS, CPPFLAGS or LDFLAGS in the form of special comment: // #cgo CFLAGS: -DYOUR_DEFINE // #cgo LDFLAGS: -lyourlib // #include <header.h> import "C"

vldo 10y ago

I'd probably use andlabs/ui or lxn/walk. https://github.com/andlabs/ui https://github.com/andlabs/ui https://github.com/lxn/walk https://github.com/lxn/walk

davb 10y ago

There's something elegant about https://github.com/LeZuse/minimal-win32-app/blob/master/main.cpp https://github.com/LeZuse/minimal-win32-app/blob/master/main... I remember just how painful working with the Win32 API could be (a lifetime ago), but I felt like I really understood how it worked. These days, it's layer upon layer of abstractions. Or bindings from my language of choice to an abstraction layer/framework running on the native OS. I couldn't begin to explain how many of the popular UI frameworks work, all the way down to the native OS layer. There was something substantial, concrete in programming at this layer rather than some higher level, fragile abstraction.

achr2 10y ago
I think that sentiment is mostly revisionist nostalgia. Yes it was easier to 'know' what was going on between your code and the OS, but to say that modern UI frameworks are more fragile than the hand-coded win32 code of yore is certainly fallacious.
- davb 10y ago
  I'd argue that it's not "fallacious", it's simply a matter of opinion and taste.
- maxxxxx 10y ago
  Actually I would agree that win32 is more stable once you get the hang of it. I have worked with WPF, Winforms, MFC and win32. win32 was by far the most complete, predictable and flexible environment. It takes a lot of learning and you can't just let anybody work on the codebase. But once you know what you are doing and maybe have some simple wrappers for routine stuff it's pretty good.
  - pjmlp 10y ago
    Coming from MS-DOS and Amiga as background, I was amazed how Win16 was a productivity changer (for the better). It is funny to see people bashing it nowadays, given how I came to enjoy it. When I started GUI coding on UNIX, Xlib, Xt and Motif on the other hand were anything but productive.