WineHQ

World Wine News

All the news that fits, we print.

05/14/2004
by Brian Vincent
Issue: 222

XML source
More Issues...

This is the 222nd issue of the Wine Weekly News publication. Its main goal is to wash smelly socks. 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, 283 posts consumed 1186 K. There were 87 different contributors. 43 (49%) posted more than once. 37 (42%) posted last week too.

The top 5 posters of the week were:

  1. 24 posts in 65K by Mike Hearn
  2. 23 posts in 54K by Alexandre Julliard
  3. 15 posts in 35K by Dimitrie O. Paun
  4. 11 posts in 32K by Dmitry Timoshkov
  5. 11 posts in 35K by Bill Medland

News: Wine-20040505, CrossOver Office 3.0, WineX 3.3.2 05/01/2004 Archive
News

Well, looks like I have a bit of catching up to do. Last week while I was gone, Alexandre released Wine-20040505:

WHAT'S NEW with Wine-20040505: (see ChangeLog for details)

  • Many more filesystem improvements, including autodetection of drive types and devices, and support for editing the drive configuration with winecfg.
  • Many Direct3D improvements.
  • Several fixes to the various sound drivers.
  • Lots of bug fixes.

The major changes are the DLL separation of the filesystem architecture. In fact, things seem to be mostly complete now. Various cleanups remain and a few things still reside in the files/ directory. It also seems like some work is shifting towards Wine configuration. Alexandre said a few months ago he didn't want to get rid of the Wine config file until the filesystem changes are done. Now we're starting to see some of the configuration work commence.

The biggest news from the commercial side of Wine is the release of CrossOver Office 3.0. CodeWeavers announced the details on Tuesday. Many people will be ecstatic about new support for Lotus Notes 5.0 and 6.5.1, Microsoft Project, and Outlook XP. Lotus Notes has long been on the wish list and happens to have the highest bounty in CodeWeavers' Compatibility Center. While not officially supported, there are reports that Microsoft Money and FrameMaker have also seen dramatic improvements.

Besides new applications, CodeWeavers has dramatically changed the product by combining all of the CrossOver Plugin functionality into CrossOver Office. In fact, CrossOver Plugin is now a product that will not be released separately. To accompany these changes a new licensing mechanism was introduced. Jeremy White explained the reasoning behind it in an email to the CrossOver announcement list:

we have split the product into a 'Standard' edition and into a 'Professional' edition. The Standard edition does everything our single user customers have always wanted, and it does so now at a much lower price - $39.95. The Professional edition is focused on our customers who value higher support, multi user features, and the ability to perform managed application installations.

To try to make this change as painless as we possibly could, we have taken the following steps:

  1. We have added 1 month of support time to all customers. This should ensure that anyone that bought CrossOver 2.1 is entitled to a free upgraded to 3.0.
  2. We have upgraded everyone's account status as follows:

      A. All Plugin and single user Office customers have access to CrossOver Office Standard

      B. All Bundle and multi user licenses have access to CrossOver Office Professional, including an increase in support priority to level 2.

There were several rounds of beta tests and it seems to have paid off. There are many positive reports of successful upgrades on the CodeWeavers' mailing list.

Not to be left out, TransGaming announced a minor upgrade to WineX bringing it up to version 3.3.2. The major addition is support for Star Wars: Knights of the Old Republic . May's Development Status and Voting Report was published the same day.

Did you see our first interview of the year with Mike Hearn ?

Finally, we got a little bit PR this week. A short article on eWeek appeared about running Windows apps on Linux. CrossOver Office made the list . Slashdot referenced Wine twice with regards to the CrossOver 3.0 release and solicting questions for CodeWeavers' Jeremy White.


Project David Uses CodeWeavers CrossOver Office 05/08/2004 Archive
Commercial Development

Ge van Geldorp spotted some news pointing at Project David being a Wine derivative:

There are some screenshots available now at

One of the comments on osnews noticed that in the picture

the second line in winbridge.lst is /etc/wine... There are more clues that this project David is just a (possibly repackaged) Wine.

