Windows 11は、まだWindows 95時代のコードで動いている。Microsoftが認めた驚きの事実 [すらいむ★]

Windows 11は、まだWindows 95時代のコードで動いている。Microsoftが認めた驚きの事実

　Windows 11でファイルをクリックし、右クリックメニューを開く。
　一見何でもない操作だが、その瞬間に実行されているのは、インターネットが商業化される以前の1990年代に書かれたコードである。
　Win32 APIは、Windows 95以前のWindows NTにまでその起源を遡る。
　MicrosoftのAzure最高技術責任者（CTO）であり、Sysinternalsの創設者でもあるMark Russinovichは、2026年5月にMicrosoft Dev Docsの公式Xアカウントに投稿されたビデオの中でこう言い切っている。
　「1990年代に、Win32が2026年においても第一級のAPIサーフェスであり続けると予想した人間はいなかったと思う。当時の我々が思い描いていたのは、空飛ぶ車や月面基地であって、Win32ではなかった」。

（以下略、続きはソースでご確認ください）

xenospectrum　2026年5月9日
https://xenospectrum.com/windows-11-win32-api-legacy-code/

Windows95はMS-DOS7.0にGUI乗せただけだろ
WindowsNTとは別物
Windows95（MS-DOS）の系譜はMEで終了

API云々なら64ビットになってもいまだに根っこがX86ベースになってる事実の方を心配しろよ

「枯れた技術」なんだな
極めて安定していて、信頼性が高いということが、何十年にもわたって実証されているんだから使い続けりゃいいんじゃね

何が問題なの？

今だったらAIに頼んだらWIN32APIくらい自動で作ってくれそう

スパゲッティで迂闊に手が入れられないだけだろ

動いてるから
ッヨシ！！

ピンボール返せよ

さすがにCよね？
アセンブラじゃなくて

今のWindowsの内部バージョンはWindows NT10か
Windows10と11は両方ともNT10らしい
しかしPCでやることはWindows2000あたりからたいして変わってないというのに、なんでこうも膨大なCPUパワーとメモリとストレージを食うようになってるんだろうな？
Windows2000の推奨環境はPentium133MHz以上、メモリ64MB、ストレージ2GBとかになってるけど、今はその100倍以上のリソースを何に使ってるんだ？

Microsoft Admits Nobody Expected Win32 to Still Power Windows in 2026
After three decades, Win32 still remains central to Windows

マイクロソフトは、2026年になってもWin32がWindowsの基盤であり続けるとは誰も予想していなかったと認めた。
30年経った今でも、Win32はWindowsの中核を担っている。

Microsoft has officially acknowledged something many Windows users already suspected: the Win32 API was never expected to remain this important in 2026. Yet despite decades of replacement attempts, it still powers much of Windows today.

As Windows Latest reports, Microsoft Technical Fellow Mark Russinovich recently described Win32 as the “bedrock” of Windows, admitting that nobody expected it to remain a first-class platform this long.

マイクロソフトは、多くのWindowsユーザーが既に疑っていたことを公式に認めた。Win32 APIが2026年になってもこれほど重要な存在であり続けるとは誰も予想していなかったのだ。しかし、数十年にわたる代替APIの試みにもかかわらず、Win32は今日でもWindowsの多くの機能を支えている。

Windows Latestの報道によると、マイクロソフトのテクニカルフェローであるマーク・ルシノビッチ氏は最近、Win32をWindowsの「基盤」と表現し、これほど長く第一級のプラットフォームであり続けるとは誰も予想していなかったと認めた。

Win32 became impossible to replace

Originally introduced during the Windows 95 era, Win32 evolved into the foundation of the Windows desktop ecosystem. Millions of applications still rely on it today, especially enterprise software and professional desktop tools that depend on deep Windows integration and long-term compatibility.

According to Russinovich, backward compatibility became one of the biggest reasons for Win32’s survival. Businesses needed older applications to continue working, while developers still required unrestricted access to system-level Windows features that newer frameworks often failed to provide.
Win32はもはや代替不可能な存在となった

Windows 95時代に登場したWin32は、Windowsデスクトップエコシステムの基盤へと進化を遂げた。現在でも数百万ものアプリケーションがWin32に依存しており、特にWindowsとの緊密な連携と長期的な互換性を必要とするエンタープライズソフトウェアやプロフェッショナル向けデスクトップツールは、その重要性を強く示している。

ルシノビッチ氏によれば、Win32が生き残った最大の理由の一つは、後方互換性にあるという。企業は古いアプリケーションが引き続き動作する必要性を感じており、開発者は新しいフレームワークでは提供できないシステムレベルのWindows機能への無制限アクセスを必要としていた。

Microsoft Dev Docs
@docsmsft

Did anyone expect Win32 to still be going strong in 2026? Mark Russinovich explains why its deep roots in Windows—and the massive ecosystem built on top—have given it serious staying power. Turns out “legacy” can still mean essential.


2026年になってもWin32が健在だと誰が予想したでしょうか？Mark Russinovich氏が、Windowsに深く根ざしたWin32の基盤と、その上に構築された巨大なエコシステムが、なぜWin32に揺るぎない存続力を与えているのかを解説します。「レガシー」が「不可欠」を意味することもあるのです。

Microsoft spent years attempting to move developers toward platforms such as UWP and WinRT, but those efforts never fully replaced traditional desktop development. Many developers viewed UWP as too restrictive because sandbox limitations blocked deeper operating system access. Frequent strategy changes also damaged trust in Microsoft’s long-term Windows app direction, and the UI development became chaotic.
マイクロソフトは長年にわたり、UWPやWinRTといったプラットフォームへの開発者の移行を促そうと試みてきたが、これらの取り組みは従来のデスクトップ開発を完全に置き換えるには至らなかった。多くの開発者は、サンドボックスの制限によってオペレーティングシステムのより深い部分へのアクセスが阻害されるため、UWPは制約が多すぎると感じていた。また、頻繁な戦略変更は、マイクロソフトの長期的なWindowsアプリ開発の方向性に対する信頼を損ない、UI開発は混乱を極めた。

WebView2 pushed Windows toward web apps

Over the past several years, Microsoft has increasingly adopted web technologies through WebView2, leading to a new generation of Windows applications built around Chromium-based interfaces instead of native desktop code.

Apps such as Microsoft Teams, Microsoft Outlook, Microsoft Copilot, Clipchamp, and Windows Widgets all became associated with this shift toward web-based experiences.

That transition also drew criticism from users who complained about heavier RAM usage, worse responsiveness, and weaker desktop optimization compared to native Win32 applications. Many users connected these issues to broader memory and performance complaints surrounding Windows 11.

WebView2はWindowsをWebアプリへと導いた

ここ数年、マイクロソフトはWebView2を通じてWebテクノロジーの採用を積極的に進め、ネイティブのデスクトップコードではなくChromiumベースのインターフェースを基盤とした新世代のWindowsアプリケーションを生み出してきた。

Microsoft Teams、Microsoft Outlook、Microsoft Copilot、Clipchamp、Windowsウィジェットといっ​​たアプリは、いずれもこのWebベースのエクスペリエンスへの移行を象徴するものとなった。

しかし、この移行はユーザーからの批判も招いた。ネイティブのWin32アプリケーションと比較して、RAM使用量の増加、応答性の低下、デスクトップ最適化の弱さなどが指摘されたのだ。多くのユーザーは、これらの問題をWindows 11におけるメモリとパフォーマンスに関する広範な不満と結びつけて考えていた。

Microsoft now appears to be moving back toward native apps

Microsoft now seems focused on modernizing Windows without abandoning the strengths of Win32. Instead of trying to fully replace the platform, the company appears to be combining newer UI frameworks with native desktop performance and compatibility.

The company continues investing in WinUI 3 and the Windows App SDK while still preserving traditional Win32 access. Recent examples include the redesigned File Explorer Properties dialog and the rewritten Win + R Run dialog.

Microsoft reportedly built the new Run dialog using .NET AOT technology, achieving a median launch time of roughly 94 milliseconds. According to the company, the updated implementation can now match or even exceed the responsiveness of older Win32-based components.

The shift suggests Microsoft no longer views Win32 as aging technology waiting to disappear. Instead, the company increasingly appears to treat it as the permanent foundation of Windows moving forward.

マイクロソフトはネイティブアプリへの回帰を強めているようだ。

マイクロソフトは現在、Win32の強みを放棄することなくWindowsの近代化に注力しているように見える。プラットフォームを完全に置き換えるのではなく、新しいUIフレームワークとネイティブデスクトップのパフォーマンスおよび互換性を融合させようとしているようだ。

同社はWinUI 3とWindowsアプリSDKへの投資を継続しつつ、従来のWin32アクセスも維持している。最近の例としては、再設計されたファイルエクスプローラーのプロパティダイアログや、書き直されたWin + Rキーの「ファイル名を指定して実行」ダイアログが挙げられる。

マイクロソフトは、新しい「ファイル名を指定して実行」ダイアログを.NET AOTテクノロジーで構築し、平均起動時間を約94ミリ秒に短縮したと報じられている。同社によれば、この改良された実装は、従来のWin32ベースのコンポーネントと同等、あるいはそれ以上の応答性を実現しているという。

この変化は、マイクロソフトがもはやWin32をいずれ消滅する時代遅れのテクノロジーとは見なしていないことを示唆している。むしろ、同社はWin32を今後のWindowsの永続的な基盤として捉えつつあるようだ。

Win32 apiはWin95よりも前にExcelアプリを作る際にExcelだけでは役不足だったので使ったよ
つまり1993年とか1994年とかあたりでね

確かCOMとかembeddingとかいう言葉をその時知った
その時のembeddingが埋め込みだったから
最近のgen aiのvector embeddingも2023年くらいには埋め込みです！って訳してるやつ多かったが
こっちのembeddingは表現変換だよね
ベクターへの数値表現変換

ちゃんと動く事が分かっている安心して使えるものは貴重だよ
それに比べて、最近のiPhone 付属のメモアプリは動作が不安定で恐ろしくて使えない

そんなこと言ったらAppleのMac OSだって
1990年代のNEXT時代の遺産じゃね

ほい
次のxenospectrumネタは
Atoms and bitsだぞ
atomはoil とかフィジカルもんのタンジブル
bitsはinformationでロジカルもんデジタルもんのインタンジブル

その間をつなぐのがセミコンダクタでAIデータセンターという視点

共有ライブラリが紹介された時、ライブラリのバグ直すと
いっぺんに全実行体がバグフィックスされて便利です！
とか言われてたけど、結局未検証はいかんということになって
共有ライブラリ（DLLね）もバージョン指定で使うようになって、
結局手間と煩雑さは同じになった、のはいいとして、
よくそれを今まで管理してるとは思う

＞インターネットが商業化される以前の1990年代に書かれたコードである。

えっ？
この著者どこの世界線から来たの？
windows95ってインターネット接続簡単にするのが売りだっただろ
windows3.1からもう商業利用が当たり前になってたぞ？

今日本中で動いてる原発炉はPC98で制御してる
シリアルポートの関係らしく

>>23
Visual C++ redistributable を何個も入れなきゃいけないし、32bit版と64bit版があって訳分からないよね。
ってか、全部システムに組み込んどけよと思う。

>>21
NEXTStepもだけど、
DarwinはBSDの系譜やね

>>1
常識だと思ったw
うざいアップデートに続き、俺がWindowsをやめた理由は正しくそれだ。ソフトウェアアーキテクチャと作り込みが雑すぎる。設定アプリを細かくチェックすれば､Windows10､7、95などのウィンドウやシステムアプリが普通に出てくる。慣れればいいという問題じゃない。Windowsだけのクソ仕様を使い続ける理由はない。

>>18
Win32s懐かしい

エクスプローラーの不具合多すぎる
これもIEに対するchromeみたいなのそろそろ出てきそう

記事にある例えばWPFってWin32APIの代替というよりはもっと上位層のフレームワークだよね

個人的にはもしwin32APIが置き換わるとしたら全く新しいWindowsが登場してwin32サブシステムは新Windows上で動作するエミュレーションとして動くものになる→何世代か経って徐々に廃止
って感じだと思うね

情弱性の塊

一応互換性維持してるんだから95のコードが残ってて当たり前やん

OSのAPIが古いなんて言い出したらMacのCocoaだってNeXT時代のを引きずってるぞ
中身のない記事

>>24
少なくとも日本では90年代に入らないと郵政省が公専接続認めてないんじゃね？
それ以前は学術機関での利用はあっても商用利用はこれより後かと

>>35
1993年商用利用可しかし会社とかのみ
1994年商用プロバイダ可ここから一般利用が進む

1993年以前は外資系は日本国内専用線だがそこからアメリカに接続されればインターネットは当然つかえた

日本では電話回線で接続するUUCPでのメール交換とか
NetNews これはcompとかaltとか掲示板の始まり

1990年ごろには雑誌SuperAsciiとかがインターネットを紹介
それはUnixワークステーションが使われてそこではtcp/ipがあたりまえだったからローカルでイーサネットでTCPIPはその頃から使われてたわけだよ

外の接続は専用線だけでなくX.25パケットが使えるようになっていた

日本の一般はパソコン通信だったが
アメリカはパソコン通信でもインターネット対応していたから
日本からAOLとかCompuServとか電話かけて繋いであっちを使うというのもアリだった

>>34
アップル50周年のプレイベントをコンピュータミュージアムが主催
その館長がアップル創業期だったから思い入れ強くて
いちばん長い勤務してるクリスエスピノーサ、あのジョンスカリー、そしてNeXTのアビーテバニアン
Machカーネル実装した本人
でネクストからアップルに来た時アップルのみんなはどんな感じだった？聞かれて、アビーはさまざまだよ
喜んだひとも多かった
しかし今やってるプロジェクトをネクストに対応させろと言われて慌ててたひともいるみたいに
でどうしたの？
やれ！

https://youtu.be/eCSNJgI2LFI

>>38
クリスエスピノーサはジョブズの家の道路挟んで向かい側だったからとか最年少で15だかから仕事したとか
カルフォルニア工科大学は働きながらだとか
英語よくわかんないけどそんなこと言ってた
たまたまの運でいちばん長く在籍してる社員
ジョブズ辞めても辞めなかったわけだ

>>33
残っててあたりまえという話ではなく
そっちがまだまだ大役果たしてるという話だよ

>>36
DosベースのFIDOnetっていうのがあってパソコンオタクに近い人たちがやってた
自宅からやる
でシニアと新人が実は入る前からの知り合い繋がってたりする釣りキチ三平みたいな話もあった

>>6
絶対不具合でるww

>>15
ひとえにマイクソンフトの悪行のせいということだな

まだCOBOLでやってます
みたいなもんか

>>18
お前はアタオカだな…

>>21
そんなマイナーOSはどうでも良いし

>>46
Macをマイナーいうのは奴隷レベル
研究者レベルはなぜかMacBook Proばかり

互換性を保つためだろ

まあそうだろうな

>>47
それはアップルがタダでばら撒いてるから、
貰った研究者は全員がLinux入れてる

勝手にUIバンバン変えていってそのたびに動作が遅くなる
昔のファイルエクスプローラーくらいのレスポンスに戻せよ

>>51
好きなバージョンのエクスプローラを入れたら良いぞ

たぶんすぐ後悔するけどな

昔のゲーム動くかな

昔のフォトショ（LE）が動かないのが困る

新しいコードで書き直したら、アップデートのたびにデータ破損を引き起こすんだろ？

新しけりゃ良いってもんじゃない
枯れたコードこそ良いコード

メニューが上から下に表示されるのではなく途中に割り込んで伸びてズレて行くの止めろ
伸び切る前に選んでしまい選んだのとズレて選択されるメニューって使いにくすぎる

さっさとRustにいこうすろ

>>2
ちがうよ
DOS上で動いてると言えるのは3.ｘまで
95以後は互換性確保のために16bitコードが残っていたがファイルIO含めて基本的に32bit化されてる

日本で作られたOS、ptosのベースは何だったのかな。
NECだった？

レジストリで見てWindowsNTのカレントバージョンのとこに書き込まれてるあたりの制御か
確かにもう何十年も同じとこ触ってるわ

>>58
Win386からのDOSにDOSエクステンダー被せて32bitDOSにしたのだよ
DOSは16bitだけってのが違う

>>61
32bitDOSw
ひょっとしてロングファイルネームのサポートを32bit化と思い込んでるのかな

UIをWindowsXPに戻せ
黙ってセキュリティ対策だけシコシコやってろ

>>59
ソードのPIPSという言語は良かった
東芝になりまたソード

Wikipediaに
PIPSはIBMなど他のハードウエアメーカーからもオファーがあったが、ソードは自社ハードのみの販売に固執。その結果、1984年にOAブームによる深刻な半導体不足が発生すると、自社で部品調達ができなかったソードはパソコンを生産できず、1984年上半期にはパソコンの受注残高が20億円に上った。また、この直前に社員を大幅に増やし、工場を増設していたことが仇となり、PIPSの足を引っ張って業績は悪化した[2]。1985年、業務提携の形で実質東芝に売却

半導体不足か

95にしろ何にしろ、どうせ日本企業には永遠に作れないレベルだから関係ない

WebView2コンポーネントがChromiumベースなもんで、
何かを表示するたびにネイティブでないブラウザを起動しているようなもので
遅いわ重いわメモリ食うわでひどい
フレームワークも山ほどあってカオス

AndroidみたいにあんまりよろしくなかったAPIは非推奨にして何世代かしたら使えなくすればいいくね

結局Webだけじゃあ限界あるのよ
PCならまだしもモバイルなんて20年経っても無理
ジョブズもてんで見当違いだったとすぐ気付いてAppStore公開に舵取りし直したからな
最近はまたプログレッシブだの何だのでチョロチョロ動きあったけど結局変わらず
PCネイティブなら別にARMでもWin32APIでもどうでもいいし誰も気にしない

>>61
それがWin95だと思ってんのかよ！w

当時は富士通FM townsってDOSエクステンダーで32bit化
したDOSマシンが有ったりした
VCPIってシングルタスクな仕様のDOSエクステンダーを使ってた
32bitDOSで32bitで動いてたパソコン

Windowsでは更にマルチタスク対応なDPMI仕様のDOSエクステンダーを使って32bitマルチタスクなDOSとしてた
Windowsを外してDOSとDOSエクステンダーとだけにしても32bitDOSアプリケーションが使える
NT系ではその32bitDOSとして使えない

>>71
お前ページ切り替えでメモリ上限突破を32bitと思ってるのか…？

しかしここで素人疑問
>>1はコードがそのまま使われているような書き方になってる

これはWin32APIの名前とその使い方を継続しているだけでそれをコールする側もコールされて動く側もコードとしては別モノなんじゃないの？

>>72
ページ切り替えって何？townsは普通に32bitアプリが動いてたが

軽くて安定的に動くなら問題ない
セキュリティだけしっかりやってくれ

枯れたコードでも不可欠であればイイじゃん
レガシーっていうヤツ

>>58
AMD64の64ビットモードだと、その16ビットコードが動かないだろうな。
上記で問題視してる部分はフル32ビットコードなんだろうけど。

C言語でラージメモリモデル選べば32bitDOSアプリだよな

あの頃だと普通にgccが使えるかどうかって大違いな部分だったからな
日本以外ではDOSエスクテンダーがPCゲームに使われるくらい普及しだしてた

あの不具合の多さだと Me じゃないのーー？

Windows NT 4.0のときにWindows95からUI部分持ってきて統合したからな
そんときのコードが残ってるんだろう

ファイル右クリックはオブジェクト指向OSの要だからな
OLE2の基幹部分だ

今のスタート右クリックでの機能駄列や
「Windowツール」みたいな汚部屋は見たくもない

>>82
もしもし
ファイル右クリックはGUI操作部分でそのオブジェクトとはGUIプログラミングレベルでのオブジェクトの話
オペレーティングシステムに入れるかどうかは別
Linuxなら完全に別もの

OLE2とはアプリケーションレベルで別アプリ同士がどうリンクし合うか埋め込め合えるかでアプリの話
アプリプログラミングがGUI含めて標準作ってないとそうはなれないだけ
アプリのプログラミング標準とその実行環境サポート
OSをアプリサポートまで入れるならOSというだけで

オブジェクトという話も多面的でこれはオブジェクトプログラミング的なGUIプログラミングとその実行環境

オペレーティングシステムのオブジェクトではないね
ネクストの方がそれだから

WindowsがアップルのGUIをDOS上に構築したあと
こんどはネクスト的なオブジェクト的アプリ構築をとりいれただけで

最初の時点ではDOSで動いていたんだから
オブジェクト指向OSじゃないよ

COMの歴史

1991年、COMの前身であるOLEが、OLE 1としてWindows 3.1とともに公開された。
1992年、OLE 2が公開された。IUnknownインタフェースなど、のちにCOMと改称される要素の多くがOLE 2で登場した。
1994年、OCXもしくはOLEコントロールがVBXコントロールの後継として紹介される。それと同時に、OLEは、もはや単なる頭文字ではなく、コンポーネント技術を表す用語となった。
1996年初頭、マイクロソフトは、OLEのうちでインターネットと関連のあるいくつかの技術をActiveXとして名称変更した。やがて、OLEとして公開されていた技術がActiveXに統合され始める。
1997年、マイクロソフトは再びコンポーネントを使用するこれらの技術の改称を行い、Component Object Modelとした。

OLE?
貼り付けたエクセルが速攻でクラッシュしたな
再現率100％で

>>73
当然、部分的に変更はあるが全体的に同じコードなんだろう。

あれか、これじゃ困ると生成AIにコード書き直させたら、
何か仕込まれて最終的に人類が滅ぶやつだな

メニュー周りはすごく苦労したと言われてたな
ショートカットとの兼ね合いもありめんどくさかったみたいだ

人間と細菌のDNAに共通部分があるようなものか

そのおかげで今でも古いアプリが動く

APがハメ殺し状態のWindowsだと中小サッシ屋が路頭に迷う

windowsはいい加減イベントドリブンからタイミングドリブンに変更してくれ
プログラム作るの邪魔くさくて仕方がない

>>1
なんですとw
てか、右クリックメニューだけじゃなくて新旧共通の動作って山ほどあるもんな
驚くことのほどでもなかったか

>>9
内部スクリプトでまだVBSとか残ってるんじゃね

どこから突っ込めば良いか分からないww

コンピュータは、今でもエジソンの時代の電気で動いている。

>>2
カーネルの話とミドルウェアの話を混同してる

こんなのWindowsにある程度詳しくて知らない人の方が珍しい
三十数年前は予想しなかったと言ってるだけで

それより驚いたのがsysinternalsの創設者が
Azure最高技術責任者になってたって事

>>34
酷いAPIだよね