New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: avoid functions forbidden on Windows 10 UWP #21805

Open
MaxRis opened this Issue Sep 8, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@MaxRis

MaxRis commented Sep 8, 2017

What version of Go are you using (go version)?

go version go1.9 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\maxr\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\maxr\AppData\Local\Temp\go-build474350779=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config

What did you do?

  1. Created static library with func defined in Go and exported to be used in C++
    Command line: go build -buildmode=c-archive puregodll.go

  2. Linked puregodll.a static library generated on previous step into the shared MinGW dll library.
    Command line:

gcc -dumpspecs | sed -e 's/-lmingwex/-lwinstorecompat -lmingwex -lwinstorecompat -lole32 -lruntimeobject/' >./specfile
gcc -specs=./specfile -shared -o goDLL.dll goDLL.c -Wl,--dynamicbase -Wl,--whole-archive puregodll.a -Wl,--no-whole-archive -lWinMM -lntdll -lWS2_32 -lsetupapi

It produces goDLL.dll as result.

  1. Running script to adjust binary PE header of produced goDLL.dll to be compatible with Windows 10 UWP platform (it expects appcontainer bit set in PE header)

  2. Created Windows 10 UWP project with latest Visual Studio 2017 and P/Invoke goDLL.dll to call func initially defined in puregodll.go

  3. Run Windows Store Certification Kit for Supported APIs Test on generated Windows Store appx bundle and getting list of forbidden API calls, it seems, used in go-runtime:

API AddVectoredExceptionHandler in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API ExitProcess in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API FreeEnvironmentStringsW in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetConsoleMode in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetEnvironmentStringsW in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetProcessAffinityMask in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetStdHandle in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API LoadLibraryA in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API RtlAddFunctionTable in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API RtlCaptureContext in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API RtlVirtualUnwind in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API SetConsoleCtrlHandler in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API SetProcessPriorityBoost in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API VirtualAlloc in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API WriteConsoleW in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API timeBeginPeriod in winmm.dll is not supported for this application type. goDLL.dll calls this API.
API timeEndPeriod in winmm.dll is not supported for this application type. goDLL.dll calls this API.

What did you expect to see?

I expect to have a way for go runtime to not use API calls which are forbidden on Windows 10 UWP platform

@MaxRis MaxRis changed the title from Consuming MinGW DLL to Windows 10 UWP application and passing Certification Kit security checks to Consuming MinGW DLL with Go Runtime to Windows 10 UWP application and passing Certification Kit security checks Sep 8, 2017

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Sep 9, 2017

API AddVectoredExceptionHandler in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API ExitProcess in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API FreeEnvironmentStringsW in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetConsoleMode in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetEnvironmentStringsW in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetProcessAffinityMask in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API GetStdHandle in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API LoadLibraryA in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API RtlAddFunctionTable in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API RtlCaptureContext in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API RtlVirtualUnwind in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API SetConsoleCtrlHandler in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API SetProcessPriorityBoost in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API VirtualAlloc in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API WriteConsoleW in kernel32.dll is not supported for this application type. goDLL.dll calls this API.
API timeBeginPeriod in winmm.dll is not supported for this application type. goDLL.dll calls this API.
API timeEndPeriod in winmm.dll is not supported for this application type. goDLL.dll calls this API.

What are the replacement functions that provide this functionality on Windows 10 UWP?

I expect to have a way for go runtime to not use API calls which are forbidden on Windows 10 UWP platform

I don't think Go is supported on Windows 10 UWP platform. What is that you are building for Windows 10 UWP?

Alex

@MaxRis

This comment has been minimized.

MaxRis commented Sep 9, 2017

Hello @alexbrainman ,

What are the replacement functions that provide this functionality on Windows 10 UWP?

I believe, some functions doesn't have replacement, since UWP doesn't support console output and maybe some others limitations also.

Possibly good reading why Go should support UWP platform can be the announcement of UWP support for Qt(C++) framework with some explanations why it was done:
http://blog.qt.io/blog/2015/04/29/windows-10-support-in-qt/

Basically, UWP apps can be placed in Windows 10 Store and distributed to any kind of device with Windows 10 ( package should has multiple builds for x86, x64 and arm platforms, but only x64 can be supported too ).

I don't think Go is supported on Windows 10 UWP platform. What is that you are building for Windows 10 UWP?

