WWN Issue 332

This is the 332nd issue of the Wine Weekly News publication. Its main goal is to play NTN. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

This week, 248 posts consumed 454 K. There were 85 different contributors. 45 (52%) posted more than once. 48 (56%) posted last week too.

The top 5 posters of the week were:

25 posts in 25K by julliard at winehq.org (Alexandre Julliard)
18 posts in 25K by truiken at gmail.com (James Hawkins)
11 posts in 28K by stefan at codeweavers.com (Stefan Dösinger)
11 posts in 12K by rob at codeweavers.com (Robert Shearman)
11 posts in 19K by mk144210 at bcm.edu (Misha Koshelev)

News: Novell's Patent Fun	Archive
News More than a few people have been angered by Novell's patent indemnification agreement with Microsoft. If you're looking for a bunch of really exciting fun, you can find a redacted version of the entire agreement filed with the SEC. There's two nice bits in there about Wine. The first pretty much means Novell won't ever ship Wine (someone please correct me if I'm wrong because it's late and I might have pieced it together wrong.) Why? Let's look at the covenant the two are agreeing to. It says: Covenanting Party, on behalf of itself and its Subsidiaries, hereby covenants not to sue Covenanted Customers for infringement under Covered Patents of Covenanting Party on account of a Covenanted Customer's use of specific copies of a Covered Product as distributed by the other Party for which the other Party has received Revenue (directly or indirectly) for such specific copies; provided the foregoing covenant is limited to use by such Customer (i) of such specific copies that are authorized by the other Party in consideration for such Revenue, and (ii) within the scope authorized by the other Party in consideration for such Revenue. So, it basically says: "We won't sue your customers if they're using Covered Products". Ok.. what's a covered product. Since you asked, 1.1 "Covered Products" of a Party means all products and services sold, licensed, supplied, distributed or otherwise made available by such Party except for Foundry Products, Clone Products and Other Excluded Products (collectively, "Excluded Products"). Alright, so you can't be sued if you're using Covered Products, but that means you better not be using a Clone Product. What's a that? Well, the definition gets a little long, but it basically says an existing product that implements a bunch of APIs among other things isn't a clone product except for Wine and few others: 1.7 "Clone Product" means a product (or major component thereof) of a Party that has the same or substantially the same features and functionality as a then-existing product (or major component thereof) of the other Party ("Prior Product") and that (a) has the same or substantially the same user interface, or (b) implements all or substantially all of the Application Programming Interfaces of the Prior Product. Those portions of a product that are otherwise licensed to one Party from the other Party, or that are compliant with a specification of a standards organization as to which the other Party has consented to the use of its Patents therefore, shall not be considered in determining whether the product is a Clone Product. (i) The Parties agree that products sold, licensed, supplied, distributed or otherwise made available by a Party for Revenue before the Effective Date ("Existing Products") will not be deemed Clone Products. For purposes of clarification, the parties acknowledge that any features and functionality of such Existing Products ("Existing Product Functionality") may be considered in determining whether a new product (or major component thereof) meets the requirements set forth in the first paragraph of this definition, provided that, even if a new product (or major component thereof) meets such requirements, only those Patents covering inventions in new features and functionality in such Clone Product may be asserted against such Clone Product, and only with regard to Clone Product Functionality. For purposes of this subsection (i), "Clone Product Functionality" means features or functionality (other than Existing Product Functionality) that add to meeting the requirements set forth in the first paragraph of this definition. (ii) Notwithstanding subsection (i) above, Wine, OpenXchange, StarOffice and OpenOffice are not subject to such subsection (i), however, the exclusion of such products from such subsection (i) is without implication as to (and shall not affect the determination of) whether such products (or any features or functionality thereof) are Clone Products. So, it appears Wine isn't covered by the little patent agreement and I'd guess Novell wouldn't ship any product that isn't. There's also this choice gem: 4.2 Customers and Distributors. The parties, on behalf of themselves and their Subsidiaries, irrevocably release the direct and indirect Distributors of the Parties from any liability for Patent infringement arising on account of using, importing, offering for sale, selling, licensing, supplying, distributing, otherwise making available, or promoting the commercialization of the Parties' products and services (including Excluded Products) prior to the Effective Date, provided the foregoing release does not apply to Wine or to any product for which such other Party did not receive Revenue directly or indirectly. The parties, on behalf of themselves and their Subsidiaries, also irrevocably release the respective direct and indirect Customers of the other Party from any liability for Patent infringement arising on account of using the Parties' products and services (including Excluded Products) obtained prior to the Effective Date, provided the foregoing release does not apply to Wine or to any product for which such other Party did not receive Revenue directly or indirectly. Over at LinuxGames there's an interview with Ryan Gordon about the state of Linux gaming and what technologies on the horizon will be important. Ryan has been doing ports of programs to Linux and Mac OS X for over a decade now. Going all the way back to the games ported by Loki, Ryan has probably been responsible for more commercial applications being ported to Linux than anyone else. Asked to rate technologies on a scale of 1-10, with 10 being the highest, this is what Ryan had to say about Wine: They're a 2. I think they'll always be around, and as long as Windows is dominant, they'll definitely have a use, but I just never manage to find anything that works with them, game or otherwise. Most things I've tried tend to crash on startup, but I don't really put much effort into it, and to be fair, I've never really tried to use them for the things they want you to: Microsoft Office, World of Warcraft, etc, so my results aren't really surprising. Usually it's more like data wrapped in a Windows installer .exe that I need to extract and can't. But if you can only use it for a handful of apps, I'm not sure it justifies the man-years of development going into them. It seems like implementing the entire win32 API to run iTunes is a long way around just to be able to buy stuff from the iTunes Store. That's just my opinion, though. People talk about Wine and company like it's going to kill Linux, but I just don't see that happening.

News: Novell's Patent Fun

Archive

News

More than a few people have been angered by Novell's patent indemnification agreement with Microsoft. If you're looking for a bunch of really exciting fun, you can find a redacted version of the entire agreement filed with the SEC. There's two nice bits in there about Wine. The first pretty much means Novell won't ever ship Wine (someone please correct me if I'm wrong because it's late and I might have pieced it together wrong.) Why? Let's look at the covenant the two are agreeing to. It says:

Covenanting Party, on behalf of itself and its Subsidiaries, hereby covenants not to sue Covenanted Customers for infringement under Covered Patents of Covenanting Party on account of a Covenanted Customer's use of specific copies of a Covered Product as distributed by the other Party for which the other Party has received Revenue (directly or indirectly) for such specific copies; provided the foregoing covenant is limited to use by such Customer (i) of such specific copies that are authorized by the other Party in consideration for such Revenue, and (ii) within the scope authorized by the other Party in consideration for such Revenue.

So, it basically says: "We won't sue your customers if they're using Covered Products". Ok.. what's a covered product. Since you asked,

1.1 "Covered Products" of a Party means all products and services sold, licensed, supplied, distributed or otherwise made available by such Party except for Foundry Products, Clone Products and Other Excluded Products (collectively, "Excluded Products").

Alright, so you can't be sued if you're using Covered Products, but that means you better not be using a Clone Product. What's a that? Well, the definition gets a little long, but it basically says an existing product that implements a bunch of APIs among other things isn't a clone product except for Wine and few others:

1.7 "Clone Product" means a product (or major component thereof) of a Party that has the same or substantially the same features and functionality as a then-existing product (or major component thereof) of the other Party ("Prior Product") and that (a) has the same or substantially the same user interface, or (b) implements all or substantially all of the Application Programming Interfaces of the Prior Product. Those portions of a product that are otherwise licensed to one Party from the other Party, or that are compliant with a specification of a standards organization as to which the other Party has consented to the use of its Patents therefore, shall not be considered in determining whether the product is a Clone Product.

(i) The Parties agree that products sold, licensed, supplied, distributed or otherwise made available by a Party for Revenue before the Effective Date ("Existing Products") will not be deemed Clone Products. For purposes of clarification, the parties acknowledge that any features and functionality of such Existing Products ("Existing Product Functionality") may be considered in determining whether a new product (or major component thereof) meets the requirements set forth in the first paragraph of this definition, provided that, even if a new product (or major component thereof) meets such requirements, only those Patents covering inventions in new features and functionality in such Clone Product may be asserted against such Clone Product, and only with regard to Clone Product Functionality. For purposes of this subsection (i), "Clone Product Functionality" means features or functionality (other than Existing Product Functionality) that add to meeting the requirements set forth in the first paragraph of this definition.

(ii) Notwithstanding subsection (i) above, Wine, OpenXchange, StarOffice and OpenOffice are not subject to such subsection (i), however, the exclusion of such products from such subsection (i) is without implication as to (and shall not affect the determination of) whether such products (or any features or functionality thereof) are Clone Products.

So, it appears Wine isn't covered by the little patent agreement and I'd guess Novell wouldn't ship any product that isn't. There's also this choice gem:

4.2 Customers and Distributors. The parties, on behalf of themselves and their Subsidiaries, irrevocably release the direct and indirect Distributors of the Parties from any liability for Patent infringement arising on account of using, importing, offering for sale, selling, licensing, supplying, distributing, otherwise making available, or promoting the commercialization of the Parties' products and services (including Excluded Products) prior to the Effective Date, provided the foregoing release does not apply to Wine or to any product for which such other Party did not receive Revenue directly or indirectly. The parties, on behalf of themselves and their Subsidiaries, also irrevocably release the respective direct and indirect Customers of the other Party from any liability for Patent infringement arising on account of using the Parties' products and services (including Excluded Products) obtained prior to the Effective Date, provided the foregoing release does not apply to Wine or to any product for which such other Party did not receive Revenue directly or indirectly.

Over at LinuxGames there's an interview with Ryan Gordon about the state of Linux gaming and what technologies on the horizon will be important. Ryan has been doing ports of programs to Linux and Mac OS X for over a decade now. Going all the way back to the games ported by Loki, Ryan has probably been responsible for more commercial applications being ported to Linux than anyone else. Asked to rate technologies on a scale of 1-10, with 10 being the highest, this is what Ryan had to say about Wine:

They're a 2.

I think they'll always be around, and as long as Windows is dominant, they'll definitely have a use, but I just never manage to find anything that works with them, game or otherwise. Most things I've tried tend to crash on startup, but I don't really put much effort into it, and to be fair, I've never really tried to use them for the things they want you to: Microsoft Office, World of Warcraft, etc, so my results aren't really surprising. Usually it's more like data wrapped in a Windows installer .exe that I need to extract and can't.

But if you can only use it for a handful of apps, I'm not sure it justifies the man-years of development going into them. It seems like implementing the entire win32 API to run iTunes is a long way around just to be able to buy stuff from the iTunes Store. That's just my opinion, though.

People talk about Wine and company like it's going to kill Linux, but I just don't see that happening.

ntoskrnl.exe	Archive
Architecture There's been some interesting projects being worked on within Wine. This week the series of changes that got the most attention was Alexandre's work on ntoskrnl.exe. What is that exactly? In short, it's the actual NT kernel that all of the major DLLs dispatch calls into. From there, ntoskrnl takes care of dispatching the calls to things like the actual hardware. In short, it's what gets you to the metal. Now, ntoskrnl.exe is not exactly news. There's been versions floating around for a few years. ReactOS has their version of it. A version of that was hacked to create CaptiveNTFS. Ivan Leo Puoti and Vitaliy Margolen worked on a version specific to Wine back in 2005. That work proved that it was possible to get the Safedisc copy protection kernel driver to work with Wine. At the time, some infrastructure didn't exist within Wine to make the design clean enough for Alexandre to accept the patch. It looks like that's changed though and Alexandre is implementing ntoskrnl.exe himself. Here are the commit logs that came through this week regarding it: ntoskrnl.exe: Initial stub version with forwards to existing functions hal: Added an initial stub ntoskrnl.exe: Implemented IoCreateDevice and IoDeleteDevice ntoskrnl.exe: Implemented IoCreateSymbolicLink ntoskrnl.exe: Export KeServiceDescriptorTable and KeTickCount ntoskrnl.exe: Added IofCompleteRequest ntoskrnl.exe: Implemented a number of memory allocation functions ntoskrnl.exe: Export a Wine-internal function to run the device request handling loop ntoskrnl.exe: Implemented PsGetVersion and added stubs for a couple of other Ps functions ntoskrnl.exe: Reuse the kernel32 instruction emulation support for kernel-mode drivers. ntoskrnl.exe: Implemented a couple of time-related APIs. Vitaliy Margolen : ntdll: Implement RtlWriteRegistryValue and forward ntoskrnl to it. Ideally this kind of mechanism could be used to load any Windows .sys driver with ways for them to talk to hardware. In reality, that's pretty tough because at some point you need to translate the Windows calls down through the Linux kernel. Last week a generic method was discussed for USB devices (see WWN #331 ) that would add USB infrastructure to ntoskrnl and potentially forward the calls to libusb. All in all, we're a lot closer than we were simply because finding a framework acceptable by Alexandre is often the hurdle in a lot of areas affecting core architecture. However, there's still a large amount of work to be done for that to work to even get Safedisc copy protection working, which seems to be the point of this patch. However, Safedisc support is huge and will allow a lot more programs to work out of the box. So as far as direction goes, right now it appears a lot needs to be done implementing the stubbed functions. Alexandre then alluded to some of the work to finish implementing this: ntoskrnl needs to be loaded from a service process that will take care of importing msvcrt. Currently the driver is executed directly which cannot work. Shortly after that a few more additions showed up: winedevice: Add a service process that loads and runs a kernel driver. advapi32: Launch winedevice. exe when asked to start a kernel driver service.

ntoskrnl.exe

Archive

Architecture

There's been some interesting projects being worked on within Wine. This week the series of changes that got the most attention was Alexandre's work on ntoskrnl.exe. What is that exactly? In short, it's the actual NT kernel that all of the major DLLs dispatch calls into. From there, ntoskrnl takes care of dispatching the calls to things like the actual hardware. In short, it's what gets you to the metal.

Now, ntoskrnl.exe is not exactly news. There's been versions floating around for a few years. ReactOS has their version of it. A version of that was hacked to create CaptiveNTFS. Ivan Leo Puoti and Vitaliy Margolen worked on a version specific to Wine back in 2005. That work proved that it was possible to get the Safedisc copy protection kernel driver to work with Wine. At the time, some infrastructure didn't exist within Wine to make the design clean enough for Alexandre to accept the patch. It looks like that's changed though and Alexandre is implementing ntoskrnl.exe himself. Here are the commit logs that came through this week regarding it:

ntoskrnl.exe: Initial stub version with forwards to existing functions
hal: Added an initial stub
ntoskrnl.exe: Implemented IoCreateDevice and IoDeleteDevice
ntoskrnl.exe: Implemented IoCreateSymbolicLink
ntoskrnl.exe: Export KeServiceDescriptorTable and KeTickCount
ntoskrnl.exe: Added IofCompleteRequest
ntoskrnl.exe: Implemented a number of memory allocation functions
ntoskrnl.exe: Export a Wine-internal function to run the device request handling loop
ntoskrnl.exe: Implemented PsGetVersion and added stubs for a couple of other Ps functions
ntoskrnl.exe: Reuse the kernel32 instruction emulation support for kernel-mode drivers.
ntoskrnl.exe: Implemented a couple of time-related APIs.
Vitaliy Margolen : ntdll: Implement RtlWriteRegistryValue and forward ntoskrnl to it.

Ideally this kind of mechanism could be used to load any Windows .sys driver with ways for them to talk to hardware. In reality, that's pretty tough because at some point you need to translate the Windows calls down through the Linux kernel. Last week a generic method was discussed for USB devices (see WWN #331 ) that would add USB infrastructure to ntoskrnl and potentially forward the calls to libusb. All in all, we're a lot closer than we were simply because finding a framework acceptable by Alexandre is often the hurdle in a lot of areas affecting core architecture. However, there's still a large amount of work to be done for that to work to even get Safedisc copy protection working, which seems to be the point of this patch. However, Safedisc support is huge and will allow a lot more programs to work out of the box.

So as far as direction goes, right now it appears a lot needs to be done implementing the stubbed functions. Alexandre then alluded to some of the work to finish implementing this:

ntoskrnl needs to be loaded from a service process that will take care of importing msvcrt. Currently the driver is executed directly which cannot work.

Shortly after that a few more additions showed up:

winedevice: Add a service process that loads and runs a kernel driver.
advapi32: Launch winedevice. exe when asked to start a kernel driver service.

Gecko Package Update	Archive
Web/HTML It's been a while since we talked about Wine and Mozilla's Gecko integration. Jacek Caban continues to improve the HTML integration in Wine using Gecko. This effort has been going on for a few years and for the most part Jacek has done all the work. It relies on a separate package to be installed providing the slim HTML engine and this week he announced an updated version of it: It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download: http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.tar.bz2 if you already have installed Gecko, simply extract the package and replace c:\windows\wine_gecko with it. otherwise extract the package and set the GeckoPath variable in the HKCU\Software\Winde\MSHTML registry key to its location. Then run an app and check if it still works. Note that you have to use current Git, older Wine is not compatible with the new Gecko. Expected visible difference should be: Working scrollbars (still not perfect, they will be visible even if app sets it to not be, but it's better than before - I will work on it later) Pages that require plugins will render like there was no plugin instead of offering to download one (that doesn't work anyway) From a technical point of view this version differs much from the previous one. The previous version was just a SeaMonkey with manually removed and changed some files. This one is my build from source (I will create a page on wiki about how to do so). It's based on XUL Runner 1.8.1.3, which has the same source as Firefox 2.0.0.3. After testing it, I will change the Gecko installer a bit to be able to deal with different Gecko versions for different Wine version and upload it to SourceForge. The announcement led to a few regression reports. It also led to Vitaliy Margolen discovering scrollbars worked in Steam for the first time. Right now it seems Jacek might be looking into Gecko more closely to discover the source of the some of the regressions. Replacing some Gecko libraries with older versions seems to fix some of the issues. In fact, Jacek did release a newer version a few days later using the same URL as announced above.

Gecko Package Update

Archive

Web/HTML

It's been a while since we talked about Wine and Mozilla's Gecko integration. Jacek Caban continues to improve the HTML integration in Wine using Gecko. This effort has been going on for a few years and for the most part Jacek has done all the work. It relies on a separate package to be installed providing the slim HTML engine and this week he announced an updated version of it:

It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download:

http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.tar.bz2

if you already have installed Gecko, simply extract the package and replace c:\windows\wine_gecko with it.
otherwise extract the package and set the GeckoPath variable in the HKCU\Software\Winde\MSHTML registry key to its location.

Then run an app and check if it still works.

Note that you have to use current Git, older Wine is not compatible with the new Gecko.

Expected visible difference should be:

Working scrollbars (still not perfect, they will be visible even if app sets it to not be, but it's better than before - I will work on it later)
Pages that require plugins will render like there was no plugin instead of offering to download one (that doesn't work anyway)

From a technical point of view this version differs much from the previous one. The previous version was just a SeaMonkey with manually removed and changed some files. This one is my build from source (I will create a page on wiki about how to do so). It's based on XUL Runner 1.8.1.3, which has the same source as Firefox 2.0.0.3.

After testing it, I will change the Gecko installer a bit to be able to deal with different Gecko versions for different Wine version and upload it to SourceForge.

The announcement led to a few regression reports. It also led to Vitaliy Margolen discovering scrollbars worked in Steam for the first time. Right now it seems Jacek might be looking into Gecko more closely to discover the source of the some of the regressions. Replacing some Gecko libraries with older versions seems to fix some of the issues. In fact, Jacek did release a newer version a few days later using the same URL as announced above.

Making Direct3D Threadsafe	Archive
Threadsafe Direct3D is probably one of the biggest items left on Stefan Dösingers to-do list. This week he posted the plan for how it will hopefully work and test patch for DirectDraw: After writing some tests for synchronisation in ddraw, I have new versions of my thread safety patches for ddraw. I want to show them for some ideas / comments before sending them in. Basically windows ddraw seems to hold a DLL global lock whenever some code of the DLL is executed even in functions that wouldn't need it (like AddRef, can use interlocked addref), unrelated calls (2 different ddraw objects or surfaces) or before checking erroneous params. As per Alexandre's comments, we don't want to copy all this insane locking exactly (until we find an app that really needs this. Basically my 2 patches handle it like this (for the ddraw object only - all others will follow): When a method needs locking, the lock is acquired after printing the trace, but before checking error conditions (like windows). If a method doesn't need locking (e.g. unimplemented, or just a getter for static info (GetCaps), or QI / AddRef / Release), then the lock is not held Since ddraw, d3d8 and d3d9 need their own locking anyway, my plan is to implement locking in them and assume synchronised calls in wined3d - ie no wined3d locking. No 2 threads may call wined3d at the same time, and ddraw/d3d8/d3d9 have to take care of that. That keeps the code simpler. Attached is my test (threading.c), the locking for main and ddraw (merged it accidentally - need to split it up again. The plan is to continue like that for the rest of ddraw and d3d8/9 Henri Verbeet did a quick review and thought the plan sounded good.

Making Direct3D Threadsafe

Archive

Threadsafe Direct3D is probably one of the biggest items left on Stefan Dösingers to-do list. This week he posted the plan for how it will hopefully work and test patch for DirectDraw:

After writing some tests for synchronisation in ddraw, I have new versions of my thread safety patches for ddraw. I want to show them for some ideas / comments before sending them in.

Basically windows ddraw seems to hold a DLL global lock whenever some code of the DLL is executed even in functions that wouldn't need it (like AddRef, can use interlocked addref), unrelated calls (2 different ddraw objects or surfaces) or before checking erroneous params.

As per Alexandre's comments, we don't want to copy all this insane locking exactly (until we find an app that really needs this. Basically my 2 patches handle it like this (for the ddraw object only - all others will follow):

When a method needs locking, the lock is acquired after printing the trace, but before checking error conditions (like windows).
If a method doesn't need locking (e.g. unimplemented, or just a getter for static info (GetCaps), or QI / AddRef / Release), then the lock is not held

Since ddraw, d3d8 and d3d9 need their own locking anyway, my plan is to implement locking in them and assume synchronised calls in wined3d - ie no wined3d locking. No 2 threads may call wined3d at the same time, and ddraw/d3d8/d3d9 have to take care of that. That keeps the code simpler.

Attached is my test (threading.c), the locking for main and ddraw (merged it accidentally - need to split it up again. The plan is to continue like that for the rest of ddraw and d3d8/9

Henri Verbeet did a quick review and thought the plan sounded good.

Free Fonts Archive

Free Fonts	Archive
Fonts RedHat has sponsored the development of some open source fonts that have glyph characteristics similar to ones on Windows. They're calling them Liberation fonts . This has the potential to make a lot of Wine installations behave better since installing a good set of fonts goes a long way toward fixing annoying bugs. Dan Kegel added the download to his winetricks script to see if they'll prove useful. Scott Ritchie began thinking about something more permanent: I'm pretty sure the proper place for these fonts is as a separate distro package - perhaps one that Wine can depend on. If the liberation fonts aren't yet being packed up in Ubuntu, I'll see about adding a new package for them. Mark Cox replied: Scott, That wasn't what i was thinking when i suggested it to Dan. If users test the fonts with wine, which they can now do using winetricks, i was hoping that the font names could be remapped/hacked so that the names of the mscorefonts map to the redhat fonts. If that is successful, the fonts could be included in wine and we wouldn't need mscorefonts anymore. Han Leidekker provided a quick script to try make that process happen: Yes, we should be able to eliminate a number of font related bugs by shipping with these fonts. Apps like Picasa [1] appear to ask for a specific font name, others even reference the font file directly. There's another bug where if an app installs the first truetype font in Wine all subsequent text is shown with that font [2]. These bugs can be worked around by installing corefonts. I have attached a script that changes the filenames of the Liberation fonts as well as the font names inside the files to match native. It requires fontforge to be installed and assumes you have already loaded the Liberation fonts, with winetricks for example: `$ wget www.kegel.com/wine/winetricks $ sh winetricks liberation $ sh convert_fonts` Scott Ritchie thought doing a hack like that (namely, renaming the fonts) wasn't the right thing to do: All right, clearly we need to handle this somehow. I'm just thinking that there needs to be a way to install these fonts WITHOUT Wine such that they're available to non-Wine programs, and that when a user has done that Wine should then reference those fonts rather than duplicate them. Something like a (free) Wine-fonts package, which would be a dependency of Wine. I didn't mean adding them to the mscorefonts type packages (which currently isn't a dependency of Wine) Hans actually made a case for including them directly in Wine; some apps may check explicitly for the existence of the font files: Yes, distros should make these fonts available to all applications. I have no doubt they will because the license is right and they make some web pages and Word documents look better. I was looking beyond that actually, because the license permits us to improve Wine's compatibility even more. By generating modified versions we can make applications work that assume the presence of these fonts and their files. So yes, there is duplication involved, but it is balanced by being more compatible.

Fonts

RedHat has sponsored the development of some open source fonts that have glyph characteristics similar to ones on Windows. They're calling them Liberation fonts . This has the potential to make a lot of Wine installations behave better since installing a good set of fonts goes a long way toward fixing annoying bugs. Dan Kegel added the download to his winetricks script to see if they'll prove useful. Scott Ritchie began thinking about something more permanent:

I'm pretty sure the proper place for these fonts is as a separate distro package - perhaps one that Wine can depend on.

If the liberation fonts aren't yet being packed up in Ubuntu, I'll see about adding a new package for them.

Mark Cox replied:

Scott, That wasn't what i was thinking when i suggested it to Dan. If users test the fonts with wine, which they can now do using winetricks, i was hoping that the font names could be remapped/hacked so that the names of the mscorefonts map to the redhat fonts. If that is successful, the fonts could be included in wine and we wouldn't need mscorefonts anymore.

Han Leidekker provided a quick script to try make that process happen:

Yes, we should be able to eliminate a number of font related bugs by shipping with these fonts. Apps like Picasa [1] appear to ask for a specific font name, others even reference the font file directly.

There's another bug where if an app installs the first truetype font in Wine all subsequent text is shown with that font [2].

These bugs can be worked around by installing corefonts.

I have attached a script that changes the filenames of the Liberation fonts as well as the font names inside the files to match native. It requires fontforge to be installed and assumes you have already loaded the Liberation fonts, with winetricks for example:


$ wget www.kegel.com/wine/winetricks

$ sh winetricks liberation

$ sh convert_fonts

Scott Ritchie thought doing a hack like that (namely, renaming the fonts) wasn't the right thing to do:

All right, clearly we need to handle this somehow. I'm just thinking that there needs to be a way to install these fonts WITHOUT Wine such that they're available to non-Wine programs, and that when a user has done that Wine should then reference those fonts rather than duplicate them.

Something like a (free) Wine-fonts package, which would be a dependency of Wine. I didn't mean adding them to the mscorefonts type packages (which currently isn't a dependency of Wine)

Hans actually made a case for including them directly in Wine; some apps may check explicitly for the existence of the font files:

Yes, distros should make these fonts available to all applications. I have no doubt they will because the license is right and they make some web pages and Word documents look better.

I was looking beyond that actually, because the license permits us to improve Wine's compatibility even more. By generating modified versions we can make applications work that assume the presence of these fonts and their files.

So yes, there is duplication involved, but it is balanced by being more compatible.

Keyboard Handling Changes	Archive
IO Release early, release often.. that works in theory, right? At the very least it can be detrimental to a project when developers work in secret without telling anyone. At worst, it can lead to a massive duplication of effort. This week Oleh Nykyforchyn dropped a patch bomb on wine-devel dealing with keyboard handling: I need an advice on what to do with some piece of code that I have written for about 3 years. I started to make changes in Wine keyboard driver because I was not able to use MS Office under it on my Linux box (3 or 4 XKB groups, 2 overlay groups used, English, Russian, Ukrainian, Belarusian, German and Polish layouts). First I submitted a patch that adds koi8-u encoding to Wine, and it was happily introduced. But my changes to X11DRV (now winex11) keyboard driver were large and I understand Wine people who didn't want to risk. Meanwhile I continued to polish my implementation to correct bugs and improve performance. I am heavily indebted to people that tested my patches, wrote me about problems with them and suggested possible solutions. I thank to L.Rahyen that supported me in my efforts. Now patched keyboard driver allows user to: have up to 4 XKB groups working (current code uses 1 or 2); detect and use XKB overlays to put 2 or 3 close layouts (e.g. Russian, Ukrainian and Belarusian) into one XKB group; freely combine available XKB layouts in any order, e.g. "en,ru,fr"; list all layouts available to the system, and implement ActivateKeyboardLayout(); notify an application (e.g. MS Word) about change of layout, and make GetKeyboardLayout() work really, not just return LCID for current locale of Unix box; input characters that do not fit into current Unix locale, e.g. German and French accented letters on a system with Cyrillic (not UTF) locale; override any of the detected layouts via registry, if the user is not satisfied with the Wine driver choice. In fact I made cosmetic changes to 3 files in winex11.drv directory: x11drv.h, x11drv_main.c, event.c, but the fourth file keyboard.c was changed much more. About half of the functions in it were rewritten, and it now it is easier to read new keyboard.c than diff output to understand the changes. I got very reasonable advice from L.Rahyen to break the patch into smaller parts. The problem is that I preserved the driver logic, but changed data structures, so any such patch (even a very small one) will touch hundreds of lines across the whole file, probably introducing new bugs and being difficult to read and understand. Also, there is no reason to change code in a patch if we can benefit of it only after the next patch. Now I will be grateful for any help. How can such big changes be introduced in the Wine tree? I also attached a patch against wine-0.9.37 and copies of original and changed files. Perhaps somebody, who is interested in multilingual keyboard input, can test it and write me about the results. Vitaliy Margolen suggested some changes to make and thanked Oleh for the patch. This doesn't seem like the type of thing that will get integrated into Wine any time soon unless Oleh is very patient and persistent.

Keyboard Handling Changes

Archive

Release early, release often.. that works in theory, right? At the very least it can be detrimental to a project when developers work in secret without telling anyone. At worst, it can lead to a massive duplication of effort. This week Oleh Nykyforchyn dropped a patch bomb on wine-devel dealing with keyboard handling:

I need an advice on what to do with some piece of code that I have written for about 3 years. I started to make changes in Wine keyboard driver because I was not able to use MS Office under it on my Linux box (3 or 4 XKB groups, 2 overlay groups used, English, Russian, Ukrainian, Belarusian, German and Polish layouts). First I submitted a patch that adds koi8-u encoding to Wine, and it was happily introduced. But my changes to X11DRV (now winex11) keyboard driver were large and I understand Wine people who didn't want to risk. Meanwhile I continued to polish my implementation to correct bugs and improve performance. I am heavily indebted to people that tested my patches, wrote me about problems with them and suggested possible solutions. I thank to L.Rahyen that supported me in my efforts.

Now patched keyboard driver allows user to:

have up to 4 XKB groups working (current code uses 1 or 2);
detect and use XKB overlays to put 2 or 3 close layouts (e.g. Russian, Ukrainian and Belarusian) into one XKB group;
freely combine available XKB layouts in any order, e.g. "en,ru,fr";
list all layouts available to the system, and implement ActivateKeyboardLayout();
notify an application (e.g. MS Word) about change of layout, and make GetKeyboardLayout() work really, not just return LCID for current locale of Unix box;
input characters that do not fit into current Unix locale, e.g. German and French accented letters on a system with Cyrillic (not UTF) locale;
override any of the detected layouts via registry, if the user is not satisfied with the Wine driver choice.

In fact I made cosmetic changes to 3 files in winex11.drv directory: x11drv.h, x11drv_main.c, event.c, but the fourth file keyboard.c was changed much more. About half of the functions in it were rewritten, and it now it is easier to read new keyboard.c than diff output to understand the changes.

I got very reasonable advice from L.Rahyen to break the patch into smaller parts. The problem is that I preserved the driver logic, but changed data structures, so any such patch (even a very small one) will touch hundreds of lines across the whole file, probably introducing new bugs and being difficult to read and understand. Also, there is no reason to change code in a patch if we can benefit of it only after the next patch.

Now I will be grateful for any help. How can such big changes be introduced in the Wine tree? I also attached a patch against wine-0.9.37 and copies of original and changed files. Perhaps somebody, who is interested in multilingual keyboard input, can test it and write me about the results.

Vitaliy Margolen suggested some changes to make and thanked Oleh for the patch. This doesn't seem like the type of thing that will get integrated into Wine any time soon unless Oleh is very patient and persistent.

AppDB Vandalism Archive

AppDB Vandalism	Archive
WineHQ Wine's AppDB was vandalized last week. It seems Molle Bestefich's account was compromised and someone began deleting massive amounts of content. The response to fix everything was pretty quick and Jan Zerebecki summarized the events: Work is currently underway to restore the state of the Appdb to the backup of May 22 07:00 CST. [ed note: I think that's about 15 hours prior to the deletion] This morning ( TZ +0200 ) someone used the account "Molle Bestefich" to vandalize the Appdb. He was also seen on IRC and on the wiki. His IP was identified on all three, logs are available. See towards the end of this mail for IRC log snippet and whois on his IP. Please contact me first if you intend to contact abuse or police personnel regarding this, so we don't cause headaches or duplicate work. We do not yet know how this person got access to Molle Bestefich's account. I received 4454 emails about deletes or other actions by the account "Molle Bestefich". Send between "Date: Tue, 22 May 2007 21:43:46 -0500" and "Date: Tue, 22 May 2007 22:18:55 -0500". (2 mails sent by the Appdb in that date range were legit actions.) I don't know if these are all, because admin-accounts were explicitly deleted and thus the notification to them stopped. The following applications where mentioned in these notification emails: [link ] On IRC from the #winehq channel: `Mai 23 05:27:14 --> noerrorsfound_ (n=nicholas at h10.66.119.64.ip.alltel.net) has joined #winehq [unrelated stuff deleted] Mai 23 06:21:37 --- noerrorsfound_ is now known as molle-molle-moll Mai 23 06:21:41 <molle-molle-moll> molle molle molle Mai 23 06:22:18 <-- Amorphous has kicked molle-molle-moll from #winehq (Amorphous)` /whois output: `[06:22:38] --- [molle-molle-moll] (n=nicholas at h10.66.119.64.ip.alltel.net) : Nicholas [06:22:38] --- [whoismolle-molle-moll] irc.freenode.net :http://freenode.net/ [06:22:38] --- [molle-molle-moll] End of WHOIS list.` 2007-05-23T06:50:15+0200 $ whois 64.119.66.10 OrgName: Windstream Communications Inc OrgID: WINDS-6 Address: 4001 Rodney Parham Rd City: Little Rock StateProv: AR PostalCode: 72212 Country: US NetRange: 64.119.64.0 - 64.119.79.255 CIDR: 64.119.64.0/20 NetName: WINDSTREAM-COMMUNICATIONS NetHandle: NET-64-119-64-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Allocation NameServer: NS1-AUTH.WINDSTREAM.NET NameServer: NS2-AUTH.WINDSTREAM.NET NameServer: NS3-AUTH.WINDSTREAM.NET NameServer: NS4-AUTH.WINDSTREAM.NET Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RegDate: 2001-08-24 Updated: 2007-02-26 OrgAbuseHandle: WINDS1-ARIN OrgAbuseName: Windstream Abuse OrgAbusePhone: +1-888-292-3827 OrgAbuseEmail: abuse at windstream.net OrgTechHandle: WINDS-ARIN OrgTechName: Windstream Communications Inc OrgTechPhone: +1-800-990-4449 OrgTechEmail: ipadmin at windstream.net Chris Morgan gave an update after things were restored: As of right now the appdb site is back online, the account we suspect was used to delete the data has been removed, the 'roop' account isn't present and most everything appears to be back, except the screenshots that we had no backup of. I've also added a comment to the appdb main page to explain the downtime and what we plan to do to improve things. Anyone interested in hacking in php on the appdb is welcome to get in touch with me, there is plenty to hack on ;-) Also, I'll be updating the cron script so we can remove the screenshot entries that have no corresponding screenshot file.

WineHQ

Wine's AppDB was vandalized last week. It seems Molle Bestefich's account was compromised and someone began deleting massive amounts of content. The response to fix everything was pretty quick and Jan Zerebecki summarized the events:

Work is currently underway to restore the state of the Appdb to the backup of May 22 07:00 CST. [ed note: I think that's about 15 hours prior to the deletion]

This morning ( TZ +0200 ) someone used the account "Molle Bestefich" to vandalize the Appdb. He was also seen on IRC and on the wiki. His IP was identified on all three, logs are available. See towards the end of this mail for IRC log snippet and whois on his IP. Please contact me first if you intend to contact abuse or police personnel regarding this, so we don't cause headaches or duplicate work. We do not yet know how this person got access to Molle Bestefich's account.

I received 4454 emails about deletes or other actions by the account "Molle Bestefich". Send between "Date: Tue, 22 May 2007 21:43:46 -0500" and "Date: Tue, 22 May 2007 22:18:55 -0500". (2 mails sent by the Appdb in that date range were legit actions.) I don't know if these are all, because admin-accounts were explicitly deleted and thus the notification to them stopped.

The following applications where mentioned in these notification emails: [link ]

On IRC from the #winehq channel: Mai 23 05:27:14 --> noerrorsfound_ (n=nicholas at h10.66.119.64.ip.alltel.net) has joined #winehq [unrelated stuff deleted] Mai 23 06:21:37 --- noerrorsfound_ is now known as molle-molle-moll Mai 23 06:21:41 <molle-molle-moll> molle molle molle Mai 23 06:22:18 <-- Amorphous has kicked molle-molle-moll from #winehq (Amorphous)

/whois output: [06:22:38] --- [molle-molle-moll] (n=nicholas at h10.66.119.64.ip.alltel.net) : Nicholas [06:22:38] --- [whoismolle-molle-moll] irc.freenode.net :http://freenode.net/ [06:22:38] --- [molle-molle-moll] End of WHOIS list.

2007-05-23T06:50:15+0200 $ whois 64.119.66.10 OrgName: Windstream Communications Inc OrgID: WINDS-6 Address: 4001 Rodney Parham Rd City: Little Rock StateProv: AR PostalCode: 72212 Country: US NetRange: 64.119.64.0 - 64.119.79.255 CIDR: 64.119.64.0/20 NetName: WINDSTREAM-COMMUNICATIONS NetHandle: NET-64-119-64-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Allocation NameServer: NS1-AUTH.WINDSTREAM.NET NameServer: NS2-AUTH.WINDSTREAM.NET NameServer: NS3-AUTH.WINDSTREAM.NET NameServer: NS4-AUTH.WINDSTREAM.NET Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RegDate: 2001-08-24 Updated: 2007-02-26 OrgAbuseHandle: WINDS1-ARIN OrgAbuseName: Windstream Abuse OrgAbusePhone: +1-888-292-3827 OrgAbuseEmail: abuse at windstream.net OrgTechHandle: WINDS-ARIN OrgTechName: Windstream Communications Inc OrgTechPhone: +1-800-990-4449 OrgTechEmail: ipadmin at windstream.net

Chris Morgan gave an update after things were restored:

As of right now the appdb site is back online, the account we suspect was used to delete the data has been removed, the 'roop' account isn't present and most everything appears to be back, except the screenshots that we had no backup of.

I've also added a comment to the appdb main page to explain the downtime and what we plan to do to improve things. Anyone interested in hacking in php on the appdb is welcome to get in touch with me, there is plenty to hack on ;-)

Also, I'll be updating the cron script so we can remove the screenshot entries that have no corresponding screenshot file.

World Wine News