World Wine News

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

• Initial implementation of a true Richedit control.
• Shell extension for browsing Unix directories.
• More MSI work.
• PBuffer support in OpenGL.
• Window painting regressions should be fixed.
• Lots of bug fixes.

I used an audio cable with a mini-jack at each end to connect my Yaesu FRG-7700 receiver to the Line In port on my SoundBlaster Live! card. Then I found a ham band with some CW activity and started CwGet. I was amazed when I saw the CW being decoded real time, as I heard it, but there it was. Yes, CwGet would work on Linux, thanks to Wine.

Could you please tell me if you consider the unixfs shell namespace extension, which I've sent to wine-patches last week, a sensible way to go in order to access the unix filesystem from winecfg? I know that there is room for improvements, and I'm working on it. But if you think it is not the right thing to do, I will stop working on it and save some time for other stuff.

I think the extension itself is perfectly reasonable. The thing I'm not sure about is creating a brand new dll for it, adding Wine-specific dlls should be avoided if possible.

Would you consider it more reasonable to implement unixfs as a part of shell32? We would not have to alter the APIs exported by shell32 to do this. Wine's shell32 would just recognize more CLSID's than the original one.

Somebody needs to write a patch to migrate the configuration branch across to a new one, disable the pre-existing config file (renaming it?) and then use it.

At least, I think that is what is needed. Alexandre may have other ideas.

So, there are 4 obvious problems with our current drive management code:

1. We add links to the floppy drive. We should blacklist it, as it causes a big delay in the file open dialogs as we poll the drive which sits there spinning its motors naval-gazing. How many people still use floppy disks in 2005 anyway? I'm hoping the answer is "virtually none"
   An alternative solution would be to poll the drives in a non-blocking manner, though I'm not sure this would work for apps which do their own file dialogs like Office.
2. We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom
3. The artwork in the file pickers sucks ass. Sorry, it does. It's ugly as sin and for some reason the Desktop icon is an arrow, not a desk.
   This doesn't matter when you only have C: and Z: drives. It does matter when you have 2 CD drives, 2 Windows drives, a floppy and a few other drives.
   Fixing this is theoretically easy but for some reason it never gets done. If any of you non-coders are reading this and want to contribute then this would be a good way to start. Good artwork already exists, it's just a case of finding it, converting it to the right format and getting the new bitmaps into CVS.
4. We don't detect new drives as they are mounted into the system, eg if I start a Windows program and then realize that my work is actually on a USB key, if I plug that key in Nautilus and GTK+ (and probably KDE) apps will detect it and see it, but we won't. Not even if I restart the app! This is bad.
   Fixing this is not, in theory, super hard. When HAL detects a new hotplug device it modifies the fstab file and mounts. If we watch the /etc/fstab file for changes and rerun drive detection therefore we can make this all magically work. Problems are:
   • Who triggers the resync? The wineserver is the obvious choice as there is only 1 per wineprefix but we'd need to integrate FAM support for that
   • How do we broadcast to apps that the drive definitions changed so we can update the UI, flush any caches etc?

Ah, so this means that the directory change notification mechanism applies to volume notification as well? Or is it still a somewhat separate API?

Nevermind, at least you just told us that this API exists, so we should try to get the hal/hotplug/fam stuff integrated with this API.

I think the umpnpmgr.exe in windows takes care of all of this for the applications and explorer using the APIs you listed. I don't know how we would really fit in the Windows design here.

http://msdn.microsoft.com/library/en-us/kmarch/pnpcomp.wmf

Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark.

What's interesting, however, is that Steam works perfectly in CrossOver 4.1 - since I don't think Steam is supported, this is not due to a special hack, and the failure in Steam therefore represents a serious regression in Wine.

This, quite simply, will be a really cool app to get working again. Plus, we'll need it to try out Half Life 2 once you awesome Direct3D boys finish up your work :)

So, where do we go about this? The installer demonstrating the error can be downloaded easily from http://www.steampowered.com/

I downloaded steam, ran it with wine(cvs from 3/6/2005) and it WORKED without doing anything special.

Wine just told me that it has to download the mozilla active X control and crashed because of a missing dll(MSVCR70.dll). I'll get this dll and do some more testing.

Steam runs indeed nice with wine. I don't know why it works all of a sudden, but it works ;-)

These are the problems I found:

• Microsoft Internet explorer needed: I didn't get the builtin shdocvw working. The automatic download of the Mozilla active X control didn't work. I downloaded it manually and installed it but it still didn't work Can someone give me a hint how I make the builtin shdocvw work?
• No keyboard without Desktop mode. It seems like wine doesn't pass the Steam Windows to the Window Manager(KDE / KWM in my case). To make the keyboard working I have to use the Desktop mode. Managed = N doesn't work.
• I can't move the Window in Managed mode. With Desktop and Managed = N it works.
• Steam sometimes causes crashes if I cancel it with Strg+C.

Ivan found that on Windows .exe's can export functions, just like DLLs. He needs this for his work on ntoskrnl.exe.

To support this, we need a bit of an interface change to winebuild. I've put together a simple patch to see if you are OK with such a change. If so, I'll finish it, and modify winegcc accordingly.

So, thing will change as follows:

OLD: winebuild --dll=mystuff.spec
NEW: winebuild --dll -E mystuff.spec

OLD: winebuild --def=mystuff.spec
NEW: winebuild --def -E mystuff.spec

OLD: winebuild --exe=myprog.exe
NEW: winebuild --exe -F myprog.exe

to build an .exe with arbitrary exports, we would do:

winebuild --exe -F myprog.exe -E mystuff.spec

I notice there has been interest from developers wanting to run valgrind with wine. I have been doing this successfully with the attached patch applied. Note that there are some false positives from the thread start routines caused by a bug in valgrind. Apparently this is fixed in the latest cvs, but I have not tried it. I find the --tool=memcheck option the most useful, which can be used for finding the source of memory corruption.

I now understand the purpose of SERVER_START_REQ et al, but now I'm in server/protocol.def and I'm trying to add a protocol definition for load_key. load_key is implemented in server/registry.c, but is not in server/protocol.def so, if I'm correct, I can't make a call to load_key from ntdll yet. I am trying to add load_key to protocol.def, but I don't know the semantics of this file. Is there any documentation available for this topic, or does anyone have any information that could be added to the docs?

I guess it's not so much that I can't understand it when I read through the code and read the comments, but that we should document this so whoever needs to work with the server next won't have to take time to read through the necessary files to understand it. There's also a big possibility that I'm not understanding this correctly. Some things that would be nice to see in documentation are:

• server protocol design decisions (ie why we use do...while(0) loops in SERVER_START_REQ as explained by Mike H)
• api like wine_server_add_data, wine_server_call
• adding a server function to protocol.def
• protocol.def: @REQ, @REPLY, @END
• protocol.def: VARARG...when to use it, syntax etc
• why we use DECL_HANDLER and what should go in it
• why there is a function and then its counterpart DECL_HANDLER

The biggest question I have right now (because I understand minimally the points listed) is why api in protocol.def have different parameters than their reg counterparts and even ntdll api.

What I'm getting at is that these things are an integral part of wine, and there isn't any documentation for it. If someone would be willing to write documentation for this topic, then wine and its developers would definitely benefit.