Skip to content
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

Win10 ARM version ? #174

Closed
pplanch opened this issue Aug 9, 2021 · 24 comments · Fixed by #196
Closed

Win10 ARM version ? #174

pplanch opened this issue Aug 9, 2021 · 24 comments · Fixed by #196
Labels
enhancement New feature or request

Comments

@pplanch
Copy link

pplanch commented Aug 9, 2021

Is your feature request related to a problem? Please describe.
I am developing Excel VBA projects for use on both Windows and Mac machines. Since the introduction of the M1 Macs, the only possibility to run Windows on a VM on my Mac is through the ARM version (from the Insider program). It appears the RibbonX installer I downloaded requires an x64 architecture ...

Describe the solution you'd like
Is it possible to get a version out that supports Win10 ARM as well ?

Describe alternatives you've considered
I am new to RibbonX and don't know if any alternatives exist for ARM-based Office 365 on Win10. If there are, I'd be happy to explore those ...

Additional context
I'm happy to contribute in translation support (I am native Dutch speaker, and fairly fluent in German and French), please let me know if this is of interest to you.

@pplanch pplanch added the enhancement New feature or request label Aug 9, 2021
@fernandreu
Copy link
Owner

fernandreu commented Aug 9, 2021

Hi @pplanch, support for Win10 ARM64 is something I could definitely add, although there might be a few issues for that to work:

  1. Tool support: dotnet should support ARM64 without issues. It seems getting a Visual Studio installed might be a bit more problematic but it isn't really needed if you can build it via dotnet. The installer tool I use, Inno Setup, has also added support for Windows 10 ARM64 recently
  2. Library support: after a quick search, I found out that WPF ARM64 support is coming with .NET 6 (to be released in November this year): WPF ARM64 Support now available in .NET 6 Preview 1  dotnet/wpf#4117. I'm not so sure about the other libraries that this repo uses though. There might be some effort needed in rebuilding some of these libraries to target ARM64 as well. In the worst case, there might be some issue preventing you from doing that
  3. Build system support: this is the part I'm less sure about. I use Azure Pipelines to do the automated builds, but I haven't seen any mention of a Microsoft-hosted Windows ARM agent after a quick search. This would make sense if only Insider builds are available so far. I suspect they will be added to Azure Pipelines eventually

So, long story short: there isn't much I can do right now (especially given I don't own a newer Mac myself), but I am reasonably confident I could add Win10 ARM64 support in the future.

In the meantime, perhaps there is something you could try on your Windows VM:

  • Download and install the latest .NET 6 SDK preview from here
  • Clone this repo (or download a ZIP and extract it somewhere)
  • Go to the file src\OfficeRibbonXEditor\OfficeRibbonXEditor.csproj and, at around line 14, change <TargetFrameworks>net461;net5.0-windows</TargetFrameworks> to <TargetFrameworks>net6.0-windows</TargetFrameworks>,
  • Run the following in a command prompt: dotnet build path\to\src\OfficeRibbonXEditor\OfficeRibbonXEditor.csproj

If you are lucky, the command will run without flagging any errors (just warnings), and an executable will be created in src\OfficeRibbonXEditor\bin\Debug\net6.0-windows for you to try. More realistically, this will throw some errors that may or may not be easy to resolve. If you show me those errors here, I will try to help.

