3.15 Merge window, part 2

Posted Apr 17, 2014 10:57 UTC (Thu) by intgr (subscriber, #39733)
Parent article: 3.15 Merge window, part 2

> the x86 architecture will no longer allow the creation of 16-bit segments when running in the 64-bit mode

Would this affect DOS emulators like DOSBox?

3.15 Merge window, part 2

Posted Apr 17, 2014 11:55 UTC (Thu) by DSMan195276 (guest, #88396) [Link] (1 responses)

While you should check if you can to be sure, chances are no. DOSBox in particular does a full emulation of the CPU so it's more accurate at the cost of speed, and thus the 16-bit code never touches the CPU directly. I don't know of any emulators that actually attempt to run the 16-bit code directly on the hardware (it's unlikely that it would ever actually work if you tried that, all things considered).

At the same time, I'm no expert. If there is a program you're concerned about you could always ask and link them back to this article or the patch.

3.15 Merge window, part 2

Posted Apr 17, 2014 13:58 UTC (Thu) by smorovic (guest, #52892) [Link]

DOSEMU comes to mind. I think they used virtual 8086 mode (Windows 9X was also running DOS executables in this way, if I remember correctly). The virtual mode was available from 386 on, however it was anyway dropped from x86_64.

3.15 Merge window, part 2

Posted Apr 17, 2014 15:37 UTC (Thu) by mstefani (guest, #31644) [Link] (9 responses)

It isn't affecting DOSBox but it breaks Wine for 16-bit Windows apps:
https://lkml.org/lkml/2014/4/11/514
And it not only breaks those but it breaks some Win 32-bit apps too because prior to Win64 showing up a lot of installers where still 16-bit...

DOS apps on the other hand will continue to work just fine in Wine as it integrates with DOSBox to run those.

3.15 Merge window, part 2

Posted Apr 17, 2014 18:04 UTC (Thu) by cesarb (subscriber, #6266) [Link]

Clearly, what Wine needs is a "WinBox" to run 16-bit Windows code. Most of the emulation code can probably come from DOSBox.

3.15 Merge window, part 2

Posted Apr 17, 2014 19:22 UTC (Thu) by viiru (subscriber, #53129) [Link]

> And it not only breaks those but it breaks some Win 32-bit apps too
> because prior to Win64 showing up a lot of installers where still
> 16-bit...

Indeed. I saw a Windows XP machine once where the Win16 emulator wasn't working correctly. It was nearly unusable until reinstallation since almost nothing would install. The install wizards for 32-bit software were 16-bit for a surprisingly long time, making this a big problem for Wine users.

3.15 Merge window, part 2

Posted Apr 18, 2014 6:58 UTC (Fri) by lkundrak (subscriber, #43452) [Link] (5 responses)

Work is in progress that adds integration with QEMU to Wine. It's used to run x86 binaries on ARM, but maybe it could be used to run 16-bit x86 applications in x86 long mode too?

http://forum.winehq.org/viewtopic.php?f=2&t=17701
http://forum.xda-developers.com/showthread.php?t=1258506

3.15 Merge window, part 2

Posted Apr 19, 2014 4:33 UTC (Sat) by dlang (guest, #313) [Link] (4 responses)

is this going to be the typical "let's fork the project and put a full version in the wine source, and then let them diverge" approach? or are they doing something more sensible this time?

3.15 Merge window, part 2

Posted Apr 22, 2014 9:36 UTC (Tue) by mstefani (guest, #31644) [Link] (3 responses)

Hell no! Wine has so many external dependencies that importing them would be madness. And Wine needs only the qemu user space emulation for the application processes, the rest will run native. See page 8 on the slides from the FOSDEM presentation http://wiki.winehq.org/FOSDEM2014?action=AttachFile&d...

3.15 Merge window, part 2

Posted Apr 23, 2014 20:22 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

well, from prior posts they imported a complete ldap server, a complete DNS server and some others, so it would not be impossible for them to pull in a complete emulator.

3.15 Merge window, part 2

Posted Apr 23, 2014 21:08 UTC (Wed) by mstefani (guest, #31644) [Link] (1 responses)

Uh? Not sure where you got that info from but Wine has no DNS nor LDAP server, never had. And it always just linked to OpenLDAP, never imported its sources. The last "big" code import into Wine was libmpg and that was removed in 2009.

3.15 Merge window, part 2

Posted Apr 23, 2014 21:25 UTC (Wed) by dlang (guest, #313) [Link]

I thought there had been posts here talking about this very problem and how they were now working to undo some of this.

It's very possible that this happened before 2009.

3.15 Merge window, part 2

Posted Apr 24, 2014 14:13 UTC (Thu) by ssokolow (guest, #94568) [Link]

I NEED my Bricklayer. (I've tried cloning it using LTris and an MP3 of T-Maxx, but it's just not the same.)

I guess I'll stay on kernel 3.14 or lower until Wine comes up with a solution and undoes whatever regression broke it under post 1.2.x Wine versions then.