9 ms·

Simple Windows GUI Application Written in Go

107 points by dsr12 10y ago

Impossible 10y ago
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.
juice_bus 10y ago
Can anyone post a screenshot of what the final product is?
- wink 10y ago
  http://imgur.com/lDXqBBm http://imgur.com/lDXqBBm
  - juice_bus 10y ago
    While not anything huge it is very interesting to see it coming from Go. Thank you!
rusanu 10y ago
How long until we see the go equivalent of pinvoke.net ? http://www.pinvoke.net/ http://www.pinvoke.net/ Ideally this sort of platform import should be automated so that Win32 specific apps could import the more advanced GUI stuff (comdlg et all).
pcunite 10y ago
Very nice. I've not always stayed true to this advice, but for commercial products it is recommended to build software in the native language of the OS. Something like .NET is available but this is supported by the creators of Windows. Why? Less bugs, better examples, community support.
- mikegedelman 10y ago
  I keep hearing how .NET and C# are supposed to be pretty great these days. C# often gets credit for popularizing async/await, although I don't actually know if that's true. Based on that, and the point you made, I'd definitely go the .NET/C# route if I ever ended up in the unfortunate position of having to develop software for Windows. Barring of course some reason that it had to be written in Go or something else.
  - jasonjei 10y ago
    WTL is also great if you want or need something that doesn't use .NET. Building GUI apps doesn't suck with WTL. What I would like to see is an example of an app where I can build an app using both WTL/C++ and have Go code with channel support...
  - addicted 10y ago
    I don't see why someone wouldn't use C#/.Net to build a native Windows app. It's open source, and supported by Microsoft, the makers of Windows as the primary Windows app environment. One reason would be if you're trying to build a node based app which you would like to use across other platforms.
    - maxxxxx 10y ago
      The problem isn't C#/.NET but what GUI toolkit do you use? Winforms, WPF, UWP and others are either in maintenance mode or incomplete. The only complete toolkit is Win32 which brings you back to C/C++.
      - 10y ago
analognoise 10y ago
Is it me or is this substantially uglier than the C version?
- robbrown451 10y ago
  I would expect it would be, for a barebones GUI program. Now make a real program, where 90% of the logic isn't specifically UI stuff, and the benefits of doing it in Go makes more sense.
- f2f 10y ago
  every beginning is hard, but at least it doesn't deal with resolving DLL procedure addresses by hand, which it would've had to do if syscall.NewLazyDLL wasn't available. after a while things will settle down and this "hello world" program will boil down to something much simpler, like: import "win" func PopWin(text string) { win.NewWindow(text, ...) } also keep in mind that this is the version that purposely avoids using C and, as a consequence, can be cross compiled for windows on every machine with Go installed. there are benefits to that.
- tomjen3 10y ago
  It is, but that is because it has to refer it directly and import a lot of stuff you get for free in C, when you import windows.h I don't think it would be that ugly if you compared it C code that didn't include windows.h
- lloeki 10y ago
  This kind of thing is bound to get better as it gets wrapped in with a more idiomatic interface. Things like https://github.com/go-gl/gl https://github.com/go-gl/gl started as ugly hacks requiring passing unsafe pointers and stuff around but have made great strides since then. I don't know the details and I'm thinking aloud right now, but the comments about "windows.h", constants, and accessing C via cgo possibly point to an automatically generated solution (possibly leveraging "go generate"). Whatever, native GUI bindings has been a key factor for the adoption (or lack thereof) of some languages where they would have otherwise been perfectly fine.
wtf_is_up 10y ago
I've used https://github.com/lxn/walk https://github.com/lxn/walk to make some simple Win GUI apps. It was a couple years ago. Very easy to use.
kmetan 10y ago
Very nice... Reminds me of an old good MFC. Happy new year 1996.
ssebastianj 10y ago
A couple of days ago I wanted to read the Active Protection Sensor bundled in a ThinkPad by accessing Sensor64.dll under Go 1.6.2. So, after several hours diving in the interwebs/Godocs I came to this issue [0] which suggests the "x/sys/windows" [1] package instead the "syscall" one if you want to load a Windows system DLL. Note: I'm a total newbie at Go and Windows API so every bit of abstraction was a bless to me. [0] https://github.com/golang/go/issues/14959 https://github.com/golang/go/issues/14959 [1] https://github.com/golang/sys/tree/master/windows https://github.com/golang/sys/tree/master/windows
fithisux 10y ago
I thought walk framework was there to reduce the code.
wiz21c 10y ago
I'm surprised by the tone of some messages here. It sounds like native GUI programming on Windows has faded away... Is it just me ?
herbst 10y ago
But can it backtrace IPs?
akavel 10y ago
If you're interested in Win32 development with Go, I've built a small library for personal use, for quick prototyping of WinAPI calls without cgo and without having to pre-declare each function: https://github.com/akavel/winq https://github.com/akavel/winq (godoc: https://godoc.org/github.com/akavel/winq https://godoc.org/github.com/akavel/winq)

