← 2026-02-16 の一覧へ戻るホーム
Windows ネイティブ開発を修正しました。

2026/02/15 20:25

Windows ネイティブ開発を修正しました。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

記事は、ネイティブ Windows プロジェクトに「Visual Studio」を依存関係として要求することが過剰であると主張しています。なぜなら、そのインストーラは数千のコンポーネントをバンドルし、誤って選択するとビルド失敗につながり、ダウンロードに数時間（約15 GB）がかかり、レジストリが乱雑になるからです。
この記事では msvcup を紹介しています。このオープンソース CLI ツールは Microsoft の JSON マニフェストを解析し、必要な MSVC コンパイラ、リンカ、ヘッダ、ライブラリ、および SDK ファイルのみを Microsoft の CDN から直接ダウンロードします。単一の 

build.bat
スクリプトで特定のツールチェーン（
msvc-14.44.17.14
）と SDK（
sdk‑10.0.22621.7
）をインストールし、環境を自動的に設定する 
autoenv
ラッパーを使って簡単な C プログラムをコンパイルする方法が示されています。
msvcup は冪等性があります：変更がない限り、再実行はミリ秒で完了し、グローバル環境を変えずに再現可能なビルドを実現します。また、クロスコンパイルも標準でサポートされており、正確な再現性のためのロックファイルを生成できます。
著者は Tuple の CI での使用例を示し、事前に Visual Studio をインストールする必要がなくなること、x86_64 と ARM プラットフォームの両方で一貫したビルドが可能になることを説明しています。さらに、Raylib をソースから構築する実際の例も示し、実用性を裏付けています。
msvcup はコアのコンパイルツールを提供しますが、完全な Visual Studio IDE が必要な場合は置き換えません。それでも、並列バージョン管理、簡単なアンインストール/再インストール、後続インストールの高速化により、小規模チームから大企業まで、CI パイプラインを速くクリーンにし、ビルド時間を短縮することが期待されます。

本文

ネイティブプロジェクトを管理している想像をしてみてください

Windows でビルドするために Visual Studio を使うので、当然のこととして「依存関係」に登録します。

Build Requirements: Install Visual Studio

まだこの点を知らない方なら羨ましい限りですが、現在は Boromir さえもその事実を知っています…

Well put, Boromir.
あなたが気づいていないのは、実際に Microsoft の Visual Studio Installer の無給テクニカルサポートになることを同意しているという点です。GitHub Issues はコードそのものではなく、特に Windows で壊れたビルドについて語る場になりがちです。貢献者に「Desktop development with C++」ワークロードだけでなく、v143 ビルドツールと 10.0.22621.0 SDK（別のものではなく、もう一つのバージョン） をチェックしていないことを説明しなければならない場面も。結果としてプロジェクトに費やす時間が減り、50 GB の IDE に対する人力依存解決者になってしまいます。

「Install Visual Studio」と書くことは、悪い結末が待ち受ける選択肢の冒険本を貢献者に渡すようなものです。何度も OS を再イメージしなくてはならない経験をした人は少なくありません。

なぜこの悲劇は Windows 固有なのか

Linux ではツールチェーンはパッケージマネージャのコマンド一つで済むことが多いです。対照的に Visual Studio は数千ものコンポーネントを含み、Microsoft は GUI インストーラという複雑なインターフェースで配布します。チェックボックスの迷路を回りながら「ワークロード」や「個別コンポーネント」を探し、実際にコンパイラが入っているものを選ばないと時間と労力を浪費します。

  • 間違ったものを選ぶ と必要の無い 50 GB をインストールして数時間を失います。
  • 1つでも逃した（例: 
    Windows 10 SDK (10.0.17763.0)
    や 
    Spectre‑mitigated libs
    ）と MSB8101 のような謎のエラーでビルドが失敗します。
  • 旧バージョンにダウングレードする場合も同様に面倒です。

Visual Studio エコシステムは「すべて一体化」型モノリスの遺産を継承しており、エディタ・コンパイラ・SDK をひとつの絡み合ったウェブに統合しています。「Visual Studio」を依存関係に書くことは、コードを書くためのツールとそれをビルドする環境を区別できていないことを意味します。

苦痛が急速に増幅される理由

項目内容
時間ロス15 GB のダウンロードバーを何時間も見ながら、最終的に 50 MB のコンパイラだけを取得
透明性の欠如どのファイルがインストールされたか、どこに置かれたか全く分からない。レジストリはゴミで埋まり、バックグラウンド更新サービスはタスクマネージャに永住者として残る
バージョン管理の不備コンパイラを Git にチェックインできず、同僚が微妙に異なるビルドツール版を使うとビルドが静かに分岐
「ゴースト」環境アンインストールしても完全にクリーンにならず、新しいマシンへ移行するたびに GUI のダンスを繰り返し、同じチェックボックスを選んだと祈るしかない
開発者プロンプトの不可視化コマンドラインから単一 C ファイルをビルドするには「Developer Command Prompt」を見つける必要がある。裏で 
vcvarsall.bat
が環境変数をグローバルに変更している