Mike McCormack then looked a little closer and discovered it wasn't just regular Wine from WineHQ:

Actually, it's just CrossOver Office's Wine repackaged. Check out this screenshot:

Look closely at right and bottom side of the window. The scrollbar and status bar are clipped. That's a CrossOver Office only bug, which doesn't appear in WineHQ!

So they've at least ripped off some (likely all) of the CrossOver Office Wine package, and hyped it as their own.

Hopefully the real media will pick up on the fact that SpecOpS Labs is peddling technology developed by other people with apparently no added value. The company seems to thrive on smoke and mirrors, and currently their website has "temporarily disabled" web pages discussing technology.

All signs point to Losers.


Retaining Clipboard After Closing Apps 05/12/2004 Archive
Integration

Wine has had decent copy and pasting support for a while. Santosh Siddheshwar discovered something that might go against expected behavior, Does WINE support access to clipboard data across WINE processes. For e.g. one app opens the clipboard and sets data into it using SetClipboardData, closes it and then exits. The other app tries to retrieve this data. It works in windows but doesn't seem to do so in WINE.

Jerry Haltom explained it was a problem in X:

This would be a deficiency (or so some say) of the X clipboard design. There is no "storage buffer" for clipboard data.

A process, when it hits Copy (SetClipboardData) registers that it owns the clipboard. When another program hits paste, only then is the data transferred between the processes. It is this way to support content negotiation... where the data that gets copied or pasted might be a different format depending on where you paste it. Plain text, HTML, RTF, etc.

A downside is when the owning program closes, the data is lost.

Ulrich Czekalla pointed out a possible workaround:

The short answer is no. We did have this functionality before and much of the code is still in cvs but it was broken for some time and I've disabled it. With a little bit of work it could be added back.

There are other ways to do this such as using klipper.


Hiding Symbols & PE vs. ELF 05/12/2004 Archive
Build Process

ELF has been the dynamic library of choice in Linux for about eight years now. Other operating systems also support the same format. Windows, however, uses a different type of library - the PE format. Dan Timis wondered how to replicate some of Windows' PE functionality on Linux:

We need to have a library that links statically to a wine application. The wine application is an .exe.so, so everything becomes in the end an exe.so. The problem we have is that all the symbols are exposed.

I have very little experience with Windows, but I understand that with a Windows DLL you can export certain functions, while hiding the others. I know that's also true for the Mac.

Is there any way to export only the functions that are called by the code we link to, without exposing the internal workings? Ideally we would like to be able to provide a static library created with ar or ranlib, link that library with other object files to create a .exe.so for wine, but when you do "nm" on the resulting .exe.so you would not see all the inner workings of our library.

Is that possible?

Dan then wrote back to clarify exactly what he was doing. After compiling he ran strip against it after which nm -D still showed all the symbols. Dan only wanted the ones needed for dynamic linking to be there. Dmitry Timoshkov understood the problem, but since it's not a problem with Wine per se he referred Dan elsewhere, Actually that's a question for binutils mailing list. I was researching that problem some time ago and found that dynamic linker has a switch '--retain-symbols-file FILENAME ' to leave only listed in the FILENAME names in the SYMBOL TABLE. But according to 'objdump -xstTR ' DYNAMIC SYMBOL TABLE still has all global symbols listed. I'd call it a limitation of ELF format, which has no a concept of exported symbols.

Mike Hearn agreed that the binutils authors were the ones to contact. The ELF format doesn't really provide a mechanism for this, however Mike thought that Nvidia has a method that uses the preprocessor to mangle symbols. Dan described such a method that he might implement:

