I was using Omnet++ in a Linux VM until performance allowed. Now I'd like to install it directly on the host, a Windows 10 machine, but I'm facing some troubles when it comes to run basic veins, inet or veins_inet examples. I've been following this tutorial: Omnet++ tutorial by Dr Skiles and the others in that channel. I'm getting errors in the make process. I'm attaching a screenshot: Build: Make error
I've downloaded last versions available of Omnet++, Inet and Veins. I've made sure keeping absolute addresses short and also tried with no spaces (in the screenshot there is omnetpp-6.0pre13 with spaces) but I've also tried 5.7 and 5.6.2 -> Omnets I tried so far. For what concerns Inet I've been downloading the suggested version as soon as I launch a new project and I've downloaded different versions of veins just to understand if it was the root cause of problems. By building Inet or Veins frameworks independently I got no errors but as soon as I emulate the previous tutorials I get the makefile error.
Omnet_5.7 is throwing a slightly different error, something like:
Makefile error: "release/blablabla/VeinsInetApplicationBase.o" requested by "blablabla/myprojectname.dll" is missing. I might recreate this as soon as I finish recompiling everything from scratch.
Omnet_5.6.2 stopped showing Qtenv after few runs of "aodv" inet's example. -> make clean -> configure.user is Qtenv=yes -> ./configure -> make -> same problem. Still, the main problem is the one in the screenshot and as far as I'm concered the problem is the integration of veins since aodv (of inet) is working.
My questions:
Also I'd like to say that I've searched a lot before writing this so hopefully this is not redundant and might help others as well.
I cannot add too much to the actual error here as I don't have experience with Veins, but I know that linking several models on Windows is a pain. One possible route for you:
If you are okay with upgrading to Windows 11, you can actually install Ubuntu in the Windows System for Linux and WSLg on Windows 11 now supports GUI programs out of the box. You will be able to continue to use the Linux version (along with the IDE and qtenv) without any further magic. In my experience, CPU performance is the same on native Windows vs. virtualized Linux. I/O performance (like disk writing, compiling etc.) are a LOT faster in a virtualized Linux container than on native Windows (yes, NTFS sucks). The only drawback with virtual VMs were that you had to allocate the memory statically between host and guest and you were running two desktop environment that eat the memory. But this is not the case with WSLg. It allocates the memory dynamically and on Linux it does not run a separate desktop but rather integrates with the main Windows desktop (using wayland instead of X).
As strange as it sounds, but IMHO the best way to actually run OMNeT++ on Windows is to run the Linux version inside WSLg.
On Windows 10, graphical programs in WSL are not (yet?) supported out of the box (fingers crossed that MS backports this), but you still can install an XServer and if properly configured you will get similar experience. (There is a chapter about how to install WSL and XServer in the InstallGuide of OMNeT++ 6.0pre13). There is also a project called GWLS that aims to ease the XServer installation for WSL that is even easier than the steps in the install guide.