WWN Issue 167

This is the 167th release of the Wine's kernel cousin publication. Its main goal is to keep me inside while everyone else digs themselves out of a meter of fresh snow. It also serves to inform you of what's going on around Wine (the Un*x Windows emulator).

This week, 172 posts consumed 616 K. There were 64 different contributors. 28 (43%) posted more than once. 33 (51%) posted last week too.

The top 5 posters of the week were:

25 posts in 88K by Dimitrie O. Paun
13 posts in 33K by Alexandre Julliard
12 posts in 65K by Dan Kegel
9 posts in 27K by Mike Hearn
9 posts in 17K by Lionel Ulmer

News: CrossOver Office 2.0, MS Threatens Developer	04/19/2003	Archive
News Wow, two major Wine product releases in the past week. WineX 3.0 last week and now CrossOver Office 2.0 this week. Major additions include support for Office XP, Access 2000, and Photoshop 7. For ordering info and a description of the product see the CrossOver Office web pages. Not surprising, Microsoft won't support it , but CodeWeavers will . The reviews are already starting to come in, DesktopLinux.com had the first one I found: I had been looking at earlier versions of CodeWeavers' products and had decided to buy CrossOver, but never got around to doing so. Oftentimes, we read reviews of what almost works on the Linux desktop and how features are "not quite there yet." CrossOver does not fit into that category. After a testing environment that allowed me to lean on the software and fully evaluate three versions of Adobe Photoshop, I determined that the product is fully capable of performing on Linux. It just works. For more details on what's new, see the Changelog and the Truth in Advertising pages. Some of additions mentioned, such as file locking and file change notification, have been in the LGPL Wine tree for a while now. We can also expect more changes merged back into the tree as the CodeWeavers patches get cleaned up and committed by Alexandre. Other news about CodeWeavers can be found in this week's interview with Jeremy White . There may not be an interview next week depending on how much load the WineHQ server is experiencing. No use in putting something up if none of you can get to it. In other Wine news, Joe Barr wrote short article for Linuxworld, "Catching up with Wine , discussing a broad range of Wine issues. The first page serves as a brief introduction about Wine, none of which is news to people who normally read this. More interesting are the claims on the second page about Microsoft threatening a FoxPro developer to prevent a demonstration of running Visual FoxPro with Wine: Whil Hentzen, longtime FoxPro developer and author, was planning to present a seminar about running Visual FoxPro (VFP) on Linux at a VFP-developers meeting in San Francisco earlier this month. His presentation included a demo of VFP running on Linux. Then he got a phone call from Microsoft. The caller informed him that doing the demo would be a violation of the VFP EULA. For the unintimidated who are curious about running Visual FoxPro on Linux, you can still visit the OpenFox.org Web site and view a HowTo on installing VFP with WINE (see "HOWTO: Install Visual FoxPro on Linux/WINE" in Resources below). [ed. quoted link is: http://www.openfox.org/wc.dll/sections/divulge/36 ] I had the opportunity to speak briefly to Hentzen as he walked through an airport, cell-phone in hand. He explained the root cause of Microsoft's unhappiness. "Microsoft hates FoxPro," Hentzen said. He went on to explain that Visual FoxPro has a free runtime. If you install a VFP application on a network with 97 users and they all use the application, Microsoft doesn't reap licensing fees for those 97 clients. Microsoft would much rather see customers use Visual Basic and Microsoft SQL because their use would require those same 97 users to purchase client licenses. When Microsoft bought FoxPro in 1992, its goal was simply to hurt market-leader Borland. The history of FoxPro since then is a perfect case study of how monopoly machinations in the software industry have absolutely nothing to do with developing good software and everything to do with control of the market. Slashdot also put together a summary of links concerning the issue, including a web page Whil is updating as the story unfolds .

News: CrossOver Office 2.0, MS Threatens Developer

04/19/2003

Archive

News

Wow, two major Wine product releases in the past week. WineX 3.0 last week and now CrossOver Office 2.0 this week. Major additions include support for Office XP, Access 2000, and Photoshop 7. For ordering info and a description of the product see the CrossOver Office web pages. Not surprising, Microsoft won't support it , but CodeWeavers will . The reviews are already starting to come in, DesktopLinux.com had the first one I found:

