INASOFT 管理人のひとこと


フリーソフトダウンロードサイト「INASOFT」の管理人 矢吹拓也 が日々の「ひとこと」を語るページです。
2021年1月1日より、旧ブログ(blog.inasoft.org)からお引越ししました。
・INASOFT Webサイト: https://www.inasoft.org/
・管理人のふたこと(長文記事/寄稿文): https://www.inasoft.org/talk/
2022年7月下旬より再び本業多忙化してきているため、更新頻度は落ちます。 [2022/7/24 19:32]

目次 | ←前へ / 2014-08-24 00:00 / 次へ→ / 最新へ⇒

■だんだんといらなくなってくるLoadLibrary

2014年 8月24日(日) 0:00:00 [さくらのブログから転記]



RSSRSS配信中
https://www.inasoft.org/



以前、ソフトウェアを作成するときは、なるべく古い環境でも動作するように心がけている時期がありました。
以前にも書いたとおり、古い環境で動かし続けることこそが、ユーザから要求される至上命題みたいな感じだった時期がありまして。

ただ最近は、Windows XPのサポート終了が大きく報道された影響もあってか、むしろ古い環境で動かし続けないことに、理解が得られるようになってきたと思います。

Visual Studio 6.0 ~ .NET 2003 の Visual C++を用いてネイティブなプログラムを作成すると、Windows 95以降で動作するプログラムを作成することができます。
ただし、Windows 98とか、Windows 2000でしか存在しないAPIを使っている場合、プログラム開始時に、

  • 該当APIの入っているDLLを探し、
  • DLLの中の関数リストからAPIの名前を探し、
  • その関数へのポインタを取得する。
という動きが発生します。該当DLLがなかったり、該当する関数名がなかったりした場合は、プログラム開始時の時点で、OSによりエラーダイアログが出力され、プログラムの実行開始に至れません。

winme_rnsf7.png

▲Windows Meで、最新の「いじくるつくーる」を動かそうとした場合

例えば、Windows 2000では、ウィンドウを半透明にするためのAPIが提供されていますが、Windows 95ではそれがサポートされていません。
もし、ウィンドウを半透明にするためのAPIを使うプログラムがあり、Windows 95で動作させようとすると、プログラム開始時点でエラーになってしまいます。

例え if文を使って、Windows 2000で動作しているときしか該当APIを呼び出さないような処理になっていたとしても、Windows 95では最初から動かなくなってしまいます。

もし、if文を使って、Windows 2000で動作しているときしか該当APIを呼び出さないような処理を実現したい場合は、上に書いたようなAPI関数へのポインタを取得する処理を、そのAPI呼び出しの直前まで遅延させなければなりません。
これを実現するためのAPIが、LoadLibrary() というAPIになります。


さて、それとは別に、Visual Studio自身の制限として、生成するプログラムが、古いWindowsで動かなくなる時がやってきます。

例えば、Visual Studio 2005のVisual C++で生成したネイティブなプログラムは、Windows 95では動作しません。
(実はちょっとした回避策はあったりするのですが、制作元であるマイクロソフトのサポート対象外であることは変わりません)

Visual Studio 2008のVisual C++で生成したネイティブなプログラムは、Windows 95/98/Meでは動作しません。

Visual Studio 2010のVisual C++で生成したネイティブなプログラムは、Windows 95/98/Me/NT 4.0/2000では動作しません。

こんな感じで、Visual Studioのバージョンが上がって行くにつれて、古いOSは切り捨てられていきます。

私は、長い間 Visual Studio 2005を使っていましたが、Visual Studio 2010に買い換えました。この時点で、Windows 98/Me/NT 4.0/2000を一生懸命サポートする必要が無くなったわけですね。


話は戻りますが、昔は、ソフトウェアを作成するときは、なるべく古い環境でも動作するように心がけておりました。
そんなわけで、各OSの新しい機能を使いたい場合、それらは全て、LoadLibrary() API経由で呼び出すようにしていたため、プログラムがちょっとだけ複雑になっていました。
例えば、LoadLibrary() APIがエラーを起こしたときのエラー判定であったりとか、DLL自体が存在しない場合の処理であったりとか、とにかく、例外処理がたくさんでてきます。


