My understanding is that yes, the no 16-bit execution limitation is because of AMD's implementation, not Microsoft's.

Ahh, that's what I was looking for: it's specifically Virtual 8086 Mode that is not available in x84-64 Long mode, due to AMD's decision.
http://en.wikipedia.org/wiki/Virtual_8086_mode

In the meantime I stumbled upon this Sourceforge project, but like so many projects there seems to be no recent development and the homepage link is dead. 😒

mr_bigmouth_502 wrote:

I thought one of Wine's main features was being able to run older programs on newer systems. 😜

Have you tried running older Windows 95 era apps in Wine lately? Try running MS Office 95. One big reason, At least on an 64bit systems, is that Wine has the same problems as Windows, it can't do 16bit natively, and many older programs have installers and some bits that are 16bit.

Jorpho wrote:

In the meantime I stumbled upon this Sourceforge project, but like so many projects there seems to be no recent development and the homepage link is dead. 😒

You would also need to have an x64 version of WOW for 16-bit Win apps.

Wine on a 32-bit OS or 64-bit? The project originally targeted the Win16 API and didn't seem to use V86 mode. Didn't realize they dropped Win16 support in later revisions. I know Sun's WABI doesn't use V86 mode under Linux. Aside from really old Windows 1.x/2.x apps, I think all Win16 apps run in 16-bit protected mode and have no need for V86 mode.

According to http://en.wikipedia.org/wiki/Virtual_DOS_machine and http://en.wikipedia.org/wiki/Windows_on_Windows , NTVDM is also used to run 16-bit Windows applications.

Wine and WABI run on *NIX, so no NTVDM. Originally Windows 3.x relied on a DOS extender to access memory above the 1MB limit and use protected mode on both the 286 and 386 CPUs. That tradition was carried over to NT in 1993, likely for compatibility reasons and to avoid an extensive rewrite of the Windows 3.1x 16-bit libraries.

Jorpho wrote:

According to http://en.wikipedia.org/wiki/Virtual_DOS_machine and http://en.wikipedia.org/wiki/Windows_on_Windows , NTVDM is also used to run 16-bit Windows applications.

Which is why I said that you would also need WOW.

On a side note, I was aware of the need for both to run 16-bit Win apps early on when I was moving from 9x to the NT kernel. Until Vista x86, the Windows version of KQ6 would not run on any NT flavor of Windows. It would launch WOW, but not the NTVDM and the game window was never painted. Since this was before ScummVM supporting SCI and DOSBox was too primitive to install Win3x. My solution was to replace the Windows LNK with a batch file that I used VDMS to start. This started NTVDM before WOW and allowed the game to start.

collector wrote:

In all of this discussion, it might be worth noting another approach. Danoon was experimenting with adding parts of WINE into his Java port of DOSBox with some success. Before anyone gets too fixated on the Java part of it, think of what might be possible with normal DOSBox or the DOSBox-X branch. I think this could be the best solution. Danoon has managed to get Full Tilt! Pinball and the Caesar 3 demo in jDOSBox without Windows being installed in it first. The goal should be to get Windows games to run without a copy of Windows.

Java Port

Implementing parts of WINE code in DOSBox sounds like a very promising project, I wonder if there is actually any possibility of (non-Java) DOSBox builds with this feature in near future?

I would love to see this. Unfortunately, Danoon is the only one that is looking into it that I know of. I have brought this up before, but most could not see past the Java and dismissed it altogether. I love jDOSBox for its ability to be embedded in a webpage, but see Java as too limiting beyond that. This approach is also a solution for 16-bit Windows code on x64. There are 16-bit Windows games that like 9x better than 3x, so Win3x installed in DOSBox is not the best solution. It is also a no go for use with my installers as that would require distributing Win3x and Microsoft is aware of SHP.

collector wrote:

Unfortunately, Danoon is the only one that is looking into it that I know of.

This is really a weird thing - I mean, Windows support doesn't have to be included in the vanilla builds, but an SVN build with this functionality would be welcome by most parties that are interested in running Windows games.

