WineLib

From Wine-Wiki

Jump to: navigation, search

Contents

Introduction

This is not release notes nor is it advice. This is a list of quotes from the mailing list archives to help you do further research. If you find an error please correct it.

A programmer apparently incorrectly noted: It doesn't look like the basic winelib information has been updated since January 2005, although there's mention of a planned 0.9 release in September 2005. That's more than three years of inactivity.

F. Gouget mar 09 winedev: The Winelib tools (winebuild, winegcc, wrc, widl, etc) are actually used everyday and are under active development as they are used to build Wine itself.

What is not under active development is the tools to automatically convert Windows projects / source code into something that can be compiled using the Wine build tools. This is winemaker's task and André Hentschel has been recently submitting patches to add support for converting Visual Studio projects to regular makefiles (and I have been slacking on providing feedback, sorry). The other thing that's not under active development is the documentation. Archived-At: <http://permalink.gmane.org/gmane.comp.emulators.wine.devel/68385>

WineLib

Essentially you compile your software using winelib and then run it on wine. However this ties you to one version of wine, so unless you are using your software on non x86 hardware it may be better just to run it under wine. That way, you will only need to fix one item, wine. And even a few interns working over the summer may be able to do this for you, though check on the wine lists about the scope of the job that is needed. If you want something to work on a non intel processor, then winelib may be your friend.

vitamin [wine user jun 08] For console app you need to use main() (or wmain() for unicode). And for gui apps you need to use WinMain().


winegcc is used to build wine, as seen in this release note on March 9, 2004 for Wine 20040309 

* Much improved winegcc tool, now used to build Wine itself.

Dimi Paun explained a little about Winegcc [May 05]: It's just a wrapper around gcc, it just passes stuff on to the native compiler Wine Archives

B. Harrosh: Winelib can be both your DLL calling code, and your complete Linux application. No need for .EXE compiled or crosscompiled for windows, No need for IPC and no need for two parts at all.

It has been proven that any windows code can be compiled as Winelib. If you are using core Libraries like MFC or ATL than that might get difficult (not impossible)[...]. On the other hand Winelib applications are a Linux applications so they can link to any Linux library. Just that they have a funny Makefile and are built with Winegcc.


Statically linking of a DLL is done as follows:

  • Write a .spec file prototyping your DLL, than winebuild it to a .DEF file. (make a rule for it in Makefile)
  • Link your Winelib against that .DEF file like you do any other Wine/Native DLL. Wine Archive Sept05 Wine Archive Oct05


A programmer asked if he would have to create a spec file for his [winelib] libraries but A. Julliard posted: You shouldn't need to export them, you can still link to the library directly at the Unix level, a Winelib dll is still an ELF library. Wine Archive

A programmer asked [Mar 06] is it possible to build real elf binaries with winelib? If i go through the tutorial on winehq.org i get only a appname.exe.so and i have to invoke wine to start the application. Is it possible to compile a binary wich can run stand alone? wine archive

Dimi Paun: No, you would still need the DLLs. It's like having a Win32 binary that includes all the DLLs that come with Windows.

Another devloper pointed to the faq http://winehq.org/site/docs/wine-faq/index


Assessing WineLib for your Port

D. Kegel [when advising a developer considering winelib] [Jul 06]: if you're sticking with x86 only, you should consider just shipping your Windows .exe unchanged, and using Wine instead of Winelib. It works just as well, and it's a lot easier. That's what was done for Picasa. - Dan

[...]If you want to get a foot in the door on OS X, [Wine] might be just the ticket. [...] once you decide to really take the plunge, I highly recommend Codeweavers; they're terriffic

A developer asked [Jul 06] is there a definitive list somewhere what API WineLib implements of Win32, and what it doesn't?

D. Kegel: [Both Wine and Winelib implement the same set of APIs.] Each of Wine's DLL's comes with a file which lists which APIs it implements, e.g. http://source.winehq.org/source/dlls/atl/atl.spec The lines that say 'stub' are not really implemented. http://www.winehq.org/site/winapi_stats has a summary of this data, I think. But even some of the ones that don't say 'stub' are only partial or sham implementations. The real way to tell how many bugs your Windows app will run into is to try simply installing the Windows app on Linux using Wine. Does your app have a regression test or GUI test framework of any sort? If so, you can run that under Wine and compare results. wine archive

