Provide a 32bit OR ARM build for Windows (Surface Pro X)

[martinkoutecky]

It is not possible to run the current (2.3.3) windows build on Surface Pro X, which is an ARM device with emulation for 32bit windows applications.

An ideal solution would be a native (ARM) build of barrier for windows. A perhaps easier and sufficient solution would be a 32bit windows build.

Seems related to #830 which asks for a 32bit linux build.

[shymega]

Yes, 32-bit support should be added again. I'm looking into ARM builds, but we would have to see how easy that would be with Azure Pipelines. I'm sure it would be possible with cross-compiling. Could you confirm the exact model of your Surface Pro X? There's different types of ARM chips, for example - armv6, armv6, hard/soft floating points, etc.

[martinkoutecky]

Hi - I'm not sure how to answer the question. I think there is only one CPU in the Surface Pro X, which is the Microsoft SQ1, which is basically Cortex-A76 / A55 (Kryo 495) (some more info here) -- when I look at downloads of other software, I'm looking for "aarch64". According to wiki it should be specifically ARMv8-A.

If there are any specific questions you have or diagnostics I could run I'd be happy to. Thanks for looking into it!

[shymega]

Hi, thanks forgetting back to me.

I'm looking into it still, but I need to see how easy it would be. I think on Windows its achievable. I can't test it on CI right now though.

I have, however, been able to build the barrier, barriers and barrierc executables on my Windows machine. I have zipped them up and attached to this issue. Let me know if that works, as they should be x86 now.

There's no installer, as I haven't got that far, and I wanted to get something whipped up quick for you.

** Ignore this previous link! Built with Qt x64 by mistake. **

I'm gonna create a issue about Azure Pipelines having x86/aarch64 support in the future.

[shymega]

Rebuilding from v2.3.3 and with x86 Qt. Made a mistake.

[shymega]

Finished the build.

Barrier-v2.3.3-x86-executables.zip

With regards to aarch64 support: so Qt, OpenSSL, and Bonjour would be one of the issues here. I'm not sure how easy it would be to convince VS to compile to aarch64. I can do some more research, but for now I suspect you will have to just use 32-bit, sorry. If you, or any others, have ideas on how to accomplish CI builds on aarch64, I'd be open to suggestions 😄

[shymega]

Oops, didn't mean to close that. I will wait for your response first..

[martinkoutecky]

Hi @shymega -- thanks a lot for your effort! Now I'm getting "Qt5Network.dll not found". Previously I was missing ssleay32.ssl and libeay32.ssl, but I can see that's fixed. I tried installing Qt5 for windows but that hasn't helped. Is there a way to bundle those libs with it? Or what can I download and install to make it run?

[shymega]

Uhhh.. I thought I had bundled Qt with it. You could probably install Qt 5, and it'd be fixed. Give that a try, and let me know if it works :)

[martinkoutecky]

As I said - I've tried installing Qt5, which seemed quite complicated (needed to create a qt account, etc.), but it didn't work anyway? Sorry for this silly question, but how did you install Qt5? (definitely Qt5Network.dll is not in the folder you supplied.)

[shymega]

Sorry, totally misread that. We use a Python script to download Qt 5, and then MSVC (on WIndows, anyway) links the Qt DLLs into Barrier. Same with Bonjour and OpenSSL. So what I've done, is used the 32-bit version of OpenSSL, Qt, and Bonjour right now.

But this is where the tricky part comes in for ARM64- the Bonjour 'stub' SDK we use only has support for Win32 and x64 right now. I need to open a issue and ask if we can get alternative architectures supported for Barrier. Then, we have OpenSSL. All of these must be compiled in ARM64 'format' for them to be linked to the Barrier executable.

All in all, we need to have a rethink about our builds. Personally, I see no reason to stop supporting 32-bit, and ARM64 would be - imho - a welcome addition in the future.

I'm just looking into getting the Qt DLLs into the folder, one moment.

[shymega]

OK. I've attached the new ZIP here. That should work. In theory...

I've opened an issue on the script's repo, too.

Barrier-v2.3.3-x86-executables.zip

[martinkoutecky]

Hi - thanks again. Now the message I'm getting is this, which I don't understand:

Again thanks so much for giving this the attention! As I said, I'm not much worried about having a native build, but getting this x32 thing running would be amazing for my workflow, so I really appreciate the help.

[martinkoutecky]

