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.
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.
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
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.
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.
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.
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.
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.
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.
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...
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.
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++.
All new APIs since Windows 8 are now COM based, yeah it is still Win32, but I guess it is just following their original idea for .NET (COM+ Runtime and not the CLR).
In some future version of Windows, when UWP with its COM foundation becomes prevalent, they can ripoff all the Win32 APIs that aren't required to support WinRT.
Just like Apple has done with Carbon, Quicktime and many others.
We will see how UWP works out. I wouldn't be too surprised if they changed their strategy in the next few years to come out with something different. That seems to be the Microsoft tradition. As soon as something starts working it gets replaced by something else.
I find this coming back from CLR to COM sad because the CLR support another very good language (F#) which isn't in WinRT and also because the CLR is going really multiplatform with .net core.
Also too bad Microsoft didn't pursed a multiplatform framework like Silverlight and go with a solution that didn't even run on its own OSes (previous version of Windows).
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.
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.
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.
> 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/) + 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.
Oh, no! Software development stack for desktop apps are all about developing desktop apps for either the most profit or the most reach. Exposing features? Please, the '90s are over - no need for vendor lock-in.
>Seriously? It's one of the worst DEs on linux. Any DE which isn't based on gnome is just cheap nowadays.
I'll take your hot opinion and replace it with mine: Gnome (3) is hands down the worst DE in the entire Linux ecosystem and is actively harming all others by merely existing due to the mentality driving its development: "fuck everyone that's not us, we set the standards and you will like them".
Currently KDE is the most polished and feature complete of the "batteries included" DEs. And even then as a developer I prefer a bare-bones tiling set-up, picking and choosing what I want and having an experience customized to my preferred workflow.
Exactly; hence if you were to say it'd be unfortunate for you to have to go back to Linux, I wouldn't say you were prejudiced either, since you know from personal experience.
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.
>> 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.
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.
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:
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.
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.
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.
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:
64 comments
[ 0.44 ms ] story [ 110 ms ] threadhttps://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.
i := C.foo(C.int(j))
Assuming j is a Go int type.
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.
https://github.com/andlabs/ui https://github.com/lxn/walk
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.
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.
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...
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.
In any case, OWL, VCL and later on MFC were my tools during those days, when given an option.
Thank you!
Ideally this sort of platform import should be automated so that Win32 specific apps could import the more advanced GUI stuff (comdlg et all).
Why?
Less bugs, better examples, community support.
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.
One reason would be if you're trying to build a node based app which you would like to use across other platforms.
In some future version of Windows, when UWP with its COM foundation becomes prevalent, they can ripoff all the Win32 APIs that aren't required to support WinRT.
Just like Apple has done with Carbon, Quicktime and many others.
The only constants are COM and Win32.
If you look at what Delphi, Modula-3, Ada, Component Pascal, Oberon variants, Eiffel were already offering before Java took off.
> As soon as something starts working it gets replaced by something else.
Just like everyone else. I can hardly think of any platform owner that has kept their APIs stable.
Not that you are not right to complain, I just get the impression many tend to forget about the other vendors similar practices.
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.
KDE? Seriously? It's one of the worst DEs on linux. Any DE which isn't based on gnome is just cheap nowadays.
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.
Same or similar? It doesn't matter what they provide because I'd go with ScalaFX(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/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.
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.
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/) + GtkBuilder.
> So which other DE on GNU/Linux does provide the same tooling and platform abstractions as KDevelop/Qt Creator do?
You answered:
> Why would you need specific features? You wanted to develop desktop apps, not gnome plugins, right?
Clearly KDevelop and At Creator expose GNU/Linux specific feature.
Software development stack for desktop apps are all about exposing the features that make a platform desired to be used.
Desktop apps that expose the features that make the platform unique.
> If you want RAD there's Glade(https://glade.gnome.org/) + GtkBuilder.
Not even close to Delphi and C++ Builder and we are talking about 90's here.
If I upgame to Blend + VS, XCode + Playgrounds, Android Studio then there is a lot of catch up to do.
I'll take your hot opinion and replace it with mine: Gnome (3) is hands down the worst DE in the entire Linux ecosystem and is actively harming all others by merely existing due to the mentality driving its development: "fuck everyone that's not us, we set the standards and you will like them".
Currently KDE is the most polished and feature complete of the "batteries included" DEs. And even then as a developer I prefer a bare-bones tiling set-up, picking and choosing what I want and having an experience customized to my preferred workflow.
and .NET isn't?
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.
after a while things will settle down and this "hello world" program will boil down to something much simpler, like:
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.I don't think it would be that ugly if you compared it C code that didn't include windows.h
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.
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
Is it just me ?
https://github.com/akavel/winq
(godoc: https://godoc.org/github.com/akavel/winq)