Anyone Look Into Wine?

[Hooovahh]

So random shower thought. Has anyone looked into running any Windows compiled exes, or DLLs using wine on the x86 based Linux RT systems? Once I get some time and hardware availability I plan on looking into it but wanted to see what the community has done first.

https://www.winehq.org

[Hooovahh]

Okay so I figured I would share what I tried.  I thought of several ways to install Wine so I tried all of them to see which I could get the farthest on, none were successful.

     1. Install the RPM made for Other Distros

So posted here are some of the Wine repositories for Suse Linux which are made into RPM files.  Using OPKG you can install RPM, then use the command RPM -i <RPM File> to install it but saw random errors.

error: Failed dependencies:

        /bin/sh is needed by wine-1.9.18-586.2.x86_64

        /sbin/ldconfig is needed by wine-1.9.18-586.2.x86_64

        /usr/bin/perl is needed by wine-1.9.18-586.2.x86_64

        cabextract is needed by wine-1.9.18-586.2.x86_64

        libGL.so.1()(64bit) is needed by wine-1.9.18-586.2.x86_64

        libGLU.so.1()(64bit) is needed by wine-1.9.18-586.2.x86_64

        libOSMesa.so.8()(64bit) is needed by wine-1.9.18-586.2.x86_64

        libX11.so.6()(64bit) is needed by wine-1.9.18-586.2.x86_64

        libXcomposite.so.1()(64bit) is needed by wine-1.9.18-586.2.x86_64

....

        rpmlib(PayloadIsLzma) <= 4.4.6-1 is needed by wine-1.9.18-586.2.x86_64

        samba-winbind is needed by wine-1.9.18-586.2.x86_64

        unzip is needed by wine-1.9.18-586.2.x86_64

        wine-32bit = 1.9.18 is needed by wine-1.9.18-586.2.x86_64

        wine-gecko >= 2.47 is needed by wine-1.9.18-586.2.x86_64

        /etc/xdg is needed by wine-1.9.18-586.2.x86_64

        /usr/bin is needed by wine-1.9.18-586.2.x86_64

        /usr/lib64 is needed by wine-1.9.18-586.2.x86_64

        /usr/share/applications is needed by wine-1.9.18-586.2.x86_64

        /usr/share is needed by wine-1.9.18-586.2.x86_64

        /usr/share/doc/packages is needed by wine-1.9.18-586.2.x86_64

        /usr/share/icons is needed by wine-1.9.18-586.2.x86_64

        /usr/share/man/de/man1 is needed by wine-1.9.18-586.2.x86_64

        /usr/share/man/fr/man1 is needed by wine-1.9.18-586.2.x86_64

        /usr/share/man/man1 is needed by wine-1.9.18-586.2.x86_64

     2. Install DEB Wine Package

So DEB packages and OPKG packages are very similar.  This link states that the structure is the same but there are subtle differences with architecture.  I manually edited the etc/opkg/arch.conf and added the i386 architecture, because it mentiones it is needed in the Debian install of Wine.  But trying to install the DEB from OPKG stated architecture issues.  I didn't copy the exact error.

     3. Compile Wine from Source

So I still don't have the full environment needed to build Wine but I feel like I'm getting close.  First needed to install the packagegroup-core-buildessential using opkg, then install flex, and bison.  If I then try to make the 32 bit version of Wine with ./configure --without-64 or just ./configure I get this error:

configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries.

If I try to compile 64 bit with ./configure --enable-win64 I get this error:

configure: error: X 64-bit development files not found. Wine will be built without X support, which probably isn't what you want. You will need to install 64-bit development packages of Xlib/Xfree86 at the very least. Use the --without-x option if you really want this.

Looking at the suse page on building source here we see these packages are needed for 32 bit:

Necessary RPM: gcc, make, flex, bison, ncurses-devel, giflib-devel, liblcms-devel, libxslt-devel, Mesa-devel, libpng-devel, libxml2-devel, freeglut-devel, zlib-devel, glibc-devel, fontconfig-devel, xorg-x11-devel, libjpeg-devel, unixODBC-devel, freetype2-devel, openssl-devel, openldap2-devel

and these are for 64 bit:

Necessary RPM: gcc, make, flex, bison, ncurses-devel-32bit, giflib-devel-32bit, liblcms-devel-32bit, libxslt-devel-32bit, Mesa-devel-32bit, libpng-devel-32bit, libxml2-devel-32bit, freeglut-devel-32bit, zlib-devel-32bit, glibc-devel-32bit, fontconfig-devel-32bit, xorg-x11-devel-32bit, xorg-x11-libXext-32bit, xorg-x11-libXp-32bit, xorg-x11-libXt-32bit, capi4linux-32bit, xorg-x11-libICE-32bit, xorg-x11-libXext-devel-32bit, sane-32bit, cups-libs-32bit, libjpeg-devel-32bit, unixODBC-devel-32bit, freetype2-devel-32bit, openssl-devel-32bit, openldap2-devel-32bit, freetype2-devel-32bit, hal-32bit, hal-devel

