Satoshi's Windows workbench: 27 months of MinGW and Visual C++ 6.0, then a Linux build of his own

In August 2009, eight months after the first release, Satoshi told Martti Malmi which of his two Windows compilers he actually relied on. The v0.1 readme had named both, MinGW GCC 3.4.5 and Microsoft Visual C++ 6.0 SP6. MinGW, he wrote, was “the better compiler, I only used VC for debugging.” For that whole stretch, and for the year and a half of coding before it, nothing in Satoshi’s record mentions Linux.

Five days later he explained why, and in the first week of November he took over the Linux build Malmi had begun in a branch. He finished the compile, merged it into the trunk, and wrote in the commit log that it “works reliably on Linux now.” The record that shows twenty-seven months on Windows also shows Satoshi leaving Windows on his own schedule, for a reason he put in writing, and still calling himself the less Linux-capable developer a year later. This entry lays it out by period.

1. Overview — three phases

The phases are anchored on public-record events: the first dated email in the archive to raise Linux (2009-08-24, beginning of Phase 2), the v0.2 release that first shipped a Linux version (2009-12-16, end of Phase 2), and Satoshi’s last known email (2011-04-26, end of Phase 3).

2. Phase 1 — coding, release, and early period (~27 months): no Linux in the record

Satoshi himself stated in his November 2008 reply on the cryptography mailing list that he had “worked through all those little details over the last year and a half while coding it,” and later told Martti Malmi in July 2009 he needed “a break from it after 18 months development.” A self-attested ~18-month coding span ending around the v0.1 release places the start of coding in mid-2007 at the latest. Satoshi himself documented the work order: “I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper” (to Hal Finney, November 9, 2008). The paper came after the code was substantially complete, not before it.

The later “Since 2007” / “2 years of development before release” framings (Hanyecz, 2010-06-18; Hearn, 2011-01-10) describe the same pre-release work at wider scopes, not a separate pre-coding design phase: the approximately-2-year retrospective adds the months Satoshi was thinking through the problem before opening an editor. The Phase 1 boundaries here track the coding span and the public release. The full self-statement timeline is collected in the cypherpunk-independent-arrival analysis.

The v0.1 release ships on January 8, 2009 as a Windows-only .rar archive on SourceForge. For another seven months after that — until the very end of August 2009 — Bitcoin’s source code lives only on Satoshi’s local machine, distributed as successive .rar releases. Across this entire twenty-seven-month window, the archive contains:

• No Linux discussion in Satoshi’s email. The earliest email in the archive to raise Linux is Malmi’s of 2009-08-24, listing a Linux port among his next steps. Nothing earlier from Satoshi surfaces Linux as a topic.
• No Linux build, port, or user-side commentary. The first “Linux build” thread in the archive is the late-October 2009 series with Malmi.
• No mention of running Bitcoin on a non-Windows machine. The one exception comes from outside: in April 2009 Mike Hearn tried the client under Wine on a Mac.

2.0 A portable GUI on a Windows core — three observations

1. v0.1 is Windows-only. From v0.1 (January 8, 2009) through the v0.1.x minor series until v0.2 added Linux support on December 16, 2009 — roughly eleven months — Satoshi shipped only the Windows-only .rar.
2. The whitepaper and the v0.1 announcement are platform-silent. No mention of OS, no portability goal, no stated intention to ship multi-platform implementations, no strategic framing like “of the available platforms, we chose Windows because…”
3. The user interface was portable from the start; the system layer was not. The v0.1 readme lists wxWidgets, a cross-platform GUI framework, among the dependencies, and every window in the client is drawn with it. Underneath, v0.1.0’s headers.h includes windows.h and winsock2.h unconditionally, so the code as shipped could not compile anywhere else. The one place Satoshi weighed the choice is in a comment in util.h: “Could use wxCriticalSection for portability, but it doesn’t support TryEnterCriticalSection.” He knew the portable option existed and took the Windows call for one function it lacked.

Observations 1 and 3 are consistent with two readings that do not exclude each other:

• (a) Satoshi’s design horizon did not foreground non-Windows users in the early period
• (b) Satoshi deliberately targeted general Windows consumers as the initial adopter base

