プログラムで自身のプログラムファイルを変更する方法について
ポケットうえだ
後日のバグ修正のために、プログラムの中に修正版のプログラムをコピーする
項目を設けましたが現場で失敗しました。
製作中は一度もコピーの失敗はなかったので変だなと調べたところ次の事
が判りました。
１．起動したプログラムは自身のコピーは可能
２．修正したプログラムファイルを起動したファイルに上書きは出来ないし、
自身のプログラムファイルを削除も出来ない。
まあ、考えて見れば当たり前のことかも知れないなと思いました。
プログラムファイルが変更できたら便利だけど、終了した時点でなかったり、
条件が異なったら困るだろうしね。（プログラム作成中はテストでは別ファイル
だから問題が起こらなかったは当たり前のことですが）
しょうがないので、運用で避けることにしました。つまり、修正したプログラムを
立ち上げて、自身のファイルを本来の位置にあるファイルに上書きすることに
コピーの方法は
１．本来の位置にあるファイルを削除（ファイルサイズが少なくなる場合に備えて
２．元ファイルを新ファイルに1バイトづつコピー
_read(hd1,moji,1); _write(hd2,moji,1); ファイル名は同一にする
３．作成後に元ファイル作成日を新ファイル作成日にコピー
何か別の方法があれば教えて下さい。
Imo
> 後日のバグ修正のために、プログラムの中に修正版のプログラムをコピーする
問題が発生したとき、デバッグ版のプログラムを 同じ名前で実行したい？？？
そんなのは、その時点でコピー／リネームすればいい話ではないのですか？
正式版のメニューに そんな機能含むこと自体ナンセンスなように思うのですが？
"ポケットうえだ" <@discussions.microsoft.com> wrote in message
news:FA621333-9A34-4AB6...@microsoft.com...
UETA, Shin-ichi
Imoさんも仰っていますけど、何を意図しているのか、ちょっと
理解しがたいですね...。
最近では自動アップデートを備えたアプリケーションが珍しく
ありませんけど、作り込むのはそれなりに大変ですよ。
ポケットうえだ wrote:
> １．起動したプログラムは自身のコピーは可能
> ２．修正したプログラムファイルを起動したファイルに上書きは出来ないし、
> 自身のプログラムファイルを削除も出来ない。
EXEファイルやDLLファイルは Memory-Mapped File という
仕組みを利用して仮想アドレス空間にロードされます。
ファイル全体が仮想メモリにコピーされるわけではありません。
必要なところだけが物理メモリにコピーされます。
ページング機構が物理メモリの内容をスワップアウトするとき、
それがEXEファイルやDLLファイルのものであればその原本
がすでにファイルとして存在しているので、スワップファイルを
消費する必要がない ― というわけです。
故に実行中のEXEファイルやDLLファイルは更新できません。
# プログラムが自分自身を削除したり書き換えたりするには
# いかにして Memory-Mapped File を解除するかがテーマ
# になります。
# いくつかの裏技がありますけど、... 面倒です（苦笑）
> しょうがないので、運用で避けることにしました。つまり、修正したプログラムを
> 立ち上げて、自身のファイルを本来の位置にあるファイルに上書きすることに
プログラムが自分自身を更新できない以上、別のプログラムで
更新するしかないでしょう。
更新機能を別のプログラムに分離した方がいいのでは?
あるいは、素直にインストーラ（MSIなど）を提供してもいいのでは?
VC6をお使いであれば Visual Studio Installer が提供されています。
Visual Studio 6.0 Installer
http://www.microsoft.com/downloads/details.aspx?FamilyID=5FBBC453-CD04-4562-A66E-5C21436E6F56&displaylang=ja
他にも、NSIS、Inno Setupなど、無償で手に入るツールがあるので
探してみては?
Nullsoft Scriptable Install System
http://nsis.sourceforge.net/
Inno Setup
http://www.jrsoftware.org/
Vector：ダウンロード Windows > プログラミング > インストーラ
http://www.vector.co.jp/vpack/filearea/win/prog/install/
--
植田システム設計事務所
Ueta System Design Studio
http://www.usdesign.jp/
植田真一
mailto:ue...@usdesign.jp
ポケットうえだ
回答ありがとうございます。
やはり出来ないのですね。やるとしたら、別プログラムを作り、そこからコピーを
行なう方法となりそうです。本体プログラムから別プログラムを呼び出し、そこから
コピーした上で改めて本体プログラムを呼び出すことに。
どうしてこんなやり方をするのか。理由は短時間で終えるためです。又改めて
インストールプログラムを行うとどうしても時間が掛かる印象を与えることを
避けるためです。
今回のプログラムはレジスタ用のプログラムです。営業時間中の空き時間を狙って
行なう必要があります。許される時間は３分程度でしょう。さもなければ
営業時間外に行なうことになります。あるユーザーでは８：００～０２：００が
営業時間です。とても、そこまでは付き合いきれないので営業時間内にさっと
変更することがどうしても要求されるのです。これがレジスタ用でなければ、
インストールプログラムで行なうつもりです。
ポケットうえだ
お手数をお掛けしました。
どうしてこんなやり方をするのか。理由は短時間で終えるためです。又改めて
インストールプログラムを行うとどうしても時間が掛かる印象を与えてしまうことに。
そうなると客先自身でやってくれなくなるでしょう。客先がパソコンに慣れているとは
限らないのです。
今回のプログラムはレジスタを操作しているので営業時間中の空き時間を狙って
行なう必要があります。許される時間は３分程度でしょう。
レジスタを止めないでプログラムを変更する必要があるのです。
ご理解下さい。
Imo
とは、キャッシュレジスタのプログラムですか？
了解しました。 確かに、時間をかけて入れ替え．．では困りますね。
ところで、 独断と、偏見で申し訳ありませんが。
私もWindowsの上でちょっとだけ仕事をしていますが、 お金の関係の仕事（Program）をWindowsの上で．．．．．．
かなり、セキュリティと機能を絞った Windowsなんでしょうか。
独断と、偏見で申し訳ありません。
"ポケットうえだ" <@discussions.microsoft.com> wrote in message
news:009356BA-BFC8-4F22...@microsoft.com...
UETA, Shin-ichi
ポケットうえだ wrote:
> 今回のプログラムはレジスタ用のプログラムです。営業時間中の空き時間を狙って
> 行なう必要があります。許される時間は３分程度でしょう。
たとえばMSIを使ったからといって、Officeのような巨大なアプリ
ケーションならともかく、時間がかかりすぎることはないと思います。
独自の更新プログラムを組んだからといって、必要とされる機能
はインストーラと大して変わらないと思いますけど...?
一度MSIを試してみては?
VSで作るMSIファイルはカスタマイズできる範囲が狭いですけど、
最低限のことはできるはずです。それで満足できなければ独自の
更新プログラムを検討すればいいような気がします。
ネット経由で自動アップデート ― くらいのことをするなら独自の
更新機能を持たせる意味はあるでしょうけど、単に時間短縮を
目的に自前の更新プログラムを作るのは何かが違うような...。
# 現場の担当者があまりPCに詳しくないとか、いろいろ事情は
# あろうかと思いますけど...。
ポケットうえだ
返信ありがとうございます。
> たとえばMSIを使ったからといって、Officeのような巨大なアプリ
> ケーションならともかく、時間がかかりすぎることはないと思います。
> 独自の更新プログラムを組んだからといって、必要とされる機能
> はインストーラと大して変わらないと思いますけど...?
そうですね。おしゃる通りだと思います。一般向のプログラムの場合は
そうしたいと思います。
> 一度MSIを試してみては?
> VSで作るMSIファイルはカスタマイズできる範囲が狭いですけど、
> 最低限のことはできるはずです。それで満足できなければ独自の
> 更新プログラムを検討すればいいような気がします。
はい、次のプログラムではそのような方針で行いたいと思います。
> # 現場の担当者があまりPCに詳しくないとか、いろいろ事情は
> # あろうかと思いますけど...。
そうなんです。原則として、使用者はパソコンとしての認識はありません。
レジスタとして操作しています。年齢も６０歳を超えるケースも多く、
キーボードアレルギーの方も多いです。そんな人が普段の画面と違う
インストール画面を見たら、恐怖におののくでしょう。だから、何気なく
そっと静かに普段の業務の中に行うことが肝心なんです。
ポケットうえだ
> かなり、セキュリティと機能を絞った Windowsなんでしょうか。
Windowｓは単なるOSとしてしか考えていません。ですから、OSとしたら
レジスタ用ではDOSプログラムの方が良いと考えます。専用機として、1プログラムの
OSと考えるとWindowｓは不利です。と言いますのは
レジスタで最も大切なのは高速処理ができることです。Windowsではどうしても
スピードが落ちます。又機器類がWindowsに合わせてCPUの処理速度が非常に
高速になっています。そうすると、当然発熱量が多くなり高温になります。レジスタは
営業開始から、営業終了まで動作中ですから、負担が大きいです。私の経験上
ハードディスクの耐用年数は４年です。４年で大抵壊れます。
ですから、CPUは出来るだけ低速で、ハードディスクは出来るだけ容量の小さい
もの、その他も同じです。これらは最近の機器の進展とまるで反対方向になります。
レジスタはLANを組む場合でも閉鎖システムです。NETにつなげることはしないのが
原則です。安全性を確保できないレジスタはレジスタではないと考えています。
考えても見て下さい。もし、故障で留まったら、店の会計はストップします。レジスタ
の前にお客様が長蛇の列を成します。クレームが技術部に殺到します。直るまで
催促の電話は鳴り止みません。担当者は針のむしろです。
実例を挙げますと、POSレジスタの出始めの時代のことです。プログラムの一部にバグがあり、コードをスキャンしたら何故か削除されるトラブルが発生したことがあります。
メーカーにクレームが行き、プログラムを修正することが出来たのは１週間後でした。
この間営業担当者は毎日その店舗に出向き、とにかく削除されたコードの再登録を
繰り返したそうです。実際の所あまり役立たなかったと思いますが、そうでもしないと
店の怒りを鎮めることができなかったのです。1週間で修正できたのは当時としては異例の早さでそれはそれでよかったのですが、ここに営業の立場と技術の立場の違いが
判るでしょう。
結論を言いますと、言葉上のセキュリティと機能よりも、実際にそのソフトを導入
されたお客の実態に合わせてやって行けばよい事ではないでしょうか。だから、特に
セキュリティがどうだとは考えません。そう言った発想はありません。
よろしいでしょうか。