![[LWN Logo]](/images/lwn.banner.gif)
Events, progress, and happenings in the Wine community for August 12, 1999. You might also be interested in the latest news (also known as next week's issue, under construction) or back issues.
Binary compatibility with a Windows-only game is, however, not the whole story. It's cool to be able to run a game under Linux, of course, but such games may not take as full advantage of the Linux platform as a native port such as those done by Loki. Worse, the lack of native ports may be exploited by marketing types, regardless of the technical merits of binary compatibility.
What's necessary for the next level is Winelib-based ports of games which rely on APIs like DirectX. Several production houses have discarded calls to port games like Battlezone 2, because "Linux doesn't support DirectX". This is silly, of course: Linux supports DirectX just fine, through Wine. What's needed is realistic sample code, showing that native ports of DirectX games is no harder than native ports of other Windows sources, such as those done by Corel.
Ulrich Weigand reorganized the 16<->32 bit thunks.
Andreas Mohr fixed some filename casing issue.
Jürgen Lock fixed a shell/shell32 crash.
Robert Hall have been trying to implement ICMP for Winsock.
Bertho Stultiens estimates that the long-awaited elf-dll split may be ready in a few weeks.
Uwe Bonnes did several fixes for serial communications.
Ulrich Weigand moved the MPR.dll implementation to the dlls/ subdirectory.
Jürgen Schmied did a lot more work on shell32 and related things.
Ove Kåven works on making the mouse wheel of certain mice work under Wine (and switching weapons in Half-Life with it).
Andreas Mohr improved RegFlushKey.
Gerard Patel fixed a no-printer crash.
Alexandre Julliard fixed some string handling.
Guy Albertelli completed GetKeyNameText (at least for US keyboard).
Mark Adams added a stub for DrawDibClose, allowing RealPlayer G2 to play several videos per run.
And a lot more user interface fixes are flowing in from the Macadamian team, really way too many to list here.
Encoding and distribution of binary resources have come up again. Jürgen Schmied proposes an application that can convert from .bmp, .ico, etc files to .hex and back, and use make rules to automatically convert to the binary format. Bertho instead suggests writing a loader for The GIMP to edit the files directly, but Jürgen isn't "that bored"... and for icons and animations with several bitmaps inside, Jürgen also suggests using multiple Xpm images, but Bertho says hotspots would be necessary too and the wrc grammar is already weird enough, so that would be difficult...
Some discussion about Win16 dll initialization reveal that init functions are not implemented for built-in Win16 dlls, but that DllEntryPoint can (and maybe should) be used instead (although it works differently and is really another ugly Win95 hack, as Ulrich explains).
There was also some discussion about serial comm timeouts, as the relevant POSIX features aren't documented too well.
Anonymous structs and unions are a big issue, seeing how Windows headers and code depends on them. There are some patches for gcc 2.95 available, but they're apparently not in the standard 2.95 distribution. It has been suggested that configure could check for it, but since it's Winelib users who will be affected, not Wine itself, this would be pointless. It appears that users that depend on this feature may have to define a couple of symbols (e.g. _FORCENAMELESSUNION and _FORCENAMELESSSTRUCT) in their projects in order to make the Winelib headers use it.
Ulrich Weigand apparently found some spare time and came up with a CPU emulator for Wine, currently being able to run 16-bit code. Although much of it was based on prior work, it still amazed several people. (While Ove Kåven brought up again the theory that Ulrich is probably a group of clones, one of which suddenly didn't have anything to do, Ian Schmidt proposed the possibly more plausible theory that Ulrich is an AI running on a Beowulf cluster. I'll have to add that to the Who's Who soon.) This sparked new discussions about the portability of Winelib, how important a CPU emulator should be for Wine, and the performance of CPU emulator technology. Rob Farnum (of CodeWeavers) explains that his experience with CPU emulators says that in order to get acceptable speed, the emulator pretty much *must* dynamically compile the code to processor-native code, and that using an interpreted approach would be a design mistake.
While the CPU emulator could in some way be a solution for Patrik's security problem from last week, Patrik now explained that Winelib is difficult to port to other architectures because there is very little available Windows source code to test Winelib with. (64-bit architectures will be particularly difficult, as Microsoft's Win64 architecture is really mostly 32-bit.)
There is still hope, though; Andrew Lynch is building an Open Source Software for Windows archive that he hopes put up on WineHQ. This may prove to be valuable for Wine testing, so help him out if you can (lynchaj@yahoo.com).
Credits: Doug Ridgway, Eric Pouech, and Ove Kåven.