Reading (b) coheres with the .rar packaging (a Windows-consumer-familiar format), the no-installer extract-and-run pattern, and the Windows-only initial scope — a self-consistent “download, double-click, run” strategy. The distribution analysis checks against the record that the overlap with the Warez scene stops at this form. Phase 2 gives (b) direct support: the first time Satoshi argues the platform question, in August 2009, his reason for staying on Windows is the individual users on it (§3).

Observation 2 belongs to Phase 1 only. In the whitepaper, the v0.1 announcement and the early correspondence the choice is never raised as a topic. The first record of Satoshi reasoning about it is a private email eight months after the release.

Four pieces of Windows-specific evidence are visible during this period, all independent of one another:

2.1 MinGW GCC 3.4.5 + Visual C++ 6.0 SP6 — the build toolchain

The Bitcoin v0.1 source archive’s readme.txt records the supported compilers in Satoshi’s own words:

Compilers Supported
-------------------
MinGW GCC (v3.4.5)
Microsoft Visual C++ 6.0 SP6

The two were not equals. In August 2009, after Malmi got the build working with MinGW and MSYS, Satoshi told him he had cut the executable down by stripping debug symbols, “That’s with mingw. That’s the better compiler, I only used VC for debugging.” The release builds came from GCC; Visual C++ 6.0 served as the debugger.

Visual C++ 6.0 was released by Microsoft in 1998; SP6, the final service pack, shipped in 2004. MinGW GCC 3.4.5 (the Windows port of GCC, last release in the 3.4.x series) shipped in early 2006. By 2008–2009, all three were several years past their replacements: Visual C++ 2003 / 2005 / 2008 had been shipping for years and the Visual C++ 6.0 IDE was widely regarded as obsolete; GCC 4.x had replaced 3.4.x on most distributions. The SVN repository history entry describes the same Windows-side codebase from the porting side. A workflow anchored on an eleven-year-old IDE plus a 2006 MinGW build is unlikely to have been freshly assembled for Bitcoin.

Satoshi knew how old it was. In November 2009, comparing hashing speed on the new Linux build with the Windows one, he wrote that “GCC 4.3.3 on the Linux build optimized the SHA-256 code better than the old GCC 3.4.5 on Windows,” and added: “I should see if I can upgrade MinGW to 4.3.x to get them on a level playing field.” In 2009 the toolchain had fallen behind by inertia, and its owner said so himself; the replacing began the next year (§4).

The readme.txt itself records a corroborating trace: “You may need Boost version 1.35 to build with MSVC 6.0. I couldn’t get version 1.37 to compile with MSVC 6.0.” Satoshi tried the newer Boost, hit a VC6 wall, and downgraded the dependency to fit the existing compiler rather than the other way around. A year later he chose the other way, raising Boost and letting VC6 go (§4).

By 2008 Microsoft’s free compiler, Visual C++ Express, ran for only 30 days unless it was registered through a Passport sign-in. Whether that is why a pseudonymous developer stayed on Visual C++ 6.0 is weighed in the analysis of Satoshi and the software-registration era.

2.2 Hungarian notation — the late-1990s Windows C++ style

Variable names throughout v0.1 follow Microsoft’s Hungarian notation (type-prefix conventions like nValue, strError, vtx). In August 2014, Wladimir van der Laan filed PR #4641 to remove the convention from new code, calling it a style that “has bugged me since the beginning.” Hungarian notation is the stylistic marker of the Win32 / MFC tradition of the late 1990s through the early 2000s — the same era as Visual C++ 6.0. (Full statistical breakdown of Satoshi’s coding-style fingerprint across v0.1.0 → v0.3.19 is in the Satoshi code analysis.)

2.3 .rar packaging and Windows-only first releases

Bitcoin v0.1 and the v0.1.x minor series, from January 2009 until v0.2 added Linux support in December 2009, shipped on SourceForge as Windows-only .rar archives. The format is treated in detail in the Warez-scene parallel entry; the relevant point here is that the Windows-only initial scope is both consistent with and dated to Phase 1.

2.4 Seven months without any team-development tooling