I might do code obfuscation. But, it may be safer for me to do something like:

    #define MyClass  F18Rsjkfgwe6
    #define MyMethod aYSm48dYo49H

    class MyClass {
      void MyMethod(cha *, bool);

rather than mess with the binaries.

Paul Davis then brought up a different point of view that turned the conversation more into an ELF vs. PE discussion:

i'd just like to mention a small concern i have.

hiding symbols might well be a perfectly honest thing to want to do. i personally can't see why, since a list of symbol names doesn't provide much extra help to somebody who wants to disassemble and reverse engineer your code. but i can understand that there might be some circumstances where its desirable.

the problem is while hiding symbols doesn't impede a disassembler/reverse engineering effort very much, it does impede attempts to demonstrate the inappropriate use of someone else's code.

for this reason, i personally wouldn't feel comfortable asking in a public forum how to go about doing this. your mileage may and probably does vary, of course.

Dmitry pointed out an alternate consideration, Well, if I could clearly predict ELF linker behaviour with several different modules each having global variables/functions with the same names I would not bother too much, but I couldn't. Could you? To which Paul agreed, No, but if that was the reason I had for wanting to hide symbols, I would probably say so up front, because its a pretty good one :)

Dmitry then expressed some frustration with not being able to have that level of control, Also, I personally feel a bit not comfortable when someone (for any reason) is looking into a binary and sees names of internal interfaces not appropriate for external learn/use. I find it ugly that I can't fully control such basic things in the ELF world.

Mike thought another way to work around the problem was to explicitly show the symbols as internal only. While it wouldn't accomplish what Dan was originally trying to do at least it would serve as a warning mechanism for anyone poking around:

IMHO it's cleaner to do what the glibc team do and simply mark them as private using symbol versioning. Yes, they still appear in the symtab, but when you read it at least you see:

    __libc_foobar@@GLIBC_PRIVATE

and there can be no doubt whatsoever that it's internal. That also lets you mark things as internal and still use them from other DSOs.

ELF linker behaviour when there are multiple symbols with the same name is defined by the way, it's just a dumb behaviour :) Basically they all get linked to the first symbol that was loaded unless you have things like -Bsymbolic set (though that only works if the symbol being linked is in the same object).

The correct solution to making ELF not suck is to implement support for the DT_1_GROUP flag so we can get grouped fixed, like on Solaris. This is closer to the Windows model that people intuitively expect. It should also help with some of the pathological slowness that prompted initiatives like prelink.

Dmitry thought that solution was just as bad and only made things more confusing, I still think that ELF is inherently sick, and inventing new (intrusive) workarounds makes it even worse. Mike disagreed:

Maybe. But let's face it, the alternatives aren't much better. The only real competition is PE (Windows) which is worse than ELF in many ways, and Mach-O (MacOS/X) which is so appallingly primitive it just blows my mind that a shipping OS actually uses it.

Given the alternatives, we could have a lot worse than ELF!

Dmitry wanted to know exactly what was wrong with PE when ELF seemingly had so many deficiencies, Can you list at least some things you think are bad in PE in comparison with ELF? Another downside in ELF in addition to mentioned already is missing a resource section, which makes our life implementing Wine much harder and forces all application developers to invent their own formats to store icon/bitmap/dialog info/strings/etc. information.

So Mike thought of some of the things he liked:

Sure - ELF has decent versioning, which PE lacks and has caused massive pain due to conflicts etc. While you can rename DLLs on Windows it's not a part of the system so not many people do, and when they do there's no pattern to it.

The ELF file format is fairly simple compared to PE where you have layers of wrappers and cruft due to its long history.

ELF is well specified for multiple CPU architectures and standard between several different operating systems. I can get the spec in many formats. The PE spec in contrast comes in the form of a Word document, and I have to agree to a bigass EULA to read it:

http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

ELF is pretty easy to extend with new sections and flags.

PE resource files are IMHO a rather dubious feature. Yes it makes implementing Wine harder, but any time I see a filing-system-in-a-file I get suspicious. Sticking files inside the EXE or DLL just makes them harder to get at, harder to replace or edit: we already have a working filing system so reinventing that in a limited fashion seems silly. I think keeping code and data physically separate is a much better plan.

In the rare case that you need to store binaries inside ELF it's still possible: see GTK+ which does this for its stock artwork.

Finally, the linking semantics of ELF are as much a blessing as a curse. While it can cause chaos sometimes, it also lets us do things like the pthread override trick. Any LD_PRELOAD hack also uses this "feature", though it could be done more cleanly with an extension.

Modern (ie GNU) ELF also has various interesting features like symbol versioning, prelinking etc ...

The discussion continued on at the time this was written.


Building With Intel's Compiler 05/11/2004 Archive
Build Process

Steven Edwards tried compiling with Intel's compiler rather than GCC:

I was able to build WINE with the Intel Compiler for Linux. Intel allows free usage for non-comercial works so I figured I would check and see if changing compilers would yield better performance. According to Intel's site it is supposed to give a 15 to 30% speed boost in applications. I was able to compile WINE with only about a 10 line patch. Somehow some of the inline asm is already getting defined by icc. I am having some problems running graphical applications and maybe it is related to the code I had to disable. If anyone else wants to test I figure this might be a good tool to have if you are porting a Winelib application and want a large performance speed up.

I was able to get all of WINE to build but was not able to run any graphical applications due to the crash shown in the attached crash.log. I was however able to run quite a few console applications including regresion tests which showed failures quite a few failures.

If anyone is interested in building WINE with the Intel Compiler I will be happy to test a bit but I don't have a lot of time to put into it. Attached is my hack.diff and the log from trying to run regedit.

  1. Download ICC and run icsvar.sh
  2. apply the following patch
  3. Configure wine with ./configure CC=icc
  4. recompile WINE.

Mike Hearn wasn't surprised about the crash, No surprise it crashes, this code is setting something in the TEB which you commented out. Wine won't get anywhere when missing such critical functions: being able to set and access the TEB is vital for nearly all Wine functions. For Wine on ICC to be useful that must be fixed.

Mike also cautioned against expecting any speedups using icc. Some of the runtime bottlenecks are due to the Wine architecture rather than any specific areas gcc fails to optimize.


Staying Within 2GB Memory Boundary 05/04/2004 Archive
Memory Management

Bill Medland tracked down a problem that appeared to be related to Windows expecting a particular memory layout:

I have this program that I am trying to run under RedHat Enterprise Linux 3.

I have installed the 20031118 rh8 rpm. (Big saga as to why that one)

When I first run the program after a reboot (of the linux) the program fails When I run it again it works, and it continues to work until the next reboot.

The BIG difference between the two runs is which memory it uses. Can anyone tell me why it is using such different areas of memory?

When it fails it is basically using memory up at approx 0xb6000000 When it is working it is using memory down at 0x40000000

    -kernel32.__wine_register_dll_16(40b35374) ret=40a8cc12
    +kernel32.__wine_register_dll_16(b6b8f3c4) ret=b6ae6c12

Alexandre sent a short response that identified it as a known problem, There's a hack in CrossOver to work around that problem, but it's not a proper fix. The right way is to reserve the high memory area so that things don't get mapped there.

Mike Hearn wondered if that affected some other work that's been going on, What address range is that? At the moment I think Mike's preloader patch only reserves the PE load area, DOS area and shared heap area. Is there another we need? Alexandre replied with where the problem was, Basically everything above 2Gb. But there's no need to do that in the preloader, it can be done in the normal init code.


Marlett Font Replacement 04/30/2004 Archive
Graphics

Fonts are always a bit of a touchy issue. Many fonts are copyrighted and can be considered proprietary. Rob Shearman asked if anyone would be interested in having some font development done:

I have several people interested in creating a replacement for the Marlett symbol font included in Windows (used for drawing of window decorations and some widgets). Would this be useful for inclusion in Wine? If so, would just the TTF file be ok, or would you need whatever propietary formatted file they will probably be working with (I think it will be some Adobe product)?

David Hammerton wrote back to say it already existed:

There already is one.

We (TransGaming) created one called TGMarlett which we released under a BSD license. It should be floating around somewhere, and at least Huw (from CodeWeavers) has it.

Perhaps I should send our version in for inclusion in winehq CVS?

I have both the .ttf and the .sfd - the native file format for the program I used.

Huw replied to mention that he did have it, Indeed, and very good it is too - nice work! The only question is where are we going to put it? Ideas welcome.

Mike Hearn suggested putting it in dlls/gdi32. As of yet it hasn't been committed.


All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.