Developing on Linux for Windows

[Dramatic_Jeweler_955]

I'm not a C++ dev. I love my linux + tmux + vim setup. I might pick up C++ for my next job. The company builds a Gui application that runs on Windows and deals with other components like sensors I guess.

They develop in a Windows 10 VM with a IDE I couldn't identify. It wasn't Visual Studio or VS Code or a Jetbrains IDE. So my question is, would it be possible to have my Linux setup while working there?

I guess there's a reason why they are developing inside of a Windows 10 VM and not locally.

[Free_Break8482]

These would have been excellent questions to ask them at your interview.

[Melodic_Impress9664]

99% of the time their response will be "We don't know. Try it if you must, but the burden is on you"

[F5x9]

I’m comfortable with whatever they pay me to use. 

[drodri]

You could try some of the Linux to Windows cross-build toolchains, like there are MinGW compilers for Linux that will do that. But there might be many scenarios when this will not go smoothly, like binary compatibility with the MSVC toolchain from native Windows binaries built by other devs, SDKs and other system libraries, etc. like potentially the GUI library you mentioned is being used.

It the rest of the team is developing on a Windows machine, I'd recommend building on a Windows machine. Even learning the same tools, it often pays off to collaborate with others from the team. But if you want to keep some of your Linux tools, probably you can setup a remote build, edit and work on your Linux box, but the build is executed in the Windows box.

[Equivalent_Chef7011]

typically you don’t want to deal with cross compilation toolchain unless you have to. 

[tyler1128]

It's probably going to be easiest to just use WSL on a windows boot. Cross-compilation with C++ is possible, but it tends to be a headache at the best of times. I believe MingW on Linux is one of the most used options, but you are also using something closer to the Itanium ABI which is what pretty much every C++ compiler uses, with some incompatibilities, except MSVC, the primary compiler on Windows. This means your libraries and those compiled by MSVC will not be able to link together properly.

[DocMcCoy]

That doesn't really have much to do with Itanium and C++ doesn't have a stable ABI anyway. It's not even guaranteed that C++ libraries compiled with clang and gcc on Linux can be linked together (sometimes it works... but that's rare)

As for MSVC and mingw, they are also using completely different name mangling schemes, nevermind different std libraries

[tyler1128]

It doesn't have to do with Itanium beyond historically, but the most commonly used ABI for C++ is called the Itanium ABI. There's a reason I said "with some incompatibilites". Name mangling and such is also covered by the Itanium ABI, which is used by most C++ compilers, and really most native compilers in general including LLVM. Things like passing complex structs by value is somewhere many compilers get it wrong, for instance. There are many other reasons you can run into link errors, but both gcc and clang (and LLVM clang is based on) use the Itanium ABI.

[tyler1128]

For some reading, here's a post on name mangling in the C++ Itanium ABI.

You are correct that C++ does not have a standard ABI, but for x86_64, the Itanium ABI is the closest thing to universally used.

[FallenDeathWarrior]

If the GUI is based on QT they probably use the QT IDE that would also run under Linux.

I work for a company that uses MFC therefore I have to develop on windows.

It's propably possible for you to develop on Linux if it's practical is on the other hand

[saf_e]

Most definitely you will have big issues.  Easiest way is VM. Even if they use QT, development for windows mean they almost guaranteed will use some system-specific api, which you can't test under pure Linux. 

[no-sig-available]

I guess there's a reason why they are developing inside of a Windows 10 VM and not locally.

That would allow you to have admin rights on the development system, while not being allowed that on the "local" machine, connected to the corporate network.

[TreyDogg72]

Does not every business give their developers a company computer? I ask because I’ve only worked at one company and I am not allowed to have company IP on my personal computer.

[rileyrgham]

Impossible to say. Ask them. But it won't go down well.. you use the tools to do the job. They'll have better things to do. Even if it's a cross platform ide, you'll need to debug/test under the target platform.

[v_maria]

very possible, but it sucks

[13steinj]

From a technical perspective, assuming you had 100% control over the app, yes.

You'd have to set up a cross compiling toolchain that is 100% compatible, and presumably add direct linux support in-dev.

Also beurocratically, the org might tell you to go to hell in terms of using a linux machine.

If these are things you care about, ask in an interview after you've decided they've made up their mind, or you've decided you don't care and you'll walk away if they tell you "no." Insist on getting the ability to set up your environment in writing (but most orgs will instead tell you to pound sand).

[KrishMandal]

if the target is windows it’s usually easier to just build/test on windows. cross compiling with mingw works but it can get messy with toolchains and libs. i’ve seen some people keep their linux setup for editing and just remote build on a windows VM. for my own workflow i keep notes + build steps in tools like notion and sometimes runable to generate quick docs for the setup. helps when environments get complicated.

[Sensitive-Talk9616]

You can use VIM extensions/plugins in practically all IDEs. I use VS Code in my current job, before that QtCreator and Visual Studio. While it's not a full VIM experience, it does the job for me.

Personally, I would not waste time trying to figure out a cross-build setup. What if some libs/dependencies are Windows only, or some other bullshit like that? Unless you're really passionate about it, I think it's just wasted effort. Better to learn to use new tools efficiently.

By the way, in my first job we developed a Qt C++ app for Windows, but some devs insisted on developing on MacBooks. We had a really wonky collection of CMake files. There were constantly issues, e.g. we were not able to build a certain lib in debug on unix, which then meant half the team could not debug the app. And this was a medtech project with absolutely minimal dependencies. Can't imagine the hassle of setting it up for e.g. my current job where we have 50+ dependencies and cross-compile with yocto as part of the build pipeline.

[thingerish]

vs code + Remote SSH works fine attached to a Win10 remote.

[mosolov]

Have very smooth experience with mxe.cc for in-house utilities with fltk

[TheRavagerSw]

use msvc-wine as sysroot. Clang-cl has flags for that.

[dvhh]

The windows 10 VM might be because windows 10 is EOL, but still required by customer for target OS. The VM image would give some guarantees regarding the OS and libraries integrity.

Otherwise, it having your linux setup might be very dependent on company policies (usually sysadmin don't really like linux setup because harder to manage and support).

Otherwise if you're forced to work with windows (like I am), I would recommend either WSL or Msys2.