Windowsプログラミングの歴史を考えてみる。 [プログラミング]
Windowsをずーっと使っていたわけだけど、ずっと開発してきたわけではない。途中で興味がMac上か、Linux上に変わっていったのだが、それまでは仕事でVisual C++やVisual Basicで仕事をしてきた。まぁWindowsで普通にプログラミングしていたわけだ。
シェアに比べて、そんなにWindowsで動くプログラムが大事ではなかったのだが、なんにつけWindowsプログラミングが絡んできて手を入れないといけないことになることも少なくなかった。いわゆる嗜み的に身につけておくとつぶしが利くという事なんだけど、知らないと厳しい必要事項が多くて、簡単な残業どころで済む話ではなくなる。
大まかな流れを思い出してみると、
Win16 -> Win32API -> .NET framework
みたいな感じなのだろうか。Win64ってのもあるらしいが、基本的に64bitでのメモリなどのエクステンションが主だったみたいなので、特に書かなかった。基本的にWin32が大手を振っていた時代のプログラマです。Win16の頃のメモリ管理がどうかしている時期は知らないし、.NETは一番初めの頃に簡単に全体を見た程度で、細かくは今も知らないのだけれど、知識としてはどちらもそこそこは知っている。結局、どっちも必要なかったので、UNIX系の知識が増えてきたわけだけど、それでもクライアントOSがWindowsってのは普通の話で、Linuxに駆逐されることはなかった。
Windowsで多くのアプリケーションは、VBかVC++で作られていて、手を入れる場合はどちらの知識も必要だったりすることも少なくなかった。まぁVBは結構使ったけど、まともに勉強した覚えがない。大抵コピペで済ませていました。VBAとかもExcelなど（というかエクセル以外で見たことがない）を使う時にはとても便利でした。それが未だに引きずって、LibreOfficeやApache OpenOfficeに移行できない所も多いでしょう。WindowsRTなんかはマクロが実行できないらしいけど、そんなMSの製品なんか使う気になんてなんないよね。
今は.NET frameworkの動作環境を全部ガッツリ入れてしまうようになっているけれど、昔はHDDが今のように余裕があったわけじゃないので、VBなんかは部品のコンポーネントごとに入れていた気がする。よく使うコモンコントロールですら、いちいちOSごとに入れないといけないので、そこいらはインストーラを作るのが面倒で、VC++で作る意味も十分にあったのでした。
とはいえ、VC++にしてもMFCというクラスライブラリを使う場合は、ランタイムを入れなきゃダメなのはおんなじでした。大体、いろんなソフトを入れると勝手に入ることも多かったので、MFCで作っておけばわりと面倒な環境を整える作業をしなくてもいいのでした。MFCはWin32APIをクラスライブラリにして、VC++で使いやすくしていただけだったので、Win32を直接使っていれば、MFC用のライブラリも不要だったのですが、そこまで原始的な方法を採っている人は少なくて、否が応でもMFCの知識は必要なのでした。しかも、プログラミングの便利な部品としてのライブラリじゃなく、GUIの部品とコードを結びつけることぐらいしかできなくて、ビットマップの操作すら原始的なものしかなかったと思います。Borlandのライブラリだったら色々楽なんだろうな、と思った時期もありましたが、仕事に入ったら100%VC++だったので、無駄な苦労をしないで済んだのでした。
問題なのは、Win32が全部入れ込まれたライブラリじゃなく、結局、MFCを使ったクラスの中からナマのWin32APIを呼ぶしかない処理が多かったところだった。確かにGUIでC++プログラミングできるのは便利だったのだが、MFCだけを知っていればいいという訳にもいかなかった。そういうのが面倒なので、VBやVC++が初期の頃は、VBでインターフェイスを作って、VC++で作ったDLLを蹴るという方法も少なくなかったらしい。そこいらは補完的に使われていたり、仕事の切り分け的に使ったりしていたようだ。
VBにしても、少々面倒なだけでWin32APIを使うことはできた。動作が遅いみたいな話はあったんだけど、どっちにしてもGUIでもたついているのであれば、主要な処理をDLLを呼ぶにしても遅いのは変わらない気がしました。というか、VBは途中までインタプリタで動かしていたらしいから遅いという話があったんだけど、私が仕事で使う頃には大体EXEをコンパイルして作るようになっていたので（たぶん）、そんなに遅いことはなかったですね。全部VBで作ったほうが早いよなぁという事態になっている時も、VC++で作っていました。そもそも、スクラッチでアプリを作るという仕事があまりなかったし、僕としてはVBの文法が気持ち悪かったので、VC++を使っていただけなんですが、正直VBの方が手数が少ない場合もWebの資料も多かったので、仕事時間的には残業せずに終わってたからどっちでも良かったんだけど。
.NETがリリースされた時の黎明期に、C#の仕様を見て、SUNに指摘されて、Visual J++とかがすっ転んで、自社版のJavaが欲しかったんだなと思った。案外C#は健闘したみたいだけど、結局Javaプログラマの方が多くなったようだ。国の情報処理の試験にしても、Javaで受けられるという話は聞いたけど、C#で受けられるという話は聞いていない。
MSはC++をモディファイしたと言ってきた気がしたが、どう考えてもJavaの代替技術であることは明らかであった。その頃にはMSの色々な問題にうんざりしていて、Linuxが台頭してきたのでそっちにある程度移行してしまったところもある。少なくともサーバをWindowsにする必要はほぼなくなった。もちろん使えって言われたら使うけど、マシンパワーがかかるだけの話だ。
Javaに似ている点としては、中間コードを生成して、それをVMで実行させるところだ。オリジナル要素として、どの言語を使っても、吐き出される中間コードはだいたい同じであると言われていた。それじゃ言語を色々使う意味ないやん、って思ったけど、結局.NET frameworkに人を呼びこみたかっただけだと思われる。
LLVMとかが台頭してきていることを考えても、そういう流れを組み入れていたのは、MSとしては先んじていたのかもしれない。SUNのパクリが結果的に先進的だったのかもしれない。つーか、ゴスリングがすげーって話か。まぁemacsの話からするとクソッタレな野郎であることは間違いないんだけど。
その後もIronPythonやIronRubyなどで、スクリプト言語を無理矢理導入しようとしたり、AzureでPHPできるぜとか、OSSを使って姑息な真似をしていたようです。まぁMSらしいよね。あとガジェットとかもう無くすらしいけど、HTMLとJavaScriptで作れたんだったっけ？ それも今の時流に沿っている気がする。でも、そのガジェットもMacからパクってきたんだよね。そういうのはFirefoxの拡張機能のほうが先なんだっけ？ そこいらへんは曖昧。
最近はWindows 8で少しは開発も変わったんだろうけど、全く気にしてないな。どんな言語で開発できるか、.NETとどう絡んでくるかすらも知らない。もう興味が無い。とか言いながら調べた。.NET、ネイティブ（C++）、JavaScriptですか。
http://t.co/vLyOVbvtDx
Windowsではもう誰かがソフト作ってくれるの待つことしかしてないし。フリーソフトの出来も悪くない。もうWindows上に開発のモチベーションはないです。WebブラウザなどとSSHのクライアントマシンでしかないです。それに、そもそもWin8は持ってないしね。8.1もマシになるとされているけど、正直、魅力的なノートパソコンが出てくるまで待ちの状態であります。
正直、今使っているWin7のCULVマシンもSSDに換装して、パフォーマンス的に悪いってわけでもないし。ただ、なんとなくHaswellを使いたい気はしている。Haswellはガンガンに回すと消費電力は大して低くないよ、とか、GPUはそれなりにパワーアップしているけれど、CPUコアの方は大して性能が伸びてない、とか聞いています。でも、パソコンは放っておいた時間のほうが長いので、アイドル時の電力カットは非常に魅力的ではあります。パソコンが全体的に少消費電力になるのは悪くないことだと思います。筐体が熱くなりにくいというのもあるし、持ち運ぶ気になれるっていうのは行動範囲も広がるしね。
そんなわけで、ソフトは今の所Windows上では興味が無い。誰かが作ったものを使うのみですね。腑抜けたものだと思うけど、それだけ魅力がなくなったというわけで。それに、一人の力でなんとかなるプログラミングってのも限界はかなり見えているし、Windows自体がそういうツールを組み合わせて使うようには、UNIX系ほどにはなっていない所は、少しだけプログラミングして作業を改良しようという気にもならないわけで。
UNIX系もツールを導入するために、一からコンパイルするような苦労をすることは少なくなったので、そういう意味ではWindowsは逆にお手軽にできなくなったとも言える。GUIでMacの後追いをし、普及率で征したわけだけど、結局、わたし的にはMacの方が使いやすいOSになってしまったのでした。確かに使う人が多いので、選べるソフトも多いけれど、それだけにいくつかの中から選ばないといけないし、要らない心配が増える事も少なくない。必ずしもMacがいいという妄信的な信者ではないものの、公平に見てもWindowsはやっぱりビジネスマシンであることは間違いない。
そおいや、MacOSXはまだLionのままなんだよね。新しくマシンを新調しようとも思ったけど、MacBook Airは自分的には不発だったし、今度のAppleの発表はiPhone5Sか6になると思うから、その時はiPhone買うから金ないし。iPhoneはLTEもテザリングもしたいので、5の時点で買いたかったんだけど、4Sがあるのに5ってどんだけAppleが好きなんだよって話だし。というか、次のiPhoneのトピックって、前回のMB Air以上に無い気がするんだよね。IGZOにしてくれたらありがたいけど、今更っていう気もするし。大きさが変わるとか色が違うとかだったらもう終わってる。廉価版は必要な機能がなかったら意味ないし。前回のWWDCって目玉商品がMac Proだったし、しかも今年の終わり頃に発売でしょ。もうApple沈没するんじゃなかろうか。
さらにテザリングにしても、外でパソコンを使う用ってあんまりないんだよね。って、おいらは何をしようとしているのだろう。やっぱり、MacBook AirとiPhoneでテザリングってのが理想なんだよね。世の中上手く行かないもんだ。今更ながらMBAirのRetina化がなかったのが悔やまれる。Retina化してもすぐ買わず、値段が落ちてきてから買おう。最悪、10万円を切ったら買おう。アベノミクスとか言って、財布の紐が緩んじゃってる人がいますが、使いたい人はガンガン使ってください。少しでも金のめぐりを良くしないと景気は良くならないし。僕は来るべき時期のために貯めこんでおきます。とにかく、今はすぐに欲しいものがない。
シェアに比べて、そんなにWindowsで動くプログラムが大事ではなかったのだが、なんにつけWindowsプログラミングが絡んできて手を入れないといけないことになることも少なくなかった。いわゆる嗜み的に身につけておくとつぶしが利くという事なんだけど、知らないと厳しい必要事項が多くて、簡単な残業どころで済む話ではなくなる。
大まかな流れを思い出してみると、
Win16 -> Win32API -> .NET framework
みたいな感じなのだろうか。Win64ってのもあるらしいが、基本的に64bitでのメモリなどのエクステンションが主だったみたいなので、特に書かなかった。基本的にWin32が大手を振っていた時代のプログラマです。Win16の頃のメモリ管理がどうかしている時期は知らないし、.NETは一番初めの頃に簡単に全体を見た程度で、細かくは今も知らないのだけれど、知識としてはどちらもそこそこは知っている。結局、どっちも必要なかったので、UNIX系の知識が増えてきたわけだけど、それでもクライアントOSがWindowsってのは普通の話で、Linuxに駆逐されることはなかった。
Windowsで多くのアプリケーションは、VBかVC++で作られていて、手を入れる場合はどちらの知識も必要だったりすることも少なくなかった。まぁVBは結構使ったけど、まともに勉強した覚えがない。大抵コピペで済ませていました。VBAとかもExcelなど（というかエクセル以外で見たことがない）を使う時にはとても便利でした。それが未だに引きずって、LibreOfficeやApache OpenOfficeに移行できない所も多いでしょう。WindowsRTなんかはマクロが実行できないらしいけど、そんなMSの製品なんか使う気になんてなんないよね。
今は.NET frameworkの動作環境を全部ガッツリ入れてしまうようになっているけれど、昔はHDDが今のように余裕があったわけじゃないので、VBなんかは部品のコンポーネントごとに入れていた気がする。よく使うコモンコントロールですら、いちいちOSごとに入れないといけないので、そこいらはインストーラを作るのが面倒で、VC++で作る意味も十分にあったのでした。
とはいえ、VC++にしてもMFCというクラスライブラリを使う場合は、ランタイムを入れなきゃダメなのはおんなじでした。大体、いろんなソフトを入れると勝手に入ることも多かったので、MFCで作っておけばわりと面倒な環境を整える作業をしなくてもいいのでした。MFCはWin32APIをクラスライブラリにして、VC++で使いやすくしていただけだったので、Win32を直接使っていれば、MFC用のライブラリも不要だったのですが、そこまで原始的な方法を採っている人は少なくて、否が応でもMFCの知識は必要なのでした。しかも、プログラミングの便利な部品としてのライブラリじゃなく、GUIの部品とコードを結びつけることぐらいしかできなくて、ビットマップの操作すら原始的なものしかなかったと思います。Borlandのライブラリだったら色々楽なんだろうな、と思った時期もありましたが、仕事に入ったら100%VC++だったので、無駄な苦労をしないで済んだのでした。
問題なのは、Win32が全部入れ込まれたライブラリじゃなく、結局、MFCを使ったクラスの中からナマのWin32APIを呼ぶしかない処理が多かったところだった。確かにGUIでC++プログラミングできるのは便利だったのだが、MFCだけを知っていればいいという訳にもいかなかった。そういうのが面倒なので、VBやVC++が初期の頃は、VBでインターフェイスを作って、VC++で作ったDLLを蹴るという方法も少なくなかったらしい。そこいらは補完的に使われていたり、仕事の切り分け的に使ったりしていたようだ。
VBにしても、少々面倒なだけでWin32APIを使うことはできた。動作が遅いみたいな話はあったんだけど、どっちにしてもGUIでもたついているのであれば、主要な処理をDLLを呼ぶにしても遅いのは変わらない気がしました。というか、VBは途中までインタプリタで動かしていたらしいから遅いという話があったんだけど、私が仕事で使う頃には大体EXEをコンパイルして作るようになっていたので（たぶん）、そんなに遅いことはなかったですね。全部VBで作ったほうが早いよなぁという事態になっている時も、VC++で作っていました。そもそも、スクラッチでアプリを作るという仕事があまりなかったし、僕としてはVBの文法が気持ち悪かったので、VC++を使っていただけなんですが、正直VBの方が手数が少ない場合もWebの資料も多かったので、仕事時間的には残業せずに終わってたからどっちでも良かったんだけど。
.NETがリリースされた時の黎明期に、C#の仕様を見て、SUNに指摘されて、Visual J++とかがすっ転んで、自社版のJavaが欲しかったんだなと思った。案外C#は健闘したみたいだけど、結局Javaプログラマの方が多くなったようだ。国の情報処理の試験にしても、Javaで受けられるという話は聞いたけど、C#で受けられるという話は聞いていない。
MSはC++をモディファイしたと言ってきた気がしたが、どう考えてもJavaの代替技術であることは明らかであった。その頃にはMSの色々な問題にうんざりしていて、Linuxが台頭してきたのでそっちにある程度移行してしまったところもある。少なくともサーバをWindowsにする必要はほぼなくなった。もちろん使えって言われたら使うけど、マシンパワーがかかるだけの話だ。
Javaに似ている点としては、中間コードを生成して、それをVMで実行させるところだ。オリジナル要素として、どの言語を使っても、吐き出される中間コードはだいたい同じであると言われていた。それじゃ言語を色々使う意味ないやん、って思ったけど、結局.NET frameworkに人を呼びこみたかっただけだと思われる。
LLVMとかが台頭してきていることを考えても、そういう流れを組み入れていたのは、MSとしては先んじていたのかもしれない。SUNのパクリが結果的に先進的だったのかもしれない。つーか、ゴスリングがすげーって話か。まぁemacsの話からするとクソッタレな野郎であることは間違いないんだけど。
その後もIronPythonやIronRubyなどで、スクリプト言語を無理矢理導入しようとしたり、AzureでPHPできるぜとか、OSSを使って姑息な真似をしていたようです。まぁMSらしいよね。あとガジェットとかもう無くすらしいけど、HTMLとJavaScriptで作れたんだったっけ？ それも今の時流に沿っている気がする。でも、そのガジェットもMacからパクってきたんだよね。そういうのはFirefoxの拡張機能のほうが先なんだっけ？ そこいらへんは曖昧。
最近はWindows 8で少しは開発も変わったんだろうけど、全く気にしてないな。どんな言語で開発できるか、.NETとどう絡んでくるかすらも知らない。もう興味が無い。とか言いながら調べた。.NET、ネイティブ（C++）、JavaScriptですか。
http://t.co/vLyOVbvtDx
Windowsではもう誰かがソフト作ってくれるの待つことしかしてないし。フリーソフトの出来も悪くない。もうWindows上に開発のモチベーションはないです。WebブラウザなどとSSHのクライアントマシンでしかないです。それに、そもそもWin8は持ってないしね。8.1もマシになるとされているけど、正直、魅力的なノートパソコンが出てくるまで待ちの状態であります。
正直、今使っているWin7のCULVマシンもSSDに換装して、パフォーマンス的に悪いってわけでもないし。ただ、なんとなくHaswellを使いたい気はしている。Haswellはガンガンに回すと消費電力は大して低くないよ、とか、GPUはそれなりにパワーアップしているけれど、CPUコアの方は大して性能が伸びてない、とか聞いています。でも、パソコンは放っておいた時間のほうが長いので、アイドル時の電力カットは非常に魅力的ではあります。パソコンが全体的に少消費電力になるのは悪くないことだと思います。筐体が熱くなりにくいというのもあるし、持ち運ぶ気になれるっていうのは行動範囲も広がるしね。
そんなわけで、ソフトは今の所Windows上では興味が無い。誰かが作ったものを使うのみですね。腑抜けたものだと思うけど、それだけ魅力がなくなったというわけで。それに、一人の力でなんとかなるプログラミングってのも限界はかなり見えているし、Windows自体がそういうツールを組み合わせて使うようには、UNIX系ほどにはなっていない所は、少しだけプログラミングして作業を改良しようという気にもならないわけで。
UNIX系もツールを導入するために、一からコンパイルするような苦労をすることは少なくなったので、そういう意味ではWindowsは逆にお手軽にできなくなったとも言える。GUIでMacの後追いをし、普及率で征したわけだけど、結局、わたし的にはMacの方が使いやすいOSになってしまったのでした。確かに使う人が多いので、選べるソフトも多いけれど、それだけにいくつかの中から選ばないといけないし、要らない心配が増える事も少なくない。必ずしもMacがいいという妄信的な信者ではないものの、公平に見てもWindowsはやっぱりビジネスマシンであることは間違いない。
そおいや、MacOSXはまだLionのままなんだよね。新しくマシンを新調しようとも思ったけど、MacBook Airは自分的には不発だったし、今度のAppleの発表はiPhone5Sか6になると思うから、その時はiPhone買うから金ないし。iPhoneはLTEもテザリングもしたいので、5の時点で買いたかったんだけど、4Sがあるのに5ってどんだけAppleが好きなんだよって話だし。というか、次のiPhoneのトピックって、前回のMB Air以上に無い気がするんだよね。IGZOにしてくれたらありがたいけど、今更っていう気もするし。大きさが変わるとか色が違うとかだったらもう終わってる。廉価版は必要な機能がなかったら意味ないし。前回のWWDCって目玉商品がMac Proだったし、しかも今年の終わり頃に発売でしょ。もうApple沈没するんじゃなかろうか。
さらにテザリングにしても、外でパソコンを使う用ってあんまりないんだよね。って、おいらは何をしようとしているのだろう。やっぱり、MacBook AirとiPhoneでテザリングってのが理想なんだよね。世の中上手く行かないもんだ。今更ながらMBAirのRetina化がなかったのが悔やまれる。Retina化してもすぐ買わず、値段が落ちてきてから買おう。最悪、10万円を切ったら買おう。アベノミクスとか言って、財布の紐が緩んじゃってる人がいますが、使いたい人はガンガン使ってください。少しでも金のめぐりを良くしないと景気は良くならないし。僕は来るべき時期のために貯めこんでおきます。とにかく、今はすぐに欲しいものがない。
コメント 0