It would help if somebody suggested specific new API that would work for all known cases. It seems to me that just adding syscall.SyscallFloat may not be enough. What about syscall.(*Proc).Call and syscall.(*LazyProc).Call?

Good point. I had not yet encountered a case where I needed this in my own projects, but that should be considered as well. I’ll try to come up with a list and post it here.

Are the APIs you reference unimplemented in x/sys/windows?

See also discussion in #6510.

cc @alexbrainman @zx2c4 @mattn

Looking through both package syscall and golang.org/x/sys/windows, it appears these are the APIs that need a "Float" variant for the return:

syscall.Syscall -> syscall.SyscallFloat
syscall.Syscall6 -> syscall.SyscallFloat6
syscall.Syscall9 -> syscall.SyscallFloat9
syscall.Syscall12 -> syscall.SyscallFloat12
syscall.Syscall15 -> syscall.SyscallFloat15
syscall.Syscall18 -> syscall.SyscallFloat18
syscall.(*Proc).Call -> syscall.(*Proc).CallFloat
syscall.(*LazyProc).Call -> syscall.(*LazyProc).CallFloat

windows.(*Proc).Call -> windows.(*Proc).CallFloat
windows.(*LazyProc).Call -> windows.(*LazyProc).CallFloat

runtime·asmstdcall -> runtime·asmstdcallfloat <-- this is where a one-line change is needed to return the float register (X0, I believe)

Regarding @networkimprov 's question: golang.org/x/sys/windows doesn't implement the syscall code itself -- it just calls through to the implementation in syscall.

Another possibility, which would require only a single code change in function runtime·asmstdcall in runtime/sys_windows_amd64.s and no visible API changes: make use of the currently-unused r2 result by always copying the X0 register into it on return, much like is currently done for the first 4 potential floating point arguments. This value is used on 32-bit systems, but I don't think the float problem exists there and no change is needed in runtime/sys_windows_386.s.

Do Windows function that accept floating point arguments work correctly?

Is there a need to fix this in the syscall package, which is more or less frozen, or can we just fix it in golang.org/x/sys/windows?

In my usage of them, yes, floating point args do work since the fix to fill the first four registers was put in. I found I do have to pass them by calling the conversion function in the math package, but that’s workable.

As stated earlier, the fix has to be in the runtime package, as that’s where the info is and the plumbing is private to that package so can’t be fixed externally.

My particular case is the Direct2D and DirectWrite APIs, although I've seen the need elsewhere as well.

Which API are you talking about?

Another possibility, which would require only a single code change in function runtime·asmstdcall in runtime/sys_windows_amd64.s and no visible API changes: make use of the currently-unused r2 result by always copying the X0 register into it on return, much like is currently done for the first 4 potential floating point arguments.

That sounds reasonable. Is X0 register documented by Microsoft to receive returned value on amd64?

This value is used on 32-bit systems, but I don't think the float problem exists there and no change is needed in runtime/sys_windows_386.s.

Fair enough.

Alex

My particular case is the Direct2D and DirectWrite APIs, although I've seen the need elsewhere as well.

Which API are you talking about?

As stated above, both the Direct2D and DirectWrite APIs are the ones I'm currently using. Did you want a specific function call? If so, here's one off the top of my head: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/nf-d2d1-id2d1brush-getopacity
I'm not sure it matters, though -- this is basic functionality that should be possible, even if official Microsoft APIs didn't have FLOAT return args.

Another possibility, which would require only a single code change in function runtime·asmstdcall in runtime/sys_windows_amd64.s and no visible API changes: make use of the currently-unused r2 result by always copying the X0 register into it on return, much like is currently done for the first 4 potential floating point arguments.

That sounds reasonable. Is X0 register documented by Microsoft to receive returned value on amd64?

Yes. From here: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019:
A scalar return value that can fit into 64 bits is returned through RAX; this includes __m64 types. Non-scalar types including floats, doubles, and vector types such as __m128, __m128i, __m128d are returned in XMM0. The state of unused bits in the value returned in RAX or XMM0 is undefined.

Change https://golang.org/cl/220578 mentions this issue: runtime: allow float syscall return values on windows amd64

... Did you want a specific function call?

I did. I was not aware of its existence.

If so, here's one off the top of my head: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/nf-d2d1-id2d1brush-getopacity

Sounds good. Thank you.

I'm not sure it matters, though -- this is basic functionality that should be possible, even if official Microsoft APIs didn't have FLOAT return args.

No argument.

... From here: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019:
A scalar return value that can fit into 64 bits is returned through RAX; this includes __m64 types. Non-scalar types including floats, doubles, and vector types such as __m128, __m128i, __m128d are returned in XMM0. The state of unused bits in the value returned in RAX or XMM0 is undefined.

Looks good. Thank you.

Alex

Change https://golang.org/cl/236562 mentions this issue: syscall: document float arguments and results on windows/amd64