VOGONS


Boxedwine (Wine on multiple platforms)

Topic actions

Reply 60 of 184, by danoon

User metadata
Rank Member
Rank
Member

3Dmark 2001 is starting to run. It didn't fully install in the emulator, so I installed it on the PC and was able to run the emulator against that. Most of the benchmarks works.

Attachments

  • 3dmark01.jpg
    Filename
    3dmark01.jpg
    File size
    107.68 KiB
    Views
    3130 views
    File license
    Fair use/fair dealing exception

http://www.boxedwine.org/

Reply 61 of 184, by danoon

User metadata
Rank Member
Rank
Member

I was curious about Android and got BoxedWine to build on it. It's pretty cool to see it work, but it is also obvious it will need a better CPU core, the default normal core only gets a score of 3 on the MDK performance test on my Samsung S9, so maybe a 7MHz Pentium 😀

Attachments

  • android.jpg
    Filename
    android.jpg
    File size
    50.08 KiB
    Views
    3086 views
    File license
    Fair use/fair dealing exception

http://www.boxedwine.org/

Reply 62 of 184, by captain_koloth

User metadata
Rank Newbie
Rank
Newbie
danoon wrote:

I was curious about Android and got BoxedWine to build on it. It's pretty cool to see it work, but it is also obvious it will need a better CPU core, the default normal core only gets a score of 3 on the MDK performance test on my Samsung S9, so maybe a 7MHz Pentium 😀

Wow! Please keep working on this! You have no idea how much time I've wasted trying to get Win 9x games to run on Android (I can't quite articulate why but I have this dream of running Alpha Centauri on my phone). There are various QEMU-based Android applications out there that supposedly could be used for this, but they're all broken to the point of unusability in one form or another.

Reply 64 of 184, by danoon

User metadata
Rank Member
Rank
Member

captain_koloth: I'm still playing around with Android. I hope to have my faster CPU emulation for x64 running soon. But for ARM64, it could be a long while before I get something faster for that.

robertmo: Thanks, I didn't even notice that. I fixed the installer so that the next one I make will default to the 64-bit version of Program Files

http://www.boxedwine.org/

Reply 65 of 184, by Jo22

User metadata
Rank l33t++
Rank
l33t++
captain_koloth wrote:
danoon wrote:

I was curious about Android and got BoxedWine to build on it.
It's pretty cool to see it work, but it is also obvious it will need a better CPU core, the default normal core only gets a score
of 3 on the MDK performance test on my Samsung S9, so maybe a 7MHz Pentium 😀

Wow! Please keep working on this![..]

I think the same, great work so far! Considering this is the work of a single person is remarkable, IMHO. 😎
Once If I have got some free time, I'll do more games/application testing for Boxedwine again, too. 😀

captain_koloth wrote:

You have no idea how much time I've wasted trying to get Win 9x games to run on Android
(I can't quite articulate why but I have this dream of running Alpha Centauri on my phone).

Hey Captain, I wanted to play Solar Vengeance and Space Exploration Mission Alpha on a mobile device since ages, too. 😁
So far, I'm using some DOSBox and Windows 3.x, but it's not perfect since the mouse integration doesn't work so well.
The mice drivers of DOS and WIndows 3.x expect a relative mouse input (mouse moves), which doesn't work so nicely with a stylus.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 66 of 184, by leileilol

User metadata
Rank l33t++
Rank
l33t++

I just tried that september build out with my game that I don't want to show much of. I'm surprised how far this has come so quickly!

(Had to run this in Wine 1.7 instead of 4.0 for some reason. Also vertex shader extensions couldn't work, and there's no color control so the traditional q3 overbright technique doesn't work. but what mattered is that mouse worked and I won a match)

Attachments

  • boxedwineoacropped.png
    Filename
    boxedwineoacropped.png
    File size
    16.79 KiB
    Views
    2899 views
    File license
    Fair use/fair dealing exception

apsosig.png
long live PCem

Reply 67 of 184, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Greetings, dannon!

Congratulation on how things have improved so far, and I am truly amazed by your work on Boxedwine. It re-ignites the hope to see full-speed legacy Direct3D games on modern systems, particularly for games in Direct3D v3-v7 era which have been poorly supported by anything so far. Wine has been a thorn in my experience so far, as I couldn't get anything to work with its Direct3D implementation so far (even for a simple MS Direct3D Tunnel demo). So I didn't have so much hope on Wine, until I tried out Boxedwine 19R1.

I have a few questions and hope to get them clarfied, thanks!

  • How about CDROM support for games looking for CD? Can you provide command-line examples of how to mount CD for games to see it, and what if the game requires CD changing? For DOSBox/QEMU, since we use Daemon Tools within the OS to emulate CD-ROM, we can just have multiple CD-ROMs and mounted all the images before hand. The games are usually smart enough to scan the drive letter without prompting for CD change. This works for Descent Freespace.
  • I understand that the high-level architecture (correct me if I was wrong) that Boxedwine emulates Linux environment within a container to run Wine. How about using Boxedwine on Linux then? For Linux(host)<->Linux emulation container(Boxedwine)<->Wine<->Win32 games, would Boxedwine still be relevant on Linux host?
  • Would you mind providing a detailed build/compile guide to recreate the experience of Boxedwine entirely from source, including the different Wine engines that bundled with Boxedwine? Just the command-line portion is good enough, I am really not interested in the GUI overlay/front-end.

Finally, I wish you success in your project and supporting open-source.

Reply 68 of 184, by danoon

User metadata
Rank Member
Rank
Member
leileilol wrote:

I just tried that september build out with my game that I don't want to show much of. I'm surprised how far this has come so quickly!

(Had to run this in Wine 1.7 instead of 4.0 for some reason. Also vertex shader extensions couldn't work, and there's no color control so the traditional q3 overbright technique doesn't work. but what mattered is that mouse worked and I won a match)

Do you know what happened with the vertex shader? OpenGL is pass though, APIs that take simple arguments end up working well, but some APIs, especially ones that return pointers require marshaling from the 32-bit emulated environment to the 64-bit host. I made my best guess for most of the APIs, over 1000 of them, but very few of them have been well tested. Basically I got Quake 2 and 3 working and that was about it.

Is your game written in OpenGL or Direct3D?

The biggest difference I can think of between Wine 1.7 and Wine 4.0 is that the filesystem for Wine 1.7 has the DirectDrawRenderer key set to GDI. This means DirectDraw will be handled internal to Wine and in Wine 4.0 OpenGL will handle DirectDraw.

http://www.boxedwine.org/

Reply 69 of 184, by danoon

User metadata
Rank Member
Rank
Member
kjliew wrote:
Greetings, dannon! […]
Show full quote

Greetings, dannon!

Congratulation on how things have improved so far, and I am truly amazed by your work on Boxedwine. It re-ignites the hope to see full-speed legacy Direct3D games on modern systems, particularly for games in Direct3D v3-v7 era which have been poorly supported by anything so far. Wine has been a thorn in my experience so far, as I couldn't get anything to work with its Direct3D implementation so far (even for a simple MS Direct3D Tunnel demo). So I didn't have so much hope on Wine, until I tried out Boxedwine 19R1.

I have a few questions and hope to get them clarfied, thanks!

  • How about CDROM support for games looking for CD? Can you provide command-line examples of how to mount CD for games to see it, and what if the game requires CD changing? For DOSBox/QEMU, since we use Daemon Tools within the OS to emulate CD-ROM, we can just have multiple CD-ROMs and mounted all the images before hand. The games are usually smart enough to scan the drive letter without prompting for CD change. This works for Descent Freespace.
  • I understand that the high-level architecture (correct me if I was wrong) that Boxedwine emulates Linux environment within a container to run Wine. How about using Boxedwine on Linux then? For Linux(host)<->Linux emulation container(Boxedwine)<->Wine<->Win32 games, would Boxedwine still be relevant on Linux host?
  • Would you mind providing a detailed build/compile guide to recreate the experience of Boxedwine entirely from source, including the different Wine engines that bundled with Boxedwine? Just the command-line portion is good enough, I am really not interested in the GUI overlay/front-end.

Finally, I wish you success in your project and supporting open-source.

1) CDROM support is something that still needs to be done. Currently you can mount a directory/folder as a drive in Wine with this command line,

-mount_drive "c:\my games" d

2) Boxedwine runs on Linux, but it doesn't pass through any of the kernel commands, it still emulates all of them.

3a) Simple build documentation: http://www.boxedwine.org/documentation/build/

