Since we [released Node.js for Mobile Apps](http://www.janeasystems.com/blog/announcing-node-js-mobile-apps-true-node-js-runtime-android-ios/), the most requested feature has been support for Node.js native modules (also known as "C++ Addons"). This makes sense, since it is common for an npm module to either contain some native code itself or have a dependency on a module that does.

So we have been working hard to tackle this challenge. We are now excited to announce that support for native modules is available in the latest release of the React Native and Cordova plugins.

Being able to use these modules strengthens compatibility of Node.js for Mobile Apps with the npm module ecosystem, and opens a lot of possibilities for building mobile applications with Node.js.

### How to start using native modules with Node.js for Mobile Apps

With the latest release of [nodejs-mobile-react-native](https://www.npmjs.com/package/nodejs-mobile-react-native) and [nodejs-mobile-cordova](https://www.npmjs.com/package/nodejs-mobile-cordova), the plugins automatically detect the existence of native modules inside the \`nodejs-project\` folder in your app, and take care of building and packaging them as part of the application build process. It just works!

In the samples repo, you can find a [React Native sample app](https://github.com/janeasystems/nodejs-mobile-samples/tree/master/react-native/UseNativeModules) and a [Cordova sample app](https://github.com/janeasystems/nodejs-mobile-samples/tree/master/cordova/UseNativeModules) that include the [sqlite3](https://www.npmjs.com/package/sqlite3) and [sha3](https://www.npmjs.com/package/sha3) native modules, so you can try this feature right away.

### Node.js native modules and their challenges for mobile

[Node.js native modules](https://nodejs.org/api/addons.html) are Node.js packages that contain native code and instructions on how to build that native code using [node-gyp](https://github.com/nodejs/node-gyp). When installing a native module from npm, the default behavior is for the module to be built for the system on which npm is currently running. This makes sense when using Node.js on the server/desktop, where we can expect the required build tools to be available on the system, or for the module to be prebuilt and copied from a similar system. On mobile, however, this is either not practical or (on iOS) downright impossible; so we had to modify a few things to enable native modules to get cross-compiled and packaged with the application.

To that end, the plugins are using a [modified version of node-gyp](https://www.npmjs.com/package/nodejs-mobile-gyp) that is able to target the right OS and CPU architecture and include the Node.js headers from the Node.js for Mobile Apps release.

On iOS, we also need to ensure that the module binaries are packaged as a Framework signed with the application's signing identity and loaded from the application's /Frameworks path, which is required for loading dynamic libraries and for being accepted in the iOS App Store. Many thanks to [Patrick Chugh](https://twitter.com/patrickchugh), for all his help in validating iOS App Store submission with the [Shango App](https://github.com/neogeno/shango-lightning-wallet/blob/master/README.md).

On Android, we have to build a standalone toolchain before we can cross-compile native modules, and that needs to be done for each ABI supported by the application. We are able to support Universal APKs by packaging binaries for all the supported ABIs, and then choosing which binary to load at runtime.

Special care is also needed for modules the use [node-pre-gyp](https://www.npmjs.com/package/node-pre-gyp) to download a prebuilt binary, to ensure that they are actually built on the current machine and for the target OS and architecture.

All of that and more is handled automatically by the plugins, so developers don't even need to worry about whether their app uses native modules or not.

### Limitations and future work

Our goal was to ensure that as many existing native modules as possible work without modification on mobile. However, Node.js native modules are so flexible that it is not feasible to support every possible scenario. Modules that have non-standard build steps (e.g. depending on shell scripts rather than node-gyp, for building) may require further changes to work on mobile. Modules with platform-specific code or dependencies might need porting of that code to iOS or Android.

Given the large number of native modules out there, it would probably take our team a very long time to test and try to solve all the possible compatibility issues. So this is an area where we hope to get a lot of help from the community. To that end, we have created a [GitHub repository](https://github.com/janeasystems/nodejs-mobile-module-compat) where the community can discuss compatibility issues of existing modules with nodejs-mobile.

There are also other improvements to be made:

*   Adding support for building native modules for Android on Windows development machines (currently only macOS and Linux are supported).
*   Providing an easy way to use native modules in applications that are not using the \`nodejs-mobile-react-native\` or \`nodejs-mobile-cordova\` plugins.
*   Being able to use an installed NDK instead of building a standalone NDK toolchain for Android.

### A whole new world of possibilities

Having native modules opens a whole new world of possibilities for using Node.js for Mobile Apps. Our [community Gitter channel](https://gitter.im/nodejs-mobile/community) has been filled with questions and experiments on this topic. We can't wait to see what sort of novel and creative applications can be developed now that native modules are supported out of the box.

We invite you to try using Node.js with native modules in your mobile applications, and to get involved with the project. Provide feedback, report bugs, suggest improvements, contribute code. Go build amazing new apps and radically new frameworks with it!

To get started, visit the [Node.js for Mobile Apps website](https://code.janeasystems.com/nodejs-mobile).

Node.js for Mobile Apps further improves compatibility with the npm module ecosystem by adding support for native modules.

Support for native modules in Node.js for Mobile Apps - Janea Systems - Blog

Support for native modules in Node.js for Mobile Apps

In our ongoing quest to improve [Node.js for Mobile Apps](https://code.janeasystems.com/nodejs-mobile) (a.k.a Node.js Mobile), we have just completed a series of major improvements and made them available in the latest release. Of course, in delivering these improvements, we have paid close attention to the desires and feedback of our valued users, as always.

## **V8 JavaScript engine now on iOS**

Probably the most noteworthy update is the use of the V8 JavaScript engine on iOS. This replaces the ChakraCore engine that was used previously on Apple devices. With this update, Node.js relies on the same engine on both Android and iOS, ensuring consistent behavior and reliability across all devices.

Previously, when we used V8 on Android and ChakraCore on iOS, some specific code cases behaved differently due to implementation differences between the two engines. Some APIs were available on one platform and not the other. These issues are now eliminated.

The use of V8 on iOS was made possible by the engine now supporting a JIT-less mode, since its [7.4 release](https://v8.dev/blog/jitless).

## **Based on Node.js 12.16 LTS (Long-Term Support)**

The latest release is based on Node.js 12.16 LTS (Long Term Support), and has all of the latest security fixes patched into the software. Node.js 12 is the active LTS version, until [Node.js 14](https://nodejs.org/en/about/releases/) enters LTS on Oct. 20, 2020.

This also offers access to more recent APIs, such as 'worker\_threads', which make it possible to run JavaScript on more than one thread. This is an innovation that has been strongly desired among the Node.js Mobile community, and we're delighted that we can deliver it as required.

There is also ES6 JavaScript module support included, and the system now contains a more recent N-API version, which ensures improved module compatibility. 

The Node.js Mobile codebase is now rebased on the main [Node.js repository](https://github.com/nodejs/node/) instead of [node-chakracore](https://github.com/nodejs/node-chakracore). This will make it easier to keep up to date with future LTS versions and security vulnerability fixes. 

## **Built with V8 snapshots for Android**

The new release has been built with V8 snapshots for the Android version. Since V8 and Node.js internal JavaScript code are pre-initialized to be directly loaded into the heap, faster startup and run times are possible. Users on our [community channel](https://gitter.im/nodejs-mobile/community) have reported application launch time reductions of 50%. 

The challenge in building Node.js Mobile with snapshots was the cross-compiling of V8 and Node.js, while also having to build the snapshots to run on a different OS and CPU architecture.

With this recent release, Node.js Mobile is more powerful than ever. [Check out](https://code.janeasystems.com/nodejs-mobile/getting-started) the new changes, and we would love to know what you think!

Interested in exploring the possibilities of Node.js on mobile devices or Node.js application development? If so, [contact our consulting services team](http://www.janeasystems.com/#contact) to find out how we can help.

In our ongoing quest to improve Node.js for Mobile Apps (a.k.a Node.js Mobile), we have just completed a series of major improvements and made them available in the latest release.

Significant Updates in the New Release of Node.js Mobile- Janea Systems - Blog

Significant Updates in the New Release of Node.js Mobile

In the ever-evolving domain of enterprise open-source software (OSS), our team takes pride in being trusted to maintain a variety of pivotal projects. From enhancing libraries like [PyTorch, Node.js](https://www.janeasystems.com/blog/unlocking-the-power-of-open-source-lessons-from-janeas-seasoned-developers/), and [React Native](https://www.janeasystems.com/blog/janea-systems-helps-unblock-key-microsoft-customers-utilizing-react-native-for-windows/) for seamless cross-platform performance to building and maintaining award-winning tools like Microsoft PowerToys, our collaborative efforts highlight the collective power of open source. As we delve into our top tips for enterprise OSS project maintenance, we draw from over two decades of experience, sharing insights to help both seasoned maintainers and those just starting their open source journey.

Read on to discover how our global team of top software engineering open source advocates navigate the complexities of enterprise OSS, shaping the future of technology with every commit.

## 1\. Meticulous Merges – Understand Every Line of Code

João Reis emphasizes: "Understand every line." Before integrating changes, it's crucial to rigorously assess the implications of pull requests. Every merge has a ripple effect – from developers to end-users. In the realm of open-source, hasty merges can be costly. What you gain in time, you may pay for with your reputation and the need for follow-up fixes. Prioritize accuracy over speed, and remember that in the open-source ecosystem, our mistakes are communal, but so are our triumphs.

## 2\. Priority and Expectation Management – Master the Art of Triage

Jaime Bernardo on navigating a bustling project landscape: "Master the Art of Triage." Managing an enterprise open-source project is a balancing act between client deliverables and the vibrant unpredictability of community contributions.  
The phenomenal performance of PowerToys in 2022 — hitting 3rd place for first-time contributor count and 5th for total contributors, as well as being the 2nd fastest-growing open-source project on GitHub — showcases this balance in action. It's about embracing the unexpected while steadfastly adhering to your project roadmap. "It's essential to discern what demands immediate action and what aligns with long-term objectives. Each task, whether it's an anticipated bug fix or a surprising new feature suggested by a first-time contributor, must be weighed and prioritized to foster growth without derailing the project's course."

## 3\. Community Engagement – Be the Welcome Sign

João Reis advises: "Be the welcome sign." Open source is as much about the code as the community. "Extend a hand, be accessible, and foster a nurturing environment. Your guidance today could empower the lead maintainers of tomorrow. Remember, every expert was once a novice."

## 4\. Cross-Platform Consideration – Think Ecosystems, Not Just Features

João Reis on maintaining a holistic view: "Think ecosystem, not just features." In a multi-platform world, ensure that solutions are inclusive of diverse environments. “Each merge should be a step towards unity, not divergence, across platforms. The strength of your project lies in its universal operability, not just its individual features.”

## 5\. Pace and Patience – Speed isn't Everything

Stefan Markovic shares a pragmatic reminder: "Speed isn't everything. In the open-source world, especially in projects with thousands of contributors like ours, rapid movement isn't always a sign of healthy progress. It's important not to rush. True, things can progress slowly, but the best solutions are often those that are given time to mature. Patience is not just a virtue; it's a necessity for sustainable development.”

[Get in contact here](https://www.janeasystems.com/#lets-talk) to find out how we can support your open source initiatives.

---

## More about our software engineers:

### Joao Reis – Lead Software Engineer

One of the first employees at Janea Systems, Joao has worked on maintaining the Windows version of Node.js, including the development and maintenance of the Windows CI system in close collaboration with the open source community. João also worked on several cloud-agnostic projects, giving him deep experience and the ability to work across the board, from embedded to massive web applications.

### Jaime Bernardo – Lead Software Engineer

Jaime’s project work for Janea Systems covers many areas, including porting Node.js to Android and iOS, porting react-native modules to Windows, and developing/actively maintaining Microsoft PowerToys to this day, among other projects.

### Stefan Markovic – Lead Software Engineer

Stefan's professional journey began with a local outsourcing company where he specialized in developing and maintaining GNU tools, primarily utilizing the C programming language. After gaining valuable experience there, he transitioned to TomTom, where he worked on developing navigation software systems, with a focus on the routing engine using C++ language. He now works closely with Jaime, actively maintaining the award-winning Microsoft PowerToys project.

Discover best practices for managing enterprise open source projects. Gain insights from expert software engineers working on pivotal projects like PyTorch, Node.js, and React Native.

5 Top Tips for Maintaining Enterprise Open Source Projects 

## A brief history of open source  

In the 1950s, when academics and corporate researchers were the primary producers of computer software and compilers, most software came free with hardware purchases. Much of the software from this era was shared as public-domain software, i.e., software with no ownership. Towards the 70s, as OSs and programming languages evolved, it was clear that bundling software with hardware for free was not financially viable. Software providers had no incentive to maintain programs as they weren't getting paid for it.    

In 1974 software was legally considered copyrightable, and over the next decade, companies charging for software became the new norm. As large-scale operating systems matured, fewer organizations allowed modifications, and eventually, operating systems became closed to modification. By the 80s, companies were no longer distributing source code with products. Despite this shift towards closed-source software, open source (or free software) advocates used alternative means to share their source code freely with other programmers and users, such as computer magazines and bulletin board systems.   

In 1983, the same year Apple won a lawsuit clarifying that a program's source code and binary code were covered by copyright, Richard Stallman launched the free software movement. Motivated by incidents where the lack of access to source code prevented users from fixing software problems, Stallman initiated the GNU Project intending to create a complete operating system free from constraints on using its source code. In 1989, the GNU General Public License was published, providing a legal framework for software's unrestricted use, modification, and distribution.   

A couple of years later, in 1991, we saw the birth of arguably the most significant open source project to date, the Linux kernel, released under the GNU General Public License. Today, this massive collaborative project powers 85% of all smartphones, it's used by major space programs such as those of SpaceX and NASA, and the kernel ran on all of the world's 500 supercomputers in 2021.  

Although 90% of companies are now using open source, the movement has democratized creating, using, and sharing software for everyone. This blog delves into the importance of open source, featuring insights from seasoned developers with first-hand experience working on some of the world's most significant open source projects.  

## What is Open Source?  

Open source refers to software with publicly accessible source code. It allows developers to build on top of software, reverse engineer it, and repurpose it however they see fit. Anyone can inspect, modify, or distribute the software's source code, encouraging collaboration, transparency and fostering a developer community. Today, dozens of open source licenses exist with varying terms and conditions for modifying and distributing modified works. Some allow users to take open source code to be edited and used in commercial, closed source settings. Others ensure that open source stays open. The rise of Open Source projects has enabled the success of platforms like GitHub, where developers worldwide contribute to thousands of projects every day.  

## Advantages of Open Source 

Open source continues to revolutionize software development. It empowers organizations and individuals to tailor software to meet specific needs. It's a much more cost-effective solution to developing closed source software because it avoids vendor lock-ins and costly license fees. It also stimulates rapid innovation from a large developer community, increasing the quality of software, the number of features, and its security because it is constantly under review. Open source also bolsters interoperability, often being compatible with other open source and proprietary software. It fosters community, creating robust support networks, forums, and resources for troubleshooting and learning. With all of this, it creates a higher level of trust. Users can verify what the software is doing instead of relying on vendor assurances.  

## Janea Systems' Experience with Open Source  

Here at Janea, we have over 18 years of experience working on open source projects and even more tinkering in our spare time. Across Janea's portfolio of ventures, our diverse team of open source advocates work across several operating systems and hardware setups. It's because of this that we know, all too well, the annoyance of system incompatibility, and it's one of the primary reasons why a lot of our open source work revolves around interoperability. Our open source work ensures developers can utilize systems and programs in settings that feel native to them, whatever their setup.  

![](https://www.janeasystems.com/wp-content/uploads/2023/07/Alexis-MacBook-ThinkPad.png)

Our Founder and Chairman of the Board, Alexis Campailla, stuck a ThinkPad keyboard on a MacBook Air.   

## Different Types of Open Source Projects

> > "Essentially, there are two kinds of open source projects.   
> > 
> > (1.)Projects started in the community, driven by people who want to build and share code online altruistically.
> > 
> > (2.) Then you have open source projects from companies. These projects could be closed source, but being open source is mutually beneficial for the open source community and the company because it gives anyone access to the software, and companies get help to support more features."   
> > 
> > _João Reis, Lead Software Engineer at Janea Systems_

Take a look at just a few of the open source projects we've worked on and what our developers have had to say about them.  

## [PyTorch](https://github.com/JaneaSystems/pytorch)  

Our ongoing work enables developers and data scientists to utilize PyTorch to its full potential across the Windows ecosystem. Our team is trusted to maintain PyTorch for the Windows open source community. This work includes ensuring stability by resolving PyTorch Continuous Integration (CI) test failures, actively contributing to TorchSharp - an initiative aimed at extending the PyTorch API to the .NET ecosystem, and transitioning PyTorch to C++17 which our Lead Engineer, João Reis, describes below:  

> "One piece of work from this project that we're really proud of was enabling C++17 on PyTorch. This was blocked on Windows because of a few issues, but we reviewed them, fixed them, and helped move it forward. Now PyTorch is coded in C++17 to keep up with the C++ standard, essentially modernizing the code base."  

## [React Native](https://github.com/orgs/JaneaSystems/repositories?q=react-native&type=all&language=&sort=)

Our work on React Native provided a unified developer experience across the Windows ecosystem, enabling devs to create Windows desktop applications. While React Native successfully served iOS and Android developers, there was a significant gap for the Windows user base. Several mobile platform modules were unavailable on Windows, which hindered the development process. Our work porting 16 core modules was significant to many Microsoft clients and the broader developer community.  

Jaime sums up the project here: 

> "Native modules allow you to access information specific to the device. Let's say you want to access photos or get information on what OS the hardware is running or the available Ram on mobile. You don't get access to any of that when you're just doing an application with JavaScript and HTML because it's supposed to run in a browser. But these are native desktop apps, so for each platform, there needs to be some code that accesses this information. This was already in place for iOS and Android. Our work on this project helped bring this functionality to Windows so that people could pick up the web apps they've done in iOS and Android and port them easily to also work on Windows, using their original React Native code."  

## [PowerToys](https://github.com/microsoft/PowerToys)  

We were trusted to develop the core feature set of the recently reinvented Microsoft PowerToys. This includes utilities such as Color Picker, FancyZones, Video Conference Mute (Experimental), File Explorer Addons, Image Resizer, PowerToys Run, Keyboard Manager, Shortcut Guide, and PowerRename.  

Jaime tells us about a problem the team overcame while working on FancyZones:  

"One specific challenge we faced was with a particular set of screens or monitors. Screen manufacturers should set a unique string that identifies the screen, but one set of monitors would send the same ID for that model on every screen. So, there was no way for us to see which screen was which. This was especially problematic working on modules like Fancy Zones. We had to implement and iterate on many strategies to ensure the zones wouldn't reset when, for example, people disconnect and reconnected screens, or when they restarted a computer or went to their lock screens."  

This is just one small example of the diverse set of problems our team must overcome while working on open source projects. We're particularly proud of our work on this project and the great reception from the open source community. [GitHub’s 2022 State of Open Source report](https://octoverse.github.com/) ranked PowerToys: 

*   2nd place for open source projects with the highest contributor growth 
*   3rd place for top open source projects by first-time contributor count 
*   5th place for top open source projects by contributors as a whole  

## Challenges in Open Source Projects  

When working on open source projects, no two days are the same. With anyone being able to contribute, there's always something new to work on, but this also poses challenges.   

One difficulty with open source projects is learning new frameworks and working methods. For example, our work on react native covered 16 diverse modules from text to speech systems to media player functionality. This keeps our developers on their toes because they must have an intricate understanding of a module to successfully work on it. Our developers see this as a challenge and an opportunity as every new codebase endeavors to expand on their deep tech-agnostic expertise.  

When working for a company on open source, multiple stakeholders are often involved at varying levels. Some programs are owned by one company but maintained by another for specific OSs and hardware. In addition, the open source community is a significant stakeholder in projects. Prioritizing and juggling requirements can sometimes prove difficult, but we've managed to overcome this over the years by ensuring clear communication with all stakeholders and holding ourselves accountable.  

Much of our work revolves around solving incredibly complex software engineering challenges. More significant bugs must be solved quickly to ensure that the program works for most users but "minor" issues can sometimes be left by the wayside, especially when it comes to edge cases with unique hardware setups. One of the challenges we face in this work is being unable to replicate and troubleshoot bugs because of the hardware setups.  

## Conclusion  

Open source allows us to harness collective intelligence for exponential innovation. Here at Janea, embracing open source affirms our commitment to transparency, collaboration and inclusiveness while enabling developers of all skill sets to thrive.  

Open source encourages us to transcend the traditional silos of knowledge, inviting us into a global workshop where collaboration, creativity, and transparency lead. We firmly believe that no matter how smart the people you hire inside your company, there are always smarter people outside. That's why we're committed to open source and will continue to contribute to it, absorb its lessons, and help shape our collective digital future with it.  

Get in contact with us to find out more about our open source work.

 Unlocking the Power of Open Source: Lessons from Janea's Seasoned Developers

Microsoft's move to ARM64 processors in their new devices is a game-changer. It's not just a hardware upgrade but a substantial shift impacting software compatibility and performance. With ARM64 architecture becoming more prevalent, the need for proficient software porting to this platform is critical. This transition is part of a broader industry trend, with many software companies and open source projects actively porting and optimizing their applications for ARM64 architecture, including Chromium, Adobe Creative Cloud apps (like Photoshop), Visual Studio Code, and many others.

Here at Janea Systems, we've been at the forefront of this wave, guiding businesses through the complexities of ARM64 porting. With a rich history of successful projects and deep technical expertise, we made this guide offering practical insights from real-world projects to help technical teams, product managers, and executives navigate the road to seamless ARM64-optimized software.

## **Understanding ARM64 Architecture**

#### ARM32 vs. ARM64

ARM64, also known as AArch64, isn't just a beefed-up version of ARM32. It's a whole new beast. ARM64 offers improvements that ARM32 and traditional x86/x64 architectures simply can't match, such as:

*   Performance: ARM64 provides significant performance improvements over ARM32.
*   Energy Efficiency: ARM64 processors are designed to be more power-efficient, which is crucial for extending battery life in mobile devices and reducing energy consumption in data centers.
*   Scalability: ARM64 architecture is highly scalable and suitable for various devices, from smartphones to servers.

#### Emulation Performance

Emulating x86 and x64 on ARM64 might seem like a good idea until you realize it's slower than a snail on a salt track. "Emulation works but is slow. This is especially true for applications that interact heavily with the operating system or require significant processing power," João Reis points out. Windows 10 and 11 support emulation, but if you want speed, native ARM64 support is the way to go.

Below, we'll provide tips and tricks for porting your applications to ARM64, complete with real-world examples from our expert engineers at Janea. Let's dive in!

# Your Guide to Porting Applications to ARM64

## Processor Level Changes, Assembly Code, and Intrinsics

If your code includes low-level processor-specific instructions, get ready to roll up your sleeves. You'll need to rework this for ARM64. Applications built with higher-level or portable languages might dodge this bullet, but anything involving assembly or intrinsics will need attention. If you already have a mobile or Linux ARM version, you might be able to reuse parts of the existing code.

When we [ported Node.js Mobile to run on ARM Apple devices](https://www.janeasystems.com/client-success/node-js-windows), we had to introduce some assembly changes to handle the different calling conventions used by Apple ABI:

Handling Apple's calling convention:  
[https://github.com/JaneaSystems/nodejs-mobile/commit/91e5413390b5e07c066c24cb1464e75416838b31](https://github.com/JaneaSystems/nodejs-mobile/commit/91e5413390b5e07c066c24cb1464e75416838b31)  
This commit introduces changes to the arm64\_CallFunction assembly code to support ChakraCore's custom ABI on iOS ARM64 devices. The main changes involve:

*   Adding a new macro PROLOG\_SAVE\_REG\_PAIR\_INDEXED for iOS
*   Modifying the existing PROLOG\_SAVE\_REG\_PAIR macro for non-iOS platforms
*   Adjusting the use of these macros in the arm64\_CallFunction implementation to maintain semantic equivalence with the original Windows-based assembly file

Further adjustments:  
[https://github.com/JaneaSystems/nodejs-mobile/commit/9e0b148670c990acf17bc503b430a6d78a2eeaa9](https://github.com/JaneaSystems/nodejs-mobile/commit/9e0b148670c990acf17bc503b430a6d78a2eeaa9)  
This commit makes further modifications to the arm64\_CallFunction:

*   Removes the use of PROLOG and EPILOG macros
*   Introduces explicit frame creation instructions
*   Adds CFI (Call Frame Information) directives
*   Adjusts register usage and stack operations

Final tweaks:  
[https://github.com/JaneaSystems/nodejs-mobile/commit/5d8380ea30a032a205a4afc4453911df967ae776](https://github.com/JaneaSystems/nodejs-mobile/commit/5d8380ea30a032a205a4afc4453911df967ae776)  
This commit makes additional refinements:

*   Further adjusts register usage
*   Modifies stack operations
*   Tweaks the overall implementation of arm64\_CallFunction

Compiler-specific extensions or intrinsics that have been in use for a long time may have better alternatives at the programming language level. For example, to enable V8 (formerly Node.js' JavaScript engine) to compile on ARM64 with Visual C++, we replaced some GCC-specific instructions that were only used on ARM with standard C++ code that can be compiled with any supporting compiler:

[https://chromium.googlesource.com/v8/v8/+/0f81fe3a06e1ad726e4be4fb04a53befd40d860a%5E%21/](https://chromium.googlesource.com/v8/v8/+/0f81fe3a06e1ad726e4be4fb04a53befd40d860a%5E%21/)

Another example of processor-level changes is our work on Microsoft PowerToys, where we reviewed an open source contribution that added support for ARM-specific registers in exception handling. This pull request adds support for ARM-specific registers in exception handling for PowerToys:

*   Adding ARM64-specific register definitions (X0 to X28, FP, LR, SP)
*   Implementing GetImageArchitecture function to detect ARM64 architecture
*   Modifying DumpExceptionInfo to handle ARM64-specific context information

[https://github.com/microsoft/PowerToys/pull/17587](https://github.com/microsoft/PowerToys/pull/17587)

These modifications demonstrate the detail required when porting low-level code to a new architecture, especially when dealing with platform-specific calling conventions and CPU features.

## Dependency Management

All of your dependencies need to play nice with ARM64. It's like trying to fit a square peg in a round hole if they don't. Here's how we've handled dependency issues in various projects:

#### Evaluating Alternative Libraries

In some cases, you may need to find ARM64-compatible alternatives for your existing dependencies. For example, PyTorch uses Intel's Math Kernel Library on Windows Intel platforms. As part of an ongoing collaboration to add Windows ARM64 support to PyTorch, we developed prototypes to evaluate the performance and functionality of the following libraries on ARM:

*   **OpenBLAS:** [OpenBLAS](https://www.openblas.net/)
*   **ARMPL:** [ARMPL](https://developer.arm.com/Tools%20and%20Software/Arm%20Performance%20Libraries)

#### Updating Native Dependencies

If you're shipping native dependencies, they need to handle ARM64 as well. In PowerToys, we had to ensure the native Visual C++ Redistributables were compatible with ARM64:

*   We modified the installer to detect ARM64 architecture and install appropriate redistributables
*   We updated dependency management to include ARM64-specific versions of Visual C++ libraries

[https://github.com/microsoft/PowerToys/commit/ba4b9cf549adee784e2e3a7b51aa7d2b54a55a87](https://github.com/microsoft/PowerToys/commit/ba4b9cf549adee784e2e3a7b51aa7d2b54a55a87)

#### Handling Unsupported Dependencies

Sometimes, you may encounter dependencies that don't have suitable installers for ARM64. In such cases, you might need to temporarily disable affected modules. We faced this issue with PowerToys:

*   We implemented conditional compilation to exclude the affected module on ARM64 builds
*   We added runtime checks to disable the module's functionality on ARM64 systems

[https://github.com/microsoft/PowerToys/commit/f6a63582a26336b7ec285e1e9acb128ba494b715](https://github.com/microsoft/PowerToys/commit/f6a63582a26336b7ec285e1e9acb128ba494b715)

#### Contributing to Open Source Projects

In some cases, you might need to contribute to your dependencies to add ARM64 support. While adding ARM64 support to Node.js, we encountered a new dependency that didn't support ARM64 Windows. We raised the issue and helped fix it:

[https://github.com/simdutf/simdutf/issues/216](https://github.com/simdutf/simdutf/issues/216)  
[https://github.com/nodejs/node/pull/46800](https://github.com/nodejs/node/pull/46800)

#### Top Tips for Dependency Management when Porting to ARM64

Remember, if a dependency is blocking your ARM64 build, you have several options:

*   For internal dependencies, rebuild them with ARM64 support
*   For third-party dependencies, request the maintainer to add ARM64 support.
*   For open-source dependencies, check if a newer version with ARM64 support exists, or consider contributing the support yourself
*   As a last resort, consider removing or replacing the dependency

By carefully managing your dependencies, you can ensure a smooth transition to ARM64 architecture and take full advantage of its benefits.

## Operative System Interaction

Windows on ARM64 isn't just Windows on Intel with a new coat of paint. There are subtle but crucial differences. For example, there are new environment variables and ARM-related values (e.g., for the PROCESSOR\_ARCHITECTURE environment variable). Executables that run under x86/x64 emulation will see the system a bit differently. Depending on how much your application interacts with the system (environment variables, registry, COM objects, etc.), you might need to make some small but often confusing adjustments.

#### Handling OS Differences

There are new environment variables and ARM-related values to consider. Executables under emulation will see the system differently. This can be a bit of a rabbit hole, but it's essential to get it right.

One notable issue we faced in PowerToys was the user PATH not being available for child processes. We had to implement workarounds to handle this:

[https://github.com/microsoft/PowerToys/commit/fb7a85ec81f2766562b42bd91fc80df94e4738e7](https://github.com/microsoft/PowerToys/commit/fb7a85ec81f2766562b42bd91fc80df94e4738e7)

This commit implements a workaround for the user PATH not being available for child processes on ARM64 Windows:

*   Adding a new function GetUserPath to retrieve the user's PATH environment variable
*   Modifying the CreateProcessHelper function to include the user's PATH in the environment block

[https://github.com/microsoft/PowerToys/commit/c601a3e3e22d919ddb913faef1bc80b02999fe8d](https://github.com/microsoft/PowerToys/commit/c601a3e3e22d919ddb913faef1bc80b02999fe8d)  
This commit provides further adjustments to the PATH fix for child processes:

*   Refactoring the GetUserPath function to use ExpandEnvironmentStringsW
*   Improving error handling and logging for PATH-related operations

## Build System Adjustments

Your build system needs to support ARM64, and you need to configure it to produce ARM64 binaries. Here's a guide on how to add an Arm64 configuration to your project in Visual Studio: [https://learn.microsoft.com/en-us/windows/arm/add-arm-support#step-1---add-an-arm64-configuration-to-your-project-in-visual-studio](https://learn.microsoft.com/en-us/windows/arm/add-arm-support#step-1---add-an-arm64-configuration-to-your-project-in-visual-studio)

Take a look at how we implemented changes for the build systems on PowerToys, Node.js, and node-gyp:

*   We added ARM64 cross-compilation support to PowerToys: [https://github.com/microsoft/PowerToys/commit/6a2d9e4e3943da75d9ddc3dca1276fb9231870ce](https://github.com/microsoft/PowerToys/commit/6a2d9e4e3943da75d9ddc3dca1276fb9231870ce)
*   To add ARM64 support to Node.js, we fixed a compilation issue in V8, the JavaScript engine used by Node.js: [https://chromium.googlesource.com/v8/v8/+/71985a16ea035ae21a46efb847fdba19ed26bc2e%5E%21/](https://chromium.googlesource.com/v8/v8/+/71985a16ea035ae21a46efb847fdba19ed26bc2e%5E%21/)
*   We reviewed and helped with an open source community contribution to add ARM64 Visual Studio support to node-gyp: [https://github.com/nodejs/node-gyp/pull/2650](https://github.com/nodejs/node-gyp/pull/2650)

## Installer and Distribution Formats for ARM64

Packaging for ARM64 isn't just about ticking a checkbox in your installer settings. If your application is packaged in an installer, you must ensure it supports ARM64. If you're using MSI installers, you will need to build a new one and make sure any Custom Actions are working correctly. For example, the WiX Toolset included support for ARM64 since version 3.14.

For PowerToys, we added ARM64 binaries to releases, ensuring users had access to ARM64-optimized versions: [https://github.com/microsoft/PowerToys/commit/13750188fd521bb695ebd729b54d492995c05f2b](https://github.com/microsoft/PowerToys/commit/13750188fd521bb695ebd729b54d492995c05f2b).

We also supported ARM64 MSI packages in Node.js, adding WiX Toolset 4 support and official ARM64 releases:

**MSI Package:** [https://github.com/nodejs/node/commit/0b66df61efec996cef593fbdfa18751c55d19153](https://github.com/nodejs/node/commit/0b66df61efec996cef593fbdfa18751c55d19153)

*   Updating the WiX Toolset configuration to support ARM64 builds
*   Modifying the MSI package generation process to include ARM64-specific

**Official ARM64 Releases:**

[https://github.com/nodejs/build/commit/76fd047c18bf3b5e460b92d1b2daeb696eb886a7](https://github.com/nodejs/build/commit/76fd047c18bf3b5e460b92d1b2daeb696eb886a7)

*   We configured the build system to generate ARM64 binaries
*   We updated release scripts to include ARM64 packages in the official releases

[https://github.com/nodejs/build/commit/f0640bbbd6f1cd6f51c7915d098dcd3f344bdaf6](https://github.com/nodejs/build/commit/f0640bbbd6f1cd6f51c7915d098dcd3f344bdaf6)

*   We added ARM64-specific build configurations to the CI system
*   We modified release automation to handle ARM64 artifacts

[https://github.com/nodejs/nodejs.org/commit/b40c70cd04f18d27a9634536b0f518fa5305fa5c](https://github.com/nodejs/nodejs.org/commit/b40c70cd04f18d27a9634536b0f518fa5305fa5c)

*   We added ARM64 download options to the website's download page
*   We updated release information to include ARM64-specific details

## Testing and CI Adjustments

Testing on ARM64 requires more than just running your existing tests. Your CI system needs to be set up to handle the ARM64 binary independently to ensure it remains functional. If you're using a CI system on the cloud, Azure has ARM64 Windows VMs available.

#### Ensuring ARM64 Compatibility in CI

In our continued work maintaining Microsoft Powertoys, we perform manual tests on every release and check utilities to make sure they are still working on Windows 10 and Windows 11.

Test the program on a clean system without any other software installed to ensure that all dependencies are present.

The CI infrastructure needs to be set up to enable testing on Windows ARM64. Here's an example of how we did this for the Node.js CI:

[https://github.com/nodejs/build/pull/3211/files](https://github.com/nodejs/build/pull/3211/files)

This pull request sets up ARM64 testing infrastructure for Node.js CI and:

*   Adds ARM64 Windows machines to the CI pool
*   Configures Jenkins to run tests on ARM64 hardware
*   Updates test scripts to support ARM64-specific scenarios

After fixing all the tests that had issues on ARM64, we enabled testing by default on the Node.js CI.

[https://github.com/nodejs/build/commit/af948e4eb12424dcab5e9738a10077b167d51034](https://github.com/nodejs/build/commit/af948e4eb12424dcab5e9738a10077b167d51034)

This commit enables ARM64 testing by default on the Node.js CI:

*   It modifies the CI configuration to include ARM64 in the default test matrix
*   It updates test result reporting to handle ARM64-specific outcomes

We reviewed an Open-Source community contribution to PowerToys aiming to ensure new contributions cover ARM64: [https://github.com/microsoft/PowerToys/pull/19878](https://github.com/microsoft/PowerToys/pull/19878)

## Cross-compilation vs. Native Compilation

#### Benefits and Challenges

Cross-compilation can be a lifesaver if you don't have an ARM64 machine on hand. But you should always test on native hardware to catch any platform-specific quirks.

In PowerToys, we added native compilation support based on existing cross-compilation support: [https://github.com/microsoft/PowerToys/commit/57bde1c54c36f8387741557877e2e20161f0e1e8](https://github.com/microsoft/PowerToys/commit/57bde1c54c36f8387741557877e2e20161f0e1e8).

## ARM64EC: A Tool for Gradual Porting

ARM64EC (Emulation Compatible) is a powerful tool in the ARM64 porting process, designed by Microsoft to facilitate a smoother transition for complex applications. Key features of ARM64EC include:

*   Gradual Porting allows developers to port their applications to ARM64 incrementally rather than requiring a complete rewrite all at once.
*   Compatibility with x64 Code: ARM64EC enables ARM64 apps to interoperate with x64 plugins or dependencies that haven't been ported yet.
*   Performance Benefits: While not as fast as native ARM64 code, ARM64EC offers better performance than full x64 emulation.
*   Simplified Debugging: It allows debugging of both ARM64EC and x64 code together, streamlining the development process.

ARM64EC is particularly useful for large, complex applications with numerous dependencies. It allows teams to start benefiting from ARM64 performance improvements while gradually transitioning their codebase and dependencies. For more detailed information, refer to the [official Microsoft documentation on ARM64EC](https://learn.microsoft.com/en-us/windows/arm/arm64ec).

## Conclusion

As ARM64 for architecture becomes more prevalent, porting to ARM64 is a complex but necessary process to ensure your applications run at their best. We hope this guide has helped you in whatever stage of transitioning your software to ARM64 architecture.  We're ready to help you navigate this transition if you need further assistance, ensuring your software runs smoothly and efficiently on ARM64 platforms. Whether you're a technical team embarking on a porting project or a C-suite executive seeking reliable expertise, we're here to support you every step of the way. Speak with our expert team [here.](https://www.janeasystems.com/contact)

ARM64 processors are on the up, and x86/x64 emulation isn't enough. Discover how to port software to ARM64 architectures with our comprehensive guide. 

A Technical Guide to Porting Software to ARM64 Architecture: Everything You Need to Know 

Porting Software to ARM64 Architecture: Everything You Need to Know 

small_Jaime HD.jpg

thumbnail_Jaime HD.jpg

Jaime HD.jpg

Jaime

Windows developers were missing core modules in React Native, creating a significant gap in development capabilities.

Core Module Accessibility

Missing modules blocked core initiatives for customers, limiting the potential for application development on the platform. 


Blocked Customer Initiatives

The absence of vital modules meant a lack of functional parity with other operating systems, necessitating a tech-agnostic approach to port 16 modules.

Functional Parity

Bridging the gap between React Native and Windows applications, enabling developers to utilize a unified codebase across platforms.

Bridging Platforms

Integrating 16 missing core modules for a seamless Windows development experience, expanding the capabilities of React Native on Windows.

Unblocking Customers

Enabled collaboration between Microsoft and the open source community for a richer, more inclusive developer experience.	

Community Collaboration

While React Native successfully served iOS and Android developers, there was a significant gap in the Windows user base. Several mobile platform modules were unavailable on Windows, which hindered the development process, blocking key Microsoft customers and the broader open source community. This project was initiated as a response to the increasing need for a unifying developer experience across various platforms, enabling devs to create Windows desktop applications in React Native. 

Microsoft leveraged Janea Systems' tech-agnostic expertise to port 16 modules to React Native for Windows to increase functional parity with other OSs. 

Porting Core React Native Modules to Windows

Enabling React Native Desktop Applications 

Extend Azure Maps’ influence to an untapped market of over 1 billion iOS users.

Unlocking iOS Market Potential

Achieving web and Android parity on iOS.	

Feature Parity

Building an SDK that enables companies to bring their products to the iOS market.

Creating an iOS SDK with a Native Feel

Bringing Azure Maps to a whole new user base by integrating it with iOS. 

Successful iOS Integration

Achieving feature parity, enabling developers to utilize Azure Maps regardless of the platform.

Web, Android and iOS Feature Parity

Offering native-feel SDK tools to both Swift and Objective-C developers. 

Dual Language Development

Expanding Azure Maps' potential market reach exponentially.  	 

Market Reach Amplification

Owned by Microsoft, Azure Maps was only available for web and Android users. This drastically reduced the size of their market as there are over a billion iOS users that were missing out on the world-class enterprise software.   

Find out how we built an interoperable SDK in Swift and Objective-C to unlock Azure maps for iOS developers.  

Expanding Azure Maps to over a Billion iOS devices 

Expanding Azure Maps to Over a Billion iOS devices 

Reviving and updating a historic software utility for modern operating systems.	

Historical Revival

Prioritizing, managing, and integrating vast community feedback, contributions and issue reports.	

Open Source Engagement

 Navigating and integrating diverse tech stacks across 20+ modules.

Tech Stack Diversity 

Ensuring smooth integration and functionality across devices within the Windows ecosystem.

Seamless OS Integration

Enhanced productivity tools for power users, elevating efficiency and utility. 

Boosted User Productivity

Fostered a highly engaged and collaborative open-source community.

Active Community Engagement

Established PowerToys as a platform for trialing potential future Windows features.

Windows Feature Sandbox

Expanded the module offerings, catering to a wide range of user needs.

Rich Module Library

Microsoft Powertoys has over 15 million downloads and counting.

15M+ Downloads

Microsoft, aiming to revive PowerToys for modern Windows versions, partnered with us, leveraging our extensive expertise in open-source development. Our collaboration focused on updating and innovating utilities to meet contemporary user needs. 

Janea Systems champions Microsoft PowerToys, enhancing Windows for power users through active development and community engagement. Discover the impact. 

Maintaining Microsoft PowerToys 

Reviving Microsoft PowerToys for the Open Source Community 

Objective-C

Java

Python

Lead Software Engineer

large_Janea Systems OG Image No Text.png

medium_Janea Systems OG Image No Text.png

small_Janea Systems OG Image No Text.png

thumbnail_Janea Systems OG Image No Text.png

Janea Systems OG Image No Text.png

Janea Systems is a software engineering consultancy, serving the enterprises that drive global innovation for over two decades. We help our clients build and optimize technologies used by millions of developers and billions of consumers. 

Skills

Projects

Related Blogs

Let's talk about your project

Let's talk about your project