Category Archives: Windows

VB6 コモンコントロールダウンロード

ダウンロードの詳細 : Microsoft Visual Basic 6.0 コモン コントロール

このパッケージをインストールすると、mscomctl.ocx および comctl32.ocx の 2 つの Visual Basic 6.0 コモン コントロールが更新され、このページの「関連リソース」セクションに表示されているサポート技術情報の記事に記載された問題を解決できます。

以下の不具合点の改善とのこと
FIX: コンパイルされたアプリケーション Visual Studio IDE が突然終了し、 Visual Studio 6.0 SP6 の ListView コントロールの列を並べ替えるとき、「 0xC0000004 が 0 で除算する」エラー メッセージを表示します。
FIX: Windows 2000 またはしばらく Comctl32.ocx の違反にアクセスします。
FIX: アプリケーションまたは Visual Basic 6 IDE が突然終了するのにアプリケーション Windows 一般的 コントロール Mscomctl.ocx、 Comctl32.ocx と、 Visual Basic 6 IDE を発生、または「 分割で ゼロ」エラー メッセージを表示することがあります。

なぜPDFではだめなのか

マイクロソフトの「Metro」はPDFキラーになるか – CNET Japan

「本当の問題は、PDFの代わりにわざわざMetroを使う理由があるのかということだ」(Gartenberg)

たぶんその理由はPDFがXMLではないからだ。
個人的には、ドキュメントイメージデータがPDFと言うかPostscriptに全て修練されるのは空恐ろしい物も感じるので、オルタナティブな何かがあっても良いと思う。

Visual Studio 2005 Beta2 MFC気づきメモ

デバッグ時VS2003で混合モードと呼んでいたアセンブラのウインドウは「逆アセンブル」と言う名称に代わっている。
AfxMessageBox()で以下のような書き方だとcharの配列が変換できないとコンパイルエラーになってしまう。
AfxMessageBox(“エラーだよ!”);
以下のようにするとOK
CString s1(“エラーだよ”);
AfxMessageBox(s1);
ちなみに
CString s1 = “Hoge”;
もコンパイルエラーになります。
なんでや!
ちなみに製品のフィードバックってどこでするのでしたっけ?

Windows Graphic Faundation

The Future of Windows’ Graphics Technology Review by ExtremeTech
Longhornでのグラフィック周りのソフトウェアブロックが上で説明されています。

この記事によると、Longhornの基本はWindows Graphic Faundation(WGF)1.0と言うDirectX9.0ベースの新しいAPIを持っており、その後DirectX10になると思われていた次世代の3DグラフィックエンジンがWGF2.0として登場するようです。そして、このブロック図ではAvaronはこのWGF1.0のすぐ上に実装される形になるので、思っていたよりマネージドとアンマネージドとの境界の厚みは薄そうですね。
また、これらのグラフィックエンジンが使用するグラフィックドライバはLonghorn Display Driver Model(LDDM)と言う新しいドライバモデルにより実装された物となるようです。今回のWinHECビルドのLonghornではAeroの一部効果が特定のグラフィックチップでしか動作しなかったようですが、このドライバモデルの変更が影響しているのではないかと思います。
しかし、こうなると、気になるのがWinXP/Win2KでのAvaronの実装方法で、今のOSではLDDMに基づいたグラフィックドライバは動作しないでしょうから、Avaron以下のレイヤとAvaronとのひも付けは別の方法で行うことになるはずで、そのときのパフォーマンスだとか、制限等が気になりますね。(たぶんDX9のAPIの上にWGF1.0の互換レイヤを挟んでAvaronを実装するのでしょうけど。)
元ネタは:さすらいの.NETプログラマーさん。多謝。
Longhorn Graphics

64bit Windows

64bit版Windows「Windows XP Professional x64 Edition」登場 – 清水理史の「イニシャルB」
普通のユーザーにとって、64bitネイティブなアプリケーションが登場するまでは、正直あんまり意味がない状態だと思う。ちょうどdaytona(Windows NT 3.5)が登場したときと状況は似ていると思う。あのときも32bitアプリケーションなんて皆無なのに何で32bitアプリケーションが必要なんだと言われていたっけ。
そこで、個人的バイアスも含めて64bit化されるであろうデスクトップアプリケーションを羅列してみよう。(まさにGWひま企画だ!)
Adobe Photoshop
Adobe Illustrator
Adobe Premedia
Adobe Indesigne
Autocad
Mathmatica
Matlab
Visual Studio
Microsoft Office
Java VM
ということで、Adobeのデザイン関係は一通り64bit化される可能性は高いでしょう。特に大容量メモリの貢献を一番受けやすい分野です。Autocadも順当に対応してくるでしょうね。ここには書いてませんが各CADメーカも対応してくるでしょ。これもメモリが多いことの恩恵を受けやすい所です。
さて、Officeですがこれはもうフラグシップとして出さないわけにはいかないんじゃないのと言うことであげて見ました。VisualStudioは願望って言うか、やはり出さないのはおかしいでしょ。

Norton Internet Securityステステ

Norton Internet Security 2005があまりにも見にくく頻繁にExplorerを道連れに死んでくれるので、思い切って削除して、Windows Firewall + Microsoft AntiSpyWare(B1) + AVG Freeと言う組み合わせに変更した。
取りあえず今のところ問題も無し。使用リソースや余計なフックも減少したらしく意外とより快適に。

Longhorn Build5048 あれこれ。

本田雅一の「週刊モバイル通信」
Longhorn Build5048 あれこれ。
何となく、まだグラフィック表示に関する部分は変更がありそうな感じ。この記事に書かれたような構成だと、AvaronがLonghornネイティブのグラフィックエンジンとどれくらいタイトに結びつけられるのか疑問があるなぁ。逆にネイティブのグラフィックエンジンであるMILに対するプログラミング環境がどのように用意されるんだろう。従来ここはAvaronオンリーだったと思うのですけど、ただのWin32APIなのだろうか。
取りあえず、Beta1, PDCビルドが出てくるまではまだまだ流動的かなぁと思う。

Longhornとは何であるのか。

名無し#さんのblog中さんのblogにもあるように、今回のWinHECで公開されたビルドはWinFX無しという物でした。WinHECがハードウェア技術者向けのイベントだと言うことを割り引いてもかなり後退した感が否めません。このままLonghornが製品化されるのであれば、これは普通のWindowsのバージョンアップにすぎないような気がします。少なくとも2003年のPDCで約束された「革新」ではありません。
WinHECで登場したLonghornが示しているのは、マイクロソフトの.netに対する姿勢の変化を示した物なのでしょうか、それとも単にLonghornの開発の遅れを示しているだけのでしょうか。
今年はマイクロソフトの大きなカンファレンスがあと2回、TechEdとPDCが残されているので、注目していきたいと思います。