Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||19 Apr 2003 - 25 Apr 2003||(3 posts)||News: CrossOver Office 2.0, MS Threatens Developer|
|2.||22 Apr 2003||(2 posts)||Winelib CoolPlayer Port|
|3.||22 Apr 2003 - 23 Apr 2003||(6 posts)||Wintab Status and Development|
|4.||22 Apr 2003||(1 post)||Another List of Working Apps|
|5.||17 Apr 2003 - 19 Apr 2003||(6 posts)||Improving Wine's Debugger|
|6.||23 Apr 2003 - 24 Apr 2003||(2 posts)||Accessing ODBC Databases|
|7.||24 Apr 2003||(5 posts)||WineHQ Outage|
This is the 167th release of the Wine's kernel cousin publication. It's 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).
Mailing List Stats For This Week
We looked at 172 posts in 616K.
There were 64 different contributors. 28 posted more than once. 33 posted last week too.
The top posters of the week were:
1. News: CrossOver Office 2.0, MS Threatens Developer
19 Apr 2003 - 25 Apr 2003 (3 posts) Archive Link: "News"
People: DesktopLinux.com, LinuxWorld, CodeWeavers, , codeweavers, Jeremy White, DesktopLinux, 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 CodeWeaver's 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.
2. Winelib CoolPlayer Port
22 Apr 2003 (2 posts) Archive Link: "Winelib CoolPlayer port"
People: Vincent Beron,
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.
3. Wintab Status and Development
22 Apr 2003 - 23 Apr 2003 (6 posts) Archive Link: "Wintab32 dll devlopment"
People: Robert North, Aric Stewart, Mike Hearn, Jeremy White, CodeWeavers,
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
Immediate to dos
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.
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 Codeweaver 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.
4. Another List of Working Apps
22 Apr 2003 (1 post) Archive Link: "another wine apps database"
People: Dan Kegel,
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.com/?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.
p.s. Here's its lead-in text:
"The WINE List
By Graeme Bennett
Posted Aug. 6, 2002; updated Mar. 26, 2003
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."
5. Improving Wine's Debugger
17 Apr 2003 - 19 Apr 2003 (6 posts) Archive Link: "winedbg"
People: Michal Miroslaw, Eric Pouech, Ove Kaaven, , Ove Kåven
Michal Miroslaw had some ideas for improving the Wine debugger and wanted to know if anyone thought the improvements would be helpful:
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.
6. Accessing ODBC Databases
23 Apr 2003 - 24 Apr 2003 (2 posts) Archive Link: "ODBC"
People: Leonardo Luduena, Bill Medland,
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.
7. WineHQ Outage
24 Apr 2003 (5 posts) Archive Link: "Server Crash"
Topics: Project Management
People: Jeremy Newman, CodeWeavers,
Jeremy Newman dropped a note to inform everyone WineHQ died early in the morning Thursday. CodeWeavers hosts WineHQ along with their own network, perhaps this is an indication of how popular the new CrossOver Office is:
It's time for the annual server crash kids! Whee!
Our server melted last night at about 3am or so after 2 days of solid high traffic (the load average was up over 100). I managed to get it up and running with some WD-40, Duct Tape, and some bubble gum. I can't guarantee uptime right now. I AM, however, scrambling to beef it up to handle the load.
I apologize in advance for any further downtime. As you can imagine, with all this good press, I don't want the server do be down any longer than a few nanoseconds.
If anyone has a quad processor Xeon they are not using, feel free to send it my way. :-D
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.