For functions defined in the syscall or golang.org/x/sys/windows packages we can just make the generated code do the right thing, but I don't see any such functions. Are there any?

So I guess the question is: how should we handle functions loaded using DLL.FindProc or similar that take GUID argument values. Is that right?

It does seem tough to handle that case. I don't see any way to do it. I don't even see how to generalize it, since GUID values take different numbers of arguments for different GOARCH values.

How many such functions are there?

For functions defined in the syscall or golang.org/x/sys/windows packages we can just make the generated code do the right thing, but I don't see any such functions. Are there any?

Not at the moment in x/sys/windows. There are a few scattered around win32 APIs, though. OLE stuff, for example, passes GUIDs by value rather than by reference. I had to make this change a few months ago: lxn/win@c5100a6#diff-bc58b257cf27988dcfdc566b7e06d2b860735a55a826eccd037b89f5bb5bcda5 There might also be other functions that take structs other than GUIDs, though none I can name off the top of my head.

So yea one approach would be making mkwinsyscall split up generic structs according to the splitting rules of the ABI, and then generating helper functions per-arch and using runtime.GOARCH to choose. That would work, though could also be kind of hard. Another approach would be just doing this for matches on windows.GUID or syscall.GUID types, which split things up the same way every time. That's a little easier, but less robust. And not totally easy too -- we'd need logic in there that examines how many arguments are prior to the split argument to see if it actually should be passed by reference because there aren't enough registers (per arm abi).

I wonder if there's a more clever approach that could be done in syscall.Syscall, though, where arbitrary types can be passed rather than just uintptr. But casting through interface{} sounds kind of bad. Would this need special compiler support? Or more flexible trampolines done in asm that handle this better? Or Go2 generics?

How many such functions are there?

I'm not sure, and this most certainly is not a pressing need of any kind, at least at the moment.

But I thought I should at least open the discussion as something to keep in mind as things evolve -- winmd, generics, regabi, maybe other exciting things -- and if anybody has new ideas about it.

An example of this apparently lives in syscall/, brought to my attention by @rsc's recent CL: https://go-review.googlesource.com/c/go/+/288815

@gopherbot add OS-Windows

Perhaps I don't understand the problem. But you should talk to @aclements about it.

I reviewed his CL recently that fixed problems passing Go structs / different data types from C to Go during callbacks. Austin needed correct C to Go data translation for future work they do for passing parameters in registers. There is even runtime.TestStdcallAndCDeclCallbacks that uses gcc to build correspondent C dlls to test this interaction. You can add your own data types to see, if they work (for whatever GOARCH). Windows callback code is part of runtime package. But I am sure Go Team can adopt similar code in the compiler.

I hope it helps.

Alex