
Simple Windows GUI Application Written in Go - dsr12
https://gist.github.com/nathan-osman/18c2e227ad00a223b61c0b3c16d452c3
======
Impossible
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...](https://github.com/LeZuse/minimal-
win32-app/blob/master/main.cpp)

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).

~~~
davb
There's something elegant about [https://github.com/LeZuse/minimal-
win32-app/blob/master/main...](https://github.com/LeZuse/minimal-
win32-app/blob/master/main.cpp)

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
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.

~~~
maxxxxx
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
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.

------
wtf_is_up
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.

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

~~~
wink
[http://imgur.com/lDXqBBm](http://imgur.com/lDXqBBm)

~~~
juice_bus
While not anything huge it is very interesting to see it coming from Go.

Thank you!

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

~~~
tomjen3
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

------
pcunite
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
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.

~~~
mb_72
Why 'unfortunate'? What is 'unfortunate' is developers having prejudice
against any OS / IDE / language / etc; it restricts your creation of solutions
for the problems that need to be solved. Keeping up with developments across
all platforms - like the fact these days you can use C# for non-Windows
targets- helps us be well-rounded and capable developers.

~~~
icebraining
It's only prejudice if it's not based on direct experience. Many of us would
rather avoid going back to Windows at all.

~~~
pjmlp
After several years using GNU/Linux I have happily returned.

Windows and Mac OS X are the only sane alternatives for developers that care
about desktop applications and developer friendly toolchains. Same applies to
iOS, Android and WP.

The other alternatives feel like only the CLI and daemons matter, stuck in a
PDP-11 view of the world.

Then again, NeXT was the only UNIX based OS with an alternative culture
regarding developers tools and UX.

KDE is the only environment that can match in terms of tooling and UX, yet it
is lacking some serious love nowadays.

I want my developer and user experience to be a Xerox Star and not a PDP-11.

~~~
idobai
> KDE is the only environment that can match in terms of tooling and UX, yet
> it is lacking some serious love nowadays.

KDE? Seriously? It's one of the worst DEs on linux. Any DE which isn't based
on gnome is just cheap nowadays.

~~~
pjmlp
So which other DE on GNU/Linux does provide the same tooling and platform
abstractions as KDevelop/Qt Creator do?

GNOME has a very nice HIG from UX point of view, but it is stuck in C + POSIX
as technology stack in what concerns developer experience. Vala is still not
there and I don't believe in JavaScript for native UIs.

~~~
idobai
> So which other DE on GNU/Linux does provide the same tooling and platform
> abstractions as KDevelop/Qt Creator do?

Same or similar? It doesn't matter what they provide because I'd go with
ScalaFX([http://www.scalafx.org/](http://www.scalafx.org/)) + IntelliJ or
Vala|Genie + Vala IDE. Mono is also an option if you're into it.

> but it is stuck in C + POSIX as technology stack in what concerns developer
> experience.

Yes, GTK isn't the newest but it isn't hard at all to develop apps with
Vala/Genie([https://wiki.gnome.org/Projects/Vala/GTKSample](https://wiki.gnome.org/Projects/Vala/GTKSample)
,
[https://wiki.gnome.org/Projects/Genie/GtkGuiTutorial](https://wiki.gnome.org/Projects/Genie/GtkGuiTutorial)
?)

> Vala is still not there and I don't believe in JavaScript for native UIs.

What do you mean? Vala is almost the defacto standard language for
ubuntu/gnome apps.

~~~
pjmlp
ScalaFX([http://www.scalafx.org/](http://www.scalafx.org/)) + IntelliJ and
Mono are not exposing any GNU/Linux specific feature.

I can use the same toolchain in many other operating systems.

The last time I bothered to check GNOME, there was some ongoing discussion of
JavaScript becoming the official language to pair with C.

Just checked Genie and Vala IDE web sites, they still need to do catch up with
what Borland was doing in the 90's, let alone modern IDEs.

~~~
idobai
> ScalaFX([http://www.scalafx.org/](http://www.scalafx.org/)) + IntelliJ and
> Mono are not exposing any GNU/Linux specific feature.

Why would you need specific features? You wanted to develop desktop apps, not
gnome plugins, right?

> Just checked Genie and Vala IDE web sites, they still need to do catch up
> with what Borland was doing in the 90's, let alone modern IDEs.

If you want RAD there's
Glade([https://glade.gnome.org/](https://glade.gnome.org/)) + GtkBuilder.

~~~
idobai
@woflgke you're going off on a tangent: it's about the maturity of tools and
not about "exposing" system features. That's unrelated to desktop apps.

~~~
pjmlp
No @woflgke is quite right.

Software development stack for desktop apps are all about exposing the
features that make a platform desired to be used.

------
akavel
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))

------
ssebastianj
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
I thought walk framework was there to reduce the code.

------
wiz21c
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 ?

------
rusanu
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).

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

------
herbst
But can it backtrace IPs?

