トライアル版から製品版への移行

弊社製品をご検討頂いているお客様から時々頂くご質問に、

「トライアル版（評価版）で検証した後、製品版に移行するにはどうするのか」
「トライアル版に製品版キー/シリアル番号を適用して製品にしたいがどうするのか」

というものがあります。

弊社のシステムでは、評価版を製品版キー/シリアル番号で制限解除する方法は採用しておりません。

製品版の setup.exe を実行し、インストール中に示される手順に従って再インストールして頂く形になります。この手順内で製品版のキーとシリアル番号を要求されますので、ここに入力することにより製品版のライセンスが登録されます。

既に評価版がインストールされている環境の場合、ライセンス情報はこの時点で製品版のものにより置換されます。

製品版 setup.exe は弊社公式サイトの http://www.nsoftware.com/download/ からダウンロードしていただけます。

IPDaemon のイベントとマルチスレッド

以前あったお問い合わせに、

「IPDaemon をメインフォームではないクラスで別スレッドで動作させているのだが、そのクラスに InvokeThrough してもイベントを受け取れない」

というものがありました。私もちょっと気になったので弊社技術者の回答をチェックしてみたところ、以下のような回答がなされていました。

「IPDaemon は非同期に動作するため、イベントは DoEventS() 呼び出しが行われるまで発生しない。これを解決するには、IPDaemon の DoEvents() をプログラムのループ内で明示的に呼び出すか、タイマーを使って (定期的に) DoEvents() を呼び出すようにすることで解決できる」

ちょっと面倒ではありますが、シングルスレッドでは動作していたプログラムをマルチスレッド化してイベントを受け取れなくなった場合はこれをお試しください。

インストール時の "key verification failed" エラー

弊社製品をインストールする際に、製品シリアル番号およびキーを入力すると

"key verification failed (xx)"

のようなエラーが表示されることがあります。これは、入力したデータが実行中のインストーラ (setup.exe) に適合しないものであった場合に発生します。(例: C++ Builder Edition のインストーラで C++ Edition のシリアル番号とキーを使用した、等。)

このエラーが発生した場合は、使用しているインストーラとシリアル番号およびキーが一致しているかどうかをご確認ください。

インストーラの情報は、インストーラ起動時に表示されるスプラッシュ画面をご参照ください。シリアル番号の種別は先頭4バイトで識別されます。

例)

IPN8 - IP*Works! V8 .NET Edition
IPJ8 - IP*Works! V8 Java Edition
ISN8 - IP*Works! SSL V8 .NET Edition
ISJ8 - IP*Works! SSL V8 Java Edition
IZN8 - IP*Works! ZIP V8 .NET Edition
IZJ8 - IP*Works! ZIP V8 Java Edition
IPA6 - IP*Works! V6 ActiveX Edition
ISC6 - IP*Works! SSL V6 C++ Edition

製品を正しくインストールしアクティブ化もしたはずなのに「アクティブ化が必要」と表示される

弊社製品の V6 (およびそれ以前) のライセンスを新しいマシンに移行したお客様から時々このお問い合わせを頂くことがあります。

これは、新しいマシンが 64bit Windows OS の場合に発生します。ライセンスのアクティブ化情報はレジストリに格納されますが、Windows システムの都合で 32bit OS の場合と 64bit OS の場合で格納先が異なるためです。

これに該当する場合は、アクティブ化キー取得ページの URL の末尾に &w64=1 （全て半角 ASCII 文字でアンパサンドに続けてダブリュー、数字の６、数字の４、等号、数字の１) というパラメータを追加してアクセスします。例えば IP*Works! V6 .NET Edition の場合通常の 32bit OS 時は

http://www.nsoftware.com/download/lic.aspx?prod=ipn6a

ですが、これを

http://www.nsoftware.com/download/lic.aspx?prod=ipn6a&w64=1

とすることで 64bit Windows OS 用のアクティブ化キーを取得することができます。

Windows 以外の OS での Zip 自己展開形式サポート

弊社 Zip の .NET Edition では自己展開形式ファイルの作成をサポートしています (ZipSFX コンポーネント)。

このコンポーネントが生成するのは Windows の .EXE ファイルであり、Windows 以外の OS ではご利用いただけません。

なお、「OS に依存せず専用ツールなしで Zip を展開したい」ということであれば、.jar 形式を採用することでこれに近いことを行えます。(ただし Java ランタイムは必要。)

.jar 形式は、java -jar コマンドで展開可能ですので、Java ランタイムがインストールされている環境であれば OS に依存することなくまた専用展開ツールなしでアーカイブの展開を行うことができます。

EndTransfer イベントについて

あるお客様から、EndTransfer イベントの発生タイミングに関するお問い合わせを頂きました。

その内容は

・EndTransfer イベントが発生するのは、データ転送終了直後なのか、転送に関わる処理が終わった直後なのか

というものです。例えば弊社 IMAP コンポーネントで FetchMessageText() や FetchMessagePart() を実行した際に、fetch されたデータのプロパティへの書き込みは EndTransfer イベントが発生した時点で 終了しているのかどうか、ということです。

弊社の製品仕様では、EndTransfer イベントはデータの受信が完了した直後に発生しています。そして受信データから取り出した情報の各種プロパティへのセットはその後行われます。

従って、

・EndTransfer イベントは純粋にサーバとクライアント間でデータの転送が終わった事をのみを意味する
・転送されたデータのプロパティへの反映は、EndTransfer イベント内では保障されていない

ということになります。FetchMessageText() や FetchMessagePart() から制御が戻った時点では全てのプロパティ処理は完了していますので、プロパティ参照はそれ以降に行う必要があります。

tar ファイルのファイル末尾データについて (補足)

過去の記事で、EOA (End-Of-Archive) について述べましたが、今回はこれに起因する互換性の問題について述べてみたいと思います。

先の記事では、tar ファイルはその歴史的経緯からブロック化書き込みを行う必要があり、アーカイブの実データサイズとファイルサイズは必ずしも一致しないことを述べました。

しかし、実運用上はファイルの EOF (End-Of-File) を検出した時点で EOA を読み取ったのと同等の処理をする処理系が多く、弊社の tar コンポーネントも既定値では EOA を付与しないようになっています。

しかし弊社へのお問い合わせを見ていると、この EOA が必須となっている tar 展開プログラムも存在しているようです。(WinRAR 3.71 等。)

このような場合に対処するために、弊社の tar コンポーネントには ExtraNullBytes という構成設定項目が用意されています。

tar.Config("ExtraNullBytes=1024")

上記を行うことにより、生成される tar アーカイブの末尾に 1024 個の NULL 文字 (0x00) から成るブロックが付与され、EOA として機能するようになります。