On Windows it's possible to build static library with CGO using MSYS2/MinGW-w64 toolchain and link static library to MinGW DLL to be P/Invoked from UWP application.

Ideally, CGO should support msvc compiler toolchain to eliminate some difficulties to support UWP platform, but because MinGW already is supported and it's possible to bring MinGW DLL with exported C-functions to UWP, it might be not so much additional work to support UWP platform.

I'm trying to consume the go module to Windows 10 UWP platform, which is already used cross-platform for iOS and Android. The main benefit of UWP platform is that UWP port of react-native library already exists + Windows 10 Store publishing will be available for final application.

Thanks

@MaxRis

This comment has been minimized.

MaxRis commented Sep 10, 2017

What are the replacement functions that provide this functionality on Windows 10 UWP?

https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Sep 11, 2017

@MaxRis thank you for explaining. Unfortunately I have no plan to work on this. So, if you are interested, you have to do it yourself. I am happy to answer any questions you have along the way.

Alex

@MaxRis

This comment has been minimized.

MaxRis commented Sep 12, 2017

@alexbrainman thank you! I've started looking into this, so definitely will have some questions soon...

@MaxRis

This comment has been minimized.

MaxRis commented Sep 19, 2017

Hello @alexbrainman ,
It seems that support of UWP will require extending Go with new GOARCH.
I'm planning to start adding of "windows_amd64_uwp" GOARCH support.
Going to start looking into extending of src\cmd\dist bootstrap tool with new UWP arch.

@ianlancetaylor ianlancetaylor changed the title from Consuming MinGW DLL with Go Runtime to Windows 10 UWP application and passing Certification Kit security checks to runtime: avoid functions forbidden on Windows 10 UWP Sep 19, 2017

@ianlancetaylor ianlancetaylor added this to the Go1.10 milestone Sep 19, 2017

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 19, 2017

I assume you mean a new GOOS, not a new GOARCH.

If you intend your work to be added back to the main Go distribution, please discuss it on the golang-dev mailing list. If this really needs a new GOOS value--I don't really know--there are various requirements that need to be addressed. See https://golang.org/wiki/PortingPolicy.

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Sep 20, 2017

@MaxRis what Ian said. It is a big job.
You can also just copy Go source code, change it for yourself and see if it is useful to you. I would say you should do it anyway - you need something working and useful before it can be merged back into main Go repo.

Alex

PS: See related (but, probably, not relevant today) https://groups.google.com/d/topic/golang-dev/ZfmKRl5V6kw/discussion

@MaxRis

This comment has been minimized.

MaxRis commented Sep 20, 2017

Thank you @ianlancetaylor @alexbrainman !
Links should be very helpful!
My best guess, is that new GOARCH should suit better, because it's the same Windows OS, but some API calls can't be used. That's the only difference.
Maybe even new ARCH is too much for such small difference, but after looking a little bit at source, it seems should be more cleaner way to implement, than put some additional checks into source code for Windows platform.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 20, 2017

Just to be clear, it can not be a new GOARCH value. It could possibly be a new GOOS value.

But I would hope that it can be done without changing either GOARCH or GOOS.

@MaxRis

This comment has been minimized.

MaxRis commented Sep 20, 2017

Okay, @ianlancetaylor thanks!

@tfriedel6

This comment has been minimized.

tfriedel6 commented Nov 1, 2017

Just wanted to say that I am also interested in building UWP apps in Go. @MaxRis have you been able to get something running yes?

@MaxRis

This comment has been minimized.

MaxRis commented Nov 1, 2017

@tfriedel6 , not yet, but still planning to work on this. Sample project might be used as starting point to bring dll built with MinGW to UWP platform. As suggested above, some discussion should be started.

@gedw99

This comment has been minimized.

gedw99 commented May 10, 2018

Can anyone tell me the status of this ?

About a week ago Microsoft finally stabilised their winrt c/c++ runtime so that you don't need to use their weird cx API.
Chrome uses the c / c++ winrt runtime for example.

So does this mean a new golang GIOS is not needed and I can use golang on Windows 10 and call the winrt runtime now ?

@gedw99

This comment has been minimized.

gedw99 commented May 10, 2018

@rsc could you comment on this please ? It's really important that golang is not locked out of Windows 10 desktops for me. Especially the new appx and windows store

@gedw99 gedw99 referenced this issue May 10, 2018

Closed

windows packaging #1

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jul 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment