フレームワークを使わず純粋なC言語でWindows ToDoアプリを作ってみた！容量なんと278KB！
引用元：https://news.ycombinator.com/item?id=43954649
Raymond Chenの話とか読むと、win32 GUIプログラミングって面白いんだよね。昔Petzoldの本でいっぱいGUIアプリ作ったのが楽しかった。strcpyとかsprintf使ってるみたいだけど、危ないから長さチェック付きの使った方がいいよ。Win32 APIにはC標準ライブラリの代わりがいっぱいあるから、サイズ減らしたいならZeroMemoryとかCopyMemoryとか使ってみたら？ 生Cは大変だけど最初学ぶには良いよ。WTLっていうC++のラッパーもあるから、GUIやりたいなら見てみて。
少なくとも今どきは、strcpyじゃなくてstrncpy使わないと、みんな（AIとか）にずっと言われ続けることになるよ。zig使うとこういう落とし穴少ないんだけど、Cでも大丈夫。
へー、で、もしstrncpy()使うなら、今度は僕が「strncpy()は間違った関数だよ」って講釈垂れることになるね。
strncpyは固定長の文字列フィールドがあるバイナリプロトコルで超完璧なんだ。パディングが必要なんだよね。読むときもstrnlenとかstrncpy使うんだよ。
うん、それがstrncpy()の本来の使い方だよ。OPみたいな汎用プログラミングには向いてないね。バッファがいっぱいだとnull終端してくれないから問題になるし、余計なnullも書いちゃう。FreeBSDにはstrlcpy()、Windowsにはstrcpy_s()ってのがあるよ。OSのAPIはnull終端を期待してるから、読むときもnull終端前提で処理した方が安全でエラーも少ない。C++でstd::string使うとか、他の言語使えばいいんだよ。Cは文字列がひどいね。
ZeroMemoryとかCopyMemoryが、既存のWindows C stdの関数の代わりに提供されてるのって、何のためにあるの？
memset()とかCopyMemory()の代わりにZeroMemory()があるって話だけじゃなくて、fopen/fread/fcloseじゃなくてCreateFile/ReadFile/WriteFileとか使うべきって点にも同意だね。
ほとんど同意だけど、win32 GUIプログラミング（この記事みたいの）は正直痛いよね。MFCでもちょっとマシになったくらい。BorlandのDelphiみたいなC++ライブラリの方が断然良かったな。CreateFileはファイルだけじゃなくて、他のものも開く最高のAPIなんだよね。懐かしいな。
stringって、最後の要素がNullのバイト配列だと思ってたんだけど？ どうやったらNull終端しないstringになるの？
文字列がNULLで終わるかはプログラマ次第だよ。慣習だけど、最後のバイトを何にするかは自由。単なるバイトの配列なんだ。
Cは書いてないけど、Pascalみたいな文字列ラッパーがなんで流行らないのかずっと気になってたんだ。先頭に長さ情報があって、互換性のためにNULL終端も付けるやつ。
＞ Borlandの”Delphi like” C++ライブラリはすごい
ってあるけど、実際はDelphiのVCLそのものだったんだ。C++Builderに言語拡張があったのは、Delphiの機能と1:1で合わせるため。DelphiのユニットもC++で使えたし、Delphiのソースもコンパイルできたんだよ。
WindowsはCに標準化したわけじゃないよ。最初はアセンブリやPascalで、後からC/C++。MicrosoftはCを他の言語と同等に見てて、UNIXみたいに特別扱いしてない。C標準ライブラリもOSじゃなくてコンパイラ付属だった。最近は変わってきてるけど、Windowsは他のOSと違って言語独立性を大事にしてるんだ。WinRTとか見るとわかるよ。
そうそう、Object Windows Libraryから発展したんだよね。OWLも拡張があって、MFCよりずっと使いやすかった。過去形じゃなくて、今も製品は市場にあってリリースも頻繁だよ。昔ほどじゃないけどね。
＞ fopen/fread/fcloseを使ってる
ToDoリストだよ、ネットワークサービスじゃない。無制限のstrcpyを使ってても何が問題？攻撃の余地はほぼないし、彼は自分のために書いたんだ。HNの細かい批判はやめようぜ。人の作品を素直に見てみようよ。コンピューターは何かをやるためのツールで、たまには見た目悪くてもいいんだ。ここでの批判は”lsをセキュリティのためにRustで”みたいなナンセンスと同じレベルだと思うね。
memset()の代わりにZeroMemory()、memcpy()の代わりにCopyMemory()があるね。MSVCのintrinsicはrep stos/movs命令を使うはずで、これって関数呼び出しよりサイズが小さくなるんだ。
Cでは全部バイト配列なんだ。uint32_tも4バイトの配列って言う人もいる。だから慣習が必要なんだよ。文字列は最後にNullがあるバイト配列と定義されてる。Nullがなくなったらもう文字列じゃない。
Pascalは元々、文字列を扱う前に長さを指定する必要があったんだ。これってすごく良いアイデアだけど、当時は使うのが面倒だって思われてたんだよ。
無制限のstrcpyを使ってても何が問題？攻撃の余地はほぼないし、彼は自分のために書いたんだ。HNの嫌味な連中からの批判のためじゃない。← これを指摘したのは賢い気分になりたかったわけじゃないし、世界をRustで書き直せとかも思ってないよ。バッファオーバーランとかでデバッグに費やした時間はめちゃくちゃ多いんだ。最初からsaferなAPIがあれば、どれだけ時間を節約できたか。クールなプログラムだし、学ぶのは良いことだけど、不必要な問題は避けた方がいいと思うんだ。
Windows 1.xとか2.xってさ、C89標準より前に出てたんだよね。だからWINAPIの呼び出し規約がCじゃなくてPascalから受け継がれてるのもこれで説明つくわけ。C standard libraryは当時「ただの競合相手」だったってことだね。
＞ freebsdにはstrlcpy()があるって？
strlcpy()はOpenBSDから来たやつで、後からFreeBSDとかSolarisに移植されたんだよ。
OWLって、一部の標準コントロールを独自に描画するから、Win 3.11だとOWLアプリだけ浮いて見えた気がするな。MFCは叩かれがちだけど、結構不当な批判だと思うよ。だって根本的に違う種類のフレームワークなんだもん。MFCは底层APIを使いやすくするラッパーだけど、その核心は隠さない。一方でOWLやVCL（あとVB6とかWinFormsも）は、たとえネイティブウィジェットを使ってても、もっと高レベルで色々やってくれるラッパーなんだ。そういう視点で見ると、MFCへの適切な批判は「やりすぎ」ってことかな—例えばあのドキュメント/ビューの仕組みとか。フレームワーク全体の設計から浮いてる気がしてたんだよね。WTLは、MFCが目指したけど失敗したものを実現した感じ。
標準でmemsetとかmemcpyはインラインコードに置き換えても良いことになってるんだ。パフォーマンス上げるために非標準の拡張機能を使う必要なんてないんだよ。
＞ win32 guiプログラミングに惹かれるものがある
マジで同意だわ。AlomWare Toolboxっていう超優秀なPCアプリを使ってて、これこそまさにWin32設計の極致って感じなんだ（https://www.alomware.com/images/tab-automation.png）。あんなに機能多いのに、たった3MBくらいしか容量ないのもそれが理由。これもフレームワーク一切なし、実行ファイル一つだけ。ソフトウェアが全部まだこうだったら良いのにって思うよ。
公平に言うと、CreateFileとかってfopenよりずっと記述が冗長だよね。
2バイトじゃ足りないね、普通は長さのためにsize_t分のバイトを使うことが多いかな。でも、utf-8っぽい感じで、長さの最初のバイトのあるビットパターンを見れば、長さ自体が何バイト使ってるかわかる、みたいなこともできるかもね。
それは可能な規約の一つにすぎないし、特段良い規約ってわけでもないね。
ほとんどのライブラリ（この場合はWin32含む）のAPIに渡すには、やっぱり0終端文字列が必要だよ。
＞ 世界全部をRustで書き直すっていう考えには全く賛同しないね。
良い心がけだよ。だってRustの人達って、「XをRustで書き直す」のがRustのほぼ全てだって指摘すると、めちゃくちゃ怒るからね。
俺もそれにはすげー時間かけたよ。正直、ネイティブコードでネイティブUI開発するの、懐かしいし、できなくなって寂しいんだよね。
もっとコメントを表示（1）
CreateWindow()でいちいちコントロール作るより、昔ながらの方法だと.rcファイルにダイアログリソース置いてたんだよ（Visual Studioには今もエディタある）。で、CreateWindow()じゃなくてCreateDialog()使う。これだと全部勝手に作ってくれるんだ。さらにアプリマニフェスト足せば、モダンなUIスタイルとか高DPI対応もできちゃうぜ。
その方法だと、コントロール間の自動タビングとか、いくつかのキーボードショートカットも勝手についてくるんだ。サイズ変更は手動でやる必要があるけどね、でもそれは簡単で、コードも数百バイトもあれば十分だよ。
UNIX以外だとC標準ライブラリはOSじゃなくてコンパイラベンダーが提供してたんだ。だから昔はいろんな会社（Borland, Microsoftとか）のがあった。Windows 10以降はUniversal C Runtimeもあるけどね。
Petzold見てみろって昔は言ってたもんだよ…
でもこの記事のアプローチは、FFIがある言語なら移植しやすいんだ。リソースファイルとかDLLいらないし。リソースファイルって良いAPIじゃないしね。高レベル言語でCreateWindow呼ぶなら、リソースみたいなDSLをメタプログラミングで作るのもありかも。
”リソースDLL”なんていらないよ。コンパイルした.rcファイルはバイナリに直接リンクされるんだ。MinGW含むWin32 Cツールチェインなら何でもできる。APIも悪くないと思う。GPも言ってたけど、メリットたくさんあるよ。高DPI対応とかね。.rcファイルは”ダイアログユニット”使うから、CreateWindowのピクセルと違ってDPI独立なんだ。
もし”バイナリ”が自分でビルドしたりリンクしたりしてない、既成の言語ランタイムだったらどう？ 俺が考えてるのはそっちのケースなんだ。この記事みたいにCreateWindow直接呼ぶプログラムは、そういう状況にうまく合うんだよね。
もしアプリが.rcからコンパイルした.resファイルをインクルードできる.exeにリンクする言語じゃない場合は？その言語は.exeランタイムは持ってるかもしれないけど、それにリンクできるわけじゃない。その場合でも.rcファイルを使いたいなら、そこからリソースDLLを作って動的にロードしたいと思うんじゃないかな。（ローカライズ可能な文字列のためにリソースDLLがある理由の一つなのはわかってるよ。それはGUIレイアウトリソースを静的にリンクできるプログラムでも意味がある使い方だね。）
あ～、言いたいことわかったよ。でも記事の文脈（C言語Win32アプリ）では.rcファイルを避ける理由はないかな。
君が説明してるケースでも、リソースDLLを使わなくてもCreateDialogIndirectを使えばDLGITEMTEMPLATE構造体の配列からダイアログを作れるよ。コンパイル済みのダイアログも basically その配列のダンプだと思うんだ。
”Visual Studioにはそれを視覚的にやるダイアログエディタがまだある”
彼らはgccを使ってるよ。
それは関係ないよ。.rcファイルを作るのにVisual Studioを使うことはできる。このテクニックはMinGWベースのプロジェクトでもすごくうまくいくんだ。重要なのはVisual Studioに.rcダイアログエディタがあるってこと。
VS以外にも視覚的なダイアログ編集を組み込んだWindows用の.rcエディタはいくつかあるよ。Pelles Cはまだ定期的にアップデートされてる例の一つだね。
Pelles Cのヒントありがとう。ちょうど起動してみたんだけど、ちょっと clunky だね（Visual Studioもそうだけど）。でも.rcダイアログリソースを読み込んで編集できたよ。Visual Studioの古いダイアログエディタは最近はけっこう crashy だから、代替があるのは素晴らしいね。
俺も前に Linux でアセンブリで似たようなこと（2 KiB以下）やってたよ：https://gaultier.github.io/blog/x11_x64.html
純粋な C で動的にリンクすれば、Linux でも簡単に 20 KiB 以下に収まるよ。Windows はもっとシンプルだろうけど。
とにかく、この努力には敬礼！記事の最後に書いたリンクオプションを試してみるといいよ、サイズ小さくなるはず。
えっと、俺のちょっと拡張した TUI (ncurses) TODO プログラムは 15K だね。Linux。スタティックリンクじゃないけど。musl で ncurses をビルドするとこまではまだやってない。
”no frameworks”
なるほどね：スケーリングされた dpi でフォントがぼやける、Tab サポートがない、テキストフィールドで Ctrl-A でテキストを選んだり modern な frameworks が提供してた他の stuff ができなかったり、行を追加するとエラー、とかとか…
”modern”
どういう点が？
DPI設定の例だよ！
このコードはWindowsのバージョン見てDPI関係の関数を動的に呼び分けてるんだって。
XPとか古いのだと何も呼ばないみたい。
https://github.com/Dwedit/GameStretcher/blob/master/Stretche…
DPIはアプリのマニフェストでも設定できるよ。
プログラムでやるよりこっちがおすすめらしい。
詳しくはこちら！
https://learn.microsoft.com/en-us/windows/win32/hidpi/settin…
テーマとかGDIとか使うともうちょっと複雑になるよ。
前に自分で作ったDPI対応の例を貼っとくね！
https://github.com/tringi/win32-dpi
WindowsのDPIサポートはXP以降色々変わったけど、
アプリ開発者がやらかしたのを直すためって感じかな。
ちゃんとやればXPでも250%DPIで綺麗に表示できるよ！
https://x.com/TheBobPony/status/1733196004881482191/photo/1
あー、user32:みたいなWindows API関数って、
「純粋なC」とは違うフレームワークなんじゃないの？
コロンはC++じゃないよ。
それは特定のDLL（user32とか）に入ってるWindows API関数を指すときの書き方。
古いWindowsには無い関数だから、
DLLを動的に読み込んで関数のアドレス取ってきて呼び出してるんだ。
だからどのDLLにあるか知る必要があるんだよ。
ぶっちゃけ、Windows自体が
オブジェクト指向なUIフレームワークって言えなくもないよね。
OSなしで起動できる組み込みプログラムなら近いかもだけど、
それも結局BIOSとかドライバーに依存するよね。
今のハードウェアで現実的に『純粋なC』プログラムって
ほぼ無理じゃないかなー。
知識も労力もヤバすぎる。
仮想環境でも結局ABIインターフェースあるから、
ソースコードレベルで完全に純粋ってのは難しいと思うな。
『現代的』っていうのは、
必要以上にデカいのに機能不足って意味でしょ？
（キミが言う足りない機能の多くは、
特にコントロール間のタブ移動とか、
ちょー簡単に追加できるけどね。）
フォントスケーリングはSetThreadDpiAwarenessContext(-4)で
直る（有効になる）と思うよ。
-4に相当する定数がなんて名前かは知らんけど。
6502プログラマーだった俺の中の何かが、278KBが軽量だって言われて死んでるよ。
ビルド再現しようとしたら、gitの設定とかで最初うまくいかなかったんだ。でもMinGW使って試したら、最初から102KBになったよ。記事の278KBよりだいぶ小さいね。作者さん、どんな環境や設定でやったか教えてほしいな。GCCのオプション（-Os, -Oz, -flto, -s）で試したら、もっと小さく47KBにもできたよ。EXEサイズだけなら、まだまだ小さくできる余地あると思う。
＞ 作者さんが別のツールチェーンとか設定使ってるのかな？
デバッグシンボル付けてコンパイルしてるのかなって思ったんだけど。素のC言語でどれだけ変わるか分からないけど、まず最初に思いついたのはそれ。
どこかタイプミスだと思う。リポジトリとかリリースだと27KBって書いてあるよ（278じゃない）。
昨日投稿した時点のv0.1リリースは278KBだったんだよ。でも9時間前の最新リリースv0.3では、-Osと-sオプション付けて、さらにUPXで圧縮して27KBになってるんだ。
もっとコメントを表示（2）
俺もmingw使ったのに、違う結果になったんだよね。たぶんバージョンが違うか、MinGWのディストリビューションが違うか、32ビットか64ビットかの問題か、リンクしてるCRTが違うのかも。作者さんの詳細がないと、よく分からないな。
多くはプラットフォームとか実行ファイルフォーマットによるものだよ。スタックトレースの情報とか、動的リンクのインフラとか、例外処理のテーブル（C言語でも例外がC関数を通過する場合に必要）とか、そういうのがないと、もっとずっと軽量にできるんだ。
no dynamic linking infrastructureみたいなのはWindowsならタダで付いてくるし、例外処理テーブルも純粋なCなら必須じゃないよ。SEHだってそんなに必要ないし。
デモシーンの大会に「64kb TODOアプリ」部門とか作ってもらうよう請願してみる？
正直、意外とデカいなってびっくりしたよ。もっと小さいか、半分くらいアイコンに取られてるかと思った。昔、こういうの書いてた時はもっと小さかった気がするんだ。MinGwのせいかな？
これ聞くと、急にassemblyでのwin32プログラミングが流行った頃を思い出すね。たぶん、sharewareダウンロードがどんどんデカくなったこと（MFCの暗黒時代だったね）への反動だったんだろうな。昔のPalm Pilot 68kプログラミングと合わせると、あれが非レトロコンピューティングのasmの最後の盛り上がりだった気がするよ。
へへ:) ああ、書くのがもっと簡単なやつ作ったよ。しかも小さいんだ、15kBのquickrun.exe :)
C言語で、純粋なWin32 APIだよ。バイナリを小さくするハックは何もしてない、Mingw32コンパイラだよ。これはエイリアスでアプリをすぐ起動できるGUIアプリさ。
今夜は自分で書いたエミュレータのデバッグに時間使ってるんだ。Z80プロセッサと64kのRAMで動くシステムをエミュレートしてるやつ。
時々さ、立ち止まって色々どう変わったか見るよ。でもサイズの変更に対して、俺たちはたくさんの進歩をしてきたってことだと思うんだ。
90年代初頭にNethackが900kb以上の実行ファイルになるのを見て、雷に打たれたような衝撃を受けたのを覚えてるよ。
なぜかMSVCじゃなくてGCCでビルドされてるし、最適化も有効になってないみたいだね（速度とかサイズのための）。
ABIの問題もあるし、8bitとかから64bitアーキテクチャになったんだ。ポインタ1つが8倍も長くなってる。文句言うんじゃなくて、ただ感心しようぜ。これはアートだよ。
それ、5 1/4インチのフロッピーディスクにギリギリ入るくらいじゃん！
Win10/Win11の”新しい”電卓開いてみろよ。まるで別のOSを読み込んでるみたいだぞ…マジで無駄。
多分JIT-ingしてるのかな？ネイティブにコンパイルされてたら起動は一瞬なはず。どうやってコンパイルしてるのか全然わかんない。
やあみんな、このアプリは試してみたり、ちょっと楽しむために作っただけなんだ、ハハ。でもコメントにある通り、こういうのはC++とか他の言語でもっと賢くやれただろうね、アハハ。
これって、俺が30年前に初めてWindowsプログラムを作るときにexactlyどうやって学んだかと全く同じやり方だよ。ただ、C++コンパイラを使ったけどね。なんでかわからないけど、C++コンパイラでCスタイルのコードを書くのが、Windows APIのドキュメントの使い方だったと思うんだ。Microsoftは単にC++がCの改良されたスーパーセットだから、Cスタイルのコードでも使うべきだっていう考え方に行ったんだと思うよ。
