LWN: Comments on "3.15 Merge window, part 2"

3.15 Merge window, part 2

ssokolow — Thu, 24 Apr 2014 14:13:32 +0000

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.

3.15 Merge window, part 2

dlang — Wed, 23 Apr 2014 21:25:17 +0000

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

mstefani — Wed, 23 Apr 2014 21:08:28 +0000

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

dlang — Wed, 23 Apr 2014 20:22:32 +0000

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

mstefani — Tue, 22 Apr 2014 09:36:32 +0000

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...

Resume time and ATA controllers powering up

magila — Sat, 19 Apr 2014 18:26:53 +0000

It looks like the driver was waiting for the power management command to complete which for hard drives means waiting for them to spin-up. The wait times of ~10 seconds and ~5 seconds are what I would expect it to take for a large 3/4 platter drive and a single platter drive to spin-up respectively.

Resume time and ATA controllers powering up

giraffedata — Sat, 19 Apr 2014 17:53:02 +0000

It takes 10 seconds for the ATA controllers to power up and get into a working state? What are they doing? And there are multiple ATA controllers?

3.15 Merge window, part 2

dlang — Sat, 19 Apr 2014 04:33:41 +0000

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

lkundrak — Fri, 18 Apr 2014 06:58:31 +0000

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

viiru — Thu, 17 Apr 2014 19:22:50 +0000

> 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

cesarb — Thu, 17 Apr 2014 18:04:33 +0000

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

djbw — Thu, 17 Apr 2014 16:25:12 +0000

Correction, the async resume patches were championed by Todd Brandt. I (Dan Williams) just did some reworks to get the code accepted upstream. Anyone interested in the details should take a look at the data from Todd's AnalyzeSuspend tool:

https://01.org/suspendresume/blogs/tebrandt/2013/hard-dis...

3.15 Merge window, part 2

mstefani — Thu, 17 Apr 2014 15:37:00 +0000

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

smorovic — Thu, 17 Apr 2014 13:58:50 +0000

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

DSMan195276 — Thu, 17 Apr 2014 11:55:05 +0000

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

intgr — Thu, 17 Apr 2014 10:57:37 +0000

> 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?