3b) As for building a new Wine version, that is pretty complicated and not documented. The hard part is keeping the file system size down by not pulling in every recommended dependency. BoxedWine implements its own winex11.drv so that X11 isn't required. Because of this if Wine changes WINE_GDI_DRIVER_VERSION, I will have to implement the new changes, currently I implement Wine 1.5.20 to Wine 4.5

version 46: // Dec 18, 2012, wine-1.5.20
version 47: // Sep 1, 2015, wine-1.7.51
version 48: // Feb 27, 2018 wine-3.3
version 49: NOT IMPLEMENTED Apr 9, 2019, wine-4.6
version 50: NOT IMPLEMENTED Jul 6, 2019 wine-4.12.1

If you build your own wine or use a pre compiled version, you will probably have to recompile winex11.drv, see cpp\tools\wineboxed.drv in the source code

If you want to compile your own version of Wine, for example Wine 4.0 to Wine 4.5 you can use the file system I have now for Wine 4.0 and just replace the wine files. That has a chance of working. If you create your own file system from scratch, including a newer version of libc, it is very likely that it will call linux kernel syscalls that have not been implemented yet.

This is not documentation for how to do this, but rather an rough overview: To create a file system from scratch, I unpacked all the .deb files for wine and all of Wine's dependencies, except X11 and a couple of others. I download the .deb files from debian.org. For Wine 4 I used http://http.us.debian.org/debian/dists/buster … 386/Packages.gz and ignored the following dependencies: libncurses, libpcap, libpulse, libtinfo, libudev, libvkd3d1, libx11, libxext, ocl-icd-libopencl, libopencl, libasound2, ucf, dpkg, perl, debconf. After all that I had to create a few files, like passwd, shadow, group, gshadow, resolv.conf

Basically it is bringing up a dist from scratch 😀

http://www.boxedwine.org/

Reply 70 of 184, by robertmo

User metadata
Rank l33t++
Rank
l33t++
kjliew wrote:

It re-ignites the hope to see full-speed legacy Direct3D games on modern systems, particularly for games in Direct3D v3-v7

As I understand it: Boxedwine can only be like an easier to use DOSBox, as it uses emulated CPU like DOSBox.

Reply 72 of 184, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:

As I understand it: Boxedwine can only be like an easier to use DOSBox, as it uses emulated CPU like DOSBox.

Based on the published results on Quake2 and Quake3, they are quite comparable to KVM/WHPX accelerated Win98SE guest on QEMU. The only difference I can see is Boxedwine use OpenGL pass-through while QEMU uses Glide pass-through. OpenGL pass-through does have performance advantages over Glide pass-through when I compared QEMU VirGL vs Glide pass-through on Linux host. I don't know how Boxedwine achieved such performance if it relies on full-fledged CPU emulation similar to DOSBox.

robertmo wrote:

How about using QEMU WHPX for cpu virtualisation? (it runs Linux VM on Windows pretty well)

That's the motive behind my question #2, if he finds ways to reduce emulation costs and pass-through or directly dispatch kernel commands to Linux host. However, on Windows QEMU has no OpenGL acceleration. You will need to run QEMU on Linux and Boxedwine can pass-through OpenGL to Linux VM and the VM then pass-through into Linux host. Assuming Wine can achieve 100% perfect Direct3D v3-v7 compatibility with OpenGL 3.2 (supported by QEMU VirGL), then this is in fact another viable approach for Direct3D retro-gaming.

IIRC, OpenGL 1.2 is somewhat equivalent for Direct3D v6. If Boxedwine/Wine engines can support Direct3D emulation through the deprecated, no longer maintained MESA FX (OpenGL 1.2 compliant), then at least Direct3D v3-v6 can be possible with acceleration from QEMU Windows through Glide pass-through.

Reply 73 of 184, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
danoon wrote:
1) CDROM support is something that still needs to be done. Currently you can mount a directory/folder as a drive in Wine with t […]
Show full quote

1) CDROM support is something that still needs to be done. Currently you can mount a directory/folder as a drive in Wine with this command line,

-mount_drive "c:\my games" d

AFAICR, this does not quite work out for Win32, unless you did the spoofing of GetDriveTypeA to fake a drive as CD-ROM in Wine. Games explicitly looking for CD-ROM as a mean of anti-piracy will always call the API to make sure it is a CD-ROM. If not, it will prompt for CD.

Anyway, I am looking forward to things getting improved, just to let you know.

Reply 74 of 184, by danoon

User metadata
Rank Member
Rank
Member
kjliew wrote:

I don't know how Boxedwine achieved such performance if it relies on full-fledged CPU emulation similar to DOSBox.

I think the CPU emulation is about 25% of the host, combined with OpenGL pass-though, it makes the games appear pretty fast. The x86 to x64 binary translator I wrote took about a year to write. I imagine I can still squeeze some more performance out it, but overall I'm pretty happy with it. It uses the host to manage flags and such, so an instruction, like adding two registers will remain untouched, so it stays pretty fast. The hard part is generating the code to handle segments. So something like mov eax, [fs:ecx+4] could be changed into 3 instruction. But the biggest hit is probably the loss of the host's branch prediction for the ret instruction. Current cpu's can predict call/ret pairs. But I emulate them as jmp's.

http://www.boxedwine.org/

Reply 75 of 184, by leileilol

User metadata
Rank l33t++
Rank
l33t++
danoon wrote:

Do you know what happened with the vertex shader?

Seems to ignore the presence of GL_ARB_vertex_shader despite explicitly passing that.

it's OpenGL 1.1 + optional 2.0 feature stuff. The fragment shader is only used to do gamma correction/overbrights.

apsosig.png
long live PCem

Reply 76 of 184, by vedmysh

User metadata
Rank Newbie
Rank
Newbie
Agathosdaimon wrote:

Oh okay thanks - i guess i would be looking for somethign that can run direct 3d - i am trying to get games like Jane's F/A-18, iF/1-18 and other late 90s, early 00s sims working

Well, Jane's F/A-18 currently runable with dxWnd+dgVoodoo without any additional (with some exception) compatibility patches and shims.

https://www.youtube.com/watch?v=dceUnaPFVuU&feature=youtu.be

But I can't say its in playable shape. Sometimes fps drop to ~3-5.
Also I made some modification to dgVoodoo wrapper. But this fix atm rough and shallow. I prefer to spend more time and do more research on the topic.
The only problem now - spare time 😢

Reply 77 of 184, by danoon

User metadata
Rank Member
Rank
Member
leileilol wrote:
danoon wrote:

Do you know what happened with the vertex shader?

Seems to ignore the presence of GL_ARB_vertex_shader despite explicitly passing that.

it's OpenGL 1.1 + optional 2.0 feature stuff. The fragment shader is only used to do gamma correction/overbrights.

I found an example using GL_ARB_vertex_shader here, the "Cel-shading" example:

http://www.humus.name/index.php?page=3D&ID=58

On my system it worked fine, but in Boxedwine it only showed a white screen. Turns out it was counting on a couple more extensions that my card supported, but I didn't return in Boxedwine. I added about 30 extensions that Boxedwine is capable of returning if the hardware supports it. Now that demo works in Boxedwine. Hopefully GL_ARB_fragment_shader will fix your issue. I put up a new build with the OpenGL extensions.

https://sourceforge.net/projects/boxedwine/fi … R1%20Alpha%201/

vedmysh: glad to hear that things are at least moving in the right direction.

http://www.boxedwine.org/

Reply 79 of 184, by CoolGamer

User metadata
Rank Member
Rank
Member

danoon,

Thanks for the Boxedwine project. It is amazing to be able to use the wine compatibility layer under Windows operating systems. I ran the Star Wars Racer demo under Boxedwine on my Windows 7 pc and it worked fine. Wine DirectX implementation has known issues with that game (missing fog, etc.), but the game runs.

I have a feature request. Is it possible to implement passthrough from boxedwine to host Windows system for DirectX? This way we can use directx wrappers such as dgVoodoo2 for old directx games (DirectX 1 to 9) running under Boxedwine. You just have to provide passthrough for DDraw.dll, D3D8.dll and D3D9.dll files for dgVoodoo2 wrapper to work. Please let me know if this is possible.

DirectX passthrough can give Boxedwine an edge over wine running under native linux computers.

Thanks.