Within Phase 1, the seven post-release months (January–August 2009) overlap with an unbroken solo-developer pattern: no version control, no test suite, no issue tracker, no second-reviewer process. Each release was a fresh .rar of the current source tree; the public commit history begins only when Malmi opens the SVN repository at the boundary of Phase 1 and Phase 2. The SVN-history entry records the toolchain transition: when team-development infrastructure arrived in August 2009, it arrived because Malmi built it.

Jeff Garzik, an early core developer who worked with Satoshi from 2010, later made the same observation from outside the code: Satoshi combined well-known cryptographic building blocks in a novel way but lacked formal computer-science training in modularity and unit testing (see the Garzik retrospective).

Four independent observations — a MinGW + Visual C++ 6.0 Windows toolchain, Hungarian notation throughout the code, .rar Windows-only packaging, and the absence of any team-development tooling — all fit a single Windows-side, individually-working developer profile across the full 27-month period.

2.5 OSS library dependencies — active as a consumer

The same readme.txt lists Bitcoin v0.1.3’s external library dependencies:

Bitcoin itself ships under MIT/X11 — a permissive OSS license also documented at the top of the same readme.txt.

This places Satoshi unambiguously in the OSS-user population. “Did not know OSS exists” is not a tenable reading: v0.1 wires four major OSS libraries together and ships under an OSS license itself. What Phase 2 (§3 below) documents is a different observation: Satoshi was reluctant on the OSS community-conventions layer (autoconf, license-thread participation, etc.). The shape is active as a library consumer, passive as a community participant, a configuration not unusual for solo developers who treat OSS as a toolset rather than as a culture to join.

3. Phase 2 — the Linux build (~4 months)

Linux enters the record on August 24, 2009, and it enters as Malmi’s idea. Having got the build to compile with MinGW, he listed his next steps: minimize to tray, autostart with Windows, “After that I could see if I can do a Linux port.” Five days later Satoshi answered with the only statement anywhere in his record that weighs the platforms against each other:

SNSatoshi Nakamoto (email to Martti Malmi, August 29, 2009, 5:31:05 PM UTC)

While it’s tempting to do a Linux port, once we do it we have that extra work with every release from then on. I’d rather put it off a while longer. Auto-run might give us 300% more nodes while Linux might give us 3% more. Linux would help server farms, but actually we’d like to favour individual users. Someone reported that it works fine in WinE.

The choice of Windows was deliberate after all, and the reasoning is about nodes and users, not about what Satoshi knew. Two months later he started on it anyway. On October 29 and 30 he committed the first portability changes: critical sections moved from Windows calls to wxWidgets, and QueryPerformanceCounter, %I64d in format strings, Sleep and CheckDiskSpace made portable (“I fixed some non-portable stuff I came across,” he told Malmi). Malmi committed Linux alternatives for the Windows headers on October 31, and on November 3 reported a branch where “Util, script, db and the headers compile fully now and net.cpp partially.”

From there Satoshi took the build over. “Great, I’ve been looking forward to working on the Linux build,” he replied that day. The next day he “got it to finish compiling,” wrote build-unix.txt, and kept wxWidgets at 2.8.9 “because it’s the same version as on Windows”; later the same day he let Malmi know he was still on it, “so we don’t duplicate work.” On November 5 he merged the Linux changes into the main trunk, on November 6 the build “works reliably on Linux now,” and on November 8 he sent Malmi linux-0.1.6-test1: “The Linux build is ready for testing on the network.”

The SVN log, preserved in the Bitcoin Core repository on GitHub, records the same weeks under the committers’ handles (s_nakamoto for Satoshi, sirius-m for Malmi):

The November 5 merge carried Malmi’s branch work into the trunk under Satoshi’s name, so the commit log alone cannot divide the code line by line. The emails can: Malmi had the first files compiling, and Satoshi took it from there to a working program.

Testing ran the same way. NewLibertyStandard ran the test builds on 64-bit Ubuntu; Satoshi diagnosed a zombie-socket problem from his reports, fixed it in test5 with MSG_DONTWAIT, and ran his own stress test on a 32-bit Linux machine (“He has Ubuntu 64-bit and I have 32-bit, so I’m assuming that’s the difference,” November 15). Comparing hashing speed between the two builds, he called his Windows compiler “the old GCC 3.4.5” (§2.1).

