Comment 1:

After launching godoc from desktop, to places are not working on home page.
1. Search box doesn't work.
   Message: Search index disabled: no results available
2. "Run" button doesn't work, with following message in cmd.exe shell
2012/03/06 07:23:12 GetFileAttributesEx C:\goweekly\compile: The system cannot find the
file specified.

Comment 2 by aroman@google.com:

+ Initial install was smooth.
+ Godoc server shortcut from desktop works perfectly.
+ Adding GOPATH var to user environment works great.  Can run "go build" from anywhere.
+ Trivial hello world runs.
- Retrieving additional packages via "go get" fails due to dependency on hg.  Is this
still expected?
C:\gocode\src>go get code.google.com/p/gorilla/mux
# cd .; hg clone -U https://code.google.com/p/gorilla
C:\gocode\src\code.google.com\p\gorilla
package code.google.com/p/gorilla/mux: exec: "hg": executable file not found in %PATH%

Comment 3:

go get command uses appropriate cvs executable to fetch source files, so it expects to
find correspondent command (mecrurial hg.exe in your case) in the PATH. I do not think
Go distro will come with all different cvs commands. You would have to provide your own:
http://mercurial.selenic.com/downloads/.
Alex

Comment 4:

Windows 8 Consumer Preview Build 8250
You must override the default Windows virus protections in order to run the installer --
presumably because the installer is not signed.
After manually setting GOROOT and GOBIN, I'm able to run go build, etc.
Clicking on GoDocServer starts a web browser at localhost:6000, but only shows the 
"Internet Explorer Cannot Display the Web Page" error page
As previously reported, "go get" assumes a repo client in the path

Comment 5 by allard.guy.m:

Win 7, Home Premium, 64 bit, running in a VBox VM, host OS is Ubuntu 11.10 AMD64
1) Install is very clean
2) Shortcut to godoc server moans about firewall stuff, I say 'let it go'.  The 'run'
for the hello world program does not work.  I get a 'Error communicating with remote
server.' on the page and in the DOS box I see:
2012/03/06 20:48:05 GetFileAttributesEx c:\go\compile: The system cannot find th
e file specified.
Close browser, and DOS box hangs.
3) Write hello.go, and 'go build'.  I get an executable named 'hello'.  I had to rename
it to 'hello.exe' for it to run.
4) Uninstall works: C:\go is gone, and the shortcut is gone.
5) Second install looks clean.
6) Set 'GOPATH' and put the hello.go program in %GOPATH%\src\hello.  Then 'go install
hello' works.  This time I do get 'hello.exe' in %GOPATH%\bin.
7) Same no 'hg' observation as described above.  Ditto 'git'.  I tried to alleviate this
by sticking c:\cygwin\bin in %path%.  Same result for 'hg'.  'git' tries but eventually
dies with:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Cloning into C:\Users\gmallard\Documents\gowintest\src\github.com\gmallard\stomp
ngo...
    137 [main] git-remote-https 3872 child_info_fork::abort: data segment start:
 parent(0x3C5000) != child(0x5E5000)
error: cannot fork() for fetch-pack: Resource temporarily unavailable
8) Second uninstall is also clean
9) Third install is clean
General comments:
I can probably obtain a native 'hg' install ..... Tortoise maybe.
'git' .... not sure.  Maybe Msysgit.  I have never used it.
I am an habitual Cygwin user for *Nix functionality on Win.  I do not mind flip/flopping
between DOS and Cygwin command lines, but that is not going to work very well (if at
all) in this case.

Comment 6:

- Default install path is c:\Go. Should probably be %ProgramFiles%\Go (which expands to
C:\Program Files\Go on a default english language install of Windows)
- 64-bit installer is not aware that it is a 64-bit installer. When I manually set the
install path to C:\Program Files\Go, it installed to C:\Program Files (x86)\Go (the
32-bit bin path) instead. Windows does this automatically to installers that do not
identify themselves as 64-bit aware.
- GoDocServer shortcut is added to the desktop without asking (that I recall). Installer
should at least ask.
- GoDocServer shortcut has insufficient quoting. When installed to a location with
spaces in the path, clicking on the icon produces "Windows cannot find 'Files'. Make
sure you typed the name correctly, and then try again." Removing the /d option to start
and moving the path to the "Start in:" field of the shortcut appears to work.
- As others have noted, GOROOT is not set by the installer, and go is not added to
%PATH%. After setting these manually, using go is smooth.
This is on Windows 7 Ultimate x64

Comment 7:

Thanks for testing. Great feedback! I'm looking into the godoc, and other, problems now. 
There's a todo to add an option to allow opting out of the desktop shortcut icon, sorry
it's not already in the installer. 
-joe

Status changed to Started.

Comment 8:

Windows 8 Consumer Preview, MacBook Pro via Boot Camp:
After setting environment variables via standard system dialogs, clicking on the godoc
icon works.

Comment 9:

Windows 7 Enterprise, 64-Bit:
Installation path is not honored. Installation goes to C:\Go regardless 
of the selected installation path.
One trivia: The desktop Gopher icon for godoc has a white background (normally
the backgrounds are transparent.)

Comment 10 by hotei1352:

Win 7 / 64 install on Intel i5 notebook was no problem.  hello build was no problem. 
Hit a temporary snag while building a project that required a package I had written but
then I remembered how to set environment variables and got past that.  Windows
installation instructions (currently entirely missing) should definitely mention how to
set ENV (temporarily or permanently) because that varies a bit depending on which
version of m$win you're using.
Was surprised that speed of sample project build was still sub-second on this midrange
notebook.   Bravo!

Comment 11:

Windows 8 Preview amd64.
Binary distribution worked fine.  I turn off the "smartscreen filter" and other stuff MS
tries to enable by default, so I can't comment on potential issues there. Part of me
hopes developers will have the sense to have these turned off already, but some may not
due to large company policies or are just starting to program...
Works great to compile from source with tdm-gcc 64 and hg.  Windows 8 no longer
advertises cmd.exe in favor of Powershell.  If questions arise, make sure people are in
cmd.exe (if in Powershell, need to run: "start cmd").
Some text directly in the installer itself about how godoc works (http server, requires
a firewall exception) might be useful.  May want to add an option in the installer at
some point to add exception to windows firewall for godoc server. Exceptions in firewall
can be either port based or application based.
I greatly appreciate all the effort that has gone into making Go an awesome
cross-platform tool.

Comment 12:

Please include a supported version of GDB for debugging.  Versions of GDB >= 7.3 have a
bug that can cause a crash while debugging Go:
http://sourceware.org/bugzilla/show_bug.cgi?id=13791
It has proven difficult to find a pre-compiled version of GDB 7.2 for Windows X64 and it
would be helpful if a version was included in the binary.
A thread on GoLang-Nuts has been discussing this issue:
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/K1PbxjMNieE

Comment 13:

Some unzip programs complain while unzipping the binary release:
!   C:\Users\aram\Downloads\go.weekly.2012-03-13.windows-386.zip: CRC failed in
go\src\pkg\image\png\testdata\invalid-crc32.png. The file is corrupt
!   C:\Users\aram\Downloads\go.weekly.2012-03-13.windows-386.zip: CRC failed in
go\src\pkg\image\png\testdata\invalid-noend.png. The file is corrupt
Obviously the invalid CRC is by design, but it makes WinRAR complain.

Comment 14:

aram.sci,
I just opened go.weekly.2012-03-13.windows-386.zip with WinRAR-4.11
(http://www.rarlab.com/) and pressed TEST button. It checked the file and said OK and
didn't complain about anything. How can I reproduce the results you are seeing? Thank
you.
Alex

Comment 15:

Excuse the noise, the SHA-1 was different than the one posted, it seems the file was
corrupted in the download process.
Apologies for wasting your time.

Comment 16:

Windows 7 Consumer Preview
2012-03-13 zip installed, no issues

Comment 17 by robert.hencke:

If a previous version of Go was installed at C:\Go, the installer succeeds, but the
installation may not behave correctly.  In my case, any program that imported "fmt"
failed to build with the error "typechecking loop" due to (I'm assuming) stale source
files that caused circular package dependencies.  Removing the entire C:\Go directory
and re-installing fixed the issue.

Comment 18 by strebkov:

Windows 7 Professional SP1 64-bit
Installation worked (installing to default directory C:\Go). C:\Go\bin was corretly
added to the end of the PATH environment variable.
But GOROOT and GOBIN environment variables was not set.

Comment 19 by briantreich:

Win 7 Pro SP1 x64 weekly 03-13 binary
os.Chdir( "C:" ) returns "C:\Windows\System32" when called from a different drive letter
The same code does not change the cwd at all when the program is already on the C: drive.
See http://pastebin.com/Ax2ANrtw for the exact program I used to test this or use the
attached file.

Attachments:

1. chdirTest.go (333 bytes)

Comment 20:

This is consistent with the traditional DOS behaviour: "cd c:" switches you to the
current directory of drive C:. You have to specify a path to actually switch
directories, like C:\. So it is the expected behaviour to me.

Comment 21:

Status changed to WaitingForReply.

Comment 22 by capitaineglacon:

Windows 7 Ultimate 64-bit french version. Installed with msi installer in "C:\go".
weekly.2012-03-22.
"go build" the hello world example on the golang homepage.
Error: "c:\go\src\pkg\fmt\print.go:10:2: import loop"
Code: http://pastebin.com/gWUAJunt

Attachments:

1. go.jpg (76406 bytes)

Comment 23:

Did you install Go on top of an existing installation?

Comment 24 by capitaineglacon:

I uninstall Go when I want to re-install it.

Comment 25:

Labels changed: added priority-later.

Comment 26 by capitaineglacon:

When I unistall Go with the dedicated tool, the Go directory "C:\go" is not deleted. I
had deleted it and re-installed with the msi installer. The bug is fixed.

Comment 27 by capitaineglacon:

When I uninstall Go with the dedicated tool, the Go directory "C:\go" is not deleted. I
have deleted it and re-installed with the msi installer. The bug is fixed.
(Sorry for double comment).

Comment 28:

Didn't the amd64.msi installer reject 32-bit-only Windows?
details here:
http://groups.google.com/group/golang-nuts/browse_thread/thread/4d6fcf12e5afa8aa

Comment 29:

Closing these issues now that Go 1 is out. Please create a new issue for any problem
with the binary distributions.

Status changed to Done.