107 points by dsr12 10y ago

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.

juice_bus 10y ago

Can anyone post a screenshot of what the final product is?

wink 10y ago
http://imgur.com/lDXqBBm http://imgur.com/lDXqBBm
- juice_bus 10y ago
  While not anything huge it is very interesting to see it coming from Go. Thank you!

rusanu 10y ago

How long until we see the go equivalent of pinvoke.net ? http://www.pinvoke.net/ http://www.pinvoke.net/ Ideally this sort of platform import should be automated so that Win32 specific apps could import the more advanced GUI stuff (comdlg et all).

pcunite 10y ago

Very nice. I've not always stayed true to this advice, but for commercial products it is recommended to build software in the native language of the OS. Something like .NET is available but this is supported by the creators of Windows. Why? Less bugs, better examples, community support.

mikegedelman 10y ago
I keep hearing how .NET and C# are supposed to be pretty great these days. C# often gets credit for popularizing async/await, although I don't actually know if that's true. Based on that, and the point you made, I'd definitely go the .NET/C# route if I ever ended up in the unfortunate position of having to develop software for Windows. Barring of course some reason that it had to be written in Go or something else.
- jasonjei 10y ago
  WTL is also great if you want or need something that doesn't use .NET. Building GUI apps doesn't suck with WTL. What I would like to see is an example of an app where I can build an app using both WTL/C++ and have Go code with channel support...
- addicted 10y ago
  I don't see why someone wouldn't use C#/.Net to build a native Windows app. It's open source, and supported by Microsoft, the makers of Windows as the primary Windows app environment. One reason would be if you're trying to build a node based app which you would like to use across other platforms.
  - maxxxxx 10y ago
    The problem isn't C#/.NET but what GUI toolkit do you use? Winforms, WPF, UWP and others are either in maintenance mode or incomplete. The only complete toolkit is Win32 which brings you back to C/C++.
    - 10y ago

analognoise 10y ago

Is it me or is this substantially uglier than the C version?

robbrown451 10y ago
I would expect it would be, for a barebones GUI program. Now make a real program, where 90% of the logic isn't specifically UI stuff, and the benefits of doing it in Go makes more sense.
f2f 10y ago
every beginning is hard, but at least it doesn't deal with resolving DLL procedure addresses by hand, which it would've had to do if syscall.NewLazyDLL wasn't available. after a while things will settle down and this "hello world" program will boil down to something much simpler, like: import "win" func PopWin(text string) { win.NewWindow(text, ...) } also keep in mind that this is the version that purposely avoids using C and, as a consequence, can be cross compiled for windows on every machine with Go installed. there are benefits to that.
tomjen3 10y ago
It is, but that is because it has to refer it directly and import a lot of stuff you get for free in C, when you import windows.h I don't think it would be that ugly if you compared it C code that didn't include windows.h
lloeki 10y ago
This kind of thing is bound to get better as it gets wrapped in with a more idiomatic interface. Things like https://github.com/go-gl/gl https://github.com/go-gl/gl started as ugly hacks requiring passing unsafe pointers and stuff around but have made great strides since then. I don't know the details and I'm thinking aloud right now, but the comments about "windows.h", constants, and accessing C via cgo possibly point to an automatically generated solution (possibly leveraging "go generate"). Whatever, native GUI bindings has been a key factor for the adoption (or lack thereof) of some languages where they would have otherwise been perfectly fine.

wtf_is_up 10y ago

I've used https://github.com/lxn/walk https://github.com/lxn/walk to make some simple Win GUI apps. It was a couple years ago. Very easy to use.

kmetan 10y ago

Very nice... Reminds me of an old good MFC. Happy new year 1996.

ssebastianj 10y ago

A couple of days ago I wanted to read the Active Protection Sensor bundled in a ThinkPad by accessing Sensor64.dll under Go 1.6.2. So, after several hours diving in the interwebs/Godocs I came to this issue [0] which suggests the "x/sys/windows" [1] package instead the "syscall" one if you want to load a Windows system DLL. Note: I'm a total newbie at Go and Windows API so every bit of abstraction was a bless to me. [0] https://github.com/golang/go/issues/14959 https://github.com/golang/go/issues/14959 [1] https://github.com/golang/sys/tree/master/windows https://github.com/golang/sys/tree/master/windows

fithisux 10y ago

I thought walk framework was there to reduce the code.

wiz21c 10y ago

I'm surprised by the tone of some messages here. It sounds like native GUI programming on Windows has faded away... Is it just me ?

herbst 10y ago

But can it backtrace IPs?

akavel 10y ago

If you're interested in Win32 development with Go, I've built a small library for personal use, for quick prototyping of WinAPI calls without cgo and without having to pre-declare each function: https://github.com/akavel/winq https://github.com/akavel/winq (godoc: https://godoc.org/github.com/akavel/winq https://godoc.org/github.com/akavel/winq)