Most of these aren't on NI's repository, and most I can't find as opkg packages.

[cirrusio]

Brian,

First of all - why?  Linux is just fine on it's own

Second of all - doesn't wine require some kind of windowing system such as x11?  If that is the case I would expect this to be a no go given that the distro on the RT machines is a RT Linux distro and unlikely to support any kind of GUI as these tend to be more hardware intensive.

cirrus

[MattP]

FYI, our 903x cRIO targets do support an embedded UI mode where we expose an xfce desktop and can run front panels and have direct user interaction.  Main limitation is no subpanels.  We only support it on the more highly-powered cRIO targets, so not everyone comes across it.  Handy link for what is/is not supported: http://zone.ni.com/reference/en-XX/help/370622M-01/lvrtconcepts/display_developing/

[rtollert]

If you're masochistic enough -- or brilliant enough -- to try this, it's probably easiest and safest to just debootstrap together a debian or ubuntu chroot on the target and run wine using something like schroot.

https://forum.winehq.org/viewtopic.php?t=9000#p46242 explicitly states that wine doesn't need X11 if the code doesn't request a UI.

Wine actually works pretty well for a lot of stuff, at least on the desktop, but it does not play well with vast swaths of technologies. IIRC, one of those technologies happens to be NI installers, but if you copy all of an existing installation, it may work better. It is also wholly ignorant of thread priorities.

[Hooovahh]

cirrusio wrote:

First of all - why?  Linux is just fine on it's own

Tell that to the customer who has these DLLs they'd like to run.  In all honestly the task of running these DLLs can probably be off loaded to a remote computer, and the result can be passed back to the Linux target but it is a pain, and adds more dependencies to the system (not that adding wine wouldn't be doing that too but it would be more contained in the single system).  But if I could get Wine to be installed, that opens up so many more options for future development for hardware that only has a Windows compiled DLL, or a Windows built command line program.

cirrusio wrote:

Second of all - doesn't wine require some kind of windowing system such as x11?  If that is the case I would expect this to be a no go given that the distro on the RT machines is a RT Linux distro and unlikely to support any kind of GUI as these tend to be more hardware intensive.

So I successfully ran a command line Windows built EXE in an Ubuntu server with no UI.  I ran md5.exe with an input, it processed that input, and returned the result.  I tried on an AutoIt built EXE but even with it made as a command line program, and even with the NoTrayIcon option I got an error mentioning the display couldn't be rendered.  So for that I think I'll need some more investigating but it seems that even on a Linux RT with no UI some usefulness can be found in Wine.  Now getting the display working would be awesome but lets not get too ahead of ourselves I'm still seemingly a long ways away from getting Wine running on a Linux RT system, and any help is appreciated.

[ScotSalmon]

What do the DLL's do? I assume if there was any obvious Linux equivalent you'd have latched onto that before heading down the Wine path, but I'm interested to know. Maybe there is an obscure alternative someone knows about.

[Alejandro_del_Castillo]

A possible solution is to use docker, but that requires to go off the beaten path to get it working. It is a powerful technology that gets you a way to run another distribution in a container, but is not supported with the current nilrt configuration. A while back I got it working on a cRIO 903x, I'll post the steps I follow here, but take them with a grain of salt, as I haven't follow those steps in a while:

1) Compile a kernel with namespace support, run the script at https://github.com/docker/docker/blob/master/contrib/check-config.sh to get a list of what config options needs to be enabled

2) Disable our nicgroup* init scripts. Docker requires that cgroups are mounted under /sys/fs/cgroups

     nicgroup* (2015) or nicreatecpusets & nicreatecpuacctgroup (2014)

3) Mount cgroups on /sys/fs/cgroup

    -Run cgroupfs-mount from https://github.com/tianon/cgroupfs-mount

4) Install bridge-utils, ca-certificates and kernel-module-xt_conntrack

5) Install docker:

    wget http://get.docker.com/builds/Linux/x86_64/docker-latest-O docker

6) Run docker:

   docker -d

if you do give docker a try, I would love to hear your thoughts on it.

[Hooovahh]

The DLL I am most interested in getting to work is a Seed and Key DLL for performing security authentication for automotive ECUs.  You give it an input, it returns an output based on a proprietary encryption.  Beyond that I have a few pieces of USB hardware that come with a proprietary DLL for communicating, and while I don't need to use this hardware in this way, it would open the door to other possibilities.  The ones that come to mind are Intrepid, Kvasar, and Vector CAN hardware, each of which works off of a DLL provided by the manufacturer.

[BradM]

Brian Hoover wrote:

...

Beyond that I have a few pieces of USB hardware that come with a proprietary DLL for communicating, and while I don't need to use this hardware in this way, it would open the door to other possibilities.  The ones that come to mind are Intrepid, Kvasar, and Vector CAN hardware, each of which works off of a DLL provided by the manufacturer.

The likelihood of a sucessful outcome here is fairly low, unless the .dll's are expecting to talk to a USB-to-serial interface for doing the proprietary thing that they do (and even then, there are some old patches that will need to be tracked down and applied to WINE).