Cannot open a file chooser dialog from a 386 binary on 64bit Windows

[piroor]

I'm trying to create an small application providing a file chooser, and I saw an unexpected error only on 386 binary running on Windows 10 64bit.
An amd64 binary built from the same source running on Windows 10 64bit works as expected.
Should this error be tracked on this project? Or, should I report this to other place?

Thanks,

Steps to reproduce

1. Prepare a golang development environment. I'm using go1.16.6 linux/amd64 on Ubuntu on WSL1 on Windows 10.

2. Create testcase.go under a directory, as:

   package main
   
   import (
   	"github.com/harry1453/go-common-file-dialog/cfd"
   	"github.com/harry1453/go-common-file-dialog/cfdutil"
   	"log"
   )
   
   func main() {
   	result, err := cfdutil.ShowOpenFileDialog(cfd.DialogConfig{
   		Title: "Title",
   		Role:  "TestCaseRole",
   		FileFilters: []cfd.FileFilter{
   			{
   				DisplayName: "File",
   				Pattern:     "*.*",
   			},
   		},
   		SelectedFileFilterIndex: 0,
   		FileName:                "file",
   		DefaultExtension:        ".txt",
   	})
   	log.Fatal(err)
   	log.Fatal(result)
   }
   

3. Start bash on Ubuntu on WSL1.

4. Change working directory to the directory testcase.go placed at.

5. Run gox -os="windows" . to build binaries.

6. Then two binaries golang-testcase_windows_amd64.exe and golang-testcase_windows_386.exe are built.

7. Start cmd.exe on Windows.

8. Run golang-testcase_windows_amd64.exe on the command prompt. A file chooser dialog appears, so close it.

9. Run golang-testcase_windows_386.exe on the command prompt.

Expected result

A file chooser dialog appears, same as golang-testcase_windows_amd64.exe.

Actual result

No dialog appears and an error:

C:\Users\piro>>C:\Users\piro\golang-testcase_windows_386.exe
Exception 0xc0000005 0x0 0x140d8b64 0x779cef90
PC=0x779cef90

syscall.Syscall(0x75d08a90, 0x2, 0x1222df0, 0x1, 0x11c06290, 0x0, 0x0, 0x0)
        /usr/local/go/src/runtime/syscall_windows.go:330 +0xbb
github.com/harry1453/go-common-file-dialog/cfd.(*iFileDialogVtbl).setFileTypes(0x75cc18b4, 0x1222df0, 0x11c04180, 0x1, 0x1, 0x1, 0x31d44c50)
        /home/piro/go/src/github.com/harry1453/go-common-file-dialog/cfd/vtblCommonFunc.go:51 +0x11e
github.com/harry1453/go-common-file-dialog/cfd.(*iFileOpenDialog).SetFileFilters(0x1222df0, 0x11c04180, 0x1, 0x1, 0x1222df0, 0x11c06201)
        /home/piro/go/src/github.com/harry1453/go-common-file-dialog/cfd/iFileOpenDialog.go:104 +0x41
github.com/harry1453/go-common-file-dialog/cfd.(*DialogConfig).apply(0x11c5deb8, 0x410754, 0x1222df0, 0x0, 0x0)
        /home/piro/go/src/github.com/harry1453/go-common-file-dialog/cfd/DialogConfig.go:99 +0xef
github.com/harry1453/go-common-file-dialog/cfd.NewOpenFileDialog(0x3e659e, 0x5, 0x3e7965, 0xc, 0x0, 0x0, 0x0, 0x0, 0x11c04180, 0x1, ...)
        /home/piro/go/src/github.com/harry1453/go-common-file-dialog/cfd/CommonFileDialog_windows.go:20 +0x76
github.com/harry1453/go-common-file-dialog/cfdutil.ShowOpenFileDialog(0x3e659e, 0x5, 0x3e7965, 0xc, 0x0, 0x0, 0x0, 0x0, 0x11c04180, 0x1, ...)
        /home/piro/go/src/github.com/harry1453/go-common-file-dialog/cfdutil/CFDUtil.go:9 +0x68
main.main()
        /home/piro/testcase.go:16 +0x8e
eax     0x140d8b64
ebx     0x0
ecx     0x1222de4
edx     0x140d8b66
edi     0x140d8b64
esi     0x0
ebp     0x10ff9d8
esp     0x10ff9d4
eip     0x779cef90
eflags  0x10202
cs      0x23
fs      0x53
gs      0x2b

C:\Users\piro>

Environment

• host OS: Windows 10 Pro 21H1 (64bit)
• guest OS: Ubuntu 18.04.5 LTS (on WSL1)
• go: 1.16.6 linux/amd64
• go-common-file-dialog revision: 5bfd608

Additional info

I've not tested this on 32bit Windows environment yet.

[harryjph]

I'm investigating this now, I've found where the crash occurs and will try to resolve this.

[snurbol]

On Windows 7 32-bit version same problem. Show exception and crush.

Compiled to Windows 386 on MacOS 10.13. And runing on Windows 7 32-bit version.

Environment

• go: 1.17.1 darwin/amd64
• build with: GOOS=windows GOARCH=386
• go-common-file-dialog: version 1.1

[harryjph]

@snurbol Thanks for the report. I can replicate this but I have no idea what is causing it. I don't know what would cause it to behave differently on a 32-bit platform. Worst of all, I have replicated my code in C++ and Rust and it works fine.

[piroor]

My Twitter follower said that the problem can be caused by differences of struct sizes or alignments between 386 and amd64. Is this information help your investigation?