The wchar_t type has different standard sizes in Unix (4 bytes) and Windows (2 bytes). You need a recent gcc version (2.9.7 or later) that supports the -fshort-wchar option to set the size of wchar_t to the one expected by Windows applications. If you are using Unicode and you want to be able to use standard library calls (e.g. wcslen, wsprintf), then you must use the msvcrt runtime library instead of glibc. The functions in glibc will not work correctly with 16 bit strings. There are 2 choices available to you regarding which C library to use: the native glibc C library or the msvcrt C library. Note that under Wine, the crtdll library is implemented using msvcrt, so there is no benefit in trying to use it. Using glibc in general has the lowest overhead, but this is really only important for file I/O, as many of the functions in msvcrt are simply resolved to glibc. To use glibc, you don't need to make changes to your application; it should work straight away. There are a few situations in which using glibc is not possible: Your application uses Win32 and C library unicode functions. Your application uses MS specific calls like beginthread(), loadlibrary(), etc. You rely on the precise semantics of the calls, for example, returning -1 rather than non-zero. More likely, your application will rely on calls like fopen() taking a Windows path rather than a Unix one. In these cases you should use msvcrt to provide your C runtime calls. import msvcrt.dll to your applications .spec file. This will cause winebuild to resolve your c library calls to msvcrt.dll. Many simple calls which behave the same have been specified as non-importable from msvcrt; in these cases winebuild will not resolve them and the standard linker ld will link to the glibc version instead. In order to avoid warnings in C (and potential errors in C++) from not having prototypes, you may need to use a set of MS compatible header files. These are scheduled for inclusion into Wine but at the time of writing are not available. Until they are, you can try prototyping the functions you need, or just live with the warnings. If you have a set of include files (or when they are available in Wine), you need to use the -isystem "include_path" flag to gcc to tell it to use your headers in preference to the local system headers. To use option 3, add the names of any symbols that you don't want to use from msvcrt into your applications .spec file. For example, if you wanted the MS specific functions, but not file I/O, you could have a list like: @ignore = ( fopen fclose fwrite fread fputs fgets ) Obviously, the complete list would be much longer. Remember too that some functions are implemented with an underscore in their name and #defined to that name in the MS headers. So you may need to find out the name by examining dlls/msvcrt/msvcrt.spec to get the correct name for your @ignore entry. If you get undefined references to Win32 API calls when building your application: if you have a VC++ .dsp file, check it for all the .lib files it imports, and add them to your applications .spec file. winebuild gives you a warning for unused imports so you can delete the ones you don't need later. Failing that, just import all the DLL's you can find in the dlls/ directory of the Wine source tree. If you are missing GUIDs at the link stage, add -lwine_uuid to the link line. gcc is more strict than VC++, especially when compiling C++. This may require you to add casts to your C++ to prevent overloading ambiguities between similar types (such as two overloads that take int and char respectively). If you come across a difference between the Windows headers and Wine's that breaks compilation, try asking for help on wine-devel@winehq.org.