1401 builds a macOS install stick from Windows

What 1401 is actually trying to do on a Windows machine

1401 is a Windows application whose purpose is to put macOS onto a PC that already runs Windows, which the project describes as the reverse of Boot Camp. It is aimed at people who want a Mac environment on hardware they own rather than on Apple hardware, and it concentrates on the part of that job that is genuinely hard to do by hand: matching an OpenCore configuration to the specific processor, graphics card and board in the machine in front of it. The application reads the hardware, builds the OpenCore setup for it, and writes a macOS install stick. The scope is stated rather than implied. The Mac installer targets macOS 15 on OpenCore, and individual GPU, display and application support still requires validation on the reader's own combination. It is also worth knowing that the project describes itself as free of charge and never for sale, with a PolyForm Noncommercial License 1.0.0 covering the code, so the intended audience is an individual user rather than a reseller.

Unzipping the Windows app and reaching the first screen

Getting started involves no package manager and no dependency install. The release archive is named 1401-Windows-1.0.24.zip, and the instruction is to unzip it and keep the 1401 folder together, because the executable expects its companion files to sit beside it. The entry point is 1401.exe. It requests administrator rights on launch, and the reason given is concrete: it reads the hardware and writes the stick, both of which need elevation on Windows. The helper package for the NVIDIA side is delivered separately, either as a verified download or as a copy staged on the USB stick by the Windows app. The end to end test described in the project was run on an Intel Core Ultra 5 225F with a B860 board and a GeForce RTX 5060, and the project states plainly that it may not work on every PC. If that caution applies to your hardware, the documented fallback is to set up OpenCore by hand following the OpenCore Install Guide and the OpenCorePkg releases.

Four buttons: check, build, BIOS notes, write the stick

The Windows workflow is a short guided sequence. Check this PC gathers the hardware report, Build the Mac setup generates the OpenCore configuration, Your BIOS steps prints the firmware settings that have to be changed before booting from the stick, and Create the macOS stick writes the result to a USB device of 4 GB or more that can be erased. Internet access is required at this stage. After a restart with the adjusted firmware settings, the stick is booted and the macOS installer is chosen from the OpenCore menu. Inside that installer, only the intended macOS partition or volume should be selected, and a whole disk holding Windows or other data must not be erased. The destination is formatted as APFS with Disk Utility, and Reinstall macOS then downloads the remaining macOS files from Apple. The project asks for verified backups and recovery media before any partition work begins, which is a reasonable instruction given what the following steps do.

The rule engine that adjusts an OpCore-Simplify build

1401 does not author an OpenCore configuration from nothing. It builds with OpCore-Simplify and then applies its own rules on top, and every rule that fires is recorded in the build result, which gives the user an audit trail rather than a black box. The rules are narrowly aimed at specific combinations. sip-minimal keeps SIP enabled unless a chosen feature requires lowering it, and then lowers it only as far as that feature needs. The tahoe-weg-amd and tahoe-weg-args rules apply to macOS 26 with an AMD card, removing WhateverGreen because it panics on 26 and stripping its boot arguments. tahoe-intel-bt adds the -ibtcompatbeta argument for Intel Bluetooth on macOS 26. arrow-lake-ctr and arrow-lake-ctrsmt switch off CpuTopologyRebuild and ctrsmt for Core Ultra 200 processors, matching a configuration known to install and run macOS 15 on that CPU. keep-boot-args is the safety net for existing machines, since the stick never overwrites the boot arguments of a machine that already runs macOS.

The NVIDIA rules and the separate Mac companion app

