x/sys/windows: mkwinsyscall: Support - and . in DLL name

[dagood]

Let's say I wanted to add this API to x/sys/windows: https://learn.microsoft.com/en-us/windows/win32/api/socketapi/nf-socketapi-setsocketmediastreamingmode. My initial thought is to add something like this //sys line:

//sys	SetSocketMediaStreamingMode(value bool) (err error) = windows.networking.SetSocketMediaStreamingMode

However, go generate ./windows/ then fails:

Could not extract dll name from "SetSocketMediaStreamingMode(value bool) (err error) = windows.networking.SetSocketMediaStreamingMode"

This is because mkwinsyscall doesn't handle more than one ., and windows.networking.SetSocketMediaStreamingMode has two: https://github.com/golang/sys/blob/6e4d1c53cf3b2c1c6d104466749f76cc7a5c9ed8/windows/mkwinsyscall/mkwinsyscall.go#L483-L491

---

- doesn't break in quite the same way, but the fix is related. For example, api-ms-win-wsl-api-l1-1-0.WslRegisterDistribution isn't rejected by mkwinsyscall itself, but the generated code isn't valid because an identifier can't contain a -.

Changes

• It's easy to change the default case to support this by assuming any extra . segments are part of the DLL name. This seems like a valid assumption because the win32 methods won't have . in them.
• After making that change, there are some changes needed elsewhere to escape . so mkwinsyscall generates buildable Go code.
  • To make - work, too, it can also be escaped.
• A simple escaping rule is to replace . and - with _.
  • In theory, escaped DLL names could collide, but I'm not aware of any instances where this would happen.

Effect on //sys lines being (almost entirely) readable Go code

//sys	CryptAcquireContext(...) (err error) = advapi32.CryptAcquireContextW

In that line, = advapi32.CryptAcquireContextW lets us think of this as aliasing a func in a advapi32 Go package.

The proposal breaks the metaphor: = windows.networking.SetSocketMediaStreamingMode is not valid Go. Is this ok, or does mkwinsyscall need to strictly enforce the metaphor?

An alternative would be extending the metaphor by importing a "package" with a rename, but this would be more complicated to implement properly:

//sysimport windowsnetworking "windows.networking"
//sys	SetSocketMediaStreamingMode(...) (...) = windowsnetworking.SetSocketMediaStreamingMode

Background

I'm trying to use mkwinsyscall for x/sys/windows: use win32metadata? #43838 by having a generator create //sys comments. When I generated //sys lines for all the API methods for Windows.Win32.winmd, I hit these . and - cases.

I don't know if it makes sense for #43838 to end up using mkwinsyscall in this way, but I figure until that proposal gets traction one way or another, it's worth asking about adding this kind of support.

• I also filed x/sys/windows: mkwinsyscall isn't diagnosable if format.Source fails #57925 for an improvement to diagnosability I made while looking into this issue.

[qmuntal]

I don't think this has to be a proposal but a bug fix: mkwinsyscall fails when a DLL name can contain - and .. The metaphor think you mention is not documented anywhere nor it affects the generated code, so I'm good with this change.

@dagood can you create a separate bug issue that focus on improving the diagnostics of failing format.Source calls?

@alexbrainman @zx2c4

[dagood]

I'm planning to submit a CL soon to escape by changing - and . to _.

[alexbrainman]

@dagood thanks for creating this issue

Let's say I wanted to add this API to x/sys/windows: https://learn.microsoft.com/en-us/windows/win32/api/socketapi/nf-socketapi-setsocketmediastreamingmode.

Can this function be used from Go programs?

For example, api-ms-win-wsl-api-l1-1-0.WslRegisterDistribution isn't rejected by mkwinsyscall itself, but the generated code isn't valid because an identifier can't contain a -.

Same question. Is it possible to use api-ms-win-wsl-api-l1-1-0.WslRegisterDistribution function from a Go program?

I'm planning to submit a CL soon to escape by changing - and . to _.

So far no one complained about using mkwinsyscall with these functions. Perhaps the functions are not useful for current Go users or are not possible to call from Go programs.

Otherwise it is fine to make that change. If changes are simple enough.

You can also make your own copy of mkwinsyscall program and do what you like with it.

Alex

[gopherbot]

Change https://go.dev/cl/463215 mentions this issue: windows/mkwinsyscall: support "." and "-" in DLL name

[dagood]

Can this function be used from Go programs?

I got the signature wrong earlier, it should be:

//sys	SetSocketMediaStreamingMode(value BOOL) (r HRESULT) = windows.networking.SetSocketMediaStreamingMode
type BOOL int32
type HRESULT int32

With that, I'm able to call it with 1 or 0 and I get 0 (S_OK) returned. I'm not sure how to tell if it's actually doing what it says it should do, but at least it doesn't fail!

Same question. Is it possible to use api-ms-win-wsl-api-l1-1-0.WslRegisterDistribution function from a Go program?

Yep, this works, and the result shows up in wsl --list.

I don't have any concrete reasons why either of these would be needed by a Go program. They do seem fairly niche, and I can see why they haven't (and maybe wouldn't have) ever come up. This is just for completeness--it might make more sense to fork/integrate the generator rather than reuse it when #43838 gets further along.

I think it's a simple change--just submitted the CL.