I had been looking at earlier versions of CodeWeavers' products and had decided to buy CrossOver, but never got around to doing so. Oftentimes, we read reviews of what almost works on the Linux desktop and how features are "not quite there yet." CrossOver does not fit into that category. After a testing environment that allowed me to lean on the software and fully evaluate three versions of Adobe Photoshop, I determined that the product is fully capable of performing on Linux. It just works.

For more details on what's new, see the Changelog and the Truth in Advertising pages. Some of additions mentioned, such as file locking and file change notification, have been in the LGPL Wine tree for a while now. We can also expect more changes merged back into the tree as the CodeWeavers patches get cleaned up and committed by Alexandre.

Other news about CodeWeavers can be found in this week's interview with Jeremy White . There may not be an interview next week depending on how much load the WineHQ server is experiencing. No use in putting something up if none of you can get to it.

In other Wine news, Joe Barr wrote short article for Linuxworld, "Catching up with Wine , discussing a broad range of Wine issues. The first page serves as a brief introduction about Wine, none of which is news to people who normally read this. More interesting are the claims on the second page about Microsoft threatening a FoxPro developer to prevent a demonstration of running Visual FoxPro with Wine:

Whil Hentzen, longtime FoxPro developer and author, was planning to present a seminar about running Visual FoxPro (VFP) on Linux at a VFP-developers meeting in San Francisco earlier this month. His presentation included a demo of VFP running on Linux. Then he got a phone call from Microsoft. The caller informed him that doing the demo would be a violation of the VFP EULA.

