UWP support

[FreakTheMighty]

I was able to run some of your example then switched the platform to UWP and I'm seeing some errors. First when I hit play I get this:

System.Exception: generate binding code before run
  at QuickJS.ScriptRuntime.Initialize (QuickJS.Utils.IFileSystem fileSystem, QuickJS.Utils.IFileResolver resolver, QuickJS.IScriptRuntimeListener listener, QuickJS.IScriptLogger logger, QuickJS.IO.IByteBufferAllocator byteBufferAllocator) [0x0007a] in C:\Users\jvand\Documents\Code\unity-jsb\Assets\jsb\Source\ScriptRuntime.cs:138 
  at jsb.Sample.Awake () [0x000ec] in C:\Users\jvand\Documents\Code\unity-jsb\Assets\Examples\Source\Sample.cs:64 
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
QuickJS.Extra.MiniConsole:LogException(Exception) (at Assets/jsb/Extra/MiniConsole/MiniConsole.cs:135)
QuickJS.Extra.MiniConsole:LogException(Exception, Object) (at Assets/jsb/Extra/MiniConsole/MiniConsole.cs:196)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

I had previously generated the bindings, but perhaps it is only partially successful. I get this error:

JetBrains.Rider.Unity.Editor.Plugin.Full.Repacked, Version=2020.1.0.182, Culture=neutral, PublicKeyToken=null  System.ArgumentException: The specified path is not of a legal form (empty).
  at System.IO.Path.InsecureGetFullPath (System.String path) [0x00025] in <fb001e01371b4adca20013e0ac763896>:0 
  at System.IO.Path.GetFullPathInternal (System.String path) [0x00000] in <fb001e01371b4adca20013e0ac763896>:0 
  at System.IO.FileInfo.Init (System.String fileName, System.Boolean checkHost) [0x00007] in <fb001e01371b4adca20013e0ac763896>:0 
  at System.IO.FileInfo..ctor (System.String fileName) [0x00014] in <fb001e01371b4adca20013e0ac763896>:0 
  at (wrapper remoting-invoke-with-check) System.IO.FileInfo..ctor(string)
  at QuickJS.Editor.BindingManager.IsAssemblyBlocked (System.Reflection.Assembly assembly) [0x00002] in C:\Users\jvand\Documents\Code\unity-jsb\Assets\jsb\Source\Unity\Editor\BindingManager.cs:1381 
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
QuickJS.Extra.MiniConsole:LogError(String) (at Assets/jsb/Extra/MiniConsole/MiniConsole.cs:121)
QuickJS.Extra.MiniConsole:LogErrorFormat(String, Object[]) (at Assets/jsb/Extra/MiniConsole/MiniConsole.cs:181)
QuickJS.Extra.MiniConsole:LogFormat(LogType, Object, String, Object[]) (at Assets/jsb/Extra/MiniConsole/MiniConsole.cs:210)
UnityEngine.Debug:LogErrorFormat(String, Object[])
QuickJS.Editor.BindingManager:IsAssemblyBlocked(Assembly) (at Assets/jsb/Source/Unity/Editor/BindingManager.cs:1393)
QuickJS.Editor.BindingManager:Collect() (at Assets/jsb/Source/Unity/Editor/BindingManager.cs:1313)
QuickJS.Editor.UnityHelper:GenerateBindings() (at Assets/jsb/Source/Unity/Editor/UnityHelper.cs:46)

And this success message:

generated 50 type(s), 11 delegate(s), 0 deletion(s) in 1.22 seconds.

[ialex32x]

It's a bug of codegen process, I have commited a fix. I'm not familiar with WSA, not sure the result code is valid for the target platform (WSA project build).

[ialex32x]

Sorry, the quickjs.dll is still missing, I haven't compiled it for WSA. I'll check it out how to build quickjs.dll for WSA this weekend.

[FreakTheMighty]

Awesome, I'll check out the bugfix soon and will look forward to the WSA compile.

[FreakTheMighty]

@ialex32x just confirmed your patch fixed the code gen.

[FreakTheMighty]

I forgot to mention that I'm targeting ARM/ARM64. Also, I'd be curious to learn the build process. I see the build folder, but couldn't quite make out what the process is.

[ialex32x]

The folder jsb_build is the source and the makefiles of quickjs and other third-party libs, I use CMake to generate makefiles for target platform. For quickjs, it's \jsb_build\quickjs\CMakeLists.txt, and make_jsb_*.* for platforms.

I've tried to build quickjs targeting UWP platform, but it seems some problems need to be resolved, because quickjs is written primary with linux/gnu toolchain, not for windows. And cross-compile is not available for UWP (I can't find the right solution). So the quickjs source must be modifed to pass the compilation with Visual Studio. I will continue to have a try.

Alternatively, You could try other solution such as Tecent/xlua (if you use Lua), it's more mature for production.

[FreakTheMighty]

Thanks @ialex32x I am testing with xlua. It seems there may be experimental support for UWP arm64. I'm sure there will be trade offs for both libraries, but the use of JS is certainly something I'm pretty interested in.

I'm curious to try building this to see where we are. A few things I'm a bit confused about. I noticed you have these utility scripts. The script for windows is a shell script. Is it possible to build the windows library on a *nix system or is there someway to run that on Windows?

The other thing I'm unclear about is what makes building for windows different from building for windows uwp?

[ialex32x]

Yes, It's ok to build windows dll by mingw64 on linux. I choose this way to build quickjs make_jsb_win.sh. Requirements:

• Linux or WSL on windows
• CMake
• mingw-w64

The primary difference between windows build and uwp build is the libraries linked (for security requirements of windows store apps sandboxing), and the PE header of the result dll file is also different.

I found mingw-windows10-uwp, maybe it's a solution. Or maybe there's someway to use Visual Studio with clang/mingw.

[FreakTheMighty]

🤔 I have a windows machine so I think what I'll try is something like cmake -G "Visual Studio ..." and see if I can't build from there.

[FreakTheMighty]

Well, I gave this a quick try without much success. I'm just not familiar enough with the process to know where to go. If you ever do make progress, or have other updates/tips on compiling for UWP ARM, let me know.

[ialex32x]

Ok, I will update this issue if any progress made. I have tried:

• linux mingw64 cross compile, failed (no direct support for UWP)
• Visual Studio with clang, failed (not supoported by microsoft yet)

So, the only way at present is to modify quickjs source code manually, make it compatible with Visual Studio default compiler.

[lorenalexm]

Ok, I will update this issue if any progress made. I have tried:

• linux mingw64 cross compile, failed (no direct support for UWP)
• Visual Studio with clang, failed (not supoported by microsoft yet)

So, the only way at present is to modify quickjs source code manually, make it compatible with Visual Studio default compiler.