さて、Windows 98/Me/NT 4.0/2000を一生懸命サポートする必要が無くなったことにより、そもそも LoadLibrary() API経由で一生懸命呼び出しをする努力自体が不要になりました。

というわけで、不要な LoadLibrary() API経由での呼び出し処理を一掃し、プログラムをスッキリさせたいと思います。
おそらく、ちょっとくらいはプログラムサイズが小さくなるでしょうし、ちょっとくらいは動作速度も速くなるかも知れません。




さて、話は変わります。
同じく、古いOSに引きずられている処理がありました。
いじくるつくーる」の各ダイアログのヘルプに使われている、リッチエディットコントロールです。

リッチエディットコントロールとは、通常の文字列を表示/入力するコントロールに、文字の大きさや色・太さなど、様々な修飾要素を表現できるようにしたものです。
ヘルプ表示にぴったりなため、「いじくるつくーる」の各ダイアログのヘルプに用いています。

リッチエディットコントロールを使うには、必ず、その機能を持っているDLLを読み込んでおかなければならないのですが、2種類のDLLが存在しています。

RICHED32.dll … リッチエディットコントロール 1.0
RICHED20.dll … リッチエディットコントロール 2.0以降

(Windows XP SP1以降で使える別のファイル名のものもありますが、いじくるつくーるは XP SPなし も動作対象となっているので、ここでは省略します)

これまでは、古いOSでの動作を考慮して、RICHED32.dllの方を使っていたのですが、そもそもRICHED32.dllにこだわる必要性はありませんから、RICHED20.dllの方を使うことにしたいと思います。
これを使うと、文字列中のURLに下線が引かれ、マウスでクリックすることでブラウザが呼び出されるような機能を簡単に構築することができるので。

rnhlurl.png


というわけで、最新の「いじくるつくーる」では、RICHED20.dll を使うようにしています。

rnsf7re.png

上記プログラムの下線部分が主な変更点。それ以外にも変更点はありますが、詳しくは公開されているソースコードを参照ということで。

同じようにして、URLに下線を引きたかった場所が、バージョン情報ダイアログです。

rnsfabout.png

従来は、URLとメールアドレスが左側に表示され、右側にそれっぽいボタンが表示され、ボタンを押すと、URLで示されたWebサイトを開いたり、メールを送信できたりする構成になっていました。

今回からは、ダイアログの一部をリッチエディットコントロールで作り、境界線を取り除き、背景を灰色(フォームと同じ色)にし、リンクを配置して、リンクをクリックすると、Webサイトを開くようにしています。

(ついでに、作者のメールアドレス変更に伴って、メールアドレスの直接表記は止め、メールアドレスを書いたWebページを開くような仕掛けに変更しています)

似たようなダイアログを採用する他のソフトウェアも同時に更新しています。

というわけで、作者の中で、リッチエディットコントロールがプチブームになっているというお話でした。

[参考]




目次 | ←前へ / 2014-08-24 00:00 / 次へ→ / 最新へ⇒


目次の表示:


ブログではないので、コメント機能とトラックバック機能は提供していません。ご質問・ご意見等はメールフィードバックまたはTwitter等からお願いします。いただいたご質問・ご意見などは、この「管理人のひとこと」の記事に追加、あるいは新規の記事にする形で一部または全文をそのまま、あるいは加工させていただいた上で、ご紹介させていただく場合があります。
当サイトでは掲載内容による不具合等に関する責任を持ちません。また、内容の正確性についての保証もありませんので、情報をご利用の際は、利用者の自己責任で確認をお願いします。本ページは公開から1年半後の任意のタイミングで削除される予定です。


- 最近の更新 -



3213044 (+0108)[+0285]

Copyright© 2010-2024 INASOFT