かつて、仮想マシンに古いバージョンのWindowsのコレクションがあり、ホストマシンとこれらの仮想マシン間でファイルを転送するには、共有フォルダーのサポートがWindows for Workgroupsでのみ表示されたため、フロッピーディスクを使用する必要がありました。
フロッピーを介したファイルの転送は遅くてノイズが多く、「仮想フロッピードライブ」を作成して通常どおりVMに接続できる仮想フロッピードライブドライバーを見つけたとき、私の興奮は際限がありませんでした。残念ながら、彼のプロジェクトに対する著者の関心は2005年に薄れ、2010年に彼のWebサイトと電子メールは存在しなくなりました。それ以来、Windowsの世界では多くの変更が行われています。
- 64ビットOSは広く使用されており、2005年にコンパイルされた32ビットドライバーをロードすることは不可能です。
- Vista SP1以降のWindowsは、ドライバーをロードするためにシステムの再起動を必要とするデジタル署名または退屈な操作のいずれかを必要とし始めました。
- Visual C ++ 6で記述されたプロジェクトは、自動変換後の最新バージョンのVisualStudioではビルドされません。
すでに2011年に、ReactOS開発者のメーリングリストは、放棄されたプロジェクトのサポートの提供について議論しました。しかし、作者自身の同意なしには、これは起こり得ず、その時までに作者は数年間生命の兆候を示していませんでした。同時に、あるAndriy G. Tereshchenkoが、失踪した作者のWebサイトのコピーを使用して非公式のミラーvfd.sourceforge.netを作成しました。ソースソースにはまだバージョン2005があり、このバージョンがWindows7以降では機能しないという苦情がまだあります。github.com/tyomitch/vfdで
VFDの開発を続けたいと思いました。あなたがVFD自体に無関心であるとしても、私の話はあなたがWindowsの下で他の放棄されたプロジェクトを「復活させる」のを助けることができます。
コンパイル
Visual Studio 2019は
vfd.dsw、構成プロジェクトを開いて最新の形式に変換することに同意します。しかし、変換は不完全であるため、変換されたプロジェクトはコンパイルを拒否します。
次の問題が見つかりました。
- メッセージコンパイラ（
mc $(InputName)）呼び出しが正しく変換されませんでしmc %(Filename)た-VS2019ではなくmc %(FullPath)。MC（$(InputName).hおよび$(InputName).rc）用に作成されたファイルの名前はまったく変換されません。VS2019では、とのように%(Filename).hなり%(Filename).rcます。 - リソースコンパイラ（
$(IntDir)\$(InputName).res）用に生成されたファイル名も変換されませんでした。VS2019では、次のようになります$(IntDir)\%(Filename).res。 <TargetName>デフォルト（$(ProjectName)）vfdからprojectvfdlibおよびvfdwinprojectvfdwinに変更する必要があります。そうしないと、ビルドlib.dllおよびを試行しgui.exeます。- zlibなしでVFDをコンパイルするには、定義
VFD_NO_ZLIBに追加するだけでなく、#include "zlib.h"サブを削除する必要があります#ifndef VFD_NO_ZLIB-何らかの理由で、作成者はこれを忘れていました。zlibstat.libから削除する必要があります<AdditionalDependencies>。
これらの修正後、32ビットバージョン
vfd.dllとvfdwin.exe; ただし、64ビットバージョンをビルドするには、さらに作業する必要があります。
x64への適応
まず、コード自体はx64と互換性がないため、置き換える必要があります
- すべて
DlgProcからBOOLへの戻りタイプINT_PTR。 - すべてのコール
GetWindowLong(GWL_USERDATA)へGetWindowLongPtr(GWLP_USERDATA)とはについて類似しているSetWindowLongとのためにDWL_MSGRESULTとDWL_USER。
次に、
$(Platform)VC6の時点ではプラットフォームが1つしか存在できなかったため、変換されたプロジェクトの設定では使用されません。したがって、32ビットファイルと64ビットファイルは同じディレクトリに収集しようとします。彼らの品種に、上で修正しなければならない$(IntDir)値<AssemblerListingLocation>、<PrecompiledHeaderOutputFile>、<ObjectFileName>、<ProgramDataBaseFileName>、<OutputFile>リンカーの場合は、$(TargetPath);に修正します。無駄なものを削除し、<AdditionalLibraryDirectories>プロジェクト間の依存関係を手動で追加<PostBuildEvent>し、コンパイルされたファイルをターゲットディレクトリに手動でコピーします。
第三に、
vfdwin64ビットのWindowsで実行しようとしたり、Windows 95/98 / Meで実行しようとしたりすることに積極的に抵抗します。これを停止するには、関数VfdIsValidPlatform()とその関数へのすべての参照を削除する必要があります。
ドライバーのダウンロード
私は手元にWindowsDDKを持っていないので
vfd.sys、特定のcritical0によってコンパイルされた64ビットのものを取り、尋ねましたダートライデン「古代中国の方法」で署名してください。このようなドライバーは、vfdwin管理者権限で起動するとロードされ、正常に動作します。これを常に行うには、リンクオプションを追加する必要があります<UACExecutionLevel>RequireAdministrator。
別の愛好家であるIgorLevickiは、ブログ投稿全体
vfd.sysをx64のコンパイルに捧げており、彼のバージョンは vfd.syscritical0よりも優れていると主張しています。ただし、自家製の証明書で署名されており、追加のジェスチャーがないと読み込まれません。自家製の証明書に加えて、野心的なIgor Levickiは、ドライバーファイルに彼自身と彼のブログについての言及を追加しました。critical0はそのようなナンセンスをしませんでした。
使用する
上記の変更に加えて、github.com / tyomitch / vfdのAboutウィンドウで長いデッドURLを置き換え、シェルの1つのバグを修正しました。これは、デバッグのコンパイル中にのみ目立ち
VfdGetLocalLinkます。関数は、タイプパラメータCHARを標準ライブラリのisalpha()行_ASSERTE(c >= -1 && c <= 255);に渡し、行にダンプします。最近のhabrapostで説明されているように、動作はisalpha()負の数に対して定義されていませんがCHAR、Windowsでは署名されているだけです。コンパイル中に141の警告が発行されるという事実から判断すると、コードにはまだそのようなバグがたくさんある可能性があります。だから私は自由な夜と関係があるでしょう。
準備ができたバイナリはgithub.com/tyomitch/vfd/tree/master/x64/Debugにあります