32ビット用Visual Basic 4.0ソフト

質問

いつも、解答いただきありがとうございます。

　Windows8.1、NEC lavie 64ビットのノートパソコンを使用しています。
　従来は、WindowsXP　32ビットマシーンを使用していました。

　LETSCLIPと言うクリップのユーティリティプログラムを使用しています。

　プログラム内部で、VB4.0 Visual Basic 4.0を使用しています。マイクロソフトがサポートを終了していることを知っています。だからと言って使用できる範囲で使用することは、問題ないでしょう。動かなくなっても保証の限りで無いというだけです。

　64ビットの機械は、32ビットの上位互換があり、基本的には、32ビットのソフトも動くはずです。
　VB4.0 Visual Basic 4.0で必要になるライブラリーファイルを
C:\Windows\system32\
のフォルダに全て入れています。それなのに
　Windows8.1の元で、インストールしようとすると、
VB4.0 Visual Basic 4.0のライブラリーを引っ張ってこようとして、ここで、
VB4.0 Visual Basic 4.0のライブラリーを見つけることが出来ませんのエラーが出ます。

●(Q01)C:\Windows\system32\のフォルダの中にライブラリを入れておけば、どこのフォルダから実行しても、
最初の起動時にパスが切られているので、指定のライブラリファイルは、参照できるはずでは、無いのでしょうか？

●(Q02)　もし、それでも、参照できないと言うのであれば、起動したフォルダの中にライブラリをコピーして入れれば、インストール時と実行時にライブラリを参照して正しく実行できるのでしょうか？

　LETSCLIPと言うプログラムが、今では、ほとんどどこにも登録されてなく、サポートも終了していて64ビット版のプログラムを作り直してもらうことが困難なのです。

　32ビットバージョンのプログラムは、多く、64ビットバージョンに作り直されているようです。

●(Q03)　しかし、そのままのプログラムで、64ビットマシーンで動く場合も有るようです。これは、64ビットの機械が32ビットの上位互換で作られているせいでしょうか？

　敬具

回答No.3

noname#228894 · ベストアンサー

それはクリップボードを複数持てるようにするってものですよね？であれば、いまどきなOSに対応したソフトに乗り換えることを検討すべきでしょう。以下のように複数のものが出回っている状況で、古いフリーソフトにこだわり続けるのもどうかと思います。

http://s.freesoft-100.com/pasokon/clipboard.html

なお32bit版のWindows8ならば、古いWin16アプリ（Windows16と言うことではなく古典的な16bitのWindows3.1アプリと言う意味）でも動作することになっています。

64bit環境ではWOW64と言う機構により、32bitアプリの互換性を保っています。さすがにドライバやセキュリティ対策ソフトみたいなのを動かすのは無理ですが、一般アプリはほとんど動きますね。

お礼

randensai2さん、そして、みなさん、こんにちは、いつも回答ありがとうございます。

　多数のフリーソフトを紹介いただきありがとうございます。

　参考にさせていだきました。どのプログラムが良いのか?

　どう使うのか皆目見当がつきませんが、現在使用と類似していて使用しやすいもの信頼性の厚いソフトを選択したい。

　まずは、評価の高いソフトを選びます。

　印刷して勉強を始めました。

　敬具

回答No.4

parts

当該アプリケーションは、スナップショット関連のソフトでしょうか？それなら、Vista以降では厳しいでしょう。8で動く可能性は限りなく0に近いです。その理由は、後述しますけど、GDIリソース管理がもう原則としてないからです。

VB4.0系のアプリケーションは、WindowsXPでは確かに動く物も多いですけど、Vista以降の環境では32bit環境でも動かないものが多いですよ。理由は、管理者権限という概念がVB4.0/5.0以前にはないことと、そもそも同じWindowsでも中身が違うからです。VB6.0/.Netでもかなり苦しいといえます。

Q01については、System32にライブラリを入れてもHALとユーザーサービスやカーネルへの接続パスがなければ動作しません。当該プログラムはたぶん良くてWin32 VMベース、悪ければWin16 VMでしょうから、今まで動いていたのが幸運です。

Q02については、当該プログラム及びライブラリが相対パスか絶対パス設定かによります。元々絶対パスとしてsystem32を参照しているなら、プログラムグループの保存先においても意味はないでしょう。

Q03については、説明が難しいのですが、まずWindowsXPがVB4.0のアプリケーションライブラリをどのように参照するかという点から説明します。

WindowsXPでは基本的にVB4.0のライブラリを全てサポートしているとは言えません。これは、Windows9xとNT4.0までの製品をサポートしています。

そのため、厳密にはVB6.0以前なら動かないケースがあるのです。それに、32bitや16bitのコードというのは正確に言えば関係ありません。動かない物はどうやっても動かないと思ってください。ただ、それでは古いソフトは皆動かなくなります。文句を言われるでしょう。そこで、多少古い製品は動かせるように、エミュレーターのような機能で動かしているケースがあります。

では、動かないはずのソフトが何故動くのかというと、NTVDMとAppFixを介して仮想的にWin95またはWinNT4.0の環境を作るためです。要は、仮想的に9xやNT4.0のHAL（ハードウェアとOSまたはアプリケーションソフトウェアの間でデータの仲介をする機能）を生み出すのです。

