From 5cb89119d3d19aacc139d42d9bf989ac6a6488f6 Mon Sep 17 00:00:00 2001 From: "Dimitrie O. Paun" Date: Mon, 15 Sep 2003 20:09:07 +0000 Subject: [PATCH] Remove no longer current issues from the Winelib guide. --- documentation/winelib-porting.sgml | 144 +++-------------------------- 1 file changed, 13 insertions(+), 131 deletions(-) diff --git a/documentation/winelib-porting.sgml b/documentation/winelib-porting.sgml index e76d78576c5..71f6f2f672a 100644 --- a/documentation/winelib-porting.sgml +++ b/documentation/winelib-porting.sgml @@ -1,125 +1,26 @@ Portability issues - - Anonymous unions/structs - - Anonymous structs and unions support depends heavily on the compiler. - The best support is provided by gcc/g++ 2.96 and later. But these - versions of gcc come from the development branch so you may want to - hold off before using them in production. g++ 2.95 supports anonymous - unions but not anonymous structs and gcc 2.95 supports neither. Older - versions of gcc/g++ have no support for either. - since it is anonymous unions that are the most frequent in the - windows headers, you should at least try to use gcc/g++ 2.95. - - - But you are stuck with a compiler that does not support anonymous - structs/unions all is not lost. The Wine headers should detect this - automatically and define NONAMELESSUNION / - NONAMELESSSTRUCT. Then any anonymous union will - be given a name - u or u2, u3, - etc. to avoid name clashes. You will then have to modify your code to - include those names where appropriate. - - - The name that Wine adds to anonymous unions should match that used - by the Windows headers. So all you have to do to compile your - modified code in Windows is to explicitly define the - NONAMELESSUNION macro. Note that it would be wise - to also explicitly define this macro on in your Unix makefile - (Makefile.in) to make sure your code will - compile even if the compiler does support anonymous unions. - - - Things are not as nice when dealing with anonymous structs. - Unfortunately the Windows headers make no provisions for compilers - that do not support anonymous structs. So you will need to be more - subtle when modifying your code if you still want it to compile in - Windows. Here's a way to do it: - - -#ifdef WINELIB -#define ANONS .s -#else -#define ANONS -#endif - -. . . - -{ -SYSTEM_INFO si; -GetSystemInfo(&si); -printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture); -} - - - You may put the #define directive directly in the - source if only few files are impacted. Otherwise it's probably best - to put it in one of your project's widely used headers. - Fortunately usage of an anonymous struct is much rarer than usage of - an anonymous union so these modifications should not be too much work. - - - Unicode - Because gcc and glibc use 4 byte unicode characters, the - compiler intrinsic L"foo" generates unicode - strings which cannot be used by Winelib (Win32 code expects 16 - bit unicode characters). There are 3 workarounds for this: + The wchar_t type has different standard + sizes in Unix (4 bytes) and Windows (2 bytes). Recent versions + of gcc (2.9.7 or later) support the + -fshort-wchar option to set the + size of wchar_t to the one expected + by Windows applications. Pass this option to every file + that is built. - - - - Use the latest gcc version (2.9.7 or later), and pass the - -fshort-wchar option to every file - that is built. - - - - - Use the __TEXT("foo") macro, define - WINE_UNICODE_REWRITE for each file - that is built, and add - -fwritable-strings to the compiler - command line. You should replace all occurrences of - wchar_t with WCHAR also, since - wchar_t is the native (32 bit) type. These - changes allow Wine to modify the native unicode strings - created by the compiler in place, so that they are 16 bit - by the time any functions get to use them. This scheme - works with older versions of gcc (2.95.x+). - - - - - Use the compiler default, but don't call any Win32 unicode - function without converting the strings first! - - - - If you are using Unicode and you want to be able to use standard library calls (e.g. wcslen, - wsprintf) as well as Win32 unicode calls - (API functions ending in W, or having - _UNICODE defined), then you should use + wsprintf), then you must use the msvcrt runtime library instead of glibc. The functions in glibc will not work correctly with 16 bit strings. - - If you need a Unicode string even when - _UNICODE isn't defined, use - WINE_UNICODE_TEXT("foo"). This will need - to be wrapped in #ifdef WINELIB to - prevent breaking your source for windows compiles. - To prevent warnings when declaring a single unicode character in C, use (WCHAR)L'x', rather than @@ -141,37 +42,18 @@ printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture); --> - There are 3 choices available to you regarding which C library - to use: + There are 2 choices available to you regarding which C library + to use: the native glibc C library or the msvcrt C library. - - - - Use the glibc native C library. - - - - - Use the msvcrt C library. - - - - - Use a custom mixture of both. - - - - 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. Many of the functions in - msvcrt are simply resolved to glibc, so in reality options 2 - and 3 are fairly similar choices. + 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 @@ -204,7 +86,7 @@ printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture); In these cases you should use msvcrt to provide your C runtime - calls. To do this, add a line: + calls. import msvcrt.dll