Winelib and Apple

Power PC M. McCormack [ Oct 06]: Wine on PowerPC won't be able to do very much. You might be able to run winemine and other WineLib programs that come with Wine, but you won't be able to run Windows binaries, as they require an x86 compatible processor.

P. Krylov: If all you want is to build a Winelib program for Linux/ppc, you can try to comment out shdocvw-related stuff from dlls/Makefile.in, and rebuild. Will work fine if your application does not want this particular dll. wine archive

Winelib help

A developer asked [Apr 06]: Where should winelib questions be asked? The wine-user looks too user level and wine-devel is for Wine coders. wine archive

Dimi Paun: Any development questions (wine or winelib related) belong to wine-devel.

VB Scripting

A developer asked about active scripting (VBScript) [Jul 06]: Basically we wrote some features in VBScript [...] What would be our options for this if we were to use WinLib? [...] Are there any known issue with the native microsoft WSH (Windows Scripting Host)DLL under wine?

D. Kegel: Wine doesn't currently support VBScript (unless you install WSH from Microsoft). That could be added, but it'd be a substantial effort. [...] I know of no issues (other than that this would restrict you to running on x86, but perhaps that's not an issue for you).

B. Harrosh: I have used it under IE under Wine including direct access from a C++ program. It worked fine. I had Ole98 and IE6 native installed. But that was long time ago it might work with out these two.

J. Green suggested consulting a lawyer and D. Kegel agreed: one should always have a lawyer check these things out. For completeness, here's a copy of the WSH 5.6 EULA. Doesn't look like there's any problem to me, surprisingly enough. wine archive

Building a Simple App

A programmer posted [Jun 05] that he had just started with winelib and was trying to: build a simple app (named "type" [a simple program from Petzold's book] . Mkefile generated by winemaker creates type.exe.so; where I would expect either type.exe or simply type. What am I missing?

Dimi Paun: [If] the Makefile [is] using winegcc to compile the app[..], you should get 'type' as the executable.

After closely following the Winelib User's Guide in "Getting started" he reached the point where it says "You are done! Now you can start the application as ./notepad2..." And noted: there is no mention of script that runs ...so - so I was expecting self-contained Linux binary.

Dimi Paun: That's all fine. You should get type.exe.so (correct, we need that) and a type executable that basically does 

> wine type.exe.so

The statement above is still correct. And yeah, you don't have to worry about any script -- you just do ./notepad2 :)

Anon: I take it that means all winelib-ported apps are NOT true linux binaries - but some half-breed between win32 binaries and Linux binaries? What is then the advantage of porting (using winelib)as opposed to running win32 binaries under wine?

Dimi Paun: They are true Linux binaries (ELF format) but they need a bit of setup (for Windows compat) _before_ they start. But yes, running the Win32 (PE) executables instead is a true possibility, same speed, etc. But having a Winelib port allows you to better integrate with the Unix env, which may be what you want for a 'true' Linux app. [...a very long time ago]it's sooo back in the dark ages that's not worth mentioning it was possible to produce stand-alone version...] but don't hold your breath [For it again]-- it's a difficult problem.

S. Ritchie then offered to nearly rewrite the Winelib guide soon.Wine Archives

Michael Ost offers this pared down example in the meantime. Here is a quickie description of how to build a Linux program called "junk" that uses Windows and Linux APIs. This assumes you have a recent wine-devel installed --- mine is 20050930 --- and gcc. Note that you can use "winegcc" with "junk.c". I like C++ so its wineg++. 

create junk.cpp
#include <unistd.h>
#include <windows.h>
int main(int argc, char* argv[])
{
 char bufr[256];
 gethostname(bufr, sizeof(bufr));
 strcat(bufr, " says, 'Howdy World!'");
 MessageBox(NULL, bufr, "Junk", MB_OK);
 return(0);
}
build steps: compile, link, make "launcher" script


WineLib Tips and Tricks

There is a book soon to be released by Prentice Hall on Wine containing information on WineLib.

Update Aug 2005: the book is rolling along. I have seven chapters completed [...]I think I have most of the hard stuff done and the two chapters left shouldn't be too difficult. Right now the review process has been held up by the Winelib sections.[...] Right now my goal is to shoot for finishing those two chapters by mid September partly to coincide with a beta release of Wine. From there we're still at least 6 months from having a book on the shelves.

The licensing on the book will remain OPL. At some point the text will be available to the Wine community. I think that happens about 90 days from the original publication date. I really don't want that to stop anyone from working on the Wine User Guide or Winelib User Guide. Both of those docs are horribly out of date and need some love. Ideally someone would have the User Guide in shape for a beta release.


B. Harroz: [You dont need to pay for Visual C++, you can ] Move to a different compiler on windows. Alternatives:

  • comu-c - (2 WML (Weeks for 1 million Lines) )
  • C++ builder Borland. - (Lots of COM ATL and MFC see MinGW. Lots of Win32API STL and C++ - 4 WML )
  • gcc (MinGW) - (Very very soon - 6 WML )
  • Intel c++ - ( Don't know )

M. Stefaniuc: [You need to] recompile everything as Winelib stuff if you need to run your programs on an other CPU architecture like PPC or SPARC. But for that you need to have the whole source for your application because binary DLLs wont work. Wine Archive Link 

Wine WWN294 Winelib and Native Apps

WineLib Coding Hints

Memory

A programmer posted a demo [Jun 05] and noted: If BUFSIZE is 1044097, there's an error like this:

  • err:seh:setup_exception stack overflow 12 bytes in thread 0009 eip 4057426f esp 40580ff4 stack 0x40580000-0x40680000

If BUFSIZE is 1044096 or lower, there's no error. If BUFSIZE is much higher (like 2000000), there's a segfault. All the program does is define a character array of size BUFSIZE and scribble in it to make sure it really gets allocated. Maybe this simple example will show how to make jack_fst work.

A. Vallacis: Your sample program is trying to use almost 1 megabyte (!) of stack space. No wonder it crashes. Are you sure that your program jack_fst is trying to allocate such an enormous amount of stack space? Most (sane) programs would just declare a pointer and allocate the required space via malloc() or HeapAlloc().

M. McCormack explained how Wine handles the stack: Wine allocates a 1Mb stack by default, and more if a larger stack size is specified in a PE executeable's header. You can specify the size of the a .exe.so's stack by making a def file for it, and adding the line

STACKSIZE 3000000

that should fix the problem, however allocating a 2M buffer on the stack seems like a waste of stack space, so it would be better to fix the program to allocate memory on the heap, or directly using mmap.


Using UNIX path names

  • Proposed interface for file operations by the file dialog code

T. Rollo [Aug 05]:Work is currently proceeding on a branched version to create additional APIs for WINE that use UNIX path names rather than Windows ones. This is useful for Winelib apps and seeks to make them look more like they are native apps, thereby addressing some of the complaints that Winelib apps are somehow of lesser status than ports using other APIs. After some discussion, it was decided that this would remain a branch until at least such time as the implementation was proven to work in real-world situations.[...] Wine Archive


Calling Linux API

K. Ober Oct 05: you're free to use a linux syscall to do whatever you want, including forking the process and exec'ing the linux program. That's the beauty of wine. You have win32 *and* linux APIs available at the same time. Wine Archive

Calling a console app

A developer queried this [sept 07 wine user] and gave two examples:

#include <windows.h>
void main( void ) {
system( "foo.exe" );
}
#include <windows.h>
void main( void ) {
WinExec( "foo.exe", SW_SHOW );
}

where "foo.exe" is a windows console aplication. if i [..] launch foo.exe with wine in a terminal window [eg]: wine foo.exe is working fine !

Another devloper noted: It worked for me though. Could you specify what kind of error you got?

P. Romanyszyn [Sept 07] I have been using this in borland BC++4.5 and it works with ubuntu 7.04 and has for several other distro's in the last few years. It is a 16 bit application.

stpcpy(comandstr,"kpnl320.exe ");
strcat(comandstr,_argv[0]); /* pass executable file name to application */
if (FindWindow(0,"Simulator EDD-320") == NULL)
WinExec(comandstr,SW_SHOWNA);

GetFileDialog

+    if (win16look)
+        return GetFileName31W(ofn, SAVE_DIALOG);
+    else

S. Edwards May05 Wine Archive Link: You should not need any of this for a Winelib app. Office97 does this where it creates a 32bit dialog with a Win16 look and its needed for backwards compatiblity only. No new application should depend on this behavior and clearly not one that you have the source code to in Winelib. I already broke this in Wine once. Just return GetFileDialog95W. 

+        return GetFileDialog95W(ofn, SAVE_DIALOG, TRUE);
}


Running a Dll

A Programmer asked if they could run a dll.

B. Medland [july 05]: [If] you mean that you have a dll that also links to kernel32.dll, and you want a Linux program to make a call into that dll. The closest that you can get to this is to look at winemaker and in the end your Linux program will have to be a Linux shared object that is called by Wine; then it will be able to call the dll.


A programmer asked: Could I encapsulate my windows dll and make it be(by winemaker) a linux shared dll(.so),and at my linux program to call this dll(.so)?

B. Medland [July 05]: No, I'm afraid not. The whole point is that wine itself must be the actual process that runs (so that it can do a load of clever stuff to make memory and threading and ... work). Do you have control of the linux program? (i.e. Is it your own program so that you can edit it etc.) If so then I suppose you should be able to make your program into a shared object rather than an executable and then write a tiny windows executable around it. Wine Archive

Calling a Native Windows dll from Linux

A developer asked how to call a Windows PE Dll from Linux [Wine devel Aug 07]: I found the sameness issues in mail list. 03, 05, 04, 06. I have tried the ways discussed in these threads。 But it's not clear enough how to do this. So I send this mail to you for some help.

I have a PE Dll named Arithmetic.dll which exports a function, it's prototype is:

void sort(unsigned int*, int num)

I want to call the function in my Linux App. I used winedump to generate a spec file

winedump spec Arithmetic.dll

This comand generated three files: Arithmetic_dll.h Arithmetic_main.c and Arithmeticspec. What's the next exactly step I should do? What's the usage of the three files? And wow could I use them?

R. Colenbrander: The easiest way would be to use LoadLibrary/GetProcAddress to load the function from the library. That way you avoid linking to it which makes things more complicated. In order to be able to use wine functions you need to (re)compile parts of your program using Winelib (e.g. winegcc/wineg++). Your program will depend on Wine but you will be able to use the win32 dll.

Thunderbird [Feb 2010 wineusr]: The easiest one is to dynamically load the dll using LoadLibrary and load the functions you need using GetProcAddress.

D. Jovanovic: You can't [call the function in a Linux App], it's not supported (yet), but what you want is the Wine plugin API (http://wiki.winehq.org/WinePluginApi). At the moment you have 2 options:

  • Make a Windows application instead of a Linux application.
  • Make a winelib application which will require wine to run but can access Linux libraries as well (with some restrictions, eg. you have to use Windows synchronization primitives instead of the pthreads ones).

[july 09 update J. McKenzie: Wine pthread is[..] gone [..] because Linux and UNIX both do not support it anymore. If you really, really, really need it,get Wine 1.0.1 for now.]

[He then gave an example of how to use the files from winedump]:

#include <windows.h>

int main(int argc, char **argv) {

HANDLE h;
void (/*WINAPI?*/ *sort)(unsigned int,int); unsigned int *nums =
malloc(sizeof(unsigned int) * 4); nums[0] = 3;
nums[1] = 2;
nums[2] = 1;
nums[3] = 0;
h = LoadLibrary("Arithmetic.dll");
sort = GetProcAddress(h, "sort");
sort(nums, 4);

}

Then use wineg cc main.c -o m a i n . / m a i n


the developer reported: I have tried [the] code, It works well. Thanks a lot. Could I use g cc/g ++ instead of wineg cc/wineg ++ mplayer use gcc as it's complier？ What's the mystery in it?

D. Jovanovic: g cc/g ++ would give you the wrong ABI (eg. 4 bytes per wide char instead of 2 bytes), and the special code needed to set up the Windows memory layout and the thread extension block and structured exception handling wouldn't get executed, leading to segfaults when you call any code that tries to access them. That's assuming you can even compile and link. That's why you need wineg cc/wineg ++.


The Developer asked: Can I made Arithmetic.dll.so ? And link it against my linux App?

D. Jovanovic: A library function runs in the context of the process that invokes it. A library doesn't have its own TEB/memory layout/exception handling that works independently of the process that calls it, no matter how it is compiled. If the wine plugin API is ever made, it will modify the process so it has what the library expects when the library functions are called. Does your Arithmetic.dll.so call any Windows functions? If so, you need wine and you will always need wine, plugin API or no plugin API, whether you compile it into a DLL or .dll.so. But if you only use ANCI C stuff you can compile it into a .so and use it without wine.

The developer noted: my Arithmetic.dll does not call any windows function. It's pure ANSI C library. What's the step of m ake .dll.so ?? Use wineg cc or g cc ??


D. Jovanovic: Use g cc and m ake a .so like this:


g cc -c arithmetic.c -fPIC g cc arithmetic.o -shared -o arithmetic.so


Then put it in /usr/lib and link to it like so:

g cc -c application.c g cc application.o -o application -larithmetic

A programmer wrote [wine user July & Aug 07]: I have a win32 DLL library, which I can't decompile, and can't get it's source code, but which I'd like to use in my Linux program. I wondered about making a win32<->Linux interface to use this library, using ready-to-use wine libraries.

Is it possible, using wine libraries, to have access to functions from this DLL?

G. Streeter: The answer is yes. This is a typical scenario for a winelib program. dlls can be swapped between native and windows. So write your C code. Use LoadLibrary() and GetProcAddress(). Call your routine accordingly. The winelib libraries will do the hard work of loading the dlls for you. If you don't need dynamic linking there may be even easier techniques. Either way you need to read the winelib documentation.

Victor: As I know, wine provides "winelib". Linking with winelib should provide access for replacements of WinAPI functions like "LoadLibrary" and "GetProcAddress".


A programmer asked Jun 2007 Wine devel]: [How can I write a shared library that uses Wine and can be called from a non-winelib app?]

S. Dossinger: your plugin, that loads the dll, needs to run in Wine's environment in order to be able to load the dll. So you have to write a winelib dll. If the plugin is loaded as a library in your host app, the whole host app would have to be a winelib app. Not good :-( So you can split your plugin into two parts, one is the plugin that runs in the host app, the other one is a seperate winelib application that runs in a seperate process and loads the win32 dll. That way the dll gets the virtual memory setup it needs. The two parts of your plugin can use any Unix IPC techniques you feel like using - sockets, pipes, shared memory, semaphores, whatever. You could forward function calls using pipes, transport bigger blobs using shared memory, and synchronise everything using semaphores(and implicit pipe synchronisation).

D. Kegel: wine's code requires that the process have been set up somewhat specially. This is taken care of by the sources in the loader subdirectory. In a perfect world, some of that code would move into the operating system's process loader... then one could mix and match win32 and unix calls more easily. Anyway, knowing about the code in that directory is key to understanding why what you ask is hard, and in finding a workaround.


A programmer queried [Sept 06]: I have a windows dll and header files. I want to make a library that I can link to and use on linux. What are the steps required to do this?

D. Kegal: That's on the to-do list.

J. White: It's not [...] black and white,[...] I believe you can, and it actually works reasonably well. BUT there's a big catch - you have to make your program into a Winelib application. That is, what you (reasonably) want is just a simple foo.so you can dlopen and then do invoke_my_windows_function(). You can get that, but what you have to do is rename your main to be linux_main, and then write a whole new WinMain which invokes your linux_main. Then, from within your linux app, you can write some glue to make the connection. You can get into trouble if you depend heavily on particular IPC mechanisms, threading in particular, but I believe that basic usages should still work. So, basically, if you're willing to stand your application on its head, you can get the functionality you want [..]] wine archive.

T. Rollo: Actually there's probably an easier way - a scheme I've been considering is one involving a crt0.o designed to load Wine (essentially making the native executable an equivalent of wine-pthread with other stuff), then start a Winelib program whose entry point calls back into a second entry point in the original executable. This scheme ought to work without any modifications to the core of Wine. We also wouldn't need to be reserving any memory areas [He then gave an example].

The programmer reported: I have been working on the Winelib approach suggested by Jeremy. As my first step I wanted to get a windows console application to compile and run anyway. I now have an executable that runs and calls functions in the windows dll, but it does not work correctly. If I run it with winedbg it gives me a backtrace with errors coming from deep inside the dll. I assume there is some problem with the arguments going to the function that serves as the entry to the dll. Is there a way to find out what is getting passed to the dll and/or debugging inside the dll (without source code)?

Jacob suggested to check if wine could run the dll: Can you open the DLL from a very simple standard Windows EXE with Wine? If that doesn't work, there is probably something within the DLL that Wine can not handle, yet. wine archive

A programmer reported [Dec 05]: I am having a Simple DLL that was developed and used by the Windows Application. I am trying to port this windows DLL into linux to create the .so file and want to use the same.

  • As metioned in the winedump tool, I generated the spec file using the command
    > winedump spec simple.dll

and inserted the Stub DLL into wine tree as metioned in the winedump README (I am able to see the simple.dll.so file dlls directory.)

  • I created the .def file using the winebuild in the dlls/SimpleDll directory.

When I try to load this dll using "LoadLibrary("Simple.dll")" I am getting the "Module Notfound error". I tried the same function after loading the same .so file into /usr/local/lib/wine also. Still I am getting the same error. BTW: I am able to load the built-in dlls in wine without any problem.

He then posted the solution: The problem is due to the Dll Name UpperCase.wine archive

ything usable, and there seems to be no official documentation on how to use winebuild here. The program is called test.c, calling symbols from a vendor-supplied header file.

He created test.o through winegcc using -Wall -O2 -I. -c -o test.o test.c

[...] i've played with winedump, finally got a vendor.dll.spec. I'm calling winebuild to get a .def as follows: 

winebuild --def -E vendor.dll.spec -o libvendor.def

then, one of my better guesses on how to proceed seemed to be: 

winebuild --dll -fPIC -E vendor.dll.spec -L. -lvendor test.o -o libmxmapi32.dll.s

[...]though, linking fails with duplicate symbols: 

using winegcc with..   test.o libmxmapi32.dll.o   -o test
[...]
multiple definition of `__wine_spec_nt_header'
[...]
multiple definition of `__wine_spec_file_name'

i'm aware that i could probably avoid all of this by just using LoadLibrary() and resolving the symbols at runtime. [On the other hand], the approach above is potentially simpler, if i just knew how. :)

M. McCormack: Why not just use LoadLibrary("vendor.dll") and GetProcAddress() in you winelib application instead of mucking round with winegcc and winebuild in order to directly link your dll?

He had considered this, but: linking directly would work on windows and since the .def-mechanism with wine tools is supposed to support just that, and since, for the purpose in question, i really don't see the point in programming the dynamic loader manually, why not give it a try as well

A. Julliard: Once you have libvendor.def you should be able to simply do: 

winegcc using... -o test test.o -lvendor

He reported back: i've got both the compile-time linking as well runtime loading running now. Works well. wine archive


A Programmer posted [Nov 05]: i've got a native [...] dll which i would like to hook into on a linux box. no source code available. The case is almost identical to http://www.winehq.com/hypermail/wine-devel/2003/12/index.html#231 though, there's not much application code yet, except a small test program written by myself, currently only meant to call a single function on the dll. [...] winemaker doesn't spit out an

A developer [sept 07 wine devel] Missing MFC42 and other redistributable DLLs is a showstopper for winelib and running windows code on non i386 archtecture...

S. Dossinger: I think you can compile MFC42 for winelib and other architectures, the source code is publically accessible(shipped with visual studio). It is a bit tricky, and you have to get the license right, but there is a HOWTO somewhere on the wine website and it should work.

F. Gouget: Well, not quite. If you're going to use Winelib it means that you have the source of the application. And if it is using the MFC it should mean that you have a Visual Studio license, and thus the MFC sources (though maybe that's only in the 'Pro' edition or some such). So then you should be able to recompile the MFC using Winelib. That's exactly what I did five years or so ago. I had to trim quite a few things but got something that was somewhat usable. I did not pursue it further though. Modern day MFC probably changed a bit (did it really change much?), but then Winelib should be much better too. The real issue is the license. In the Visual Studio 6 era, it seemed like it was legal to redistribute the MFC dll with your non-trivial application, with no mention of the platform. This might have changed since, and in any case that's something you'd want to check with a lawyer.

D. Kegel: since mfc42.dll is a Visual C++ runtime file that has very liberal redistribution terms and is in fact bundled with many apps, we can get away without it for a long time. And it's not currently a showstopper as far as I can tell; I'm more interested in the bugs that keep e.g. Photoshop from running flawlessly. So one of these days it might become a priority. Until then, it's merely important but not urgent.

Closing

A programmer commented: I would like my Winelib application to do a normal shutdown from a signal, that is save files and exit normally. From scanning the web SIGTERM seems like the natural choice. It looks like it is _supposed_ to be used for a normal exit. But Wine seems to reserve SIGTERM for a summary execution with pthread_abort.

It looks like I could use SIGQUIT, since Wine doesn't seem to care about it. But, again from scanning the web, SIGQUIT is _supposed_ to be used for non-normal exits. So, is it best to use SIGQUIT in a non-canonical way or try to change how SIGTERM is handled by Wine and make it more canonical?

A. Julliard: SIGTERM in Wine corresponds to TerminateThread, which is the standard way to kill a thread in Win32, so it sounds very much canonical, I don't think you want to change it.

You can certainly use SIGQUIT, but if you are defining your own mechanism, using signals is probably not the best choice. Cleaning up properly on a signal is pretty hard to do right, and even harder in Wine since we use signals for our own purposes.

The programmer offered a simple example: All I want to do is PostQuitMessage(0). Does this look safe as a SIGQUIT handler?

static void exit_handler(int signal)
{
printf("%s: got exit signal(%d)\n", __FUNCTION__, signal);
PostQuitMessage(0);
}

A. Julliard: It should be safe, as long as you never run 16-bit code; you also need to add SIGQUIT to the various signal masks in ntdll. But a small Winelib app that sends a WM_QUIT message to the main app is probably a lot easier...

The programmer ran some tests and reported: Well the signal works without patching ntdll. But A. Julliard cautioned: If you don't add it to the signal masks, it will work most of the time, and fail dramatically when the signal happens at just the wrong spot. wine archive

Sharing Wine window messages

A user asked [Nov 05]: if there was means of running two progams in the same context on wine in such a way that they use the same message queue and can therefore potencially interact.

M. Meissner: Running two "wine foo.exe" will act as if on the same machine, including interchange of windows messages if the apps do that.

Another programmer noted this had potential for users of winelib: I could create 2 wine apps that simply duplicate the window creation and message handling , and have them use FindWindow and the like to enable using SendMessage and such to synchronize the windows.wine archive

WineLib Debugging

T. Rollo: I now use a modified gdb+insight under Linux to debug Borland compiled executables under WINE, together with some scripts that allow me to debug Borland code and GCC code in the same session.Wine Archive Link

Anon: If a developer is used to Windows MSDEV, they might like KDevelop3. The debugger is also nice for Winelib


Cross Compiling

E. Frias: We're working on setting up an environment to cross-compile a winelib application (initially from x86 linux to sparc solaris). To do this, we need a cross-compiling version of winebuild which will generate the assembly code for the target architecture instead of the build architecture.

A. Julliard: I think the right way is to get rid of the #ifdefs [in winebuild?], but not by pushing them into the .spec.c file but my making the target a run-time option. I've been meaning to do this for a while now, I was just waiting for someone to actually need that feature ;-)

D. Jankovic [Aug 05]: Recently, a target option was added to winebuild, and winebuild code was changed to use this option instead of preprocessor defines. I was wondering if a similar option will be added to winegcc, based on which it would pass the corresponding option to winebuild. When using winegcc to crossbuild wine dlls between different platforms (for instance x86-linux and sparc-solaris) that have different endianess more problems arise, especially related to resources. The resource compiler has --endianess option that caould be used to crosscompile resources, but winebuild always reads resource files as if they were compiled natively, maining --endianess cannot be used to crossbuild. Correct me if I'm wrong. If I want to be able to crossbuild from x86-linux to sparc-solaris, I need to compile resources with big-endianess and have winebuild use the target option to recognize that resource file was compiled with big-endianess and read it as such, and not natively. This is not the case currently. Like I said, winebuild reads the res file using native byteorder and fails to check res header.

A. Julliard: I put in a fix to byteswap the resource header if necessary, hopefully this will do the right thing in your case. Wine Archive


Further Reading

WineLib Troubleshooting

General Troubleshooting

Obtaining Older Versions

Steve: I'm running the 2.6.11.7 kernel with the debian distribution. I can't find the 20041019 version for libwine. What filename at http://prdownloads.sourceforge.net/wine corresponds to libwine?

E. Charpentier: You may try to search the "official" Debian unstable packages on http://snapshot.debian.net (an unofficial but extremely useful repository of all past Debian package versions). Alternatively, you may try to ask Scott Ritchie if he still has his highly unofficial build (ISTR that he did such a build).


Obtaining the wine sources
R. Muller [Jun 06] : the Winelib guide assumes that you know how to download the wine sources already. (Quick and dirty meathod of downloading the latest official tarball: On the main WineHQ page, the latest announcement "Wine 0.9.x released" or somesuch has a link "available now"; move it to an appropriate place, then unarchive it:

tar using the flags -xjf wine-0.9.15.tar.bz2 <or somesuch>)

At this point, the sentance that gave you problems could be modified to say: It can be found in the programs subdirectory of the wine source. wine archive

Troubleshooting with the notepad example

E. Frias: the procedure described won't create the 'notepad2' script. [...] running ln -s ../../tools/winewrapper notepad2 to create the script

A. Julliard: winegcc should create the script. If it doesn't it's probably because winemaker is not invoking it correctly.

E. Frias: Winemaker [was invoking wingcc and] foo.exe.so,which suppresses the wrapper script. If it's invoked [with] foo.exe it generates the wrapper script as desired. Something like the attached patch should fix the problem. [A patch was offered]. wine archive


Text application (notepad) segfaults
[Jan 06] A programmer was trying to compile the test application (Notepad) with winelib to get a feel for how to use it. I followed the instructions in your docs, [...] ended up with a target file notepad2.exe.so. The instructions [...] tell me to run [the executable called notepad2]. If I run the .so file it segfaults [...]

I am using WINE-0.9.4 built by Adam Schreiber for Slackware 10.2. He then gave his output (so you can see exactly what he did):

System()

A programmer reported: I tried to call another .exe file in my own exe file by using the system() API. But the return value of system() is -1 and errno is set to ENOENT. It indicates that the another exe file is not found.

F. Gouget: That must be because you're calling the Unix system() function. If you want system() to work in Wine applications you must link with msvcrt and call its implementation of system(). [wine devel Jul 07]

Odds and Ends, things without a place

K. Smelkov [Wine devel Sept 07 http://permalink.gmane.org/gmane.comp.emulators.wine.patches/41146 ] am going to port some Win32 applications to GNU/Linux and though it would be useful to improve the build system for Winelib applications.

Current status and Motivation

  1. Wine in-tree Makefiles for programs & dlls are pretty much good and maintainable, but they lack C++ support.
  2. . Initial approach taken by winemaker (I used it in 2003-2004) was to adapt Wine's make rules to support C++ .
  3. . At present winemaker dropped supplying above mentioned rules and generates very simple makefiles. To me this approach have several problems:
    • lack of dependency tracking
    • hard to maintain Makefiles. The rules generated are substituted in each Makefile instead of being in one place.
    • good as a starting point, but not a complete solution.


Winemaker already relies on GNU toolchain (in form of gcc and g++), and I thought: Why not use GNU make with all available extensions when necessary, and deploy a simple full-featured build system for Winelib based applications [He posted] The result [...] for public review. Comments, suggestions?

Retrieved from "http://wiki.jswindle.com/index.php/WineLib"
Personal tools