WWN Issue 46

This is the 46th release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

If you haven't already answered our <kcref> survey</kcref> last week, do so now; we will report on the results next week.

To keep more up-to-date on Wine's progress, the Wine Weekly News has created a Wine Status page. If there are any of the items listed on the status page (or even items that are not listed) that you'd like the Wine Weekly News to write a feature or howto article about, please send your requests to us at [email protected], so we can see what will be the most interesting for our users.

The WineHQ server is now hosted by Corel. You can read the announce .

This week, 144 posts consumed 392 K. There were 53 different contributors. 24 (45%) posted more than once. 28 (52%) posted last week too.

The top 5 posters of the week were:

17 posts in 34K by Alexandre Julliard
14 posts in 27K by Uwe Bonnes
10 posts in 16K by Ove Kaaven
10 posts in 29K by Bertho Stultiens
6 posts in 17K by Douglas Ridgway

Address space separation 28 May 2000 00:00:00 -0800 Archive

Address space separation	28 May 2000 00:00:00 -0800	Archive
The long awaited address space separation patch has been committed. As already covered in previous issues ( <kcref>#39</kcref> and <kcref>#27</kcref>, ), this patch lets every Windows' process run in its own address space (in term of Unix memory mappings). This firstly allow to get rid of the famous error where Wine was unable to run a 'stripped binary' with another process. Lots of people posted positive feedback on the patch, some others (like Gérard Patel, Ove Kaaven, Guy Albertelli) pointed out some errors that were quickly fixed. The most noticeable bad sides of this patch are: the -desktop option no longer work when more than one process is launched DOS (MZ) processes are no longer supported it seems that the patch is less robust with 16 bit apps than for 32 bit ones support for native USER is now broken inter-process message sending is also broken There are a few other changes, mostly involving the command line options: Wine is no longer able to spawn several processes at once. Before, it was legal to use `[old way] wine telnet freecell` Now, you must invoke twice the wine interpreter on the command line. The good side of it is you no longer need to put the optional arguments to your program into quotes on the command line. Before you had to write: `[old way] wine "winword.exe mytext.doc"` now you must write `[new way] wine winword.exe mytext.doc` Notes: if any path (to the executable, or to a file name) contains spaces, you need to tell the shell not to interpret those spaces as separators using back slashes or quotes. For example, if you used to write: `[old way] wine "c:\winnt\winhlp32.exe d:\borland\Borland Shared\MSHelp\win32.hlp"` now you need to write: `[new way] wine c:\\winnt\\winhlp32.exe d:\\borland\\Borland\ Shared\\MSHelp\\win32.hlp` or `[new way] wine c:\\winnt\\winhlp32.exe "d:\borland\Borland Shared\MSHelp\win32.hlp"` if among the arguments to your program, one starts with a dash, you'd better use `[new way] wine --desktop 640x480 -- hl.exe -console` note the '--' to tell Wine not to look for options after this sign (and consider the rest of the command line as parameters to create the new process).

The long awaited address space separation patch has been committed. As already covered in previous issues ( <kcref>#39</kcref> and <kcref>#27</kcref>, ), this patch lets every Windows' process run in its own address space (in term of Unix memory mappings). This firstly allow to get rid of the famous error where Wine was unable to run a 'stripped binary' with another process.

Lots of people posted positive feedback on the patch, some others (like Gérard Patel, Ove Kaaven, Guy Albertelli) pointed out some errors that were quickly fixed.

The most noticeable bad sides of this patch are:

There are a few other changes, mostly involving the command line options:

[old way] wine telnet freecell

[old way] wine "winword.exe mytext.doc"

[new way] wine winword.exe mytext.doc

[old way] wine "c:\winnt\winhlp32.exe d:\borland\Borland
Shared\MSHelp\win32.hlp"

[new way] wine c:\\winnt\\winhlp32.exe d:\\borland\\Borland\
Shared\\MSHelp\\win32.hlp

[new way] wine c:\\winnt\\winhlp32.exe "d:\borland\Borland
Shared\MSHelp\win32.hlp"

[new way] wine --desktop 640x480 -- hl.exe -console

Code-pages in Wine	29 May 2000 00:00:00 -0800	Archive
Bertho Stultiens announced: I am currently implementing the Wine Message Compiler (wmc: as an alternative to mc.exe). I need to implement quite a bit unicode support for it to function correctly. Unicode requires a lot of tables for conversion and I did just that for nearly all codepages (from ftp.unicode.org). Alexandre Julliard answered Dmitry Timoshkov has been working with him integrating the same needed basic features into Wine (like on demand translation table loading...). Both agreed that (g)libc didn't provide yet a reliable Unicode support, and that a separate one shall be provided. However, since the wmc message compiler shall be used to compile Wine, it would be difficult to make it heavily rely on Wine features. Also, Bertho would like to keep wmc (as wrc - the Wine resource compiler - is) independent of Wine. Bertho suggested I am not suggesting to build libunicode.so, but I do suggest to build libunicode.a, which can be linked against. This should not require a special API if it only concerns tables. The point is that libunicode.a should be self-sufficient so that you can take it out of wine's context just far enough so that it becomes usable in a wider sense. Basically, you need to place the unicode code isolated and only provide the mere minimum of API which would also be required within wine's context. This enables me to reuse the data/code in wrc without requiring a complete wine-build and does not complicate wine's internal API because it isn't really extended, but merely reused. It would be a shame to neglect the potential while not much effort is required. Alexandre agreed on the general scheme, but wasn't happy with creating another library. He strongly kept his opinion on providing those features from libwine.so. However, both agreed that libwine.so currently contains too many things and shall lose some weight (starting with removing USER and GDI code). Alexandre announced he shall start committing the code-pages to CVS when the Address Space Separation stops shaking the (CVS) tree, and asked Bertho to send also his prepatch so that both efforts shall be merged together.

Code-pages in Wine

29 May 2000 00:00:00 -0800

Archive

Bertho Stultiens announced: I am currently implementing the Wine Message Compiler (wmc: as an alternative to mc.exe). I need to implement quite a bit unicode support for it to function correctly. Unicode requires a lot of tables for conversion and I did just that for nearly all codepages (from ftp.unicode.org).

Alexandre Julliard answered Dmitry Timoshkov has been working with him integrating the same needed basic features into Wine (like on demand translation table loading...). Both agreed that (g)libc didn't provide yet a reliable Unicode support, and that a separate one shall be provided. However, since the wmc message compiler shall be used to compile Wine, it would be difficult to make it heavily rely on Wine features. Also, Bertho would like to keep wmc (as wrc - the Wine resource compiler - is) independent of Wine.

Bertho suggested I am not suggesting to build libunicode.so, but I do suggest to build libunicode.a, which can be linked against. This should not require a special API if it only concerns tables. The point is that libunicode.a should be self-sufficient so that you can take it out of wine's context just far enough so that it becomes usable in a wider sense.

Basically, you need to place the unicode code isolated and only provide the mere minimum of API which would also be required within wine's context. This enables me to reuse the data/code in wrc without requiring a complete wine-build and does not complicate wine's internal API because it isn't really extended, but merely reused. It would be a shame to neglect the potential while not much effort is required.

Alexandre agreed on the general scheme, but wasn't happy with creating another library. He strongly kept his opinion on providing those features from libwine.so. However, both agreed that libwine.so currently contains too many things and shall lose some weight (starting with removing USER and GDI code).

Alexandre announced he shall start committing the code-pages to CVS when the Address Space Separation stops shaking the (CVS) tree, and asked Bertho to send also his prepatch so that both efforts shall be merged together.

Too many GDI objects ? 01 Jun 2000 00:00:00 -0800 Archive

Too many GDI objects ?	01 Jun 2000 00:00:00 -0800	Archive
Jacques Gelinas wrote: We are trying to run a win32 application on Wine and Linux. The application is starting and ultimately fails with the following message: `LOCAL_GetBlock not enough space in GDI local heap (01d7) for 60 bytes` The application does quite a lot before failing. It does ODBC access to a sybase server, brings its splash screen, then its main windows. Note that this application main window use quite a few widgets. It is made of a notebook object with several data browsers and input fields distributed in the various pages. Trying to pinpoint the offending piece of code (This is our own application, so we have to source), we think it is not any code in particular, but simply because there are two many widgets. Commenting out the area where our app fails, we get a little further and fails in another window. Jacques asked for explanations. Obviously the number of GDI objects was the source of his problems. Either Wine is leaking some objects, or Windows provide a support for a larger number of objects. Douglas Ridgway pointed back to an old (unapplied) patch to help tracking GDI objects leak (it may even not compile). Gavriel State continued Actually, the Corel tree has an extensive resource/memory leak tracker, including a motif-based graphical profile viewer client. Last I heard, Alexandre didn't want to put that into WineHQ, since he wanted Wine to properly implement the equivalent Win32 APIs so that resource-monitoring Win32 apps would work. Stéphane Lussier provided another track In Wine there's currently a limitation on the size of the GDI heap. It is limited to 64K. This is a old limitation from Win 3.1 (16 bits), this limitation doesn't exist under Win9x/WinNT. Alexandre fixed that issue on the Corel wine tree, and I'm pretty sure eventually somebody will merge his work back into Wine-HQ source tree. It could even be you :-) If your application creates a lot of GDI objects that could be the problem. Or maybe also your application leaks some GDI object, if it's the case you'll run into that problem (no more space in the GDI heap) much faster than in Windows. I think in Windows you can create 64K objects before Windows starts to complain. In another thread, Douglas Ridway gave a slightly different explanation on GDI heap limitation: Although the Wine GDI heap is only 64K, it's not as bad as it looks. The Wine GDI heap, unlike Win16, does not store large objects (fonts, palettes, etc.) but only structures which hold flat pointers to the objects themselves. So, although the heap is of a limited size, the number of objects which can realistically be stored is large and not much different from Microsoft implementations. If you're running out of space on the GDI heap, then Wine is probably leaking GDI objects.

Jacques Gelinas wrote: We are trying to run a win32 application on Wine and Linux. The application is starting and ultimately fails with the following message:


LOCAL_GetBlock not enough space in GDI local heap (01d7) for 60 bytes

The application does quite a lot before failing. It does ODBC access to a sybase server, brings its splash screen, then its main windows. Note that this application main window use quite a few widgets. It is made of a notebook object with several data browsers and input fields distributed in the various pages.

Trying to pinpoint the offending piece of code (This is our own application, so we have to source), we think it is not any code in particular, but simply because there are two many widgets. Commenting out the area where our app fails, we get a little further and fails in another window.

Jacques asked for explanations. Obviously the number of GDI objects was the source of his problems. Either Wine is leaking some objects, or Windows provide a support for a larger number of objects.

Douglas Ridgway pointed back to an old (unapplied) patch to help tracking GDI objects leak (it may even not compile).

Gavriel State continued Actually, the Corel tree has an extensive resource/memory leak tracker, including a motif-based graphical profile viewer client. Last I heard, Alexandre didn't want to put that into WineHQ, since he wanted Wine to properly implement the equivalent Win32 APIs so that resource-monitoring Win32 apps would work.

Stéphane Lussier provided another track In Wine there's currently a limitation on the size of the GDI heap. It is limited to 64K. This is a old limitation from Win 3.1 (16 bits), this limitation doesn't exist under Win9x/WinNT.

Alexandre fixed that issue on the Corel wine tree, and I'm pretty sure eventually somebody will merge his work back into Wine-HQ source tree. It could even be you :-)

If your application creates a lot of GDI objects that could be the problem. Or maybe also your application leaks some GDI object, if it's the case you'll run into that problem (no more space in the GDI heap) much faster than in Windows. I think in Windows you can create 64K objects before Windows starts to complain.

In another thread, Douglas Ridway gave a slightly different explanation on GDI heap limitation: Although the Wine GDI heap is only 64K, it's not as bad as it looks. The Wine GDI heap, unlike Win16, does not store large objects (fonts, palettes, etc.) but only structures which hold flat pointers to the objects themselves. So, although the heap is of a limited size, the number of objects which can realistically be stored is large and not much different from Microsoft implementations. If you're running out of space on the GDI heap, then Wine is probably leaking GDI objects.

Wine mail archives	31 May 2000 00:00:00 -0800	Archive
John Freed announced that the HTTP access to the Wine mailing lists archive is back online. Those archives can be accessed at http://www.integrita.com.

Feature: DLL overrides by Ove Kåven
The wine.conf directives [DllDefaults] and [DllOverrides] are the subject of some confusion. The overall purpose of most of these directives are clear enough, though - given a choice, should Wine use its own built-in DLLs, or should it use .DLL files found in an existing Windows installation? This article explains how this feature works. <h3>DLL types</h3> native A "native" DLL is a .DLL file written for the real Microsoft Windows. builtin A "builtin" DLL is a Wine DLL. These can either be a part of libwine.so, or more recently, in a special .so file that Wine is able to load on demand. elfdll An "elfdll" is a Wine .so file with a special Windows-like file structure that is as close to Windows as possible, and that can also seamlessly link dynamically with "native" DLLs, by using special ELF loader and linker tricks. Bertho Stultiens did some work on this, but this feature has not yet been merged back into Wine (because of political reasons and lack of time), so this DLL type does not exist in the official Wine at this time. In the meantime, the "builtin" DLL type gained some of the features of elfdlls (such as dynamic loading), so it's possible that "elfdll" functionality will be folded into "builtin" at some point. so A native Unix .so file, with calling convention conversion thunks generated on the fly as the library is loaded. This is mostly useful for libraries such as "glide" that has exactly the same API on both Windows and Unix. <h3>The [DllDefaults] section</h3> EXTRA_LD_LIBRARY_PATH This specifies the location of the Wine's DLL .so files. Wine will search this path when trying to locate a DLL of the type "builtin" or "elfdll". (This does not apply to libwine.so, since libwine.so is not a DLL in this sense.) DefaultLoadOrder This specifies in what order Wine should search for available DLL types, if the DLL in question was not found in the [DllOverrides] section. <h3>The [DllPairs] section</h3> At one time, there was a section called [DllPairs] in the default configuration file, but this has been obsoleted because the pairing information has now been embedded into Wine itself. (The purpose of this section was merely to be able to issue warnings if the user attempted to pair codependent 16-bit/32-bit DLLs of different types.) If you still have this in your wine.conf or .winerc, you may safely delete it. <h3>The [DllOverrides] section</h3> This section specifies how you want specific DLLs to be handled, in particular whether you want to use "native" DLLs or not, if you have some from a real Windows configuration. Because builtins do not mix seamlessly with native DLLs yet, certain DLL dependencies may be problematic, but workarounds exist in Wine for many popular DLL configurations. Also see WWN's Status Page to figure out how well your favorite DLL is implemented in Wine. It is of course also possible to override these settings by explicitly using Wine's --dll command-line option (see the man page for details). Some hints for choosing your optimal configuration (listed by 16/32-bit DLL pair): krnl386, kernel32 Native versions of these will never work, so don't try. Leave at builtin. gdi, gdi32 Graphics Device Interface. No effort has been made at trying to run native GDI. Leave at builtin. user, user32 Window management and standard controls. It was possible to use Win95's native versions at some point (if all other DLLs that depend on it, such as comctl32 and comdlg32, were also run native). However, this is no longer possible after the Address Space Separation, so leave at builtin. ntdll NT kernel API. Although badly documented, the native version of this will never work. Leave at builtin. w32skrnl Win32s (for Win3.x). Native version will probably never work. Leave at builtin. wow32 Win16 support library for NT. Native version will probably never work. Leave at builtin. system Win16 kernel stuff. Will never work native. Leave at builtin. display Display driver. Definitely leave at builtin. toolhelp Tool helper routines. This is rarely a source of problems. Leave at builtin. ver, version Versioning. Seldom useful to mess with. advapi32 Registry and security features. Trying the native version of this may or may not work. commdlg, comdlg32 Common Dialogs, such as color picker, font dialog, print dialog, open/save dialog, etc. It is safe to try native. commctrl, comctl32 Common Controls. This is toolbars, status bars, list controls, the works. It is safe to try native. shell, shell32 Shell interface (desktop, filesystem, etc). Being one of the most undocumented pieces of Windows, you may have luck with the native version, should you need it. winsock, wsock32 Windows Sockets. The native version will not work under Wine, so leave at builtin. icmp ICMP routines for wsock32. As with wsock32, leave at builtin. mpr The native version may not work due to thunking issues. Leave at builtin. lzexpand, lz32 Lempel-Ziv decompression. Wine's builtin version ought to work fine. winaspi, wnaspi32 Advanced SCSI Peripheral Interface. The native version will probably never work. Leave at builtin. crtdll C Runtime library. The native version will easily work better than Wine's on this one. winspool.drv Printer spooler. You are not likely to have more luck with the native version. ddraw DirectDraw/Direct3D. Since Wine does not implement the DirectX HAL, the native version will not work at this time. dinput DirectInput. Running this native may or may not work. dsound DirectSound. It may be possible to run this native, but don't count on it. dplay/dplayx DirectPlay. Native ought to work best on this, if at all. mmsystem, winmm Multimedia system. The native version is not likely to work. Leave at builtin. msacm, msacm32 Audio Compression Manager. Builtin works best, if you set msacm.drv to the same. msvideo, msvfw32 Video for Windows. It is safe (and recommended) to try native. mcicda.drv CD Audio MCI driver. mciseq.drv MIDI Sequencer MCI driver (.MID playback). mciwave.drv Wave audio MCI driver (.WAV playback). mciavi.drv AVI MCI driver (.AVI video playback). Best to use native. mcianim.drv Animation MCI driver. msacm.drv Audio Compression Manager. Set to same as msacm32. midimap.drv MIDI Mapper. wprocs This is a pseudo-DLL used by Wine for thunking purposes. A native version of this doesn't exist.

Feature: DLL overrides by Ove Kåven

The wine.conf directives [DllDefaults] and [DllOverrides] are the subject of some confusion. The overall purpose of most of these directives are clear enough, though - given a choice, should Wine use its own built-in DLLs, or should it use .DLL files found in an existing Windows installation? This article explains how this feature works.

<h3>DLL types</h3>

<h3>The [DllDefaults] section</h3>

<h3>The [DllPairs] section</h3> At one time, there was a section called [DllPairs] in the default configuration file, but this has been obsoleted because the pairing information has now been embedded into Wine itself. (The purpose of this section was merely to be able to issue warnings if the user attempted to pair codependent 16-bit/32-bit DLLs of different types.) If you still have this in your wine.conf or .winerc, you may safely delete it.

<h3>The [DllOverrides] section</h3> This section specifies how you want specific DLLs to be handled, in particular whether you want to use "native" DLLs or not, if you have some from a real Windows configuration. Because builtins do not mix seamlessly with native DLLs yet, certain DLL dependencies may be problematic, but workarounds exist in Wine for many popular DLL configurations. Also see WWN's Status Page to figure out how well your favorite DLL is implemented in Wine.

It is of course also possible to override these settings by explicitly using Wine's --dll command-line option (see the man page for details).

Some hints for choosing your optimal configuration (listed by 16/32-bit DLL pair):

HowTo: Lotus Notes
Dan Schwarz has brought to our attention that he hosts a Lotus Notes on Linux resource page, which explains how to make Lotus Notes work under Wine. It appears a bit outdated as of this writing, but should make a good starting point (and you could just pester him if you want updates). We need more application tips! Submit your contributions to [email protected] .

HowTo: Lotus Notes

Dan Schwarz has brought to our attention that he hosts a Lotus Notes on Linux resource page, which explains how to make Lotus Notes work under Wine. It appears a bit outdated as of this writing, but should make a good starting point (and you could just pester him if you want updates).

We need more application tips! Submit your contributions to [email protected] .

World Wine News