Bitcoin v0.2 shipped on December 16, 2009 with “Linux version (tested on Ubuntu)” in its feature list, and Satoshi put that line under Martti Malmi’s name. The release notes record whom he chose to credit; the commits and emails record who finished the build. Both are true.

He did not claim more than he had. A week earlier, when The Madhatter offered his experience as “mostly a Linux/BSD guy,” Satoshi answered “That’s great because that’s where I have less expertise,” and in the same thread he welcomed a Mac build: “Mac support would be nice. wxWidgets really pays off for cross platform.”

Contact with OSS conventions also first appears in Phase 2. Phase 1 contains no Satoshi mention of Apache, GNU, autoconf, license-selection criteria, or similar OSS-convention topics. Phase 2 first surfaces them, in each case driven by external prompts:

• 2009-11-23: Satoshi asks Malmi for Apache configuration access to fix mod_rewrite on bitcoin.org’s Drupal install — server-admin context, demonstrating Apache configuration knowledge.
• 2009-12-12 (BitcoinTalk topic 12): a community contributor (The Madhatter) asks “given any thought to using autoconf?” Satoshi replies: “Considered autoconf. Autoconf is a necessity for large projects with a quagmire makefile, but I think we’re small enough that it’s more optimal without it. I’d rather keep the makefile simple as long as possible.”. The reply records that autoconf (the canonical OSS cross-platform tool) was “considered” — but whether this reflects prior familiarity with the tool or a quick post-suggestion look that ended at “not worth the complexity for our size” cannot be decided from the message alone. He had written the makefile.unix that autoconf would have replaced five weeks earlier.
• 2010-09-12 (BitcoinTalk “Switch to GPL”): in the community-initiated license thread, Satoshi compares MIT / Boost / new-BSD / public domain / GPL trade-offs and remarks that for small projects “the fear of a closed-source takeover is overdone.” License-comparison competence is on display, at the practical-not-theoretical level.

The weaker claim these three datapoints establish is only that Satoshi was not entirely ignorant of OSS conventions. Whether each response reflects prior familiarity or just-in-time investigation after the prompt cannot be decided from the messages themselves. What is clear is the response shape: across all three, the choice was to keep adoption minimal, and each surfaces because a community participant raised it. Linux took a different path: silence, a stated postponement, then a build Satoshi finished himself.

Read together with §2.5, the picture sharpens: at the library layer Satoshi was an active OSS consumer (wxWidgets / OpenSSL / Berkeley DB / Boost, all from Phase 1), but at the community-conventions layer (autoconf, license-thread participation, GitHub culture) Satoshi remained passive. The split is consumer-active, contributor-passive — a real and recurrent profile among solo developers, not a contradiction.

Most of the non-Windows technology in Satoshi’s record was brought in by other named people; Linux is the one he then carried himself. A consolidated view across Phase 2 and Phase 3:

SVN, macOS, autoconf, GPL-vs-others license discussion, Java/JVM, and Git all arrive in Satoshi’s recorded scope through other named people. Linux arrives the same way, as Malmi’s proposal, but Satoshi does most of the work once he decides to; Apache configuration he handles directly, in the context of running bitcoin.org rather than the Bitcoin development stack. Satoshi’s pre-Bitcoin computing horizon appears to have been completed inside the Windows / Microsoft sphere; what Phase 2 shows is how quickly he could work outside it once the cost was worth paying.

4. Phase 3 — three platforms (~16 months)

In Phase 3 the Windows tools themselves change. On February 12, 2010, Satoshi made Boost 1.35 or higher a requirement for the new command line and JSON-RPC, and in the same commit (98500d70a8 in the SVN history) Bitcoin “now compiles with MSVC 8.0.” The compiler list in build-msw.txt no longer reads as the two lines of v0.1: MinGW “recommended”; MSVC 6.0 SP6 still buildable, he thought, if Asio was added to the older Boost; and “MSVC 8.0 (2005) SP1 has been tested.” He added a caution: “MSVC 7.0 and up have a habit of linking to runtime DLLs that are not installed on XP by default.”