XPでは、まだWindowsNT4.0が持っていた純粋なNTDOSのアーキテクチャを継承しており、その上にLunaデスクトップと、GDI/GDI+を実装していました。そのため、当該のアプリケーションは動くだけの機能がまだ生きていました。

当該のアプリケーションは調べた限りでは、たぶんGDIリソースを利用するアプリケーションと思われますが、純粋に同じGDIリソースを搭載するのはNT4.0とMEまでなのです。Windows2000以降では、GDI単体での動作はレガシー（遺産）となり、GDI+を拡張として実装した強化版となりました。この頃既にGDIはVB4.0が使われていた頃より進化していたのです。

そして、これらの管理をする場所へのアクセス権は、XP以降多くのセキュリティ脆弱性が見つかったことで、Vistaより後のバージョンにおいて、UAC（ユーザーアクセスコントロール）の制御化に置かれるようになりました。UACはセキュリティ上重要なコンポーネントへの参照や書き込みなどの権限を利用する際に、メッセージを表示するようになったのです。

Windows7ではそれが強化され、一部のコアへのアクセスはユーザーの認証の産むにかかわらず無効化されます。そして何より、Windows7以降はDirect Writeと呼ばれる機能でGDIは置き換えられました。（GDI+はレガシーとして一応生きていたが、VB6以前のコマンドのパスはほとんどが排除され、一部AIKリソースのみ生き残りました。）

ちなみに、Windows8系ではアクセス権をWindows7以上に強化し、NX-BitやSSE2もCPUに求めるなど、9x時代のリソースは全部削ぎ落としています。要は、GDIはもうありません。
そのため、それを利用するコンポーネントは、全て不正なコンポーネントや、不正なプログラムとして認識するようになったのです。

いかがでしょうか？

簡単に言えば、32bitだから動くのではありません。凄く端的に言えば、ローカル鉄道がVB4.0では使われていた、WindowsXPでは、そのローカル鉄道を高速化したり、線路を増やす処理がされた。しかし、それでは線路がもう持たない。修理して広げるにも安全性も十分に確保できない。これからもっと輸送は増えそうだとなった、そこでより安全で高速な別の路線（新幹線に対するリニアのようなもの）を作ったのです。そして、古い線は一定の時間を持って廃止された。と考えてください。

そんな状況で、古い切符の購入して乗りたがるのが、質問者様が動かそうとしているアプリケーションだと思ってください。切符に値するのが、当該のモジュール（COMまたはOCXかDLLライブラリかな？）です。そのモジュールもHALやKernelの仕様が変わっていれば、利用できませんから・・・。

まあ、Vistaの32bit辺りならAppfix（プログラムの互換性ウィザード）で使える可能性はまだあるかもしれませんが、7の32bitで動くかどうかは微妙です。

お礼

partsさん、そして、みなさん、こんにちは、いつも回答ありがとうございます。

　専門的な解説ありがとうございます。

　詳しくは、分かりにくかったですが、今後研究して行きたいと思います。

　サポートもできないとの開発者の答えなので、別のプログラムを探そうと考えています。

　上位互換でできるはずだとの考えが甘いと分かりました。

　皆具

回答No.2

yama1718

多分前の方の回答の通りでしょう、VB4は32bit版を使っていますと答えられると思いますが、VB4ではまだ32bit版でも、まだ16bitがサポートされていたのに甘えて内部的に16bit版のコードやAPIを使っている部分が残っているそうです。
完全に32bit化したのは確かVB5.0かVB6.0ぐらいからです、それでもWin7でも実行するのに一部支障があるそうですから。
上位互換と言っても実行コード(機械語)だけでは不十分で、WindowsのAPIなどのシステムも伴わないと、Windowsに関してはマイクロソフトは完全に上位互換とは言っていません、実際に時代遅れのAPIは廃止されたり新しいAPIに変わっていますから。
上位互換と言っても、新しいVBでのソースレベルの互換であったり、新しく変わった部分などはソースの変換でも上手くできずに手作業による移植作業が必要だったりします。
その為にWin7では古いソフトをより確実に実行させる手段としてXPモードという仮想環境まで提供していましたが、Win8ではもうサポートしていません。
http://answers.microsoft.com/ja-jp/windows/forum/windows_8-winapps/windows-8-%E3%81%A7-xp/faf457b0-6234-4023-ad4f-54d6d8a09c28?auth=1
どうしても古いソフトをそのまま実行したかったら、VirtualBOXやVMwareなどの他の仮想環境で動かすのが手っ取り早いでしょう。

お礼

yama1718さん、そして、みなさん、こんにちは、いつも回答ありがとうございます。

　詳しい解説ありがとうございます。
　やはり、新しいソフトを導入しようと考えています。

　敬具

回答No.1

Eureka_

そのアプリは知らないですが、64ビットWindowsは16ビットWindowsプログラムの実行ができません。
そのアプリが必要とするVB4.0ランタイムの中に16ビット版のものが存在するなら、そのアプリは64ビットWindowsでは実行できないということになりますが…

お礼

Eureka_さん、そして、みなさん、こんにちは、いつも回答ありがとうございます。

　VB4.0ランタイムの中に16ビット版のものが存在
　するらしいので、もはや、互換性が無いようですね。
　新しいソフトを探すのが良いなと思いました。
　作者に聞きましたが、もはや、開発環境が無いとの事です。