結果として、ビルド手順は法的免責条項のようになります。

Works on my machine with VS 17.4.2 (Build 33027.167) and SDK 10.0.22621.0.
If you have 17.5, please see Issue #412.
If you are on ARM64, godspeed.

Windows ではこれが「ビジネスを行うコスト」となり、20 GB のインストールに3時間待つように促すことで 5 MB 実行ファイルのビルドを妨げる、ネイティブ開発への実質的な障壁となっています。

新しいアプローチ

私は他人のインストーラのデバッグ役になることには興味がありません。MSVC ツールチェーンを バージョン付き・分離済み・宣言型 のモダンな依存関係として扱いたいと考えました。

数週間で作ったオープンソースツール、msvcup を紹介します。小さな CLI プログラムで、ネットワーク/ハードウェアが良好なら数分でツールチェーン・SDKをインストールできます。ARM へのクロスコンパイルも含め、各バージョンは独自の隔離ディレクトリに配置されます。idempotent（冪等） かつ高速で、ビルドするたびに呼び出しても問題ありません。

試してみる

hello.c
と 
build.bat
を作成してください：

#include <stdio.h>
int main() { printf("Hello, World\n"); }

@setlocal

@if not exist msvcup.exe (
    echo msvcup.exe: installing...
    curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/download/v2026_02_07/msvcup-x86_64-windows.zip
    tar xf msvcup.zip
    del msvcup.zip
) else (
    echo msvcup.exe: already installed
)
@if not exist msvcup.exe exit /b 1

set MSVC=msvc-14.44.17.14
set SDK=sdk-10.0.22621.7

msvcup install --lock-file msvcup.lock --manifest-update-off %MSVC% %SDK%
@if %errorlevel% neq 0 (exit /b %errorlevel%)

msvcup autoenv --target-cpu x64 --out-dir autoenv %MSVC% %SDK%
@if %errorlevel% neq 0 (exit /b %errorlevel%)

.\autoenv\cl hello.c

このスクリプトは「Install Visual Studio」を置き換えます。

curl
/
tar
が使える Windows 10 系統なら動作します。MSVC ツールチェーンと Windows SDK をインストールし、プログラムをコンパイルします。

初回実行後は 

msvcup
コマンドがミリ秒単位で完了。ビルドスクリプトに残しておけば、ほぼすべての現代的な Windows マシン上で完全自律型ビルドが可能です。

仕組み

msvcup
は Mārtiņš Možeiko が書いた小さな Python スクリプトに触発されました。Microsoft は Visual Studio のすべてのコンポーネントを記述した JSON マニフェストを公開しており、公式インストーラもそれを使用しています。
msvcup
はこれらを解析し、コンパイルに必要なパッケージ（コンパイラ、リンカ、ヘッダー、ライブラリ）だけ を抽出して Microsoft の CDN から直接ダウンロードします。すべてが 
C:\msvcup\
配下のバージョン付きディレクトリに配置されます。

主な特徴：

機能説明
バージョン管理レジストリを汚さず、サイド・バイ・サイドでツールチェーンを保持
クロスコンパイルすべてのターゲットがデフォルトでダウンロードされる
ロックファイルペイロード/URL の自己完結型リストで再現性保証
高速・冪等再インストールはミリ秒で完了

制限点：

msvcup
はコアのコンパイルツールチェーンに焦点を当てています。IDE 全体が必要な場合は公式インストーラがまだ必須です。

実際の例：Raylib のビルド

@setlocal

set TARGET_CPU=x64

@if not exist msvcup.exe (
    echo msvcup.exe: installing...
    curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/download/v2026_02_07/msvcup-x86_64-windows.zip
    tar xf msvcup.zip
    del msvcup.zip
)

set MSVC=msvc-14.44.17.14
set SDK=sdk-10.0.22621.7

msvcup.exe install --lock-file msvcup.lock --manifest-update-off %MSVC% %SDK%
@if %errorlevel% neq 0 (exit /b %errorlevel%)

@if not exist raylib (
    git clone https://github.com/raysan5/raylib -b 5.5
)

call C:\msvcup\%MSVC%\vcvars-%TARGET_CPU%.bat
call C:\msvcup\%SDK%\vcvars-%TARGET_CPU%.bat

cmd /c "cd raylib\projects\scripts && build-windows"
@if %errorlevel% neq 0 (exit /b %errorlevel%)

@echo build success: game exe at:
@echo .\raylib\projects\scripts\builds\windows-msvc\game.exe

Visual Studio のインストールも GUI も不要です。祈る必要もなく、スクリプトが言うとおりに動作します。

さらに進んだ使い方

ここには 

