I am developing a program which, through the use of ReadProcessMemory and WriteProcessMemory from the kernel32 API, modifies another win32 program at runtime.
I would also like to support those who run target.exe on *nix platforms through the use of wine, but I cannot simply run editor.exe in wine -- the GUI is implemented in WPF, which wine does not support.
Rather than reimplement the GUI in WinForms or MFC (which are supported by wine), I would like to produce a native GUI for *nix, using QT or GTK for Linux, and Cocoa for Mac.
My question is about winelib, which seems intended to help port win32 programs to *nix. Using winelib, a program is compiled as a *nix executable, but has access to the win32 API, and continues to depend on a wine environment to provide system resources such as a registry.
According to the WineHQ introduction page, programs compiled with winelib also have access to *nix APIs, and this in-depth wiki page discusses using native APIs rather than wine-based ones. In a way, programs compiled with winelib have one foot in win32, and one foot in *nix.
Is it possible for a program to use winelib while only rendering a *nix gui, with no window or console rendered by wine? I really only need access to the ReadProcessMemory, WriteProcessMemory, and some Toolhelp32Snapshot functions (for locating the target.exe process). I believe all of these reside in kernel32.dll.