windows port status?

[Joe Poirier]

Is the windows port actively being worked on? What's the best way to
go about contributing?

I noted four potential areas for contributions, pkg/debug/proc, pkg/
os, pkg/syscall, and pkg/runtime.

-joe

[Evan Shaw]

I haven't kept close track of the Windows port, but the packages you mentioned sound about right. I think runtime's in a usable state, although it could still use some work. syscall work should come before os, as os is pretty dependent on syscall. debug/proc is the least important. I think there's also still some work that could be done in lib9 and libmach.

- Evan

[Devon H. O'Dell]

2010/2/2 Joe Poirier <jdpo...@gmail.com>:

Also pkg/net.

--dho

> -joe
>

[Joe Poirier]

On Feb 3, 10:50 am, "Devon H. O'Dell" <devon.od...@gmail.com> wrote:
> 2010/2/2 Joe Poirier <jdpoir...@gmail.com>:

>
> > Is the windows port actively being worked on? What's the best way to
> > go about contributing?
>
> > I noted four potential areas for contributions, pkg/debug/proc, pkg/
> > os, pkg/syscall, and pkg/runtime.
>
> Also pkg/net.
>
> --dho
>

Thanks guys, appreciate the information.

Have there been any detailed discussions on how to go about finishing
the remaining work? Of course to get the code committed to Go's source
tree it'll need the blessing of the core development team, so it's
important that they're involved in directing the work. Is this already
happening?

I know the mingw environment is used to build the tools (compiler,
linker, etc.) but what about the windows runtime?

At this point I'm still a bit fuzzy on the exact details of what's
left to do, or how to go about doing it, but these are some projects
that may offer some insight and/or potential lift (probably already
been considered but thought I'd list them anyway) - intact or
piecemeal:

- The cygwin library already has a unix-like layer to the windows api
but there could be issues with, licensing, being tied to cygwin, the
cygwin dll baggage.
- The mingw runtime library encapsulates the windows api and it's
public domain. Does it map of unix to windows?
- dietlibc, uClibc, others?
- Possibly have a peek at runtimes from other compilers, e.g. TCC,
Pelles, DMC, PCC, LCC, etc...

As far as developing on windows goes, getting stubs in place (like the
freebsd port) so all the packages build is a must. Then work can
proceed from the inside out.

Feedback from the core Go team would be greatly appreciated!

-joe

[Russ Cox]

It would be great to get the Windows library support fleshed out.
It should really just be a matter of reading about the various
Windows functions and calling them; there's no need to go
through a Unix compatibility layer to get there.

Russ

[Joseph Poirier]

Any place specific in mind to start?

-joe    

[CCs]

I would just go in and fix the Windows specifics, without any
dependency.

Go is new, so the libraries are small, it can be done fast.
Also this is the "Google way" of doing business...

[Michael Hoisie]

Would it be possible to add some windows instructions to golang.org?
Even with a big bold disclaimer. I use Windows primarily at work and I
could do some testing.

- Mike

[Esko Luontola]

On Feb 4, 12:43 am, Michael Hoisie <hoi...@gmail.com> wrote:
> Would it be possible to add some windows instructions to golang.org?
> Even with a big bold disclaimer. I use Windows primarily at work and I
> could do some testing.

I suppose the best would be to just instruct Windows users to run
Linux on a virtual machine, until a native Windows version is ready.
I've been quite happy with VirtualBox.

[Alex Brainman]

> It would be great to get the Windows library support fleshed out.

Sure enough, all Windows functions are just one call into dll away.
But where do you put the changes?

The way it is all structured at the moment, is the "syscall" package
at the heart of it. Grepping for syscall gives me roughly this:

206 net
224 os
50 runtime
216 syscall
3 time

Looking at this we can say that we need to make sure os, time and net
works.

One way would be to create windows version of "syscall", but, I feel,
it's too "unixy" at the moment, and none of the automation scripts
there will help.

Another way, would be to create new package (windows or winapi) with
all specific windows functions, and then use it in os, time and net.
In that situation, we would have to split these (os, time and net)
into syscall and windows versions.

Which approach to take? Are there any other options?

Alex

[Chris Wedgwood]

On Wed, Feb 03, 2010 at 05:09:29PM -0800, Alex Brainman wrote:

> Sure enough, all Windows functions are just one call into dll away.

is there some reason not invoke syscalls directly?

[Ian Lance Taylor]

Alex Brainman <alex.b...@gmail.com> writes:

> One way would be to create windows version of "syscall", but, I feel,
> it's too "unixy" at the moment, and none of the automation scripts
> there will help.
>
> Another way, would be to create new package (windows or winapi) with
> all specific windows functions, and then use it in os, time and net.
> In that situation, we would have to split these (os, time and net)
> into syscall and windows versions.
>
> Which approach to take? Are there any other options?

I apologize if I missed something, but have you looked at
http://code.google.com/p/go-windows ?

We already have system specific files in os and net, so adding a
windows version there seems entirely appropriate. The use of syscalls
in time is fairly trivial and should probably be abstracted back into
the syscalls package. I agree that it's not appropriate to try to
provide the same syscalls interface on Windows as on Unix; that's not
to say that Windows shouldn't have a syscalls package, just that it
doesn't need to provide the same API as the Unix one. The goal should
be to provide the same API at the os/net level.

Ian

[Joe Poirier]

On Feb 3, 7:54 pm, Ian Lance Taylor <i...@google.com> wrote:

Correct me if I'm wrong, but I believe the code at http://code.google.com/p/go-windows
is old (November) and contains the original work Hector did, which has
already been merged in to the Go source tree.

I had the same too "unixy" feeling about the syscall package as well
but wasn't sure if a unix comparability layer was the vision - Russ
stated it's not.

I can attempt to put together a windows api syscall package, test it,
and once it's working ask for more feedback on the best way to go
about merging it in. Once that's in place it's just a matter of
connecting all the other bits and pieces. What are your thoughts?

At some point, I think there may need to be some finer grained control
over the windows build, e.g. to differentiate between versions (win2k,
xp, vista, win7). What's the oldest version of windows that'll should
be supported?

Thanks for all the great input guys, it's much appreciated!

-joe

[Joe Poirier]

On Feb 3, 9:37 pm, Joe Poirier <jdpoir...@gmail.com> wrote:
> On Feb 3, 7:54 pm, Ian Lance Taylor <i...@google.com> wrote:
>
>
>
>
>
> > Alex Brainman <alex.brain...@gmail.com> writes:
> > > One way would be to create windows version of "syscall", but, I feel,
> > > it's too "unixy" at the moment, and none of the automation scripts
> > > there will help.
>
> > > Another way, would be to create new package (windows or winapi) with
> > > all specific windows functions, and then use it in os, time and net.
> > > In that situation, we would have to split these (os, time and net)
> > > into syscall and windows versions.
>
> > > Which approach to take? Are there any other options?
>
> > I apologize if I missed something, but have you looked athttp://code.google.com/p/go-windows?
>
> > We already have system specific files in os and net, so adding a
> > windows version there seems entirely appropriate.  The use of syscalls
> > in time is fairly trivial and should probably be abstracted back into
> > the syscalls package.  I agree that it's not appropriate to try to
> > provide the same syscalls interface on Windows as on Unix; that's not
> > to say that Windows shouldn't have a syscalls package, just that it
> > doesn't need to provide the same API as the Unix one.  The goal should
> > be to provide the same API at the os/net level.
>
> > Ian
>

> Correct me if I'm wrong, but I believe the code athttp://code.google.com/p/go-windows

> is old (November) and contains the original work Hector did, which has
> already been merged in to the Go source tree.
>
> I had the same too "unixy" feeling about the syscall package as well
> but wasn't sure if a unix comparability layer was the vision - Russ
> stated it's not.
>
> I can attempt to put together a windows api syscall package, test it,
> and once it's working ask for more feedback on the best way to go
> about merging it in. Once that's in place it's just a matter of
> connecting all the other bits and pieces. What are your thoughts?
>
> At some point, I think there may need to be some finer grained control
> over the windows build, e.g. to differentiate between versions (win2k,
> xp, vista, win7). What's the oldest version of windows that'll should
> be supported?
>
> Thanks for all the great input guys, it's much appreciated!
>
> -joe

Here's a listing of windows syscalls broken down by version and
service pack:
http://www.metasploit.com/users/opcode/syscalls.html

Based on the chart, I'm not sure that it's feasible to make the calls
directly. But I guess that'll depend on what needs to be implemented.
They were meant to be called from a standard api implemented through
an OS version-specific dll rather than directly.

[Bob Cunningham]

Since Go is a moving target, and will be one for some time to come, why not be pragmatic and take full advantage of existing UNIX API layers for Windows?

No need to reinvent the wheel (or add another one) until Go's evolution slows down a bit.

Check out the following:
Cygwin - http://www.cygwin.com/
Lina - http://openlina.com/
Microsoft Windows Services for UNIX - http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX


-BobC

[Russ Cox]

Hector made it possible to call DLL functions, not just system calls.
In fact it's almost certainly a mistake to call system calls directly
on Windows. Call the documented entry points in the win32 DLL
and its cousins.

Package syscall can have a completely different interface on
Windows if it needs to. Then, as Ian said, package os and net
can present the same interface that they do here. We tried when
designing the interfaces to make it possible to implement them
on Windows.

Hector's runtime work is merged in but I believe the go-windows
repository has some preliminary syscall/os/net stuff too.

Russ

[Joseph Poirier]

Okay, then looking at Hector's code is a good place for me to start. 

-joe 

[NoiseEHC]

They are officially undocumented and can be changed by Microsoft any time (theoretically). While it is quite unlikely that Microsoft would break compatibility here the blessed method on Windows is to use kernel32.dll wrapper functions unless you write a low level utility (like WinObj.exe).

[Joe Poirier]

I'd read that as well, but there are situations when doing things by
the book doesn't work so you figure out creative ways to get it
done.

[CCs]

I don't see there's a reason to use undocumented syscalls instead of
documented Win32/64 API.
Low level applications requiring this kind of access will be written
in plain C anyway (likely they need explicit memory management
anyway).

The main goal of Go is server-side code (like PHP or Rails), so I
think it's OK to target Windows 7/Server 2008 R2 and up.

XP 32bit can run coLinux/VirtualBox, so even today you can have a Go
web server on it.
64bit Windows (mainly Win7/2008) on the other hand needs work.

So XP support would be nice, but not essential.

[Joe Poirier]

Sorry if my last comment caused confusion.

The appropriate api calls will be used, and not the direct syscalls.
See Russ' last post.

Cheers

[Alex Brainman]

On Feb 4, 5:33 pm, Russ Cox <r...@golang.org> wrote:

> Hector made it possible to call DLL functions, not just system calls.
> In fact it's almost certainly a mistake to call system calls directly
> on Windows.  Call the documented entry points in the win32 DLL
> and its cousins.
>

Sounds good.

> Package syscall can have a completely different interface on
> Windows if it needs to.  Then, as Ian said, package os and net
> can present the same interface that they do here.  We tried when
> designing the interfaces to make it possible to implement them
> on Windows.
>
> Hector's runtime work is merged in but I believe the go-windows
> repository has some preliminary syscall/os/net stuff too.
>

If you mean http://code.google.com/r/hectorchu-go-windows/, then he
has new tree under src/pkg, like

sos pkg # tree windows/
windows/
|-- api
| |-- Makefile
| |-- api.go
| |-- api.h
| |-- defs.c
| |-- defs.go
| |-- defs.h
| |-- file.c
| |-- file.go
| |-- proc.c
| |-- proc.go
| `-- types.h
`-- os
|-- Makefile
|-- error.go
|-- file.go
|-- proc.go
`-- types.go

2 directories, 16 files

Here, I can see new / parallel version of "os" package implemented. I
guess, we can conditionally built this "version" of "os" package for
GOOS=mingw. But then we would have to keep 2 versions of "os" package
(unix and windows) in sync every time we make a change there.

Alternatively we can try implement all windows specific code right
inside "syscall" package. Mind you, windows might have very different
interfaces, and "unixy" and "windows" versions of syscall might be
very different not just in implementation, but in interface as well.

What would your approach be?

Alex

[Russ Cox]

Syscall and os (and net) already have Makefiles that
select files based on $GOARCH or $GOOS.
Windows should be just another $GOOS.
It's okay if the syscall package has a very different
function set on Windows than elsewhere
(it would provide the win32 apis) but it should
still be called syscall.

This might require making changes to some of the
os and net code but should not be too onerous.

Russ

[Alex Brainman]

On Feb 5, 11:29 am, Russ Cox <r...@golang.org> wrote:

> ...

> It's okay if the syscall package has a very different
> function set on Windows than elsewhere
> (it would provide the win32 apis) but it should
> still be called syscall.
>

Sounds like a plan.

> This might require making changes to some of the
> os and net code but should not be too onerous.
>

I do hope it's not too much. For example, the 'net' package does non-
blocking io. I can see it uses epoll for linux, kqueue for darwin and
freebsd and, i take it, will fail for nacl. First thing I can think of
on windows would be CreateIoCompletionPort/GetQueuedCompletionStatus.
Will it fitt existing "pollster" interface? If not, we have to change
"pollster", but in a way that doesn't affect other oses much. ...

I guess, the only way to see is to try <g>.

Thanks for your input, anyway.

Alex

[NoiseEHC]

I do not know about Unix too much and neither about the implementation
of asynchronous I/O completion handling in Go but I think that Go should
use the IOCompletionPort mechanism on Windows. (I do not know whether
Linux has something like that and whether Go uses that.) It can mean
that certain packages should have different implementations (mainly
which use the WinSock API) on Windows. If it turns out that there is no
I/O completion mechanism on Unix then maybe the Go scheduler should have
two implementations and you know that would suck...