msvcup
を用いて Windows 上で LLVM と Zig をゼロからビルドする手順を示すページがあります。ぜひご覧ください。

同じ日のほかのニュース

一覧に戻る →

2026/02/16 6:54

OpenAI に入社いたします。

## Japanese Translation: ** ## Summary: 著者は、OpenAIに参加する計画を発表しつつ、自身のオープンソースプロジェクト **OpenClaw** の開発を継続することを示しています。OpenAI のリソースとスポンサーシップと連携することで、ユーザーに優しく安全な AI エージェントをより広い層へ届けることを目指しています。彼らのプレイグラウンド・イニシアティブはすでに世界的な注目を集めており、アクセスしやすいツールの価値を証明しました。サンフランシスコで主要研究所と会議を行い、最先端モデルへの早期アクセスを得た一週間後、著者は OpenAI の高度な技術とオープンソース基盤を組み合わせることが責任ある AI 展開に不可欠だと考えています。 今後、OpenClaw は多様なモデルをサポートし、コミュニティ協力を奨励するファウンデーションへ進化します。著者は OpenAI の最前線研究チームに直接貢献すると同時に OpenClaw を独立して維持し、急速な商業スケールよりもインパクトのある製品に焦点を当てます。この二重アプローチは、非技術的ユーザーに強力なエージェントを提供し、開発者やデータ所有者に柔軟な基盤を構築させ、AI 業界を研究と実世界応用を橋渡しするより強固なオープンソース基盤へとシフトさせる可能性があります。

2026/02/16 2:12

LT6502：6502ベースの自作ラップトップ

## Japanese Translation: ``` ## Summary この設計は、8 MHz 65C02プロセッサを中心に構築されたコンパクトでバッテリー駆動のコンピュータを概説しています。 メモリ：46 KB RAM（0x0000–0xBEAF）はゼロページ、BASIC RAM、および Compact Flash バッファに分割されます；EhBASIC 2.22p5 と eWozMon およびブートストラップコードは ROM の 0xC000〜0xFFFF に配置されています。 周辺機器：タイマー/IO 用の 65C22 VIA（0xBFCO）、Compact‑Flash コントローラ（0xBFBO）、ビーパー（0xBFA0）、内部キーボード（0xBFEO）、コンソール FTDI インターフェース（0xBFF0）があります。 ディスプレイ：9″ RA8875 パネル（800×480）に内蔵フォントとシンプルなグラフィックスがあり、開発時には 4.3″ デモユニットも使用されました。 インターフェース：`OUTK` コマンド用の 8文字 OLED キーボード、USB‑C 充電/電源供給、シリアルコンソールアクセス、および将来のボード用に 0xBE00 に拡張スロットがあります。 バッテリー：**10 000 mAh** パック（USB‑C で電源・充電）。 ファームウェアは、BEEP、CIRCLE、CLS、COLOUR、DIR、ELIPSE、LINE、LOAD、MODE、OUTK、PLOT、SAVE、SQUARE、および WOZMON などのカスタム EhBASIC コマンドを追加します。 開発マイルストーン： - PCB スキーマティクスは 2025‑11‑12 に完成。 - 電源投入と基本機能は 2026‑01‑05 に達成。 - CF コントローラとビーパーは 2026‑01‑09 に動作確認済み。 - ディスプレイ統合は 2026‑01‑16 に完了。 - ファームウェア拡張（SAVE/LOAD、グラフィックス）は 2026‑02‑08 後から進行中。 - ケース組立は 2026‑02‑14 に完了。 このプロジェクトは、BASIC 開発者と教育者向けに低価格で携帯性の高いプラットフォームを提供し、レトロコンピューティングコミュニティおよび組込みシステム教育への影響が期待されます。 ```

2026/02/16 5:53

**GNU Pies ― プログラム起動と実行監視**

## Japanese Translation: **改訂された概要** Pies は軽量なスーパーバイザーで、外部プログラム（「コンポーネント」）を起動・監視し、自動的に再起動します。各コンポーネントはフォアグラウンドで実行され、Pies は起動時に設定ファイルからそのリストを読み込みます。コンポーネントの起動後、Pies はバックグラウンドプロセスとして継続し、終了を監視します。デフォルトでは予期せず停止したコンポーネントを自動的に再起動します。また、終了時にメール通知を送信したり別のプログラムを呼び出すなど、代替アクションを設定することも可能です。GNU ライセンスで提供される Pies は init デーモン（ブート時に最初に起動されるプロセス）として機能できます。この役割では、従来の `/etc/inittab` ファイルまたは Pies 独自の GNU スタイル設定を通じて構成を提供でき、古い init システムよりも柔軟性が高くなります。制御インターフェースは既に管理対象コンポーネントに対して広範囲な監視と管理機能を提供しています。

Windows ネイティブ開発を修正しました。 | そっか～ニュース