World Wine News

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

• Configuration settings moved to the registry.
• Graphical Wine configuration tool is now enabled.
• More MSI and OLE improvements.
• Reorganisation of the DirectDraw directory.
• Initial support for webcams.
• Lots of bug fixes.

CodeWeavers, Inc., the leading Windows-to-Linux software developer, today announced a major expansion of its software porting capabilities to include support for Windows-to-Macintosh application porting. The new capabilities, made possible by Apple's eventual move to Intel x86 chips, promises to significantly reduce the time and cost of developing Mac versions of Windows software, opening new possibilities for mid-tier Windows software companies.

"Apple's decision to shift to Intel chips is good news for many Windows developers who, for reasons of time and/or expense, have never created Mac versions of their key applications," said Jeremy White, CEO of CodeWeavers. "CodeWeavers can give these developers a low-cost and near-instant path to market through the use of CrossOver technology."

Removed files:

documentation/samples: config

Log message:

Get rid of the sample configuration file.

Patch: http://cvs.winehq.org/patch.py?id=18504

I just wanted to let folks know that we've officially announced that we'll be providing CrossOver Office for the Mac. We will likely be using/supporting/aiding + abetting the Darwine project/process as our way of achieving that.

This is pretty exciting for us; we've done a lot of Mac work through the years, and have some Mac bigots on staff. We'd just never seen a way to make a Mac version of CrossOver make business sense...until now.

We're still figuring out just how we want to attack this, and so on (and waiting for our dev kit to arrive <g>) Right now, we're trying to encourage ISVs to partner with us; the more interest we can generate now, the more energy we can put into this prior to the official Intel/Mac launch.

But I figured I'd drop a note to let folks know, and to say thank you for all the work you've put in. I hope we can pitch in and help out!

With the current CVS version, the unixfs shell namespace extension is now registered by default at the desktop. So if you do a 'regsvr32 shell32' you will see the unix filesystem in the file dialogs. It's probably still quite buggy though. It would be cool if we could get the biggest problems sorted out before the next release. So if you have an application, which doesn't work due to unixfs, please report to wine-devel.

If you don't want to use unixfs, because you don't like it or because it totally breaks your setup, you can delete the following registry-key and you should be back to the old behaviour:

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\Namespace\ {9D20AAE8-0625-44B0-9CA7-71889C2254D9}

This will also help you to figure out if a problem is due to unixfs. If you do 'regsvr32 shell32' again, the key will be re-created.

If anybody is looking for a small project, I've got just the thing for you!

hh.exe and hhctrl.ocx are two components of the Microsoft HTML help engine. hh.exe is a small wrapper around hhctrl.ocx, which is the HTML help viewer.

hhctrl.ocx embeds IE and feeds it HTML documents decoded from .chm files with itss.dll (the Infotech storage system). Implementing hhctrl.ocx would make an excellent test case for IE embedding that Jacek is working on, and for itss.dll.

So most of the components are already in place (or will be soon) to make HTML help work... any takers to fill in the dots?

The reward is, like most of Wine code, to say "I made that work" :)

Let me know if you're interested.

I think it will be great to have it done. I'd like to point out one thing for the way to implement it: the most important is to have it working with native shdocvw.dll and mshtml.dll. It won't work with builtin in their current state, but it will be fixed soon and I believe it can be in CVS even if it doesn't work without these dlls. While implementing then we shouldn't pay too much attention to get it working with Mozilla ActiveX Control - it will never work perfectly and I hope to get rid of its dependency soon. Of course you may get it working, but, as my tests show, it's far from compatible with MS. Also, we need to use itss.dll, which is impossible with Mozilla ActiveX (I'm not sure if Mozilla has support for chm protocol, but even if so it's worse to use it).

About implementing hh.exe... it seems to be pretty easy. Attached is (not tested) implementation:-)

Another related idea is, as I have spoken with Mike on irc, to use html help in winecfg. It looks like a nice way to have a complex and integrated help. This would mean that we need to implement the chm compiler. To do so we may use chmlib: http://66.93.236.84/~jedwin/projects/chmlib/ that Mike used in itss to decompress chm.

