Compiling, cross-compiling and testing for Windows

[xlucas]

In a way, this is a GNU/Linux question, but in many other ways, it's a Windows question, so I'm not sure if it should be here or there.

I am a GNU/Linux user, but I often make my programs multi-platform. I used to have Wine installed, so before publishing, I would use it to compile for Windows and for testing how it worked. Now for some reason, I seem to be unable to install Wine (it looks like it installed, but then the "Windows folders" fail to open and trying to run an EXE files gives an error too; I tried uninstalling and reinstalling; it doesn't work). I've seen there's a very old thread in this forum about cross-compiling, not sure if what it says still applies, but well, I'd still need to test the EXE, I suppose. So my questions are these:

- What are the requirements (which Windows version minimum) for the Windows FBC to compile normally? Is this also enough for the compiled programs to run on that system, so as to be tested?
- Do you guys think I should try cross-compiling, or use a VM or insist somehow on Wine? What is in your experience the best approach?
- Some answer to a question I have not thought of but that would be relevant? I'm quite lost and don't know what to do, to be honest :S

Thank you

[D.J.Peters]

I have done it from the opposite direction 2 years ago.

Windows XP (32-bit) compiling FreeBASIC code as 32 or 64-bit Windows binary
Running Qemu with 32 and 64-bit Linux image to compile same FreeBASIC code to 32 or 64-bit Linux binary.
Running Qemu with Raspberry PI image to compile FreeBASIC code for the ARM device.

To day I have a bunch of old 32-bit boxes and Laptop with Windows 7 and Linux Slackware and Ubuntu
and must reboot to cross compile for Windows/Linux 32-bit.
Than I have one 64-bit box and one 64-bit Laptop both with Windows 10 64-bit and Linux Ubuntu 64-bit on the same box.

You need on your Linux box a VM (may be QEMU) with minimum XP running to cross compile FreeBASIC for 32 and 64-bit Windows.

Joshy

[St_W]

- What are the requirements (which Windows version minimum) for the Windows FBC to compile normally? Is this also enough for the compiled programs to run on that system, so as to be tested?

If I remember correctly it works down to Windows 95 when the MinGW.org toolchain is used for compilation; with the newer (and now default) mingw-w64 toolchain (available for 32 and 64 bit targets) the minimum version is a bit higher - I don't know exactly which version, but XP should work definitely.

- Do you guys think I should try cross-compiling, or use a VM or insist somehow on Wine? What is in your experience the best approach?

The easiest approach is to set up a Windows VM. That also allows you to test your application properly in a real Windows environment instead of Wine. Especially if you go with Windows XP in the VM you get a really lightweight and fast VM - even on older systems. Of course you can try to cross-compile or compile using Wine - both should work.

[xlucas]

Thank you, guys... so... I'll probably try a VM with XP, then. I was happy with Wine before. Once it gets installed properly, it works like a charm, but it's not the first time I have problems trying to install it. Windows 95? I do have Windows 98SE in some old CDs somewhere... but I figure it's safer to try XP. Which VM would you guys recommend?

[D.J.Peters]

Most Linux distros comes with QEMU preinstalled or has QEMU packages to install.
On Linux QEMU has a kernel driver that makes QEMU really fast on Linux.
QEMU on Windows isn't fast but supports many different CPU's and dev. boards.

Joshy

[St_W]

If you only need to test for x86 or x86_64 a typical VM will do. In case you also want to test compilation for ARM or other architectures you'll need QEMU anyway (although these systems typically don't run Windows). I'd recommend Windows XP or newer. If you've enough hardware resources to run newer versions you can also go with Windows 7 or Windows 10. I wouldn't recommend any older versions as they don't have any practical relevance anymore today and are nearly 20 years old.

[Boris the Old]

