Hacker News Reader

Comment by Impossible | Hacker News Reader

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.

View on HN

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.

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.

I'd argue that it's not "fallacious", it's simply a matter of opinion and taste.

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.

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.

100% agree. With modern tools, I :

Think the UI the way I code it (declarative)

Don't have to think about screen resolution, colour depth,...

Don't have to bother with non unicode stuff

Have access to well behaved widgets

Can have portability if I need that

Even if I can't control 100% of the rendering process, my productivity has increased...

> Think the UI the way I code it (declarative)

Windows Ressource files exist at least since Windows 3.x

> Don't have to bother with non unicode stuff

Just use the WinAPI functions that are prefixed with W (Unicode) instead of A (ANSI), e.g. CreateWindowExW instead of CreateWindowExA.

> Have access to well behaved widgets

Call CreateWindowEx (https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...) (yes, the name is confusing, accepted) with lpClassName value, say, of BUTTON, COMBOBOX, EDIT, LISTBOX, MDICLIENT, SCROLLBAR (for a more complete list look at the MSDN site that I linked). This creates such a widget.

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.

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

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

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.

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.

Does that include macro pre-processing as well? There's a lot of stuff like WIN32_LEAN_AND_MEAN in there as well.

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.

So just some quick googling points to 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.

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"

Reply on news.ycombinator.com