As a conclusion: it would be really good to have this working in Wine. It uses most of IE's related API (I didn't mention URLMoniker here, which also needs some work) and getting it to work out of box will be a great test for Wine.

#include <windows.h>

typedef int WINAPI DOWINMAIN(HMODULE hMod, LPSTR cmdline);

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR cmdline, int cmdshow)
{

HMODULE hModule;
DOWINMAIN *doWinMain;

hModule = LoadLibrary("hhctrl.ocx");
doWinMain = GetProcAddress(hModule, "doWinMain");

return doWinMain(hInst, cmdline);

As I'm sure you all know, Google has now accepted 6 students to work on projects for Wine.

Alexandre, Dan Kegel, Lionel Ulmer, Dimi O'Paun and I worked on the Wine committee that reviewed the applications, and we were all impressed by the depth and quality of the applications, and we're excited to have 6 fresh new workers on Wine.

We're working right now on connecting these 6 students with their mentors; we hope to announce more details once we've made those connections.

To be honest, we're running a bit behind here; I think Google jumped into this without being as prepared as you might otherwise hope, and there have been challenges in figuring this all out. (We're still largely clueless about the responsibilities of mentors from Google's perspective, for example).

So, thanks to everyone that submitted a proposal.

I'd particularly like to thank those people that submitted a great proposal and were not accepted.

To be quite honest, we were disappointed that Google only selected 6 applicants; we put forward 18 different applications that we thought were all worthy of funding.

So, thanks again to everyone, and most of all, thanks to Google for spurring Wine development!

I just wanted to let you know that the new Google Earth application is working quite well under Wine. There is only an issue with the menus disappearing under the pictures but it is very promising.

I wrote a message to google to let them know about it (they might want to add that their application can work on other OSes than Windows).

Links:

• http://earth.google.com
• http://appdb.winehq.org/appview.php?appId=2292
• http://slashdot.org/articles/05/06/28/1733229.shtml?tid=217&tid=95&tid=159

It's me again. The latest WoW patch (1.5.1) broke stuff again, and now I'm unable to click on anything outside of menu items in game. The issue seems to be related to camera angle, as I am able to click on items/people when I have my camera positioned just right. It's basically unplayable at the moment though.

Anyway, I'd appreciate it if one of the OpenGL/D3D guys (it's most likely something that would be easily fixed by one of you) could take a look at it if they have some free time.

Well cedega seems to have the same problem (google) and they fixed it using specific memory layout for WoW (mmap begins at 0x10000000) Seems more a WoW bug than wine/cedega bug :)

It looks like a game bug related to virtual memory to me, and it's possible to do a couple of configuration changes in Cedega to provoke different virtual memory layouts, which apparently makes a difference. Exactly why, I don't know. Since workarounds exist for now, and it's not a simple bug to track down, and it's possible Blizzard may simply fix the bug themselves in a future update, this is not important enough that I've been told to drop my current tasks and do an in-depth investigation of this instead.

To me it looks like an overoptimized geometry problem. As long there is only sky and no terrain or building behind the objects, you can klick them. This is mostly the case, when you look up. Just like users reported.

I just wrote a lousy mmap wrapper which sets start to 0x10000000 . This works for me with wine 20050601 and the latest from cvs.

Also, there is an interesting workaround for the clicking problem as well on the Gentoo forums. Seems to be working for the majority of people (including myself). It seems to reaffirm that the problem is indeed the memory layout.

http://forums.gentoo.org/viewtopic-p-2509340.html#2509340

More interesting: http://forums.gentoo.org/viewtopic-t-246098-postdays-0-postorder-asc-start-200.html?sid=3afd22e0a94b246c583b2d2bd043712f

Gamers are playing with lib. wrapper ... just like me! But I came to the same conclusion:

static void initialize() __attribute__ ((constructor));

static void initialize() {
printf("Hurra !!!\n");
// _mmap = dlsym(RTLD_NEXT, "mmap");
}

Finally it is the printf which does the magic and not the wrapped mmap! The above example also worked for me. Can we still solve this problem with logic?