winevdm: 16-bit Wine for 64-bit Windows

[JJ]

https://github.com/otya128/winevdm

The usual too-short official description:

[quote]
16-bit Windows (Windows 1.x, 2.x, 3.0, 3.1, etc.) on 64-bit Windows

An altered version of winevdm (a 16-bit Windows emulator), ported to 64-bit
Windows.
[/quote]

Note: author made a mistake. Wine is NOT an emulator. See first paragraph
below. Read the rest for general description about Wine.

https://en.wikipedia.org/wiki/Wine_(software)

Further description...

This project if a fork and Windows port of the 16-bit Windows support of
Wine which is (AFAIK) no longer maintained, and has been removed from
current version of Wine. When I tested it in Debian 8.9, it says:

wine: could not run L"A:\\WRITE.EXE": 16-bit/DOS support missing

I don't know if it's missing a library/package, or it's actually no longer
supported (anyone can shed some light?).

FYI, the trial version of Cross Over included in Ubuntu 16 still support
16-bit Windows. But Cross Over is not a full cross platform software (oh,
the irony), and it's not a freeware.

Anyway, this project aims to make 64-bit Windows able to run 16-bit Windows
applications without the oficial full blown 16-bit Microsoft Windows OS
installation such as Windows 3.x, Windows 9x/ME, or any 32-bit Windows. It's
exclusively for running 16-bit Windows application. It's not for running any
n-bit DOS programs. Wine is not for running DOS programs.

It works similar to how 32-bit Windows runs 16-bit Windows applications,
which is implemented as a subsystem (a compatibility layer). But likely
because a subsystem exist in the kernel and Microsoft provides ZERO
documentation regarding subsystem development, this project is implemented
as a user-mode application loader (making it runs slower). 16-bit Windows
applications will need to be run using an application loader
(otvdm.exe/otvdmw.exe). No system file needs to be replaced. It's not
applicable anyway. But if it needs to be automatically run as needed
(without having to run the loader manually), a persistent global/system-wide
setting needs to be modified.

Below screenshot is a demo of a view Windows 3.11 built in applications
running on 64-bit Windows 7.

https://i.imgur.com/JHMGnPh.png

The tool is not yet perfect and can be unstable at times, but pretty usable.
I haven't actually tested it yet, but it doesn't seem to be made
specifically for games. Just for productivity. 16-bit Windows games aren't
quite appealing anyway. But that's just me.

[John C.]

This is what I've been hoping would show up, the ability to run 16 bit
programs on 64-bit Windows 7. I have an old graphics program (Aldus
Photostyler 2.0) which had features I've been unable to find in newer
programs. If winevdm can get this program to work, that would be very nice.

Thanks for pointing this one out, JJ! 80)>

--
John C. BS206. No ad, CD, commercial, cripple, demo, nag, pirated,
share, spy, time-limited, trial or web wares for me please. I filter out
posts made from Google Groups and cross-posted (sent to more than one
newsgroup at a time) messages. I recommend you do likewise.

[MikeS]

I have been using this for a while and it works well. Anyone interested
may find this link helpful
http://www.columbia.edu/~em36/otvdm.html
It has additional information about usage and a Windows installer
(currently updated to the 3 May 2022 Github version).

[JJ]

On Wed, 10 Aug 2022 22:07:46 +0100, MikeS wrote:
>>
> I have been using this for a while and it works well. Anyone interested
> may find this link helpful
> http://www.columbia.edu/~em36/otvdm.html
> It has additional information about usage and a Windows installer
> (currently updated to the 3 May 2022 Github version).

Nice. Didn't realize that *that* site provides a more recent build.

And while I do use a UserScript to add a generic AppVeyor link to all GutHub
project page. I find AppVeyor confusing to navigate and to actually find an
artifact. And worse... there's not even a "help" link.

[MikeS]

You may be able to explain something that has puzzled me since I
discovered it by accident. As you say in your first post, 16-bit Windows
applications need to be run using an application loader
(otvdm.exe/otvdmw.exe). However, for some reason this is only needed the
very first time I run that 16 bit program. Subsequently its .exe file
will run directly like any modern Windows program. That is consistent
across several 64 bit Windows machines.

[JJ]

On Thu, 11 Aug 2022 21:45:42 +0100, MikeS wrote:
>>
> You may be able to explain something that has puzzled me since I
> discovered it by accident. As you say in your first post, 16-bit Windows
> applications need to be run using an application loader
> (otvdm.exe/otvdmw.exe). However, for some reason this is only needed the
> very first time I run that 16 bit program. Subsequently its .exe file
> will run directly like any modern Windows program. That is consistent
> across several 64 bit Windows machines.

That's true, I may not have been clear enough. The loader will only be
needed when a 16-bit application is run from 32/64-bit application.

When a 16-bit application is run using the loader, it's run in the loader's
process within a virtual 16-bit system. Just like how ntvdm.exe of 32-bit
Windows executes and manages 16-bit programs. If 16-bit application executes
another or different 16-bit application, there is no need to use the loader
again - as it's already in (virtual) 16-bit system. If a 16-bit program
executes a 32/64-bit application, the virtualizer handles it transparently.

Like 32-bit Windows' ntvdm.exe, when multiple 16-bit applications is running
within a loader's 16-bit virtual system, if one manage to crash the
virtualizer, all 16-bit applications within the virtual system would also
terminated abruptly.

And FYI, in 32-bit Windows, Task Manager can see 16-bit programs within each
ntvdm.exe. This is not possible with winevdm, since it's not an
implementation of a Windows standard 16-bit subsystem, so it doesn't have
any "VDM" API. It's just a non standard workaround to achieve what's needed.
It doesn't have the necessary API functions implemented. That being said,
implementing them would be a waste, since 64-bit Windows no longer have a
concept of 16-bit subsystem. So 64-bit Windows is not aware and can not
detect a 16-bit virtual system container process. The needed code simply no
longer there anymore.

The site you've given also mentioned ntvdmx64, which is based on OpenNT's
VDM instead of Wine.

http://www.columbia.edu/~em36/ntvdmx64.html

That project is a modified fork of Windows standard 16-bit subsystem (with
"VDM" API) but in form of user mode application. It's supposed to provide
support for both 16-bit DOS and Windows programs. But the 16-bit Windows
part seems not yet ready, as it also includes winevdm as a separate optional
installation and declares it as the 16-bit Windows support. But I couldn't
manage to get it to work for either DOS or 16-bit Windows program. With or
without installing winevdm.