In July he wrote that “we use something in Boost that doesn’t” support MSVC6, so “we lost support for it after 0.2.0.” The same post records that keeping VC6 until then had been a choice: “I wanted to keep compatibility with MSVC6 at that time.” In September he told a Windows user to get MinGW from the new installer, skipping the latest 4.5.0 for 4.4.1, and described his own install: “I think the only thing I had to do was rename make*.exe something to make.exe.”

Bitcoin v0.3 shipped on July 6, 2010 with a Mac OS X version, “thanks to Laszlo.” Satoshi had asked the forum to test it (“Laszlo’s build is going to be our first Mac release so please test it!”), and three weeks later, after separating bitcoind from wxWidgets, he listed the platforms he could check himself: “I test compiled MinGW, VC and Ubuntu. I don’t know if I broke the Mac OSX build, someone will need to check that.” He had written two days earlier that MSVC6 was no longer supported, so this VC is something newer than 6.0. Two Windows compilers and one Linux distribution; the Mac stayed in other hands.

Malmi proposes giving the root password of the bitcoin.org server to Satoshi and one more person, and Satoshi answers by naming Gavin Andresen and giving his reasons. The note contains the most direct self-positioning on the Linux axis anywhere in Satoshi’s correspondence:

SNSatoshi Nakamoto (email to Martti Malmi, December 03, 2010, 7:58:40 PM UTC)

It should be Gavin. I trust him, he’s responsible, professional, and technically much more linux capable than me.

This is the only place in the archive’s Satoshi record where Satoshi names a concrete other person and places himself on a Linux-skill axis below that person. The framing is calmly comparative; the substance is that, a year after finishing the Linux build himself, Satoshi still does not consider himself a Linux-capable developer at Gavin’s level. It matches what he told The Madhatter in December 2009.

An email two months later shows him still writing from Windows. On February 22, 2011, Satoshi sends two PGP-encrypted blocks to Gavin and Malmi handing over the bitcoin-list mailman password. Both encrypted blocks carry the header:

Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0

MingW32 is the Windows port of GnuPG. WinPT (Windows Privacy Tray) was a Windows-only GUI wrapper for GPG, popular in the late-2000s Windows GPG ecosystem. The signature footer is automatically emitted by the client and does not have to be set by hand — it is a passive trace of the host operating system. Bitcoin by then ran on three platforms; the machine Satoshi wrote from was still Windows.

5. Cypherpunk-era context — limited claims

Was a Windows-only stack unusual for an individual cryptographer in 2008–2009? The archive does not contain a systematic survey of operating-system preferences in the cypherpunks community. What it can do is collect what the archive records for several adjacent figures:

• Hal Finney worked at PGP Corporation (later Symantec) until his 2011 retirement. His 2004 Reusable Proof-of-Work (RPOW) ran its server on an IBM 4758 secure coprocessor; the server image was built with Linux GCC, and the client came with build instructions for Linux and for Windows with Microsoft VC++. Andy Greenberg’s 2014 Forbes article says Finney ran the early Bitcoin code on an IBM Windows desktop tower. Finney is one of the more directly comparable cases to Satoshi’s profile.

• Wei Dai authored Crypto++, a C++ cryptographic library whose early development centered on Visual C++ on Windows. b-money (1998) was a paper-only proposal with no reference implementation, so direct OS evidence is limited, but the Crypto++ lineage points Windows-side.

• Adam Back released Hashcash (1997) primarily as a Perl reference implementation, which is cross-platform; Back’s academic and industry background gives him exposure to both Unix and Windows environments without an obvious primary tell.

What this scattered evidence supports: an individual cryptographer using Windows as a primary development environment in the late 2000s was not strange. Hal Finney is a direct precedent; Wei Dai’s library lineage points the same way. The cypherpunk-equals-Linux assumption, common in retrospective accounts, is not well supported by what the archive shows for the actual people in Satoshi’s intellectual orbit.

What this evidence does not support: any quantified claim about the cypherpunks community as a whole. The sample is small (three named individuals), and each individual’s environment evidence is partial. The honest statement is “Satoshi’s Windows-only stack is consistent with several documented cypherpunk-era cryptographers’ environments, not a contradiction of them” — not “the cypherpunks were mostly Windows.”

6. What the cluster suggests