......I am a GNU/Linux user, but I often make my programs multi-platform. I used to have Wine installed, so before publishing, I would use it to compile for Windows and for testing how it worked. Now for some reason, I seem to be unable to install Wine (it looks like it installed, but then the "Windows folders" fail to open and trying to run an EXE files gives an error too; I tried uninstalling and reinstalling; it doesn't work)......

We're a Linux Mint shop and use Wine to compile our PowerBasic applications. About three or four years ago, after doing a system upgrade, Wine stopped working. As I recall, the problem was caused by a newer version of Wine not being compatible with one of its hidden files from the previous release of Mint. We got this information from somewhere on the net.

The solution is to uninstall Wine using Update Manager, then manually delete the hidden file "/home/user/.wine". Once this is done then you should reinstall and reconfigure Wine. I believe this is all we did, but it's possible there was also a file in File System that needed to be deleted.

By the way, for several years we used VM software to run various flavours of Windows, but we found that it was slow and prone to being buggy. So although we do all our software development using Linux, we use dedicated Windows systems for testing our Windows applications.

Rod

[St_W]

By the way, for several years we used VM software to run various flavours of Windows, but we found that it was slow and prone to being buggy.

VMs are very common today (for example in the cloud) and used a lot for (automated) testing and similar stuff. If they are slow and buggy the fault is probably somewhere else.

[Boris the Old]

VMs are very common today (for example in the cloud) and used a lot for (automated) testing and similar stuff. If they are slow and buggy the fault is probably somewhere else.

Virtual Machines are another layer of software between one's programs and the hardware, and are subject to all the failings of modern software. Almost every day our systems receive updates to fix bugs and security issues, so why would we want to add another layer of potential problems between our software and the hardware?

A "virtual" machine cannot possibly perform like a "real" machine. And perhaps this is just another reason why modern software is so unreliable.

Rod

[St_W]

Virtual Machines are another layer of software between one's programs and the hardware, and are subject to all the failings of modern software.

You're right, VMs add a layer of complexity and thus are more likely to fail than a system without that layer. However, as I wanted to point out, virtualization is such widely used and such a mature technology that problems are very very unlikely. e.g. I'd tend to say that a large part of the internet (speaking of the servers hosting the websites) is virtualized nowadays. And performance shouldn't be an issue either because practically every CPU not older than about 10 years supports virtualization technology in hardware (e.g. IntelVT).
Anyway, I agree that a VM is of course still different to a "real" machine and potentially less reliable.

[Boris the Old]

@xlucas

The following link is from the Wine FAQ. It explains how to remove the Wine environment from your home directory.

https://wiki.winehq.org/FAQ#How_do_I_wi ... llation.3F

rod

[caseih]

Lately I use a different wine environment for every program I run in Wine. Keeps things a lot cleaner and separated. You do this by setting the WINEPREFIX variable before running wine. I tend to put all my wine prefixes into $HOME/.config/<programname>. And if I want to delete that, I can just remove that directory. Unfortunately wine tends to clutter your ~/.local/share/applications/ directory with .desktop files (menu entries) that you have to delete manually.

[xlucas]

Thank you, guys!

Boris: I really appreciate that! I think I did remove the directory, but I don't remember. I'll try again. The problem started when I first installed Wine and I reached the point at which it's going to install Windows fonts and asks me to accept Microsoft's EULA. I chose to rejected for two reasons. One is that I simply don't want to accept a MS EULA, but also because I remember that Windows fonts then would have an impact on my Xubuntu look and I had installed Wine in the past without the fonts and looked better, so I wanted to do the same. Well, this time, it finished the installation abruptly and wouldn't work, so I uninistalled it, reinstalled and accepted the EULA, but now that produced the same results again. Maybe even if I had accepted the EULA the first time, I would've got to the same. I don't know. Anyway. I'll try one more time.

Caseih: I didn't know that could be done. Yet, I rarely use Wine to run other programs. Only to compile and test my own. Although, there have been a few cases. Is there a way Wine can be set up so it doesn't automatically launch EXE files? Because that's dangerous. I would like to have to do like wine program.exe in the command line or something.

St_W: Yes, I've seen people do really huge things on VMs. Boris is right that it adds one more layer and it's true that lots of software are bloated and buggy because of the abuse in adding layers of abstraction even within the same program, but I reckon most popular VMs are so very much tested that they should be reliable. Of course, Wine would be more comfortable for my case, but...