BTW running the executables from terminal doesn't turn out any errors, it's just that it's hard for me to configure barrier without the GUI. But I might give it a try tomorrow (unless you have a new build for me) and see if I can get it running without the GUI after all.

[shymega]

OK, so basically, I'm running this build step-by-step from clean_build.bat, and there's a lot of things to factor in.

Please try moving qwindows.dll to the platforms folder, and try again.

[shymega]

Confirmed working on Windows 10, 2004.

[martinkoutecky]

Hi - thanks again. Now I've got the GUI running, but the log keeps saying "INFO: connecting to service..." and then "ERROR: ipc connection error, connection refused". I assume this is because the barrier service is not running, which may be because just copying files over is not a proper install? I.e., how do I run the service? When I try running barrierd.exe (either as a normal user or admin), it says "cannot connect to network hub" (or maybe it's socket - I'm getting the error message in Czech).

Also, when I try to run from terminal ./barrierc.exe 192.168.0.144 (my server IP), I get a timeout, and on the server I get

[2020-09-02T08:54:57] ERROR: ssl error occurred (system call failure)
[2020-09-02T08:54:57] INFO: client connection may not be secure
[2020-09-02T08:54:57] ERROR: failed to accept secure socket

The client is Windows 10 ARM, the server is openSUSE linux with barrier 2.3.2.

I'm not sure this is still connected to the x32 issue, but it seems maybe there are two issues at play, one with barrierd perhaps not running on the client, and then maybe some SSL issue (as shown in the log of the server)?

[martinkoutecky]

OK: I've got it running, sort of -- the main missing piece now is SSL. Steps to get it running.

1. On server, enter precisely the name of the client.
2. On server, disable SSL and start service.
3. On client, from terminal run ./barrierc.exe 192.168.0.144

Then it seems to work. With SSL enabled I'm getting the timeout on the client, and the same error message as above on the server.

[martinkoutecky]

So some more progress: now I've got it running completely, even with SSL. I had to manually generate the server fingerprint and put it in TrustedServers.txt in the right location. I would definitely prefer to use the GUI for all this, but maybe that gets fixed when there's a proper install package for x32 which installs the service (barrierd), because I think the reason the GUI is not yet useful is the problem with connecting to barrierd. Just my guess.

Anyway, this is essentially satisfactory now for me - thanks a lot for your help. I would say this is closed once there is an x32 build in the Releases, but I'm leaving this up to you.

[foxtrotdragon]

I would like to say, on my asus t100ta the linked build works pretty much flawlessly moving windows, and adding barrierd as a service in windows. I have been using it multiple days without issue (Aside from lag caused by shoddy network hardware)

[OKNoah]

We'll need an Apple M-series build as well.

[shymega]

As far as I know, Apple's M-series CPUs support x86_64 builds, so Barrier should still work. However, and this comment should explain things further, I would not be in a position to make any more builds. I did not even get round to adding CI support for ARM64 builds...

[mkostersitz]

I am trying to get this working the other way round. Windows X as the server and Mac OS Big Sur as the clients.
Both sides seem stuck at Barrier is starting.

On the Mac Side I am seeing "failed to connect to server: server refused client with our name. .local"

Got it working. Had to drag a new screen into the config, name it and restart server and client. Now I am connected.

[shymega]

@mkostersitz Good to hear, but your issue was unrelated to this. Please either ask on IRC, or open a new issue in future...

[willis936]

I'm having this issue on Windows 7 32-bit. I copied the executables from the artifact attached to this comment (#852 (comment)) but I now have the unsupported Qt platform error. qwindows.dll is in the installed platforms directory.

The platforms directory in the referenced artifact is empty. Could someone with a build environment upload a copy with the correct qwindows.dll?

[shymega]

I did say in a later comment that you need to move the qwindows.dll file to the platforms subdirectory. The artifact does not have the required directory structure due to a typo on my part. Try that.

[willis936]

I copied/replaced the executables directory on top of an existing Barrier install that had qwindows.dll in its platforms subdirectory. I have also tried copying the qwindows.dll to the extracted directory's platforms subdirectory and launching barrier.exe from there. Both return the Qt platform plugin initialization error.

Edit: Oh I see. The version of qwindows.dll in the top directory needs to be present in the platforms subdirectory. I hadn't realized the dll was present in the top level directory.

[shymega]

Does it work now? AFAIK, you can't really use it on top of a Barrier install - that'd be mixing things..... but if it works, that's good.

[willis936]

It is working now on Windows 7 32-bit with the copy on top of an install. I wanted windows to be aware of the shortcuts.