Win3x installed in DOSBox is no solution because personally I don't have a copy of Win3x and I have no idea where to get one even if I wanted to. Microsoft is dropping XP support in near future, and there is no Virtual PC with WinXP mode for Win8 already (while PCs today come with a preinstalled Win8, not Win7), so running legacy Windows software becomes an even more important issue.

I have minimal programming skills and knowledge but fusing some of WINE functionality with DOSBox does seem like a very promising project, especially since WINE, to the best of my knowledge, is the only endeavour that has analysed Windows software specifications (well, there's ReactOS but it is my understanding that this was initially a WINE spin-off) and implemented them to successfully run many Windows programmes.

It wouldbe nice ti have at least a version of DOSBox thatis capable of running Win16 programmes.

The SVN build is the vanilla build. It's just the lastest version.

Integrating Wine with DOSBox to support Windows games doesn't fit with DOSbox goals.

While we are on the crazy pills It would be nice to have internal DX11.2 and WIndows 8.1 support in DOSBox. It isn't going to happen any time soon if ever thank god.

DOSBox is a emulator for DOS games and it's the best emulator of DOS games for a reason.

If wine was integrated with DOSBox it would either be as a fork of DOSBox or it would have to be done in a way where it doesn't compromise what DOSBox is about. DOS GAMES

DosFreak wrote:

The SVN build is the vanilla build. It's just the lastest version.

My fault, I meant enhanced SVN builds of course.

DosFreak wrote:

If wine was integrated with DOSBox it would either be as a fork of DOSBox

That's exactly what I meant.

MrFlibble wrote:

Win3x installed in DOSBox is no solution because personally I don't have a copy of Win3x and I have no idea where to get one even if I wanted to.

...Google?

Yes, of course that is not particularly legal, but MS clearly does not care particularly about 16-bit Windows anymore, and considering it is 20 years old, they are probably reasonable in doing so.

Jorpho wrote:

MrFlibble wrote:

Win3x installed in DOSBox is no solution because personally I don't have a copy of Win3x and I have no idea where to get one even if I wanted to.

...Google?

Yes, of course that is not particularly legal

This is not an acceptable method for me, if MS haven't bothered to release their old OS for free officially I don't want a pirated copy. I'd rather prefer something like FreeDOS instead, but so far it seems like there's nothing except WINE and ReactOS for Windows stuff.

Nor is it a solution for me. While I do own two legitimate copies of 3.11, I cannot distribute it within one of my installers.

No one was suggesting that DOSBox change its goals, but a fork or a new project based on DOSBox and WINE would be fantastic. Silliness of Win 8.1 aside, all that "WinBox" would have to cover is the Win3x to Win9x era. For anything later you can play around with compatibility settings or patches. What is left might have to wait for WINE for Windows.

collector wrote:

No one was suggesting that DOSBox change its goals, but a fork or a new project based on DOSBox and WINE would be fantastic. Silliness of Win 8.1 aside, all that "WinBox" would have to cover is the Win3x to Win9x era. For anything later you can play around with compatibility settings or patches. What is left might have to wait for WINE for Windows.

I completely agree.

However, it is also my understanding that fusing DOSBox with WINE is a lot of work from a programmer's standpoint, and apparently this has been the reason why Danoon stopped working on that.

Hopefully someone else with enough programming skills will step in and continue development in this direction?

MrFlibble wrote:

However, it is also my understanding that fusing DOSBox with WINE is a lot of work from a programmer's standpoint, and apparently this has been the reason why Danoon stopped working on that.

Exactly. I do not know if he gave it up or simply put it on the back burner. However, this really would be best built on top of regular DOSBox or possible the x-branch.

ReactOS should install in DOSBox+patches; therefore providing much of the code (functionality) from the Wine project (source: http://www.winehq.org/docs/wineusr-guide/alternatives).

Games compatible with ReactOS: http://old.reactos.org/compat/?show=list&cat=4

truth5678 wrote:

ReactOS should install in DOSBox+patches; therefore providing much of the code (functionality) from the Wine project (source: http://www.winehq.org/docs/wineusr-guide/alternatives).

Really? I can't recall reading if anyone has tried that yet.