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_Joao R.png

thumbnail_Joao R.png

Joao R.png

João

Ensuring core dependencies function correctly on the Windows platform.	

Dependency Stability

Extending Node.js support to ARM64 architecture for Windows.

ARM64 Support

Navigating open-source community dynamics for cohesive development.

Community Collaboration

Building a robust platform for corporate adoption.

Reliability for Enterprises

Addressing speed discrepancies for a seamless experience.

Enhancing Performance

Successfully eliminated frequent bugs and crashes, enhancing Node.js's stability on Windows.

Stability Achieved

Achieved a 40% improvement in file I/O speeds through our optimization efforts.

Performance Breakthrough 

Ensured core dependencies work reliably, supporting a wide range of Windows-specific applications and services.

Dependable Dependencies

Established Node.js as a reliable and preferred solution in corporate environments, broadening its reach.

Enterprise Adoption

Users can rely on native Node.js capabilities like ARM64 compatibility. 

ARM64 Adoption

When Node.js emerged as a leading server-side JavaScript runtime, it was primarily optimized for Linux and macOS environments, leaving Windows users grappling with stability and performance issues. Realizing the potential of Node.js, Microsoft demanded its high-performance and reliability on Windows to ensure widespread adoption. 
 

Find out why Microsoft had trusted Janea Systems to maintain Node.js on Windows for over a decade.

Maintaining Node.js on Windows Since 2013

Ensuring a Smooth Node.js Experience on Windows 

Navigating the complexity of integrating advanced C++ features into PyTorch for Windows.

Upgrading C++

Tackling persistent CI challenges to elevate PyTorch's Windows experience. 

Windows CI Test Failures

Ensuring compatibility for devices running on the ARM-based processors under the Linux environment. 

Device Compatibility

Microsoft had a mission to expand PyTorch's reach to the .NET developer community.

.NET Integration Initiative

Transitioned PyTorch to leverage the latest advancements of C++17, supercharging performance and code efficiency.

C++17 Performance Optimization

Addressed multiple CI test failures, ensuring a more stable PyTorch experience for Windows developers.

Enhanced Stability for Windows

Enabled PyTorch's operation on ARM 64 architecture devices like Raspberry Pi and select mobile phones, minimizing cloud reliance.

ARM64 Architectural Harmony

Facilitated PyTorch's reach to the .NET developer community, expanding the user base and fostering wider adoption. 

Integration with .NET via TorchSharp

Having shown considerable expertise in maintaining some of the largest open source programs, such as react native and Microsoft PowerToys, Microsoft reached out to us to guarantee developers within the Windows ecosystem could utilize PyTorch to its fullest potential. This project is pivotal in future proofing the platform while fostering a collaborative, open source ecosystem. 

Learn about how Janea Systems Maintains the PyTorch Machine Learning Library on Windows. 

Expert Maintenance of PyTorch for Windows - Enhanced AI Development

Empowering Windows-Based AI Progress

Overcoming the complexity of the existing testing software.	 

Simplifying Complex Systems 

Reducing test engineers' dependency on software engineers for updates and modifications. 

Breaking Dependency Chains

Streamlining processes to make device testing quicker and more efficient.

Time Efficiency

Enabling non-technical users to manage and adjust testing protocols independently.

Empowering Users

Enabling Cognex to dynamically add and configure new devices for testing, significantly enhancing the flexibility of their testing environment without needing technical intervention for each new device or test scenario.

Enhanced Test Flexibility

By streamlining the testing process and allowing for easier updates, we contributed to a more reliable testing framework. This reliability ensures that industrial vision devices are rigorously vetted under diverse conditions, maintaining Cognex's high standards.

Robust Testing Reliability

The development of a user-friendly interface significantly reduced the learning curve for new users and empowered test engineers to manage testing protocols directly. This empowerment has led to a more engaged and proactive approach to testing among engineers.

Empowerment Through Usability

Cognex needed a solution to overcome the complexity and limitations of their existing testing software. Our reputation for delivering custom software solutions in industrial settings led them to partner with us for this project. 

Discover how our software solution revolutionized product testing for Cognex, enhancing efficiency and engineer autonomy in industrial vision systems.



Empowering Cognex with Streamlined Device Testing 

Streamlining Industrial Vision Device Testing

Allowing adaptable, client-driven AI modifications to turn complex data into actionable insights. 

AI Adaptability

Ensuring microscopic accuracy in data extraction and analysis tailored to industry-specific documentation.

Precision Data Extraction

Strengthening Docugami's client relationships through consistent, high-quality AI-driven outputs.

Trusted Partnerships

Significantly accelerating data analysis, turning hours of work into minutes. 

Rapid Data Processing

Enabling the deployment of machine learning models that adapt and learn from industry-specific datasets. 

Future Proofing Data Engineering

Building on a solid foundation, connecting  Docugami's software to industry-leading automation platforms, Docugami leveraged our expertise to further hone their AI for precise, industry-specific data handling. 

This project was crucial to ensure Docugami's outputs meet the unique requirements of their clients across multiple sectors; delivering sharper, actionable insights and significantly boosting document management efficiency. 

Find out how Janea Systems helps bridge the gaps between AI outputs and customer needs for Docugami. 

Enhancing AI Data Processing with Custom Engineering Solutions 

Custom AI Data Engineering for Precision-Driven Industries 

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