For the unintimidated who are curious about running Visual FoxPro on Linux, you can still visit the OpenFox.org Web site and view a HowTo on installing VFP with WINE (see "HOWTO: Install Visual FoxPro on Linux/WINE" in Resources below). [ed. quoted link is: http://www.openfox.org/wc.dll/sections/divulge/36 ]

I had the opportunity to speak briefly to Hentzen as he walked through an airport, cell-phone in hand. He explained the root cause of Microsoft's unhappiness. "Microsoft hates FoxPro," Hentzen said. He went on to explain that Visual FoxPro has a free runtime. If you install a VFP application on a network with 97 users and they all use the application, Microsoft doesn't reap licensing fees for those 97 clients. Microsoft would much rather see customers use Visual Basic and Microsoft SQL because their use would require those same 97 users to purchase client licenses.

When Microsoft bought FoxPro in 1992, its goal was simply to hurt market-leader Borland. The history of FoxPro since then is a perfect case study of how monopoly machinations in the software industry have absolutely nothing to do with developing good software and everything to do with control of the market.

Slashdot also put together a summary of links concerning the issue, including a web page Whil is updating as the story unfolds .

Winelib CoolPlayer Port	04/22/2003	Archive
Utilities Vincent Béron ported CoolPlayer to Linux/Un*x using Wine. He posted a patch to wine-patches with the modifications needed to make it compile: This is what's needed to compile CoolPlayer as a Winelib app. CoolPlayer is an MP3/OGG/stream player for Windows. Note that the patches doesn't touch anything inside of Wine. CVS Wine is needed until the next release though. The main change is the Makefiles, as CoolPlayer is currently developed with MS Visual Studio. Then there's the usual filename case-sensitivity. After that a typo and an empty enum declaration in an unused function prototype. Next is a difference in inline asm syntax between MSVC and gcc. Somebody got a better way to do it? Then is some type definition (might be better fixed in another way). This ends the conversion to gcc. Next is the actual Winelib stuff, which is very small. The first part is an MFC header (thankfully, nothing else seems to be needed from MFC). The second part is the only problematic thing. The current div implementation works fine for binary compatibility on i386, but doesn't work well for source level compatibility on the same platform. Other platforms are fine. This is really the only thing which needs to change in Wine. Next phase is to get the relevant changes accepted in CoolPlayer (already started), and fix the last Wine issue so that div_t d=div(a, b) works as expected.

Wintab Status and Development	04/22/2003	Archive
Robert North wrote in to give a status update on the wintab32 (tablet support) implementation he's working on. The status update is in the Bugzilla database as bug #1160 , but here is what he wrote: Ok, I think it's time I give a status update on the progress of the wintab32 dll implementation: What's been completed Investingation into how Photoshop 6 & Painter 5 use the wintab dll in Win98. I now have a dll that can replace wintab & log calls to wintab functions, with some parameters. It can also log the sending/posting of windows messages in the range used by wintab. I have gathered enough data to understand what to implement for Photoshop & Painter. Design of the wine wintab implementation. I now have enough design to start implementing. The design isn't complete, but should take me through to getting enough features working for Painter & Photoshop. The design doesn't go deep enough to suit needs of CAD programs, but as I don't posess any programs of this type I can't really progress any further here. Implementation of wine wintab. I've been concentrating on the WTInfo function. This is a swiss army knife of a function, for accessing all kinds of information about wintab devices. All the data structures to store info about devices, and cursors are implemented. These data structures extend the basic support for WTInfo to store private information to allow interaction of the wintab dll with XInput. Most of the code to fill these structures from XInput is completed. The WTInfo support is 90% implemented. Immediate to dos Finish WTInfo support. (Will have gaps in some areas not required by Painter or Photoshop) Implement a wintab context, and enough functions for Painter & Photoshop to configure it. The wintab context is a handle to the communication channel between the application and the wintab device. Start reading tablet packets from the wintab context. Transform the coords in accordance with the data in the wintab context. Use some form of config file to define the mapping from XInput devices to wintab devices. Long term to dos These are tasks I may not be able to spare the time for, or for which I don't have anything to test. Look at z-order issues for wintab contexts. Wintab contexts have a z-order that appears to be independent of window z-order. This will need further investigation, to find out how to map to XInput concepts. Look at the WTMgr functions: These manage the tablet devices. Is there any need for these? I'm assuming that the native OS has adequate tools to manage tablets for now. Robert's post to wine-devel also included a bunch of questions including, I heard somewhere that CrossOver Office had a tablet implementation. Does anyone know about this, and who to contact to find out more? If they've got an implementation of wintab, I wonder if it's worth continuing the development. Aric Stewart replied: I did a Wintab32 implementation for CrossOver Office 2.0. I will create a patch for winehq and submit it later today. If you want to continue to work off of that you are welcome to. It may be best not to duplicate work too much. My development was specifically for the wacom intuos tablet. I tried hard to make it general enough to incorporate anything using wintab32.dll but if you have other devices that would be great. About an hour later Aric posted a patch with CodeWeavers wintab32 implementation. That prompted Mike Hearn to ask: This is a very large amount of code, it's slightly concerning to me that apparently nothing was said about this before despite the fact that Robert North said he was working on it. Is it CodeWeavers policy not to reveal what new features are being added until the code is merged? In particular, I'm now left wondering whether or not the system tray in CX Office has XEMBED support (as this bug is highly user visible for non-kde users, so it might have been a candidate for a fix) - at some point once I've finished my current project and resolved a few ActiveX painting bugs I'm going to try and implement XEMBED support for the system tray, but I don't want to waste my time if it's already been implemented by CodeWeavers. Jeremy White replied: No, our policy is not to be particularly secretive; we particularly don't want to waste anyones time, ever. There is so much to do that any inefficiency is anathema to us. We just goofed. In fact, Alexandre often goes out of his way to spot cases where someone is working on something we're also working on, and tries to make sure that there is no wasted effort. You can use the NPTL work as one example, and there were also some critical Photoshop install bugs that were fixed in WineHQ because Alexandre noticed someone needed them. Also, we did discuss Rob's work before Aric started on Wintab. We noted he'd said he was working on it, but we hadn't seen any patches or heard anything further (afair, his last email was November), so we assumed he hadn't had time. The rude thing we did was failed to send an email to Rob with a heads up/gut check with him on the status. If it helps, Aric feels terrible about it. Now, I will say, we do like to hold our development tree separate while we're working on it. This is in part just so we can stabilize around a release, but it's also in part so we can get a big 'publicity' splash around new features. I know that Chris poked at the system tray support, but didn't get very far, and we pulled him to attacking other things in the hopes that Mike Hearn would get the XEMBED support done... Candidly, we often see other peoples work and think 'ooooh, I hope we can get that into CrossOver X.X', but we feel that it would be rude to tell you to hurry up and get XEMBED done so we can ship 2.1 <grin>. I do have to admit that I think we've done a pretty poor job of interacting with wine-devel, sometimes. We just had a big discussion on IRC about it. We're reluctant to do our development 'in the open' (i.e. submit our patches as we work on them). I should be clear - the developers are cheerful to do that, but Management is not comfortable. We really do live and die by our CrossOver Sales; we're just barely making enough money to keep doing what we're doing (and some months, not even that), and we worry that if WineHQ starts having all of our 'good stuff' before we can make a splash with it, it will harm us. It nearly happened to us just now; ELX Linux announced Photoshop 7 support before cxoffice 2.0 (luckily they didn't get much press). Also, we're really not all that secretive. We've been telling pretty much anyone who wants to know that we were working on Photoshop, Access, and Office XP. Next is the Macromedia stuff... We're small, so we do change direction when a paying customer waves money at us, but we try to be pretty open. Just ask <grin> We're debating now how to do better. And we're open to suggestions. Ideas? In fact, I'd like to know if there are more simmering complaints out there. If there is anything else we've done that pissed someone off, but they were too polite to mention it, let us know. I'd rather we intentionally pissed people off than did it by accident <grin>. Robert understood where Jeremy was coming from, but felt more communication would benefit everyone: I think the rule should be that if someone says they're working on something then anyone who wants to work on the same area should contact them. This is a rule everyone should keep in mind, not just CodeWeavers employees. Maybe you should consider approaching developers who are working on things close to you commercial interests, and see if you can work together for mutual benefit. Now back to thinking about how to integrate what I've done with Aric's code.

Wintab Status and Development

04/22/2003

Archive

Robert North wrote in to give a status update on the wintab32 (tablet support) implementation he's working on. The status update is in the Bugzilla database as bug #1160 , but here is what he wrote:

Ok, I think it's time I give a status update on the progress of the wintab32 dll implementation:

What's been completed

Investingation into how Photoshop 6 & Painter 5 use the wintab dll in Win98. I now have a dll that can replace wintab & log calls to wintab functions, with some parameters. It can also log the sending/posting of windows messages in the range used by wintab.

I have gathered enough data to understand what to implement for Photoshop & Painter.
Design of the wine wintab implementation. I now have enough design to start implementing. The design isn't complete, but should take me through to getting enough features working for Painter & Photoshop. The design doesn't go deep enough to suit needs of CAD programs, but as I don't posess any programs of this type I can't really progress any further here.
Implementation of wine wintab. I've been concentrating on the WTInfo function. This is a swiss army knife of a function, for accessing all kinds of information about wintab devices.

All the data structures to store info about devices, and cursors are implemented. These data structures extend the basic support for WTInfo to store private information to allow interaction of the wintab dll with XInput. Most of the code to fill these structures from XInput is completed.

The WTInfo support is 90% implemented.

Immediate to dos

Finish WTInfo support. (Will have gaps in some areas not required by Painter or Photoshop)
Implement a wintab context, and enough functions for Painter & Photoshop to configure it. The wintab context is a handle to the communication channel between the application and the wintab device.
Start reading tablet packets from the wintab context.
Transform the coords in accordance with the data in the wintab context.
Use some form of config file to define the mapping from XInput devices to wintab devices.

Long term to dos
These are tasks I may not be able to spare the time for, or for which I don't have anything to test.

Look at z-order issues for wintab contexts. Wintab contexts have a z-order that appears to be independent of window z-order. This will need further investigation, to find out how to map to XInput concepts.
Look at the WTMgr functions: These manage the tablet devices. Is there any need for these? I'm assuming that the native OS has adequate tools to manage tablets for now.

Robert's post to wine-devel also included a bunch of questions including, I heard somewhere that CrossOver Office had a tablet implementation. Does anyone know about this, and who to contact to find out more? If they've got an implementation of wintab, I wonder if it's worth continuing the development.

Aric Stewart replied:

I did a Wintab32 implementation for CrossOver Office 2.0. I will create a patch for winehq and submit it later today. If you want to continue to work off of that you are welcome to. It may be best not to duplicate work too much.

My development was specifically for the wacom intuos tablet. I tried hard to make it general enough to incorporate anything using wintab32.dll but if you have other devices that would be great.

About an hour later Aric posted a patch with CodeWeavers wintab32 implementation. That prompted Mike Hearn to ask:

This is a very large amount of code, it's slightly concerning to me that apparently nothing was said about this before despite the fact that Robert North said he was working on it.

Is it CodeWeavers policy not to reveal what new features are being added until the code is merged? In particular, I'm now left wondering whether or not the system tray in CX Office has XEMBED support (as this bug is highly user visible for non-kde users, so it might have been a candidate for a fix) - at some point once I've finished my current project and resolved a few ActiveX painting bugs I'm going to try and implement XEMBED support for the system tray, but I don't want to waste my time if it's already been implemented by CodeWeavers.

Jeremy White replied:

No, our policy is not to be particularly secretive; we particularly don't want to waste anyones time, ever. There is so much to do that any inefficiency is anathema to us.

We just goofed.

In fact, Alexandre often goes out of his way to spot cases where someone is working on something we're also working on, and tries to make sure that there is no wasted effort. You can use the NPTL work as one example, and there were also some critical Photoshop install bugs that were fixed in WineHQ because Alexandre noticed someone needed them.

Also, we did discuss Rob's work before Aric started on Wintab. We noted he'd said he was working on it, but we hadn't seen any patches or heard anything further (afair, his last email was November), so we assumed he hadn't had time.

The rude thing we did was failed to send an email to Rob with a heads up/gut check with him on the status. If it helps, Aric feels terrible about it.

Now, I will say, we do like to hold our development tree separate while we're working on it. This is in part just so we can stabilize around a release, but it's also in part so we can get a big 'publicity' splash around new features.

I know that Chris poked at the system tray support, but didn't get very far, and we pulled him to attacking other things in the hopes that Mike Hearn would get the XEMBED support done...

Candidly, we often see other peoples work and think 'ooooh, I hope we can get that into CrossOver X.X', but we feel that it would be rude to tell you to hurry up and get XEMBED done so we can ship 2.1 <grin>.

I do have to admit that I think we've done a pretty poor job of interacting with wine-devel, sometimes. We just had a big discussion on IRC about it.

We're reluctant to do our development 'in the open' (i.e. submit our patches as we work on them).

I should be clear - the developers are cheerful to do that, but Management is not comfortable. We really do live and die by our CrossOver Sales; we're just barely making enough money to keep doing what we're doing (and some months, not even that), and we worry that if WineHQ starts having all of our 'good stuff' before we can make a splash with it, it will harm us. It nearly happened to us just now; ELX Linux announced Photoshop 7 support before cxoffice 2.0 (luckily they didn't get much press).

Also, we're really not all that secretive. We've been telling pretty much anyone who wants to know that we were working on Photoshop, Access, and Office XP. Next is the Macromedia stuff... We're small, so we do change direction when a paying customer waves money at us, but we try to be pretty open. Just ask <grin>

We're debating now how to do better. And we're open to suggestions. Ideas?

In fact, I'd like to know if there are more simmering complaints out there. If there is anything else we've done that pissed someone off, but they were too polite to mention it, let us know.

I'd rather we intentionally pissed people off than did it by accident <grin>.

Robert understood where Jeremy was coming from, but felt more communication would benefit everyone:

I think the rule should be that if someone says they're working on something then anyone who wants to work on the same area should contact them. This is a rule everyone should keep in mind, not just CodeWeavers employees.

Maybe you should consider approaching developers who are working on things close to you commercial interests, and see if you can work together for mutual benefit.

Now back to thinking about how to integrate what I've done with Aric's code.

Another List of Working Apps	04/22/2003	Archive
Dan Kegel posted a link to a web page listing apps that work under Wine: Anyone seen this one yet? http://thetechnozone.com/pcbuyersguide/software/system/TheWineList.html It seems good enough that perhaps there should be a link to it from http://www.winehq.org/?page=supported_applications We might want to nudge the author into disclosing the version number of the Wine he was using, so non-Knoppix users can compare versions. - Dan p.s. Here's its lead-in text: "The WINE List By Graeme Bennett Posted Aug. 6, 2002; updated Mar. 26, 2003 Introduction Wine (which, its authors say, stands for 'Wine is not an emulator') is a Windows-compatible application launching environment for Linux and several other non-Microsoft other operating systems in which users can run many programs designed for Windows. Since not every Windows program runs correctly under Wine, and many of the programs I tested successfully were not listed on the other Wine compatibility lists I found, I've put together this list of programs that work (or at least seem to work -- I didn't test every function of every program!) more or less as they do under Windows. For these tests, I used the Wine version built into Knoppix versions 3.1 and 3.2. Knoppix is a free Debian-based Linux distribution that requires no installation on or changes to your hard drive. It boots and runs its filesystem directly from a CD. Additionally, it write-protects your Windows hard drive(s) by default, making it an exceptionally safe way to test Wine and/or Linux. Zero Config Wine All programs tested were previously installed and no special setup, configuration or manual file copying under Wine was used. In other words, any program listed below works "as is."

Improving Wine's Debugger 04/17/2003 Archive

Improving Wine's Debugger	04/17/2003	Archive
Debugging Michal Miroslaw had some ideas for improving the Wine debugger and wanted to know if anyone thought the improvements would be helpful: enabling/disabling of displays [done] displays shown in one function only [done] implement define command to add symbols on the fly (didn't find it is sources except in help text ...) save/restore breakpoints/displays/defined symbols reverse backtrace list (so current frame is at the bottom and you don't have to scroll all the way up) remove limit of 10 entries in DEBUG_GetSymbolValue [done] remove duplicated code in DEBUG_FindNearestSymbol/DEBUG_CheckLinenoStatus You can download the patch against current CVS from: http://mion.elka.pw.edu.pl/~mmirosla/winedbg.diff Eric Pouech was happy to see the improvements, but cautioned against doing more: I don't think we should spend too much time enhancing winedbg. moreover, the `--gdb` option deprecates most of the extension you're looking at (I even wonder if we shouldn't set `--gdb` as default way to run winedbg, and to have a specific command line options for the current debugger) Ove Kåven didn't think that was a good idea until more functionality was added, Can you see backtraces for other threads than the current (the one that crashed) from gdb yet with that code? If not, `--gdb` is almost useless, most of the problems I've had that `--gdb` might have solved have been multithreaded. I once took a look but the code didn't spell out anything like "implement this to be able to read the registers of other threads" either, do you have a plan for it? The next day Eric posted a patch to fix it .

Debugging

Michal Miroslaw had some ideas for improving the Wine debugger and wanted to know if anyone thought the improvements would be helpful:

enabling/disabling of displays [done]
displays shown in one function only [done]
implement define command to add symbols on the fly (didn't find it is sources except in help text ...)
save/restore breakpoints/displays/defined symbols
reverse backtrace list (so current frame is at the bottom and you don't have to scroll all the way up)
remove limit of 10 entries in DEBUG_GetSymbolValue [done]
remove duplicated code in DEBUG_FindNearestSymbol/DEBUG_CheckLinenoStatus

You can download the patch against current CVS from: http://mion.elka.pw.edu.pl/~mmirosla/winedbg.diff

Eric Pouech was happy to see the improvements, but cautioned against doing more:

I don't think we should spend too much time enhancing winedbg.

moreover, the --gdb option deprecates most of the extension you're looking at (I even wonder if we shouldn't set --gdb as default way to run winedbg, and to have a specific command line options for the current debugger)

Ove Kåven didn't think that was a good idea until more functionality was added, Can you see backtraces for other threads than the current (the one that crashed) from gdb yet with that code? If not, --gdb is almost useless, most of the problems I've had that --gdb might have solved have been multithreaded. I once took a look but the code didn't spell out anything like "implement this to be able to read the registers of other threads" either, do you have a plan for it?

The next day Eric posted a patch to fix it .

Accessing ODBC Databases	04/23/2003	Archive
IO Leonardo Ludueña asked a question that comes up from time to time, We have an application developed by our company, that application use a ODBC connection. I need to know if there previous experiencies with that kind of port. Bill Medland shared his experiences with it: What do you want to know? The builtin version of odbc32.dll basically acts as a connection to any underlying unix ODBC (e.g. unixODBC or iODBC; I only have experience of unixODBC). Therefore it basically handles just about anything that the underlying ODBC does. We use it against IBM DB2 databases, and I think we have succeeded (sort of, in the past) against Oracle databases. The problem against MS-SQL and other databases is finding a unixODBC driver. The other possibility is to use a native Microsoft odbc32.dll and its drivers (if that is legal) and depend upon Wine handling the low-level network stuff etc. I don't personally have any experience of that. For more info, see the Wine User Guide .

Accessing ODBC Databases

04/23/2003

World Wine News