Background

The Windows APIs use certain callbacks with floating point arguments, for example:
HRESULT IAudioSessionEvents::OnSimpleVolumeChanged( float NewVolume, BOOL NewMute, LPCGUID EventContext );

To register those from Go code, the syscall.NewCallback is needed. This in turn runs syscall.compileCallback which is implemented for Windows, in /runtime/syscall_windows.go. This function explicitly does not support floats as arguments and panics (link) with message compileCallback: float arguments not supported.

This originated from a conversation here and some comments in this issue.

Since the Go calling convention is being reworked (#40724) entirely, this may be a good moment to (try) to address this.

Proposal

Would be nice to have the support for callbacks with floating point arguments. In this way would be possible to interact with the system using pure Go, without the need of CGo.

I don't know if there are other issues in interacting with Windows APIs, but ideally a full support for interacting with Windows would be great.

Maybe it is worth mentioning that there is a project lead by Microsoft that aims at making WinAPIs more accessible to other languages, by precisely describing them in a metadata format that can be machine processed to get specific language implementations, called projections. With full support of Windows syscall/callbacks, would be possible to make a projection for Go in order to have access to the complete Windows APIs. This is probably best to be discussed in another issue (or elsewhere), but I thought was important to mention here.

Comments

As far as I understand, as the comment in the code says, in order for this to work we need to "spill" the floating point registers in order to retrieve the values. This is done in the file runtime/sys_windows_amd64.s.

I am (very) far from being an expert so I don't understand if this is a relatively easy task or a complicated one.

Also I don't really understand why in the C code in Windows SDK headers, callbacks are flagged as stdcall but here they are treated as fastcall here. In the first case the values should be in the stack as per documentation, but surely I am missing something.

Any thoughts?