You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating stubs for Windows DLL routines, mksyscall_windows.go currently maps string parameters to *byte by default and to *uint16 (with UTF-16 conversion) only if the function's name ends in W. There are many Windows routines that take UTF-16 strings but do not end in W. It would be more generally useful if there were a per-syscall or per-parameter option to specify the string width. I'm trying to use mksyscall_windows for a project, and I have to use *uint16 + manual string conversion all over the place because our UTF-16-accepting APIs do not end in W.
(As a side not, it's not clear to me if it's really supported to use mksyscall_windows outside of the go source tree, although there is precedent in some packages on GitHub.)
I'm happy to make the change to mksyscall_windows if someone else will do the bikeshedding for me on how to specify this :). E.g. if I want to import BOOL PathCchIsRoot(PCWSTR), what should I write? The following? Other ideas?
... It would be more generally useful if there were a per-syscall or per-parameter option to specify the string width. I'm trying to use mksyscall_windows for a project, and I have to use *uint16 + manual string conversion all over the place because our UTF-16-accepting APIs do not end in W.
Converting Go string into []uint16 is not free. So we're always try to leave it for the caller to decide if that price is worth it.
Also, quite often you have *uint16 field of a struct parameter, rather than *uint16 parameter. You proposal won't handle these.
I don't think it is worth complicating //sys syntax and mksyscall_windows.go code.
But feel free to copy mksyscall_windows.go and change it to your liking. I've done it few times myself.
... (As a side not, it's not clear to me if it's really supported to use mksyscall_windows outside of the go source tree, although there is precedent in some packages on GitHub.)
Use it if it works for you, but be prepared if it breaks your programs and all.
I always use it for my projects - it allows me concentrate on the job rather than spend time making syscalls right. These mistakes can be fatal.
Also mksyscall_windows.go generates GC safe code for syscalls with string parameters (applicable to your case).
mikioh
changed the title
mksyscall_windows.go should optionally treat string as UTF16 even if function does not end with W
syscall: mksyscall_windows.go should optionally treat string as UTF16 even if function does not end with W
Jul 23, 2015
When creating stubs for Windows DLL routines, mksyscall_windows.go currently maps string parameters to *byte by default and to *uint16 (with UTF-16 conversion) only if the function's name ends in W. There are many Windows routines that take UTF-16 strings but do not end in W. It would be more generally useful if there were a per-syscall or per-parameter option to specify the string width. I'm trying to use mksyscall_windows for a project, and I have to use *uint16 + manual string conversion all over the place because our UTF-16-accepting APIs do not end in W.
(As a side not, it's not clear to me if it's really supported to use mksyscall_windows outside of the go source tree, although there is precedent in some packages on GitHub.)
I'm happy to make the change to mksyscall_windows if someone else will do the bikeshedding for me on how to specify this :). E.g. if I want to import BOOL PathCchIsRoot(PCWSTR), what should I write? The following? Other ideas?
@alexbrainman
The text was updated successfully, but these errors were encountered: