Running Quarto in Windows Sandbox does not work

[cderv]

it is - in principle - possible to test different versions with the Windows Sandbox (& winget). I say "in principle" because it does not seem to work for quarto at the moment. quarto -V or quarto check don't show any output in the Sandbox. I am not sure whether this is a due to the Sandbox or due to Quarto. In general I think this is pretty powerful which is why I'd like to see full Sandbox support for winget one day (Feel free to upvote 😉).

Originally posted by @dpprdan in https://github.com/quarto-dev/quarto-cli/issues/1977#issuecomment-1234449649

[cderv]

It seems like this is an issue because VCRUNTIME140.dll is not found For example calling quarto --version will open this box in a CMD window:

This is an issue for the new quarto.exe bundle by the way, which is shipped since recently. Using quarto only will use the quarto.exe in priority over the quarto.cmd

Using quarto.cmd explicitly works fine

PS C:\Users\WDAGUtilityAccount> quarto.cmd --version
1.1.168
PS C:\Users\WDAGUtilityAccount> quarto.cmd check

[>] Checking Quarto installation......OK
      Version: 1.1.168
      Path: C:\Users\WDAGUtilityAccount\AppData\Local\Programs\Quarto\bin\
      CodePage: 1252

[>] Checking basic markdown render....OK

[>] Checking Python 3 installation....(None)

      Unable to locate an installed version of Python 3.
      Install Python 3 from https://www.python.org/downloads/

[>] Checking R installation...........(None)

      Unable to locate an installed version of R.
      Install R from https://cloud.r-project.org/

Is this a DLL that we can ship in the build ? Probably a specific use case as Sandbox is a very clean install, and most user may have VCRUNTIME140.dll available on their Windows.

[dpprdan]

Ha, I didn't get the VCRUNTIME140.dll error so far. It just stays silent. I do e.g.

.\Tools\SandboxTest.ps1 .\manifests\r\RStudio\quarto\1.1.165\

from my local win-pkgs repo.

[dpprdan]

But yeah, calling quarto.cmd works.

[dpprdan]

Ok, I can get it to work after running winget install Microsoft.VC++2015-2022Redist-x64

Details

--> Installing the Manifest 1.1.165 Found Quarto [RStudio.quarto] Version 1.1.165 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://github.com/quarto-dev/quarto-cli/releases/download/v1.1.165/quarto-1.1.165-win.msi ██████████████████████████████ 71.1 MB / 71.1 MB Successfully verified installer hash Starting package install... Successfully installed --> Refreshing environment variables --> Comparing ARP Entries DisplayName DisplayVersion Publisher ProductCode ----------- -------------- --------- ----------- Quarto 1.1.165 Rstudio, PBC {F72386FC-CBA0-4DE6-A92A-7D0CC6E34625} PS C:\Users\WDAGUtilityAccount\Desktop\winget-pkgs> winget install Microsoft.VC++2015-2022Redist-x64 Found Microsoft Visual C++ 2015-2022 Redistributable (x64) [Microsoft.VC++2015-2022Redist-x64] Version 14.32.31332.0 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://download.visualstudio.microsoft.com/download/pr/ed95ef9e-da02-4735-9064-bd1f7f69b6ed/CE6593A1520591E7DEA2B93FD03116E3FC3B3821A0525322B0A430FAA6B3C0B4/VC_redist.x64.exe ██████████████████████████████ 24.0 MB / 24.0 MB Successfully verified installer hash Starting package install... Successfully installed PS C:\Users\WDAGUtilityAccount\Desktop\winget-pkgs> quarto -V 1.1.165 PS C:\Users\WDAGUtilityAccount\Desktop\winget-pkgs> quarto check [>] Checking Quarto installation......OK Version: 1.1.165 Path: C:\Users\WDAGUtilityAccount\AppData\Local\Apps\Quarto\bin CodePage: unknown [>] Checking basic markdown render....OK [>] Checking Python 3 installation....(None) Unable to locate an installed version of Python 3. Install Python 3 from https://www.python.org/downloads/ [>] Checking R installation...........(None) Unable to locate an installed version of R. Install R from https://cloud.r-project.org/

Is this a DLL that we can ship in the build ? Probably a specific use case as Sandbox is a very clean install, and most user may have VCRUNTIME140.dll available on their Windows.

My hunch is that you ought to ship the DLL as well, since this might come up on new installations as well. I expect that this didn't come up yet because quarto is geared towards developers (in a broader sense) who usually have the runtime on their windows indeed. It's just not something you can take for granted.

[jjallaire]

It doesn't look like the Quarto executable actually depends on this DLL. Here is what I get:

$ ldd ~/Desktop/quarto-exe/quarto.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffced6d0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffcecda0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffceb010000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffcec990000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffced210000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffcec130000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffcec1d0000)
        bcrypt.dll => /c/WINDOWS/System32/bcrypt.dll (0x7ffceb5a0000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffceb4a0000)
        CRYPTBASE.DLL => /c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ffcea750000)

I then used the Rust option for building w/o the VC runtime library and it produced an identical binary.

I don't know where that dependency is cropping up from but I'm not sure we should be throwing that DLL in unless we really understand what's going on.

[jjallaire]

It appears to be the deno_dom plugin that has this dependency:

$ ldd deno_dom/plugin.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffced6d0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffcecda0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffceb010000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffcec990000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffced210000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffcec130000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffcec1d0000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffceb4a0000)
        VCRUNTIME140.dll => /c/WINDOWS/SYSTEM32/VCRUNTIME140.dll (0x7ffcd3db0000)
        CRYPTBASE.DLL => /c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ffcea750000)

Note that I do believe this is quite specific to the Windows Sandbox scenario as we've been shipping the deno_dom plugin for many months and this is the first report of it we've seen.

If we did want to bundle it in any case we would just need to put it in the deno_dom/ directory and it should get found by deno_com.

[dpprdan]

quite specific to the Windows Sandbox scenario

Should be easy™ to test with a clean Windows VM? (not Windows Dev VM or GHA runner, since they include the runtime if I am not mistaken).

[cderv]

Note that I do believe this is quite specific to the Windows Sandbox scenario as we've been shipping the deno_dom plugin for many months and this is the first report of it we've seen.

@jjallaire Is the deno_dom plugin also called when executing quarto through quarto.cmd ? I am not sure it comes from here as issue is only happening with quarto.exe

Could the DLL be part of the .exe itself by the way it is bundled and created ?

I don't know how ldd handles .exe on windows. Usually I am using native windows tools. On Windows there used to be depends.exe to inspect DLL : http://dependencywalker.com/ but I don't think it still work well, so I am using a rewrite of old depends.exe tool which is at https://github.com/lucasg/Dependencies (the former is not working well anymore on recent Windows)

I got this on the Sandbox

We see the VCRUNTIME140.dll is there and missing

It is found on my personal computer:

Based on that feeling, I searched about Rust and exe creation, which I believe is what you've done. My understand is that building an exe for Windows application will use the MSVC toolchain and dynamically links to vcruntime140.dll. It seems common in Rust: https://github.com/rust-lang/rust/issues/100874 That is why it is looked for I believe.

There seems to be a specific way to statically link this DLL using static_vcruntime crates. More on this here: https://users.rust-lang.org/t/static-vcruntime-distribute-windows-msvc-binaries-without-needing-to-deploy-vcruntime-dll/57599

[jjallaire]

Yes, I tried yesterday using the static_vcruntime yesterday and it appeared to create an identical executable. Let me try again now though and use the tool you recommended.

deno_dom is indeed called from within quarto.cmd but it has a failsafe to use a WASM version if the DLL can't be loaded. If you run quarto check --log-level debug you should see messages printed about whether deno_dom native was successfully loaded.

[jjallaire]

Okay, it looks like our GH action build of quarto.exe was including the dependency whereas my local build was not (probably due to some difference in the underlying VC toolchain on each machine).

I've adopted the static_vcruntime and confirmed that our build servers now correctly produce a version w/o the dependency on vcruntime140.dll. I'll backport this to v1.1 as well.

[cderv]

deno_dom is indeed called from within quarto.cmd but it has a failsafe to use a WASM version if the DLL can't be loaded. If you run quarto check --log-level debug you should see messages printed about whether deno_dom native was successfully loaded

I confirm on the Sandbox, deno-dom-native can't be loaded

> quarto.cmd check --log-level debug

[>] Checking Quarto installation......OK
      Version: 1.1.175
      Path: C:\Users\WDAGUtilityAccount\AppData\Local\Programs\Quarto\bin\
      CodePage: unknown

Error loading deno-dom-native: Could not open library: The specified module could not be found.

With 1.2.47 build, I confirm that this is now working on Windows Sandbox too (deno-dom-native still can't load but that is expected

> quarto.exe check --log-level debug

[>] Checking Quarto installation......OK
      Version: 1.2.47
      Path: C:\Users\WDAGUtilityAccount\AppData\Local\Programs\Quarto\bin
      CodePage: 1252

Error loading deno-dom-native: Could not open library: The specified module could not be found.

DLL is not seen as needed anymore by the dependencies tool


[jjallaire]

Excellent! This is also now available in the updated v1.1 (v1.1.179)