Read chronologically across the three phases, the cluster supports a structural reading of Satoshi’s pre-Bitcoin background:

• Long-established Windows C++ workflow. MinGW GCC 3.4.5 for builds and Visual C++ 6.0 (1998) for debugging, plus Hungarian notation, place the formative period of Satoshi’s C++ habits in the late 1990s to early 2000s Windows ecosystem. The stack was stable long before Bitcoin, and old enough that its owner called it old. In 2010 he began replacing it himself (§4).
• Individual developer, not team developer. Twenty-seven months without VCS, without tests, without an issue tracker, without a second reviewer — none of these are habits a team-embedded developer of 2008 would shed for a side project. They are habits of someone who had not been carrying those habits in the first place.
• Assumed adopter base also Windows-side, by decision. The Windows-only .rar release pattern is consistent with Satoshi assuming node operators would themselves be on Windows, and in August 2009 he said so in his own terms: Linux “might give us 3% more” nodes, and “we’d like to favour individual users.”
• Linux on his own schedule. Satoshi put Linux off for a stated reason, took the build over from Malmi’s branch two months later, and had it running reliably within a week. The capability was there; the priority was not, until it was. A year on he still ranked himself below Gavin on Linux.

Bundled together, this fits the profile of an individual developer without team or enterprise cross-platform development experience. That type is not rare: among solo developers without exposure to corporate cross-platform projects, a Windows-centered mental model of the computing world is common enough that the assumption (“of course my Windows workflow is the default”) often passes without friction. That profile explains both the Phase 1 structural absences (no team tooling, no platform discussion, Windows-only release) and why Linux had to justify itself in node counts before Satoshi spent a week on it.

The reading characterizes Satoshi’s working environment and practice patterns. It does not narrow identity to any country, employment status, or specific person — multiple kinds of developer (independent consultant, hobbyist with a long Windows C++ history, ex-corporate Windows engineer working outside hours) fit this profile.

7. Limits

• “linux capable than me” could be self-deprecating. The Gavin quote is a sincerely held comparative judgment in context, but the framing leaves room for understatement, and the man who wrote it had finished a Linux build himself a year earlier. Even so, the structural admission — that Gavin is being entrusted with root access to the project’s server in part because of Linux-side competence Satoshi does not match — is robust, and it repeats what he told The Madhatter in December 2009.
• When Visual C++ 6.0 was chosen is not recorded. The age of a toolchain is a tell about when the workflow stabilized, not about whether the developer could have moved to something newer. For the Bitcoin years the record answers that: in July 2010 Satoshi wrote that he had kept VC6 because he wanted to keep compatibility with it, and within that year he had made the code build with MSVC 8.0 and installed MinGW from the new installer himself (§4). How he used VC6 before Bitcoin is not on the record.
• Absence of Phase 1 Linux trace is not proof of Linux ignorance. The 27-month window contains no public-record Linux activity, but absence of public trace does not strictly entail absence of private exposure. The speed of the November 2009 build, from Malmi’s partial branch to a reliable program in about a week, argues for some prior familiarity; the record does not say where it came from.
• Who wrote which line of the Linux build cannot be measured from the commits. The November 5 merge brought Malmi’s branch into the trunk under Satoshi’s name, and the v0.2 release notes credit the Linux version to Malmi. The division of labor above rests on the emails, which show Malmi getting the first files to compile and Satoshi taking the build from there to a tested release.

The Wei Dai identity hypothesis, the Hal Finney identity hypothesis, the Adam Back identity hypothesis, and the Peter Todd identity hypothesis each weigh the candidate’s documented working environment against the Windows pattern recorded here, and the identity-hypotheses overview applies that same test as a constraint on candidate selection across the whole field. The architecture-evolution design entry reads the Windows-centric early codebase as the starting point of architectural drift — the technical decisions inherited from Phase 1 that successor maintainers had to live with.

The workbench stayed Windows to the end. Malmi put the Linux door on the table, Satoshi said it was worth three percent, and two months later he walked through it himself in a week and handed the credit back to Malmi in the release notes. The last artifact the record holds is still a signature footer his Windows tools wrote on their own. The record shows a developer who knew exactly which platform he was standing on, and moved only when moving paid.