| <chapter id="portability-issues"> |
| <title id="portability-issues.title">Portability issues</title> |
| |
| <sect1 id="unicode"> |
| <title id="unicode.title">Unicode</title> |
| |
| <para> |
| The <literal>wchar_t</literal> 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 |
| <parameter>-fshort-wchar</parameter> option to set the |
| size of <literal>wchar_t</literal> to the one expected |
| by Windows applications. |
| </para> |
| |
| <para> |
| If you are using Unicode and you want to be able to use |
| standard library calls (e.g. <function>wcslen</function>, |
| <function>wsprintf</function>), then you must use |
| the msvcrt runtime library instead of glibc. The functions in |
| glibc will not work correctly with 16 bit strings. |
| </para> |
| </sect1> |
| |
| <sect1 id="C-library"> |
| <title id="C-library.title">C library</title> |
| |
| <para> |
| There are 2 choices available to you regarding which C library |
| to use: the native glibc C library or the msvcrt C library. |
| </para> |
| |
| <para> |
| Note that under Wine, the crtdll library is implemented using |
| msvcrt, so there is no benefit in trying to use it. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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: |
| </para> |
| <orderedlist> |
| <listitem> |
| <para> |
| Your application uses Win32 and C library unicode |
| functions. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Your application uses MS specific calls like |
| <function>beginthread()</function>, |
| <function>loadlibrary()</function>, etc. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| You rely on the precise semantics of the calls, for |
| example, returning <literal>-1</literal> rather than |
| non-zero. More likely, your application will rely on calls |
| like <function>fopen()</function> taking a Windows path |
| rather than a Unix one. |
| </para> |
| </listitem> |
| </orderedlist> |
| <para> |
| In these cases you should use msvcrt to provide your C runtime |
| calls. |
| </para> |
| |
| <programlisting>import msvcrt.dll</programlisting> |
| |
| <para> |
| to your applications <filename>.spec</filename> file. This |
| will cause <command>winebuild</command> to resolve your c |
| library calls to <filename>msvcrt.dll</filename>. Many simple |
| calls which behave the same have been specified as |
| non-importable from msvcrt; in these cases |
| <command>winebuild</command> will not resolve them and the |
| standard linker <command>ld</command> will link to the glibc |
| version instead. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| If you have a set of include files (or when they are available |
| in Wine), you need to use the <parameter>-isystem |
| "include_path"</parameter> flag to gcc to tell it to use your |
| headers in preference to the local system headers. |
| </para> |
| <para> |
| To use option 3, add the names of any symbols that you don't |
| want to use from msvcrt into your applications |
| <filename>.spec</filename> file. For example, if you wanted |
| the MS specific functions, but not file I/O, you could have a |
| list like: |
| </para> |
| |
| <programlisting>@ignore = ( fopen fclose fwrite fread fputs fgets )</programlisting> |
| <para> |
| Obviously, the complete list would be much longer. Remember |
| too that some functions are implemented with an underscore in |
| their name and <function>#define</function>d to that name in |
| the MS headers. So you may need to find out the name by |
| examining <filename>dlls/msvcrt/msvcrt.spec</filename> to get |
| the correct name for your <function>@ignore</function> entry. |
| </para> |
| </sect1> |
| |
| <sect1 id="porting-compiling"> |
| <title id="porting-compiling.title">Compiling Problems</title> |
| <para> |
| If you get undefined references to Win32 API calls when |
| building your application: if you have a VC++ |
| <filename>.dsp</filename> file, check it for all the |
| <filename>.lib</filename> files it imports, and add them to |
| your applications <filename>.spec</filename> |
| file. <command>winebuild</command> 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 <filename>dlls/</filename> directory of the Wine source |
| tree. |
| </para> |
| <para> |
| If you are missing GUIDs at the link stage, add |
| <parameter>-lwine_uuid</parameter> to the link line. |
| </para> |
| <para> |
| 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). |
| </para> |
| <para> |
| If you come across a difference between the Windows headers |
| and Wine's that breaks compilation, try asking for help on |
| <email>wine-devel@winehq.org</email>. |
| </para> |
| </sect1> |
| |
| </chapter> |
| |
| <!-- Keep this comment at the end of the file |
| Local variables: |
| mode: sgml |
| sgml-parent-document:("winelib-user.sgml" "book" "chapter" "") |
| End: |
| --> |