随着计算机技术的快速发展，许多旧的16位Windows应用程序已经无法在最新的操作系统上直接运行。然而，对于一些仍然依赖这些旧程序的用户来说，找到一种方法来运行这些应用程序变得非常重要。本文将介绍如何使用OTVDM（也称为winevdm）来实现这一点。OTVDM基于WINE，是一个完全开源的解决方案，它的代码库可以在这里找到，详细的使用说明可以在这里找到。通过OTVDM，只需要将最喜欢的程序的完整路径传递给OTVDM可执行文件，就可以在现代计算机上运行16位Windows应用程序。
例如，可以通过以下命令来运行程序：
c:\otvdm\otvdm.exe "c:\pathto\your16bit.exe"
或者，也可以在桌面上创建一个指向OTVDM的快捷方式，然后将应用程序的可执行文件拖到这个快捷方式上，这将有效地执行相同的命令，而不会显示OTVDM控制台窗口。
第一次测试是在Windows 11上通过OTVDM安装并运行Visual Basic 3.0，整个过程非常顺利。安装完成后，可以通过将C:\VB\VB.EXE拖到OTVDM可执行文件上来启动VB3（桌面快捷方式不起作用）。还有一个控制台窗口（如果需要，可以最小化），它会显示来自OTVDM的警告/错误消息。
Visual Basic 3.0的帮助系统最初使用的是Windows帮助（.HLP）格式，按下F1键会打开VB.HLP文件。从Windows 8或更高版本开始，微软移除了对.HLP文件的支持，但如果需要，仍然可以从微软网站下载组件（WINHLP32.EXE）。OTVDM也包含了这个文件，并且会将所有打开.HLP文件的请求路由到这个可执行文件。如果按下F1键对不起作用，并且使用的是Windows 10或11，可以尝试这个指南。无论如何，可以直接打开.HLP文件来查找相关主题。
为了避免与当前Windows安装发生冲突，OTVDM有自己的WINDOWS\SYSTEM和WINDOWS\SYSTEM32文件夹，任何读取/写入Windows系统文件的请求都将被路由到这个目录。如果想要运行的软件抱怨缺少DLL，尝试将所需的DLL复制到这些目录，而不是Windows系统目录。
例如，Windows 3.1中的多媒体应用程序MPLAYER.EXE也可以工作，并且能够播放C:\WINDOWS\MEDIA文件夹中的.WAV文件。Word for Windows 2.0也可以很好地工作，并且能够打开旧文档。尽管必须说，真的没有理由在OTVDM上运行Word 2.0，因为最新的Microsoft Office版本（Office 2021）仍然可以打开Word 2.0文档并保持原始格式（除了OLE对象，如方程式或宏）。潜在地，只有在处理古董格式，如Word for DOS时，才需要运行Word 2.0。但再说一次，尝试打开不是Word for Windows 2.0或富文本格式的文档将会失败，并出现错误“Word无法启动转换器WORDDOS.CNV”（或使用的转换器名称）。尝试将相关的.CNV文件复制到OTVDM Windows目录，但这并没有帮助。所以想，处理这些格式的唯一方法就是安装一个合适的虚拟机。
通过OTVDM，Word能够看到主机上可用的打印机列表，并且可以正常打印到Foxit PDF打印机。在Borland C 3.1中，也尝试运行了一个测试程序，该程序要求用户输入一个数字，然后将其打印回来。这可以工作，但有点尴尬：除了启动OTVDM的控制台窗口外，BCW还启动了另一个控制台窗口。C程序的默认输出（通过printf或cout的stdout）将显示在OTVDM控制台窗口上，而默认输入流（通过scanf或cin的stdin）仍然在BCW控制台窗口上。在上面的测试程序中，需要在BCW控制台窗口中输入输入，并从OTVDM控制台窗口中查看输出。调试任何这样的控制台应用程序都将是一个麻烦。如果应用程序主要是图形，并且只使用控制台窗口来记录消息，事情仍然可以足够好地工作。但再说一次，如果Borland C是最喜欢的编译器，绝对应该尝试Borland Turbo C++ 4.5，它是一个32位应用程序，可以在没有OTVDM的情况下本地运行。
Borland Pascal for Windows没有这样的问题，stdin/stdout仍然在BPW控制台窗口上。OTVDM控制台窗口中唯一的错误消息“SReg Load: segment is not a data segment or readable code segment”似乎并不影响操作。如果遇到运行时错误104（文件未打开用于输入）或105（文件未打开用于输出），请确保在代码的开头添加uses WinCRT；。显然，如果没有WinCRT单元初始化代码，控制台窗口将不会被初始化，writeln/readln将会失败。如果仍然有错误，请确保从控制台窗口使用OTVDM启动BPW，而不是通过拖动快捷方式（这不会创建OTVDM控制台窗口）。如果问题仍然存在，也尝试以管理员身份运行OTVDM。
Windows 1.0的记事本也可以正常工作。这是一张文档显示的截图，以及一个模态文件打开对话框：注意到对话框似乎正确地显示和处理长文件名——位于长名称目录下的文件可以被打开。Windows 1.0是在1985年发布的，当时LFN（长文件名）还有几年的时间。那么这里发生了什么呢？Visual Basic 3.0的打开文件对话框，为Windows 3.1构建，不支持OTVDM下的LFN（正如预期的那样）。然而，1992年设计的BPW 7.0可以在OTVDM下显示和打开具有LFN的文件。进一步研究后，意识到如果一个程序使用了VB 3.0的DirListBox控件，那么LFN将会被正确显示。如果一个具有LFN的文件后来使用标准的Windows API（例如，通过OpenFile）访问，那么API（由OTVDM模拟）将自动和透明地处理这些LFN，应用程序只需要操作从API返回的句柄值。然而，如果一个应用程序使用公共对话框API（COMMONDLG）显示打开文件（或保存文件）对话框，那么这些对话框可能支持LFN，也可能不支持，这取决于这些应用程序最初是针对哪个版本的COMMONDLG库构建的。如果具有LFN的文件的完整路径太长，超过了应用程序分配的缓冲区，那么就会发生内存问题。到目前为止，还没有遇到知名应用程序的这样的问题，一旦显示了长文件名，似乎就被正确处理了。