Is it possible to call native Linux API from a Windows application running in Wine?
Scenario I have a plugin (dll) written for a Windows application (in C++). That application works fine on Linux under Wine, however, in the plugin I would like to use a feature which is not yet available in Wine. Assuming I can detect at runtime that the application is running in Wine, can I dynamically load native Linux library (or access native Linux API in any other way) in order to emulate said feature? I am curious whether this can be done without any serious hacking.
How about writing a native Linux application? If done «right», you’ll end up with a cross-platform solution that works on Linux and Windows. But this is an interesting question nonetheless.
I would write a cross-platform executable program, and two small OS-specific loadable plugins that talk to it via a pipe or some other mechanism.
Wine provides Windows features on Linux. Are you saying you want to use a Windows feature that Wine does not yet support, so you propose to emulate it? If you mean to do that, then maybe you should add the feature to Wine itself, instead.
1 Answer 1
Seems like someone has faced similar problem, or at least has predicted such situation. Wrapper-library should help you:
- You have a binary only Windows application that can be extended through plugins, such as a text editor or IDE.
In few words — you should create thin Wine builtin-dll, that acts like a bridge between ABI of your PE binary and ABI of native Linux Library. Then you should link your code against this wrapper. For Windows distribution you can provide «wrapper» with empty stubs. Such approach allows you to use one binary for your plugin, that will use wine-specific functional wrapper DLL on Linux and stub DLL on Windows.
Запуск программ Linux в Windows
Для запуска программы Linux в Windows возможны следующие варианты:
- Запуск программы «как есть» в подсистеме Windows для Linux (WSL). В WSL программа выполняется непосредственно на оборудовании компьютера, а не на виртуальной машине. WSL также поддерживает прямые вызовы файловой системы между системами Windows и Linux, устраняя необходимость в SSL-транспорте. WSL разработана как среда командной строки и не рекомендуется для приложений, интенсивно использующих графику. Дополнительные сведения см. в документации по подсистеме Windows для Linux.
- Запуск программы «как есть» на виртуальной машине Linux или в контейнере Docker на локальном компьютере или в Azure. Дополнительные сведения см. в разделах Виртуальные машины и Docker в Azure.
- Компиляция программы с использованием gcc или clang в средах MinGW или MinGW-w64, которые предоставляют слой преобразования системных вызовов Linux в системные вызовы Windows.
- Компиляция и запуск программы с использованием gcc или clang в среде Cygwin, которая предоставляет более полную среду Linux в Windows по сравнению с MinGW или MinGW-w64.
- Ручное портирование кода из Linux и компиляция для Windows с использованием Microsoft C++ (MSVC). Этот подход подразумевает рефакторинг кода, не зависящего от платформы, в отдельные библиотеки, и последующее переписывание специализированного кода, относящегося к Linux, в код для Windows (например, для API-интерфейсов Win32 или DirectX). Предположительно, этот вариант лучше всего подходит для приложений, в которых требуется высокопроизводительная графика.
Run C program written in Linux on Windows
I have C program which I wrote in Linux that runs very well. Now I want to run it on Windows. How do I easily run it on Windows?
Does it include any code that is specific to Linux? Or does it use only C standard library and POSIX API?
4 Answers 4
Elaborating a bit on the answers from caf and jartieda.
Cygwin is an attempt to emulate a (nearly) complete POSIX execution environment in a native Windows process. It is complete enough that a surprising amount of Unix application code simply compiles and runs using the familiar ./configure && make && make install idiom. This trick was done by supplying a DLL that emulates POSIX system calls using the Windows API. Based on that, you get a complete GCC toolchain, bash, and all the usual command line utilities you are used to. One downside is that the compiled program is dependent on the Cygwin DLL, which makes it tricky to deliver the result to a system that does not already have Cygwin installed and whose user doesn’t want to use a Unix shell.
MinGW is a port of the GCC toolchain that generates native Windows applications that depend on the well known (and distributed with Windows itself) MSVCRT.DLL C runtime library. It makes no attempt to emulate a POSIX operating system, but applications that are mostly based on the standard C libraries, will often build essentially unchanged.
MSYS is a compile-time environment that provides enough Unix utilities (including bash) to often allow ./configure to run, and if the project supports the results, finish the build with MinGW’s GCC. The result is a native Windows executable that does not depend on any DLLs you don’t deliberately use aside from MSVCRT.DLL. Although the MSYS environment itself was a fork of an early version of the Cygwin project, it is primarily intended to be used to provide a unix-like place to compile native Windows applications: one would generally not build new applications based on its runtime environment.
Another approach to compiling for Windows is to use the MinGW cross compiler on linux. A number of MinGW’s core developers work that way, testing they product either under Wine, or under Windows running in a VM or a separate PC.
If the program has a GUI component, then you may have additional difficulties. Some GUI frameworks are available for both Linux and Windows. Qt, wxWidgets, and IUP all leap to mind, but there are others out there.
Edit: I’ve improved the paragraph above about MSYS to emphasize that it is intended to be a compile-time environment for building programs that run as native Windows applications, and not a full POSIX environment like Cygwin.
Note, also, that there is always the option of porting the project to one of the more traditional compilers for Windows development. Open Watcom, the Borland compilers, and Microsoft all have free or inexpensive versions, although often enough not under licenses that make the opens source community entirely happy.
This approach probably requires more effort because the differences between a Linux environment and the Windows environment become more visible when you also switch from one toolchain to another. This is especially true of the Microsoft compilers which are historically not as fully standards compliant as GCC.