Running a Windows program seamlessly under Linux

[MarkMLl]

I've had my attention drawn to https://github.com/scottyhardy/docker-wine , which installs a Docker image containing Wine and then seamlessly runs a Windows (Win-32, not sure about the -64 situation) from the native filesystem hence leaving all files accessible.

It's fairly stable... I'm sure that there's some nasties in there somewhere but so far it looks like a viable solution for anybody who occasionally wants to fire up e.g. the Windows variant of the Lazarus IDE.

To get a working commandline etc. into the record, my specific use case is to run Ameol2 which is specialist communications software talking to a server over TCP. I downloaded it as a .zip and unpacked it into /usr/local/ameol2 transferring ownership to myself, I then ran

Code: Text  [Select][+][-]

1. $ ./docker-wine --as-me --force-owner --volume=/usr/local/ameol2:/data wine /data/Ameol232.exe
2.  

and everything worked automagically: in particular completely divorced from the host OS's version of Wine which cannot be relied on to be current.

MarkMLl

[MarkMLl]

A few years ago I experimented with Lazarus running on ReactOS: it was less than successful since the installer tried to write larger chunks than the OS could flush to a btrfs filesystem. In the end I got it working by installing into a FAT volume and setting up the equivalent of a symbolic link.

I believe I reported this as an installer bug.

Over the last few days I've tried to fire that up in a Qemu VM without success: ReactOS wouldn't start. However as an experiment I extracted the Lazarus+FPC files and moved them onto my desktop Linux system.

Using a copy of the docker-wine script and this wrapper, I was able to start the IDE successfully:

Code: Text  [Select][+][-]

1. #!/bin/sh
2.  
3. SCREEN='screen -d -m'
4. __CACHE='--cache'
5.  
6. # Things like --volume are run parameters, so there is a risk that omitting --name
7. # will mess up anything stored persistently in the location specified as winehome.
8.  
9. $SCREEN /usr/local/lazwin/docker-wine $__CACHE --name=Lazarus --as-me --force-owner \
10.   --volume=/usr/local/lazwin/usr.local.share/lazarus:/lazarus \
11.   --volume=/usr/local/src:/usr/local/src \
12.   wine /lazarus/lazarus.exe
13.  
14. # Discarding output appears to be done adequately by Gnu screen.
15.  
16. # >/dev/null 2>&1
17.  
18. # Doesn't like appended ampersand, either here or from QQ
19.  

I also had to edit the fpc/bin/fpc.cfg file to reflect the location of the FPC files, in particular the compiled units.

I've not experimented with using external resources via OPM etc., or made any attempt to run any cross-compiler since (from previous experience with Docker) I suspect that getting a physical connection to a target system might turn out to be a problem.

I've also seen another program crash on occasion in the docker-wine environment, the precise symptom being that a dialogue etc. displays as three sadly-pixellated beagles which is almost immediately followed by termination.

However on the balance I still feel this might be useful.

MarkMLl

[domasz]

Thanks for sharing, looks great.

in particular completely divorced from the host OS's version of Wine which cannot be relied on to be current.

In my case this has never been an issue. I installed wine on my virtual machine years ago and it still runs everything I need. It's a really great thing.

[MarkMLl]

In my case this has never been an issue. I installed wine on my virtual machine years ago and it still runs everything I need. It's a really great thing.

After moving from Slackware to Debian in the early '00s I was inclined to rely on the packages from their repo rather than rebuilding wherever possible. That's not always been a good thing in view of the time lag, and I now find myself beginning to use AppImage etc. to an increasing extent.

I had a fairly major session a year or so ago working through Docker installs (typically of a cut-down Debian) and putting the development environments for various target systems (Arduino-like, Pico, a couple of FPGAs etc.) on top. It was fairly trouble-free, except that I found I had to disable quite a lot of Docker's isolation stuff in order to get USB ports working properly.

Granted that Linux support for FPGAs etc. has improved enormously, but I still think we're up against a fair amount of Windows-only stuff. The docker-wine approach might be useful, but I'm a bit concerned about stuff I've seen that demands e.g. special installer DLLs before it will play ball.

MarkMLl