Simple Windows GUI Application Written in Go

https://gist.github.com/nathan-osman/18c2e227ad00a223b61c0b3c16d452c3

by dsr12 • 10 years ago

107 63 10 years ago

gist.github.com

Impossible• 10 years 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...

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.

vvanders3• 10 years 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_2• 10 years 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.

vldo• 10 years ago

I'd probably use andlabs/ui or lxn/walk.

https://github.com/andlabs/ui https://github.com/lxn/walk

davb2• 10 years ago

There's something elegant about 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• 10 years 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.

pjmlp10• 10 years ago

Using the message crackers and type safe handles introduced in Windows 3.1 SDK made it somewhat better.

In any case, OWL, VCL and later on MFC were my tools during those days, when given an option.

juice_bus2• 10 years ago

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

wink• 10 years ago

http://imgur.com/lDXqBBm

juice_bus2• 10 years ago

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

Thank you!

rusanu• 10 years ago

How long until we see the go equivalent of 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).

pcunite2• 10 years 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.

mikegedelman2• 10 years 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• 10 years 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• 10 years 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.

mb_72• 10 years ago

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.

serge2k• 10 years ago

Something like .NET is available but this is supported by the creators of Windows.

and .NET isn't?

pcunite2• 10 years ago

Within the context of this discussion ... I was meaning that if you don't use C/C++ you could use .NET which "is" supported. So, with Windows you don't have to use the native language since C# is supported by the creators.

kristianp• 10 years ago

> for commercial products it is recommended to build software in the native language of the OS

I'm not sure I agree with this, it may have been true before VB on windows. People like Dropbox would also disagree, they use(d) python for their UI code on the desktop, I believe.

analognoise• 10 years ago

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

robbrown451• 10 years 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• 10 years 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• 10 years 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• 10 years 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 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• 10 years ago

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

kmetan• 10 years ago

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

ssebastianj• 10 years 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 [1] https://github.com/golang/sys/tree/master/windows

fithisux• 10 years ago

I thought walk framework was there to reduce the code.

wiz21c2• 10 years 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• 10 years ago

But can it backtrace IPs?

akavel• 10 years 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

(godoc: https://godoc.org/github.com/akavel/winq)

Simple Windows GUI Application Written in Go

Related Stories