Regarding the translation support, this is always welcome! There is a German translation already, but nothing yet in terms of Dutch or French. Let me know if you need more guidelines than what I wrote in the readme or what was commented in previous issues (#139 #154 #163).

@pplanch
Copy link
Author

pplanch commented Aug 10, 2021 via email

@fernandreu
Copy link
Owner

Yeah, you can reply either via email or by going into the issue page on GitHub. Just be aware that, in both cases, anybody can see the full content. Just saying this in case you are not comfortable sharing details such as phone numbers in your email signature, in which case you can edit your last message from the GitHub page. The other thing to keep in mind is that I won't be able to see any attachment you might send via email (incl. pictures); that only works on the website.

"Clone" is one of the operations you can do when working with Git, which is the Version Control System for most software projects nowadays. Essentially, it's like downloading the repo in a local folder. But, to keep things simple, you can instead just go to the front page of this repo, click on "Code" -> "Download ZIP" and extract that somewhere, giving you the same result as git clone:

image

@rfn6
Copy link

rfn6 commented Nov 20, 2021

@pplanch Did you get this to work?

@pplanch
Copy link
Author

pplanch commented Nov 20, 2021

Fernando, thanks for the follow-up. Since our last conversation, Parallels issued an M1 desktop VM version that runs Win11 insider preview build (I believe Microsoft pulls support for Win10 on ARM themselves).

As for the RibbonS, I’ve been using the “old” Office Ribbon Editor app (version 4.4.1 I believe) on my Win11 VM and have been studying up a little bit on the basics of XML that I needed to get my own ribbon to work. It works, and it serves my purpose well enough for now. I’ll be interested to learn as soon as an ARM copy of the ribbonX comes out though …

@fernandreu
Copy link
Owner

Hi both, now that .NET 6 are is officially released, I am going to attempt to make an ARM64 version of the tool to work.

First of all, let me be clear: after starting to investigate this, I don't think the current builds will work on ARM64, so I wouldn't spend too much time testing them.

The reason is relatively simple. The tool's code editor is based on Scintilla, which is a native Windows component. This has in turn being wrapped by the C# libraries ScintillaNET / ScintillaNET.WPF. While the Scintilla project has added support for ARM64 recently, none of the C# libraries have been adapted to support this. For example, you can see there are x86 / x64 folders in here but no arm64 folder. So, assuming Windows on ARM64 doesn't provide some sort of native x86 / x64 dll emulation somehow, it won't work. If you still want to give it a go, you can try the .NET Binaries in here. You will need the .NET 6 runtime installed.

Therefore, my roadmap to add ARM64 support is:

  1. Build a newer version of Scintilla which supports ARM64
  2. Include the resulting x86, x64 and arm64 dlls in the ScintillaNET project, and update it to support ARM64
  3. Update the ScintillaNET.WPF project to use that new version of ScintillaNET and to add ARM64 support
  4. Update this tool to use that new version of ScintillaNET.WPF and to add ARM64 support

There might be some hiccups here and there. For example, newer versions of Scintilla might have introduced incompatibilities with the C# wrappers, which I'll have to investigate and fix. Or I might be unable to build Scintilla for ARM64 on my machine, which in theory it shouldn't be the case. But, overall, I am relatively confident I should eventually be able to produce an ARM64 build. That's because Notepad++, which also uses the same Scintilla component, now also supports ARM64.

@fernandreu
Copy link
Owner

Actually, this might have taken less time than I expected. Can you try one of those?
https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=1135&view=artifacts&pathAsName=false&type=publishedArtifacts

If it went well, any of those should work on ARM64:

  • .NET Binaries
  • .NET Installer
  • Self-Contained .NET (arm64) Binaries
  • Self-Contained .NET (arm64) Installer

Worth mentioning that, even if the app launches fine, I might have introduced some breaking changes when I updated the version of Scintilla (from 4.1.2 to 4.4.6) which might only manifest when attempting certain actions.

@pplanch
Copy link
Author

pplanch commented Nov 21, 2021

Fernando, I'll have a look tomorrow. Today I'm in the process of setting up my new equipment (I replaced my "old" M1 Macbook Air - which with its 16 GB of "RAM" had some performance issues running Win11 VM simultaneously with other stuff - with a new 16 M1 Macbook Pro on an M1Max processor - which on 64 GB of "RAM" should be able to run all 4 Win11 VM's in the 4 languages simultaneously and which will save me a lot of time on manual updating of the insider preview builds).

I'll keep you posted ... looking forward to your work :-)

@rfn6
Copy link

rfn6 commented Nov 21, 2021

Fernando – I just downloaded the new ARM installer you linked and RibbonX appears to load correctly. Will keep you posted if I notice any bugs or instability.

Thanks a lot!

@rfn6
Copy link

rfn6 commented Nov 21, 2021

@fernandreu The application crashes when you click on "CustomerUI14.xml" on the side bar, so you cannot edit the XML.

@fernandreu
Copy link
Owner

That's bad... that's when the Scintilla editor gets created, so it seems the ARM64 build of that is not working. Does it instantly crash without any error message? If so, does Event Viewer show any error messages instead?

An example of what could appear (from another program):
image
image

@rfn6
Copy link

rfn6 commented Nov 21, 2021

@fernandreu These are the errors I was getting

Error 1
Error 2

@rfn6
Copy link

rfn6 commented Nov 21, 2021

Application: OfficeRibbonXEditor.exe
CoreCLR Version: 6.0.21.52210
.NET Version: 6.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Windows.Markup.XamlParseException: The invocation of the constructor on type 'ScintillaNET.WPF.ScintillaWPF' that matches the specified binding constraints threw an exception.
---> System.ComponentModel.Win32Exception (0x80004005): Could not load the Scintilla module at the path 'C:\Users\User\AppData\Local\Temp\ScintillaNET\4.2.0\arm64\SciLexer.dll'.
---> System.ComponentModel.Win32Exception (193): %1 is not a valid Win32 application.
at ScintillaNET.Scintilla.get_CreateParams()
at System.Windows.Forms.Control..ctor(Boolean autoInstallSyncContext)
at System.Windows.Forms.Control..ctor()
at ScintillaNET.Scintilla..ctor()
at ScintillaNET.WPF.ScintillaWPF..ctor()
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions)
--- End of inner exception stack trace ---
at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri)
at System.Windows.Markup.XamlReader.RewrapException(Exception e, Uri baseUri)
at System.Windows.FrameworkTemplate.LoadTemplateXaml(XamlReader templateReader, XamlObjectWriter currentWriter)
at System.Windows.FrameworkTemplate.LoadOptimizedTemplateContent(DependencyObject container, IComponentConnector componentConnector, IStyleConnector styleConnector, List1 affectedChildren, UncommonField1 templatedNonFeChildrenField)
at System.Windows.FrameworkTemplate.LoadContent(DependencyObject container, List1 affectedChildren) at System.Windows.StyleHelper.ApplyTemplateContent(UncommonField1 dataField, DependencyObject container, FrameworkElementFactory templateRoot, Int32 lastChildIndex, HybridDictionary childIndexFromChildID, FrameworkTemplate frameworkTemplate)
at System.Windows.FrameworkTemplate.ApplyTemplateContent(UncommonField`1 templateDataField, FrameworkElement container)
at System.Windows.FrameworkElement.ApplyTemplate()
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Control.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint)
at System.Windows.Controls.ContentPresenter.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Grid.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Border.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Grid.MeasureCell(Int32 cell, Boolean forceInfinityV)
at System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV, Boolean& hasDesiredSizeUChanged)
at System.Windows.Controls.Grid.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Control.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Grid.MeasureCell(Int32 cell, Boolean forceInfinityV)
at System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV, Boolean& hasDesiredSizeUChanged)
at System.Windows.Controls.Grid.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.DockPanel.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint)
at System.Windows.Controls.ContentPresenter.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Decorator.MeasureOverride(Size constraint)
at System.Windows.Documents.AdornerDecorator.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Grid.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Border.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Window.MeasureOverrideHelper(Size constraint)
at System.Windows.Window.MeasureOverride(Size availableSize)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.ContextLayoutManager.UpdateLayout()
at System.Windows.UIElement.UpdateLayout()
at System.Windows.Interop.HwndSource.SetLayoutSize()
at System.Windows.Interop.HwndSource.set_RootVisualInternal(Visual value)
at System.Windows.Interop.HwndSource.set_RootVisual(Visual value)
at System.Windows.Window.SetRootVisual()
at System.Windows.Window.SetRootVisualAndUpdateSTC()
at System.Windows.Window.SetupInitialState(Double requestedTop, Double requestedLeft, Double requestedWidth, Double requestedHeight)
at System.Windows.Window.CreateSourceWindow(Boolean duringShow)
at System.Windows.Window.CreateSourceWindowDuringShow()
at System.Windows.Window.SafeCreateWindowDuringShow()
at System.Windows.Window.ShowHelper(Object booleanBox)
at System.Windows.Window.Show()
at System.Windows.Window.ShowDialog()
at OfficeRibbonXEditor.App.LaunchDialog(Window mainWindow, IContentDialogBase content, Boolean showDialog) in D:\a\1\s\src\OfficeRibbonXEditor\App.xaml.cs:line 174
at OfficeRibbonXEditor.App.OnUnhandledException(Object sender, DispatcherUnhandledExceptionEventArgs e) in D:\a\1\s\src\OfficeRibbonXEditor\App.xaml.cs:line 195
at System.Windows.Threading.Dispatcher.CatchException(Exception e)
at System.Windows.Threading.Dispatcher.CatchExceptionStatic(Object source, Exception e)
at System.Windows.Threading.ExceptionWrapper.CatchException(Object source, Exception e, Delegate catchHandler)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.Run()
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run()
at OfficeRibbonXEditor.App.Main()

@fernandreu
Copy link
Owner

It seems the tool is identifying the process architecture as arm64 as I would expect, and yet the corresponding Scintilla dll cannot be loaded. In other words, the dll isn't really targeting arm64, or the tool isn't really running in arm64, or there's some other error with the dll.

Is the tool running under x86/x64 emulation somehow?

Does the crash occur with both the framework-dependent versions of the tool (i.e. .NET Binaries / .NET Installer and the self-contained ones?

@rfn6
Copy link

rfn6 commented Nov 21, 2021

@fernandreu How do I install the .net binaries version?

@rfn6
Copy link

rfn6 commented Nov 21, 2021

FYI - "Self-Contained .NET (x64) Installer" works via emulation, so I will use that for now. Performance isn't as good because I'm running an emulation within a virtual machine (Parallels), but it works so all good lol.

@fernandreu
Copy link
Owner

Glad there is at least a way to make it work for now!

None of the Binaries versions need to be installed. They are just a .zip file that you can extract in any folder, and run the executable from there. The .NET Binaries one in particular needs the dotnet runtime installed beforehand though: https://dotnet.microsoft.com/download/dotnet/6.0/runtime

So, was Self-Contained .NET (arm64) Installer the one you tried initially and crashed, or was it something else?

I am hopeful the non-emulated arm64 tool only needs a few tweaks to work too. I have done some adjustments to show both the process and the OS architectures in the About dialog, in case it helps figuring out what's going on (but, based on the event log, I would expect both to be arm64 for the version which is crashing anyway):
image

The builds matching that screenshot are available here:
https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=1146&view=artifacts&pathAsName=false&type=publishedArtifacts

I did a bit of artifact renaming too, to refer to each variant more easily. The Framework Dependent variants are what was previously called just .NET Binaries / .NET Installer.

@rfn6
Copy link

rfn6 commented Nov 22, 2021

"Self-Contained - arm64 - Installer" still doesn't work unfortunately.

@pplanch
Copy link
Author

pplanch commented Nov 22, 2021

Fernando, here's my observations (for what they're worth ... I'm far from an expert on these matters) :

Framework Dependent installer didn't work. After installing and opening the app, I was prompted to install .net (with a download link to the installer) which I did, then whenever clicking on the RibbonX desktop shortcut NOTHING would happen. So I uninstalled RibbonX Editor again.

The Self-contained installer seems to work. I have RibbonX Editor open now. However, when opening one of my files that has CustomUI12 in it, and double-clicking on the Custom UI item in the RibbonX Editor, it crashes.

I'm running a Win11 Pro Insider Preview VM on an M1Max 16" Macbook Pro.

Let me know if this is helpful or if you need more details or logs.

For the time being, I'm going to revert back to the Office Ribbon Editor 4.4.1.

@fernandreu
Copy link
Owner

Hi @pplanch, the framework-dependent installer not even launching is something new. Did the .NET download link let you choose which architecture to install (arm64 / x64)? I wonder if it installed the wrong one, but probably not. Also, can you check the event logs to see if there is anything regarding that? Start menu, type event viewer, go to Windows Logs -> Application, then search for any errors with the source set to Application Error or .NET Runtime.

The self-contained issue seems to be the same issue as for rfn6, so no need to check the logs for that one.

There are a few things I can try to make this work, but it's going to be a bit of trial and error. In a few days I'll see if I can install Windows on a Raspberry Pi (also ARM64) and start doing the the trials myself.

@fernandreu
Copy link
Owner

fernandreu commented Nov 25, 2021

I got ARM64 installed on my RPi, and I think I've found the issue. The VC++ redistributable for ARM64 needs to be installed beforehand on the machine: https://aka.ms/vs/17/release/vc_redist.arm64.exe

I suspect the emulated x64 version worked because some other program installed the equivalent x64 redistributable, as it is a pretty common requirement. It's also a requirement on x64 Windows, but it's probably so common that it's unlikely you'd find the same issue there.

Hence, could you check the self-contained builds from here again after installing the redistributables from the link above? I think there might still be something wrong with the framework-dependent version, but now I should be able to fix it more easily.

I'll see if I can make it to be installed automatically when installing the tool. Otherwise I will just put a note in the releases page / readme.

The result:
image

@fernandreu
Copy link
Owner

It seems either ARM64 Windows insists on treating some executables as x64, or the framework-dependent build I did was truly just for x64. Technically you can still run that via dotnet OfficeRibbonXEditor.dll (the dll, not the .exe), but it seems simpler to create framework-dependent builds specific for each architecture.

Hence, all the arm64 versions in this build should hopefully work (again, installing the VC++ redistributable first):
https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=1150&view=artifacts&pathAsName=false&type=publishedArtifacts

For the framework-dependent versions, the .NET runtime you'll need is the desktop one for arm64, available here.

@rfn6
Copy link

rfn6 commented Nov 28, 2021

@fernandreu what is the latest version to download in order to test this? I saw you made a few changes today.

@fernandreu
Copy link
Owner

@rfn6 feel free to test it with any version which comes from #196 since my last post. Yesterday I only added a warning if a VC++ redistributable isn't detected which can launch your browser to download it automatically, but nothing in terms of the tool's functionality really. I'm also doing some unit test refactoring (again, not affecting the tool's functionality), but I will probably get all this merged soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants