Wine Traffic Brian Vincent

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
Documentation 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?)

Multimedia 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.

Patches 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

  • Return absolute path from SHGetPathFromIDListA
  • Allow SHGetPathFromIDListA to resolve items in special folders.
  • shlview.c: Execute items by default using new function ShellView_OpenSelectedItems()
  • Don't return executable name in double quotation marks from FindExecutable
  • Since IExtractIcon::GetIconLocation returns the icon *index* (not the resource id) and some of these indexes are hardcoded in folders.c IExtractIconW_fnGetIconLocation() add some dummy icons to force correct index.

Filip Navara

  • shell32_Cs.rc: Czech translation

Preparation before moving SHGetFolderPath[AW]() into shfolder.dll:

  • Moved actual code from SHGetSpecialFolderPathA to SHGetFolderPathW, adjusted and unicodified it.
  • Rewrote SHGetFolderPathA to call SHGetFolderPathA.
  • Rewrote SHGetSpecialFolderPath[AW] to call SHGetFolderPath[AW].

Everaldo Coelho

  • better looking shell icons with 4, 8 and 32 bit colors

Martin Fuchs

  • correct path parsing in ISF_Desktop_fnParseDisplayName()
  • handle CLSID paths in ISF_MyComputer_fnParseDisplayName()
  • return CLSID path in ISF_MyComputer_fnGetDisplayNameOf()
  • implemented flag SEE_MASK_IDLIST for ShellExecuteEx()
  • removed warning message for previously unimplemented flag SEE_MASK_INVOKEIDLIST in ShellExecuteEx()
  • add a few TRACE messages to ShellExecuteXYZ()
  • SIC_IconAppend(), SIC_GetIconIndex(): use GetFullPathName() instead of PathFindFileNameA() to make icon paths unique
  • fixed HCR_GetExecuteCommandExA/W() to correct ShellExecuteEx() behaviour with flag SEE_MASK_CLASSNAME set
  • RenderFILENAMEA/W(): only return valid file system names
  • extended CSIDL_Data for missing CSIDL_... definitions
  • introduced IDL type PT_RAS_FOLDER for "Connections" shell folder
  • implementation of shell link resolving for ShellExecuteXYZ() and IExtractIcon: _ResolveShortCut(), IShellLink_ConstructFromFile(), I...XYZ...fnGetUIObjectOf(), _PidlGeticonLocationA/W(), IShellLinkA/W_fn...(), IExtractIconW_fnGetIconLocation()
  • CreateStreamOnFile(): use flag FILE_SHARE_READ for opening OLE stream files
  • introduced optimized internal functions SHELL_GetPathFromIDListA/W() with HRESULT return value
  • SHGetPathFromIDListA/W() return now like on real Windows only real file system paths, no virtual CLSID paths.
  • shres.rc, SIC_Initialize(): moved ID for document icon from invalid index 0 to 1
  • SIC_Initialize(): use full path to shell32.dll for icon cache
  • adjusted ExtractIconExW() to be usable with MinGW and MSVC
  • ISvItemCm_fnQueryContextMenu(): corrected default menu item in shell context menus
  • ISvItemCm_fnQueryContextMenu(): distinguish between Open and Explore commands
  • ShellView_DoContextMenu(): activate Explore-Context menu on the desktop
  • ShellView_CreateList(), SIC_Initialize(), PidlToSicIndex(): enabled transparent icons on the desktop
  • SHGetDataFromIDListA/W(): corrected error handling
  • I...XYZ...fnGetUIObjectOf(): better error handling
  • ISF_MyComputer_fnGetDisplayNameOf(): better error handling
  • AboutDlgProc(): don't link to undocumented string functions in NTDLL to be compatible with MSVC and MinGW
  • SHSimpleIDListFromPathA(): don't link to undocumented string functions in NTDLL to be compatible with MSVC and MinGW
  • SHGetDataFromIDListA/W(): handle drives when retrieving file attributes
  • _ILCreateFolder, _ILCreateValue(): added missing type casts from DWORD to WORD
  • shell32_XY.rc: corrected menu item ids FCIDM_SHVIEW_OPEN and FCIDM_SHVIEW_EXPLORE
  • DllMain(): get full path and name to shell32.dll for IExtractIconW_fnGetIconLocation(); directly call InitCommonControlsEx()
  • pseudo-implementation for IPersistFile_fnIsDirty()
  • IShellLinkA/W_fnGetPath(): added FIXME
  • shellink.c: corrected SCF_UNICODE constant
  • _FS_ProcessDisplayFilename(): hide configured file extensions in file system shell folders and on the desktop
  • ISF_Desktop_fnParseDisplayName(): correct file path parsing on the desktop
  • SHELL_FindExecutable(); use PathFindExtensionA() instead if strrchr()
  • SHELL32_CoCreateInitSFEx(): improved error handling
  • SHMapPIDLToSystemImageListIndex(): improved error handling
  • SHELL_FindExecutable(): use PathFindExtension() instead of strrchr()
  • folders.c: include header files "config.h" and "port.h" for strcasecmp()
  • shellink.c: corrected shell link saving
  • IShellLink: implemented IPersistFile::IsDirty()
  • ShellExecuteExA(), ISF_MyComputer_fnGetDisplayNameOf(): handle shell links to virtual folders
  • read in shell links to control panel applets and enable ShellEcecute() to launch them
  • Implementation of control panel folder
  • partial implementation of file system folder execution in ShellExecute()
  • ExitWindowsDialog(): implemented shutdown request for OS versions NT and better
  • implementation of RestartDialog() and RestartDialogEx()
  • SHELL32_GetItemAttributes(): implemented SFGAO_LINK
  • corrected definition of PathYetAnotherMakeUniqueName()
  • implemented SHGetRealIDL()
  • fixed allocation length in RenderFILENAMEW()
  • SHBindToParent(): call QueryInterface for Desktop
  • ShellExecuteExA32(): expand environment strings

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.

Alexandre disagreed:

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.

Testing 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.

WineConf 2004

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