World Wine News

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.

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 are some screenshots available now at

http://www.flexbeta.net/main/articles.php?action=show&id=56

One of the comments on osnews noticed that in the picture

http://www.flexbeta.net/images/david/winbridge_install.gif

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

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

http://www.flexbeta.net/images/david/word2.gif

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.

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.

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.

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?

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.

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.

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.

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.

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

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.

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

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

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.