It seems some work was put in by someone already in getting QuickJS to compile with Visual Studio. Could their work (https://github.com/c-smile/quickjspp) be something to remedy this?

[ialex32x]

Yes, Thanks. I'll try soon.

[ialex32x]

I've modified quickjs source to eliminate all compilation errors and built dlls for wsa (x86/x64/ARM/ARM64).
just checkout the prebuilt libraries

but haven't tested on the target platform.

[FreakTheMighty]

I’m gonna try to find time to test this soon.

[FreakTheMighty]

I’m having a bit of trouble finding the arm64 wsa binaries. Apologies if I’m missing something obvious, where should I be looking?

[ialex32x]

here it is, https://github.com/ialex32x/unity-jsb/suites/2937737342/artifacts/65998319 WSA/ARM64/quickjs.dll, but not sure whether it's correct or not since I haven't tested it.

[FreakTheMighty]

Gotcha, thanks. Hopefully I can confirm for you wherever or not it works.

[FreakTheMighty]

🤔 for some reason when I build I get various reference errors like:

Assets\Generated\WSA_QuickJSBindings.cs(369,67): error CS0234: The type or namespace name 'GraphicRebuildTracker' does not exist in the namespace 'UnityEngine.UI' (are you missing an assembly reference?)

As I near as I can tell there are no assembly definitions in this project.

[FreakTheMighty]

I commented out all the generated code that was causing issues and was able to build. Unfortunately I get an exception at runtime. Here's the exception I get.

[ialex32x]

Thanks a lot. I'll try to fix it this weekend.

[ialex32x]

Hi @FreakTheMighty, it's because the quickjs api functions were not exported in quickjs.dll built for wsa. I've fixed it. Just check here. BTW, the reflectbind mode is not included in the wsa build at present, I will fix it later.

[FreakTheMighty]

I've got a new traceback to share.

Also, I do still get errors from the generated code. Here are the two variations I see

Assets\Generated\WSA\UnityEngine_UI_GraphicRebuildTracker.cs(26,76): error CS0234: The type or namespace name 'GraphicRebuildTracker' does not exist in the namespace 'UnityEngine.UI' (are you missing an assembly reference?)

And

Assets\Generated\WSA\UnityEngine_ParticleSystemRenderer.cs(1069,32): error CS1061: 'ParticleSystemRenderer' does not contain a definition for 'supportsMeshInstancing' and no accessible extension method 'supportsMeshInstancing' accepting a first argument of type 'ParticleSystemRenderer' could be found (are you missing a using directive or an assembly reference?)

[ialex32x]

This kind of error is caused by the differences between editor runtime and player runtime of Unity's DLL stuff. You need to customize it in the CustomBinding process.

looks like this

bindingManager.AddExportedType(typeof(System.IO.File)).SystemRuntime()
                .SetMemberBlocked("GetAccessControl")
                .SetMemberBlocked("SetAccessControl")
                .OnFilter<MethodInfo>(info => info.GetParameters().Length == 4); // not available in .net standard 2.0

[FreakTheMighty]

@ialex32x you're saying that I can blacklist methods related to GraphicRebuildTracker and ParticleSystemRenderer that are causing issues with the generated code, correct? That won't resolve the traceback during runtime, correct?

[FreakTheMighty]

Upon closer reading of the screenshot with the exception it seems to be saying that this function needs to have a MonoPInvokeCallback attribute. I'm not clear why this would only be the case for UWP. Also, I haven't made sense of what is expected of that attribute.

I thought something like this might work, but it _js_worker_ctor is an unresolved symbol.

        [MonoPInvokeCallback(typeof(JSWorker._js_worker_ctor))]

https://github.com/ialex32x/unity-jsb/blob/4110ccc7dc569c8f03bf77ebec07b2c67e42ada5/Assets/jsb/Source/JSWorker.cs#L334

[ialex32x]

Sorry for my delayed replay. Yes, CustomBinding can only eliminate the generated code errors (due to the conditional compilation of the exported types).

the error of _js_worker_ctor is because of these missing attributes: [MonoPInvokeCallback(typeof(JSCFunction))] and [MonoPInvokeCallback(typeof(JSCFunctionMagic))] It's occasionally neglected. I'll submit the change.

[FreakTheMighty]

I've gotten further. I can build and run a simple script, but for some reason while running the SampleScene with example_monobehaviour I get this exception:

System.EntryPointNotFoundException: Unable to find an entry point named 'JS_GetActiveFunction' in 'quickjs'.

Perhaps we're just missing another JS_EXPORT JSValueConst JS_GetActiveFunction

[ialex32x]

👍 Yes, I second it. I fixed it in the last commit.

[FreakTheMighty]

👏 that did it! Apologies for the delay in getting back to it.

I had some difficulty getting the examples to work, but I was able to run a simple script that created a gameobject and cube. BTW, the typescript integration is incredibly cool. I love that it was able to tell me when I made a mistake. Webpack yelled at me when I tried to create a "Box" instead of a "Cube".