you can use the syscall package to access dll exported functions without
cgo. But be aware that floating point arguments and return are not
supported.

Like @minux said. And yes you can download any .DLL as part of go get, but you would have to put it somewhere in your PATH to be able to use it.

syscall.LoadLibrary looks like it would work, but it would mean generating a lot of code for the mobile/gl package. That is, something like https://github.com/golang/mobile/blob/master/gl/gldebug.go that replaces all the cgo calls with syscall.GetProcAddress+syscall.Syscall in a gl_windows.go file.

That's probably the way to go.

If you really want to avoid cgo on windows, that is probably the way to go. The generator
need to take care of floating point arguments and returns and probably you also need
to generate the corresponding C wrapper for functions taking floating point arguments
and returning floating point result.

That said, there does exist an easier way to avoid gcc, which I'd call frozen cgo. The idea
is that we preprocess all the cgo files, and compile the cgo.o and include it as cgo.syso
in the package directory.

This approach should work well for cases where we know the interface won't change
(for example, all the C code is statically linked in the syso file). And it also relies on the
fact windows does not support external linking. However, not supporting external linking
also means the syso can't use much C++.

The frozen cgo approach does work. As an example, given this simple cgo program:
package main
/*
int f() { return 42; }
*/
import "C"
func main() {
println(C.f())
}

First go build -work cgo.go, record the $WORK it showed.

And then create a new directory, and copy these four files into it:
cp $WORK/command-line-arguments/obj/all.o cgo$GOOS$GOARCH.syso
cp $WORK/command-line-arguments/obj/cgo_gotypes.o z_cgo_gotypes$GOOS$GOARCH.go
cp $WORK/command-line-arguments/obj/cgo_imports.go z_cgo_imports$GOOS$GOARCH.go
cp $WORK/command-line-arguments/obj/cgo.cgo1.go z_cgo$GOOS_$GOARCH.go

And go build -x inside that directory. You will see that cgo and gcc are not invoked.

This generalizes all cgo programs, just copy all.o to cgo$GOOS_$GOARCH.syso,
and all the Go files inside work directory, replace their leading underscore (go build won't build
any files with underscore as prefix) and append $GOOS$GOARCH to their base name
(we must treat all these as platform dependent).

Although this means that you need to separate windows support to separate package and
precompile for both 386 and amd64, this should be much easier than to use the syscall package
and create wrappers because all this can be automated.

This is the first time I publicly discuss this concept, hopefully it has not been proposed before. :-)

@minux, I tried following your instructions, but it fails.

C:\go\path\mine\src\foo>dir
Volume in drive C has no label.
Volume Serial Number is XXXX-YYYY

Directory of C:\go\path\mine\src\foo

16/12/2014 10:36 AM

C:\go\path\mine\src\foo>type cgo.go
package main

/*
int f() { return 42; }
*/
import "C"

func main() {
println(C.f())
}

C:\go\path\mine\src\foo>go build -work cgo.go
WORK=C:\DOCUME1\brainman\LOCALS1\Temp\go-build029113339

C:\go\path\mine\src\foo>set WORK=C:\DOCUME1\brainman\LOCALS1\Temp\go-build029113339

C:\go\path\mine\src\foo>copy %WORK%\command-line-arguments_obj_all.o cgo_windows_386.syso
1 file(s) copied.

C:\go\path\mine\src\foo>copy %WORK%\command-line-arguments_obj_cgo_gotypes.o z_cgo_gotypes_windows_386.go
The system cannot find the file specified.

C:\go\path\mine\src\foo>

I am also not convinced that general C code can be packaged into executable on Windows. Some C libs might be configured to be built as DLLs. Then you have to ship these DLLs as part of your app. Some C libs might rely on external libs (DLLs) (for example Microsoft C runtime or similar). Then again you have to distribute these along with your app.

Mind you, you could, probably, create DLL file in /tmp on the fly and load it on your app startup. I have never tried that, but I don't see why it won't work. Maybe anti-virus might complain ...

I am also not sure why you want to run mobile app natively on Windows desktop. I think it would be nuch more useful to be able to launch mobile app inside of some emulator that runs on Windows desktop. The emulator that creates environment that looks as close as possible to real device. Or just launch mobile app on real device.

Alex

Configuring build environments for mobile devices is hard. For iOS, you just cannot do it on windows. For android, you need to install the SDK+NDK+Go cross compiler.

What we have right now for Mac and Linux lets you download the stock Go build, write a 15-line app and type go build. Compile+test cycles are dramatically faster than working on the real device, and the whole experience is a lot more fun. I'd like to bring that to windows users. I'm sure we can, there's just work to do.

Sure, lets try.

@alexbrainman,
the essence is that you copy all generated source files in $WORK to the new
directory.
My procedure is for tip. If you're using 1.4, then you need to adjust it
accordingly (1.4
still generates C files to be compiled by the Plan 9 C compiler.)

If you're using tip, copy all Go files in $WORK, but rename them so that
they don't have
a underscore as prefix as the go tool will ignore filenames starting with
underscore.

I think doing iOS development on Linux is possible, if we tried hard
enough, we might be
able to get it work on windows.

clang is definitely buildable on windows, as and ld64 are harder. The code
signing tools
are even harder. But at least it's possible to build everything on Linux.

I doubt any iOS app developer want to develop on Windows, though.

@minux I am using

C:\go\path\mine\src\foo>go version
go version devel +ab96371 Mon Dec 15 01:55:29 2014 +0000 windows/386

What we have right now for Mac and Linux lets you download the stock Go build, write a 15-line app and type go build. Compile+test cycles are dramatically faster than working on the real device, and the whole experience is a lot more fun. I'd like to bring that to windows users. I'm sure we can, there's just work to do.

Does x/mobile/gl support windows yet? (I can't remember if either Hana or I added it.) I hope it's not to hard to add, but I wouldn't want to break any gxui users on windows.

So AFAICT, no it doesn't. It doesn't seem trivial to add either. The problem is windows doesn't really have an OpenGL header that's worth using (the system one is OpenGL 1.1, which is pretty worthless). Typically, the drivers support more up to date versions of GL - GXUI has shown that most windows users have a driver that supports at least OpenGL 2.1, but the function pointers need to be obtained using something like wglGetProcAddress.

I'm not sure what the best course of action is for adding Windows support into x/mobile/gl. Really all you're going to end up with is something using GLEW or something that looks very similar to GLOW.

/cc @crawshaw @ben-clayton

It seems the end goal is to make it work very seamless on Windows, but it sounds hard to do right away.

What do you think about taking a smaller step first, getting it to work at least as well as github.com/go-gl/gl/v2.1/gl works on Windows, and then creating a new issue to improve the experience?

Doing that can be done very quickly and allow google/gxui#86 to proceed.

There are a few ways to make it happen:

• Import and use github.com/go-gl/gl/v2.1/gl to implement the GL interface using windows build constraint.
• Use glow (the GL bindings generator that is used to generate all go-gl/gl/... packages) to generate the implementation of GL needed for windows build constraint.
  • E.g., see https://github.com/go-gl/gl/blob/master/generate.go.
• Similar to above, but outright copy the code of github.com/go-gl/gl/v2.1/gl to implement the GL interface using windows build constraint.
• Other ways?

I like the idea of using GLOW - I didn't realise that it was usable outside of the go-gl library.
I'm wondering if we could use GLOW to generate the GLES 2 bindings for all platforms, then wrap these with x/mobile/gl's types.
It seems like GLOW might need to add an Android branch to the procaddr.go generated code. This however is certainly doable.

CL https://golang.org/cl/17777 mentions this issue.

CL https://golang.org/cl/17810 mentions this issue.

Although this is an old issue I still want to point you to my Direct3D9 wrapper.
It still needs a C compiler (it was tested with MinGW 32 and 64) but you do not have to install any extra libraries or drivers for it to work.
I am also thinking about providing a version of the wrapper that does not use CGo, similar to what w32 does but I have yet to find out how to do that. Until then, only installing MinGW seems OK.