3 ms·
Your [0] is actually a pretty neat idea - Wine is small and well-supported, and kind of cross-platform by definition. Even better if you explicitly ensured comp
by seabass-labrax 3y ago
Your [0] is actually a pretty neat idea - Wine is small and well-supported, and kind of cross-platform by definition. Even better if you explicitly ensured compatibility with both Linux and Windows, for instance with CI testing every build for API errors. After all, GTK kind of has a Wine-style compatibility layer when running on Windows; it's just often statically linked into the binary rather than installed separately.
- badsectoracula 3y agoWinelib (not libwine, my bad) isn't really that great for non-Windows stuff, it is really meant for porting applications that use Windows API calls and it really takes over everything. For example you need to compile the program using "winegcc", which creates a shell script that calls Wine to load the application (the application is compiled as a .so so it can use Linux libraries and calls, it isn't a Windows program). This in turn loads the full Wine server with its various services and Windows compatibility layers. And chances are you'll need to use "winemaker" to build the code (it generates a Makefile for you). Just as a test, compiling and running a very simple "hello, world" program that calls MessageBoxA to show a message box and exits still loads a bunch of processes (checked via ps -A) and dumps a bunch of diagnostics to the terminal. Also, IMO while Wine's GUI bits generally work, they do have a lack of polish even compared to their Windows 95 counterparts.