Table Of Contents
|1.||6�Jan�2004�-�14�Jan�2004||(5 posts)||ODBC Fun - Tips and Tricks|
|2.||13�Jan�2004�-�14�Jan�2004||(5 posts)||Radius Cinepak Decoder and Directory Structure|
|3.||11�Jan�2004�-�13�Jan�2004||(12 posts)||Shell32 Update & Patch Submission Process|
|4.||9�Jan�2004||(5 posts)||Regression Testing Revisited|
|5.||8�Jan�2004�-�9�Jan�2004||(3 posts)||Key Signing Party at Wineconf|
This is the 205th issue of the Wine Weekly News publication. Its main goal is to huck cliffs. 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 (http://www.winehq.org)
Mailing List Stats For This Week
We looked at 174 posts in 700K.
There were 52 different contributors. 27 posted more than once. 33 posted last week too.
The top posters of the week were:
1. ODBC Fun - Tips and Tricks
6�Jan�2004�-�14�Jan�2004 (5 posts) Archive Link: "Wine User's guide : using Windows ODBC driver manager seems to work"
People: Aurelien Marchand,�Ulrich Czekalla,�Emmanuel Charpentier,�Boaz Harrosh,�CodeWeavers,�,�Microsoft
There's been some discussion lately about accessing ODBC compliant data sources using Windows programs and Wine. First, Aurelien Marchand ran into a problem with Crystal Reports:
I've dumped my WinNT workstation and replaced it with Linux. So far, I can do exactly everything I was able to do (except updating my calendar on the Exchange server used where I work), minus using Crystal Report. I have installed it using CodeWeavers' CrossOver Office and it installed without even a hiccup. I've also installed unixODBC and tested the odbc.ini configuration using isql. It works great when I try to connect to the company's AS400 database. The default library is set to my username and I can query other libraries using the dot (.) as a separator (e.g: SELECT * from OTHERLIB.OTHERTABLE).
So far so good: UnixODBC works perfectly to talk to IBM's AS400.
Now I need to tell Crystal which drivers to use. I've read on the web that Crystal is not a very good student and thus ignores Windows' ODBC.ini settings but checks what's in the registry. I've also come to understand I must set ODBC.dll = "builtin, native" in my Wine's config file so that it will try to use whatever is set for LIB_ODBC_DRIVER_MANAGER env variable for Windows' ODBC connections.
I've come to that point: my system.reg or my user.reg contain one ODBC setting (the same name found on /etc/odbc.ini and ~/.odbc.ini). My wine config file uses "builtin, native" for it's ODBC setting and my ~/.odbc.ini contains proper DSN settings (since I can query from the console using isql). The best part is, when I start Crystal Report, and select ODBC sources, I have in the dropdown that appears all the entries I've put in my ~/.odbc.ini file. As I said earlier, great strides indeed.
Now the last missing piece is that it seems Crystal using Wine and unixODBC cannot login properly and retrieve the table list. It just hangs when I expand the "+" box beside a DSN entry. I've enabled sql log (in /etc/odbcinst.ini) but I can't find really relevant information. Let me know if you want to see it.
So now I'm stuck. Any ideas on how I can make it work? Note: I've tried to Crystal's DB2 ODBC drivers and also with IBM DB2 ODBC drivers (both for Windows) - although it shouldn't make a difference.
Ulrich Czekalla suggested another way to do it, " This is the way I do it. Switch to native odbc32, install mdac (available with ms office or download from MS site) and then setup the dsns using odbcad32.exe."
That short exchange appeared last week. This week Emmanuel Charpentier ran across a similar problem and provided a brief explanation how he solved it:
Following a suggestion in Wine User's Guide, (� 1.1.2), I'd like to suggest an addition.
The "ODBC" section (5.12) gives details (5.12.1) about the use of the native ODBC driver, routed through a fake "builtin" ODBC driver. I have not yet had to test it in real conditions. All I can tell is that I wasn't able to use it to "Attach" (M$ jargon) Postgres data in MS Access (see PPS for the setup) : when I tried to select "ODBC sources" from the "Attach tables" dialog, I got immediately an error box from unixODBC telling me that no data source was specified.
However, the User's Guide is quite terse about the Windows ODBC driver. Exhaustive quotation : " Does anyone actually have any experience of this and anything to add?".
Well, I do. In the same setup as before, I have been able to use the *native* odbc32.dll ODBC driver by pulling it from a real Windows instalation and adding "odbc32"="native,builtin" in the config file. I Installed the psqlodbc driver from the Postgres database, and retried : selecting "ODBC sources" in the "Attach tables" dialog box led me to the usual ODBC manager dialogs, where I have been able to create a DSN to my Postgres database. I have then been able to "Attach" my Postgres tables and views to an M$ Access database and peruse them.
My conclusion is that such a setup can be used, if only to be able to export MS Access data to a more reasonable database manager. This information could be of some help to some people, and I'd like to see it reflected in the User's guide.
Of course, I'm aware that such a quick test is no substitute to real tests and explorations. Feel free to reach to me for further information, test cases, etc ...
Boaz Harrosh followed up with some more information, " Yes it works. My QA tested it throughly with MSSQL driver and there are no reported problems. The best way to go is a free download from Microsoft. mdac_typ.exe . Just Install it under wine and off you go. Also many MS applications Install them (like office). Than in system folder find cliconfig.exe & odbcad32.exe put them on the desktop. These are the same apps from the windows control panel. (you do have .exe associate with wine! yes?) "
2. Radius Cinepak Decoder and Directory Structure
13�Jan�2004�-�14�Jan�2004 (5 posts) Archive Link: "Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine"
People: Dmitry Timoshkov,�Mike McCormack,�Eric Pouech,�,�Dimi Paun
Mike McCormack ported an open source implementation of a Radius Cinepak video decoder developed by Dr. Tim Ferguson. This video format is used in some AVI and Quicktime formats, and in particular Half-Life's intro. Tim made the driver available to Wine under the provisions of the LGPL. The new DLL led to some discussion of exactly how to structure the codebase to accept some DLL's. After Mike submitted the patch, Dmitry Timoshkov requested, " Mike, could you put the iccvid sources at the same place as msrle32 (dlls/msvideo) and resend the patch? "
Mike replied, " I asked Alexandre where it should go, and he said wine/dlls was an appropriate place. I don't mind either way..."
Dmitry didn't care either, but felt there needed to be some consistency. If the ICCVID driver was moved to wine/dlls then MSRLE32 should be moved there as well. Dimi Paun was in favor of a flatter directory structure and advocated it be placed with the other DLL's. Eric Pouech disagreed, " I still don't see the point of having a unique dlls/ flat structure. Which more than 100 dlls right now, I do think we need to structure it. So putting the video codec in msvideo directory seems the easiest structure. We could also envisage to have a drivers or codecs directory, but that'll boil down to the same thing."
Alexandre ended up committing ICCVID driver into wine/dlls without a separate subdirectory.
3. Shell32 Update & Patch Submission Process
11�Jan�2004�-�13�Jan�2004 (12 posts) Archive Link: "Re: shell32 patches to be usable by ReactOS Explorer"
People: Martin Fuchs,�Dimitrie Paun,�Alexandre Julliard,�,�Microsoft,�Steven Edwards,�ReactOS,�Dimi Paun
Martin Fuchs submitted a hefty patch updating shell32. I'll include the full changelog in case you want to read it.
This patch consists of a number of changes we implemented in the ReactOS CVS tree in order to use Wine's shell32.dll implementation for ReactOS explorer. Please see the following changelog lists for the individual patch descriptions:
Ge van Geldorp
Preparation before moving SHGetFolderPath[AW]() into shfolder.dll:
That changelog is approximately ten million times larger than your average changelog. It's exactly the sort of merge nightmare everyone hates to see. On the one hand you have all this dazzling code that will surely make things better. On the other hand, you're surely going to introduce bugs that will be difficult to narrow down to a particular patch. Alexandre's stance is pretty firm on such issues - he doesn't apply massive patches. Dimi Paun complained first:
Martin, sending a bunch of patches compressed and in one message, makes them almost unreviewable but by the most die hards readers of wine-patches. It also makes it so much more difficult for Alexandre to split them up, match the ChangeLog, review them, etc. Please stick to one-(uncompressed, inlined)-patch-per-email-messsage rule, it's so much better for everybody. Here are some relevant links:
Martin thought it should just be committed:
Yes, I am aware of that. This patch is the result of four weeks work (not only of me), spending most of the time with debugging, as most of those stuff is pretty undocumented by Microsoft. It's not possible to simply look at the ReactOS CVS history to separate out patches for every small piece of change. If you want me to send in it this way, this would take me another week. I don't think, it's worth that. It would be better to commit the code changes in one transaction. Shell32 has been quite incomplete before this patch, and it's also far from complete with this patch.
Why I have compressed the attachments: Well, I don't think every one on the list wants to read the changes, which are not very readable at their own. And reading through endless hex numbers of shres.rc is also not very interesting.
I'm afraid you'll have to do that. There's no way I can put that patch in as is, it's way too big and doing way too many different things. It also has a number of ugly hacks that will have to be cleaned up. Please submit small self-contained patches that do only one thing, with a changelog explaining what they do.
I know it's a pain, but the real solution for next time is to submit things as soon as they are done, instead of waiting a month and then sending a huge patch that cannot possibly be reviewed.
Martin was afraid of that. He asked that the new icons be committed first and then the rest would be sorted out. Steven Edwards wondered if there were any CVS tools that would help with the merge process in the future. Dimi pointed out a script that was available, " There is csgrep in the tools/ module in CVS, but for that to work you guys need to run our commit_prep and log_accum in CVSROOT. If you do that, you get the wine-cvs - type messages for free, and can use our patch.py script to generate patches. From what I see in other similar systems (used in projects such as SourceForge/gcc/KDE/etc.), ours is the best -- comes highly recommended! ;)"
From there Steven began splitting up and submitting pieces of the original patch.
4. Regression Testing Revisited
9�Jan�2004 (5 posts) Archive Link: "Compilation broken in CVS"
People: ,�Paul Millar
Almost two years ago Paul Millar announced a Wine regression testing system that automatically built the latest version of Wine in CVS. Well, Paul has kept at it and you can still find his daily testing at:
One interesting area to look at is the execution of the Wine tests designed to stress different API's. The developers are adding about 4000 tests a year and we're now up to almost 8000.
5. Key Signing Party at Wineconf
8�Jan�2004�-�9�Jan�2004 (3 posts) Archive Link: "Key signing party at wineconf"
Topics: WineConf 2004
People: Shachar Shemesh,�
Shachar Shemesh announced some ultra-geeky fun for Wineconf:
I'm organizing a key signing party at wineconf. Anyone who wishes to participate, please email me the following details: Your full, real, name. It is not possible to participate in a key signing party using a nickname or a virtual identity. Sorry. Your key's fingerprint. Your actual key. Again, the key must have your real name on it (I am talking public key, of course. You should never send your private key to anyone).
I am going to compile the list of names into a keyring and post it to a public key server. If, for any reason, you wish your key to remain unpublished (highly unrecommended), please note so in your mail.
For more info about GPG key signing parties, check out the howto at http://www.cryptnet.net/fdp/crypto/gpg-party.html (http://www.cryptnet.net/fdp/crypto/gpg-party.html)
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.