Graphics card handling splits into a build-time rule and a Mac-side application. For a card in the driver's table, nullmoth-boot-args and nullmoth-sip set macOS 15, the driver's boot arguments and SIP 0x0A43. nullmoth-installer-bar applies a small BAR during installation, with ResizeAppleGpuBars 0 and ResizeGpuBars -1, so that the installer screen survives PCI setup, and the Mac application restores the full BAR once the install completes. On the Mac side, with a supported Turing or later NVIDIA card, the NullMoth folder on the stick is opened, 1401-Mac-1.0.18.zip is unzipped and 1401.app is run, or 1401-Mac-1.0.18.dmg is downloaded instead. The app installs the NVIDIA driver and updates the driver related OpenCore settings. It does not copy OpenCore onto an internal EFI, so the stick has to stay plugged in during the run and at every startup, because OpenCore on that stick is what boots macOS and its configuration is the one the app changes.

Hardware reports stay local until a submission is approved

Privacy is handled as an explicit step rather than a background process. If a build fails, 1401 shows the reason and then offers to send the log to nullmothsystems.com, and choosing Cancel keeps it on the PC. The same restraint applies to hardware reports. For diagnosing a boot failure, the stick holds the OpenCore startup log, Apple's boot log and any macOS panic, so a machine that never reaches macOS can still explain itself. Recovering those logs means booting back into Windows, plugging the stick back in and opening 1401, or clicking Scan for logs and send them. The report identifier the application displays is the piece to quote when asking for support, which makes it the useful artifact in a support request. The boot-logs-on-stick rule is what makes this work, and it is the reason a failed boot is not a dead end.

Running the project's own corpus checks before trusting a build

The project ships a test harness, and the commands are documented. The corpus is built from public Hardware Sniffer reports pinned by commit, and a build command runs the build, the rules and ocvalidate for every machine in the corpus. Each package also carries a self test, runnable through the module invocations below. These are the checks a reviewer can point at when asking whether a rule change altered existing configurations, and they run against Python rather than requiring a Windows machine, which makes the corpus and the rule logic inspectable outside the application itself. The documented invocations are:

python3 tests/corpus/fetch.py          # public Hardware Sniffer reports, pinned by commit
python3 tests/run_corpus.py build      # build + rules + ocvalidate for every machine in the corpus
python3 -m p1401.selftest && python3 -m p1401.guide --selftest && python3 -m p1401.apple --selftest \
  && python3 -m p1401.usbwriter --selftest && python3 -m p1401.scan --selftest && python3 -m p1401.nullmoth --selftest

The fetch step is the only one that needs the network, since it pulls the public reports, and the remaining commands run locally against the pinned corpus. Note the separate Rust directory: loader is an experimental UEFI boot layer tested in QEMU only, and the application does not use it, since the sticks boot with OpenCore. It is scaffolding rather than shipping code.

Where 1401 stops, and what it leaves to you

The honest limits are visible in the documentation. It has been tested end to end on one PC, and support for a given GPU, display or application has to be validated individually. The application does not write an internal EFI, so the machine depends on an external stick until that boot arrangement is separately reviewed and presumably migrated, which means a stick failure is a boot failure. Partitioning is manual inside the Apple installer, and the project asks for verified backups first. It also does not replace the OpenCore Install Guide, it automates part of a configuration flow that the guide still describes in full. Against that manual path, the difference of approach is that the guide requires you to decide each setting and verify each kext yourself, while 1401 derives the starting configuration from the hardware it reads and applies a fixed set of recorded rules on top. That removes guesswork for common recent platforms and removes all judgement for unusual ones, where the hand built route stays the documented fallback.

Editorial conclusion

1401 suits a Windows owner who wants a Mac environment on one specific machine and is prepared to follow the printed BIOS steps and keep a startup stick attached. It does not suit anyone needing a multi machine rollout, a commercial deployment, or a support policy, since the project has been validated end to end on a single configuration and its own documentation points at hand built OpenCore as the fallback. Before starting, confirm that your board, CPU and GPU combination resembles the tested machine, and read the printed BIOS instructions twice, because partition changes happen after that point and the application does not reverse them.

Frequently asked questions

Official sources

1. Issues
2. nullmoth/1401 on GitHub
3. Project website
4. README
5. Releases