The generation of syscall wrappers is not automatic, so you need to add a
go:generate comment.

//go:generate go run ../../syscall/mksyscall_windows.go -output
zsyscall_windows.go syscall_windows.go

And then run go generate.

it doesn't use name stdsyscall. will be compile error.

On 1/20/15, Minux Ma notifications@github.com wrote:

The generation of syscall wrappers is not automatic, so you need to add a
go:generate comment.

//go:generate go run ../../syscall/mksyscall_windows.go -output
zsyscall_windows.go syscall_windows.go

And then run go generate.

---

Reply to this email directly or view it on GitHub:
#9635 (comment)

• Yasuhiro Matsumoto

OK. I see.

We have at least three choices:

1. Add a flag to mksyscall program
2. Add NewLazyDLL and Syscall9 wrapper to internal/syscall. One extra level
   of indirection won't hurt much as the overhead of cgocall is much higher.
3. Dot import syscall in internal/syscall. This might be ugly, but it is
   probably fine in this case as we are extending existing syscall package and
   it will also prevent us from redefining existing symbols in the original
   syscall package.

I like the 3rd option best.

@minux you are forgetting another option. We are calling new package internal/syscall/windows and then we don't need to do anything.

Alex

But I don't agree with that package name. Just having to import it under
another name when another package with the same name is in use is not
strong enough to change the package name. And it's possible to only use the
internal/syscall package alone if it's self-sufficient enough (like the
current internal/syscall package).

Think text/template and html/template for example.

My best is mixin

On 1/20/15, Minux Ma notifications@github.com wrote:

But I don't agree with that package name. Just having to import it under
another name when another package with the same name is in use is not
strong enough to change the package name. And it's possible to only use the
internal/syscall package alone if it's self-sufficient enough (like the
current internal/syscall package).

Think text/template and html/template for example.

---

Reply to this email directly or view it on GitHub:
#9635 (comment)

• Yasuhiro Matsumoto

Think text/template and html/template for example.

Not a good example. These two are never imported into the same source file. I would say think syscall and golang.orx/x/sys/windows instead.

Good names are important. I would like to decide on best possible name now and not to have that bikesheding every time we use these 2 packages together.

Alex

How could you be so sure that text/template and html/template are never
used in the same file?

I've found about 120 packages that import both packages (of about 2k and
2.1k packages that import either of them). And the first three common
packages happen to all import them in the same file. Renaming a package is
not as rare as you might have expected.

https://camlistore.googlesource.com/camlistore.git/+/master/website/camweb.go
https://github.com/bosun-monitor/bosun/blob/master/cmd/bosun/conf/conf.go
https://bitbucket.org/phlyingpenguin/collectinator/src/default/common/http.go

Similar name collision happen with net/http/pprof and runtime/pprof,
go/scanner and text/scanner, crypto/rand and math/rand. That's the example
in the std packages.

If you don't want renaming syscall package, you can only use it in a new
file, as long as we design internal/syscall in a way that the user are not
required to also import syscall, that should be fine too.

I believe @alexbrainman fixed this already.