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