World Wine News

Attached is a major update to the XEmbed systray patches that I sent earlier this week. After a few days of tweaking and testing the code, I think I have found the solution to the race conditions that have plagued previous versions of this work. While this is a major step forward, I still need some assistance with some issues with these patches:

1. I need people to test this on any window manager they can to see if the results that I get can be reproduced, especially on older GNOME versions (I tested on GNOME 2.14). I was able to run a small test app that I made over 120 times, and each time it docked perfectly, no zombie systray adapter windows like before.
2. In order to accomplish this reliability, I've had to ensure that systray windows are *never* mapped. According to the XEmbed specs and my testing, we can't map systray windows ourselves--the tray has to do it, or we get the race conditions. However, my current solution isn't entirely correct. The problem is that systray windows aren't mapped under *any* circumstances. While this allows the docking to work properly, the icons don't show up at all if there's no tray to dock with. I've been contemplating some solutions to the problem but I'm not sure what the correct way to go about this is. My current idea is to add a function to winex11.drv that checks to see if we have a systray window. If the function finds one, then we don't map tray windows. If it doesn't return one, then we map them. Would adding a function like that to x11drv be a good idea?

Attached is the second update of the XEmbed systray patches. Changes in this version:

1. On the advice of Juan Lang, I only acquire the wine tsx11 lock when actually making X calls, and not while initializing data.
2. Added the ability to detect if we have an XEmbed systray so that we can selectively determine if we need to map tray windows or not. Under the last version, the icons would not be mapped under any circumstances whatsoever. While it would work if we had an XEmbed-compliant tray to dock with, the icon wouldn't show up at all if there wasn't one. Things work both ways now. But, if you look at the patches, you'll notice that the logic in the if statements is a little ugly. Is there a cleaner way to do this?

Attached is the fourth update to my XEmbed system tray patches. For this version I made some fairly major changes:

1. Did away with the low-level checks for systrays, and instead had the systray icon windows created off-screen so they aren't mapped, as per Alexandre's suggestion.
2. systray_dock_window will put the icon windows back on the screen if there isn't an XEmbed tray to dock with.
3. Eliminated the WS_EX_TRAYWINDOW style hack, and moved the call to systray_dock_window to X11DRV_CreateWindow. I used the window class name to see if it was a tray window being created or not.
4. Consolidated all patches into one, as the individual patches weren't really individual changes. (Thanks to Mike McCormack for this advice.)

the latest run (with report) on the Coverity site seems to be from July 21st. It appears that the main page is updated though (not for the lines of code but for the errors fixed).

Does anybody know more about the why? I've tried to contact Coverity for the last month and my last email (where I've requested a read-receipt, shame on me) was deleted without being read.

What comes in my mind, that they offered there Service to Wine to use it as an Advertisement like: "Coverity detected >800 Errors in Wine and all where fixed in less than 2 Month"

We started to fix them, but the fixing-Rate went down near to Zero very fast. To remember, the Announcement from Ben Chelf was on 07. April 2006:

http://www.winehq.org/pipermail/wine-devel/2006-April/046354.html

The first Day, we fixed 31 Defects

( http://www.winehq.org/pipermail/wine-devel/2006-April/046433.html )

We marked 74 Defects as RESOLVED, 78 Entries are Verified and 344 are still Uninspected or Pending. (Overview at http://scan.coverity.com )

You must also remember, that every Run is visible with annotated source. This cost them a lot of GB HD-Space, that is always online for us.

IMHO, they did not see enough benefit for there investigation in Wine. Simple: We do not pay, they stopped.

Got an email from a Coverity guy.

They've hired someone to work on the Scan project full time. Apparently they have some backlog but Wine is by no means not covered anymore. Things should settle down soon and we can look forward to some nice reports again.

This documentation is copied straight from MSDN, that's not acceptable.

Since many people don't seem to understand this, from now on I'm going to reject all patches that add documentation, unless the submitter explicitly mentions that he didn't look at MSDN to write it. I'm sorry to penalize people who do the right thing, but I can't continue to waste time checking every single doc patch against MSDN.

State management in D3D... is currently kind of a mess.

• some states are applied immediately (via Set* calls)
• some are applied at draw time (like shaders, textures, transforms, ...)
• some are recorded into a stateblock structure, and applied when the app says apply().
• the GL code is all over the place, tightly coupled to the d3d code.

There's a number of projects going on at the moment, from what I understand:

• Roderick is working on making wined3d -> wgl
• Stefan D. has expressed concern about multithreaded d3d (where the D3D device state is shared, but not necessarily the GL one - or can GL contexts be shared between multiple threads?)
• I'm trying to get FBOs to work, where the FBO needs to be bound once both the render and stencil target have been assigned (that's 2 calls from the app in any order) - i.e I need those states to be applied in a delayed fashion, before draw
• Henri Verbeet wants multiple render target support added to that (meaning the FBO needs to be bound once all render targets are assigned in addition to the depth/stencil one).

All of the above have a common theme - better state management is needed, with more encapsulation, and better separation between D3D and GL. So, let's come up with a plan, and try to implement it. How about we redesign the stateblock object like this:

• remove deltas. I.E. if a SetLightEnable() command is sent, fetch the light, enable it, then save the light back - store only state, and no deltas. This should make the recording stateblock (updateStateBlock) the same as the initial device stateblock, which stores states
• provide a uniform internal interface for accessing states inside the stateblock - like:
  SetState(stateblock, ID_XYZ, (void*) state_data);
GetState(stateblock, ID_XYZ, (void**) state_data);
CaptureState(stateblock, ID_XYZ);
ApplyState(stateblock, ID_XYZ);
  ID_XYZ could be an individual state, or a "trigger" keyword, which will refer to a whole group of states. Those would be private functions in addition to the standard interface.
• provide a fn pointer table inside the stateblock [ which can be directed to OGL or WGL or AGL ], which, for each ID_XYZ, maps a get and set function using the same interface
• move all device.c GL code into those functions
• now all device.c Get* and Set* requests will do is:
  • error checking
  • recording into updateStateBlock
  • or writing to stateBlock (which may be applied later, at our discretion)
• apply() would just loop through all the IDs and call the corresponding function pointer if the states are marked dirty (we'll keep the 'dirty' field)
• capture() would do the same in the get* direction.
• new object can be instantiated per device, or per device per thread to address multithreading. It could have an associated glContext, and can be locked as necessary.
• it would use ideas from the d3d9 test framework for stateblock, except of course more competently written, and cleaner :)

The key idea that I care about seems to be to move GL code from device.c into the data structure object, and figure out a way to apply a set of delayed states at draw time. We don't have to replace everything right now - we could have 2 coexisting data structures and slowly move things from one to the other, but I wanted to see if people agree with that idea.

I don't like the way things are done right now - Set* functions can do one of two things - record to a stateblock, or apply state. Then the stateblock calls the Set* functions itself when it's applied - seems very ugly to me [ and also in certain places we're forced to disable recording to get a state applied immediately using a Set* function ].

Ok, so the main idea is to separate the applying of GL state from the tracking of D3D state. Looks like a good idea. What I would like to add to that is something BBrox mentioned on IRC a while back... grouping related states together and marking that group dirty / clean. That way we would get a tree like structure for the states, which would make checking what states changed and need to be applied somewhat faster. While it would be possible to add that afterwards, I think it would be easier to just take it into account when designing the new stateblock structure.

I think we should do the change quicky, even if we risk regressions. I do not think that we should add comments stating "if you add new gl stuff add it to <new file.c>". I think none of you wants that. What we can do for sure is to move render states, sampler states, matriced and bound shaders separately, which we should do to keep patches small.

Let me illustrate my idea:

• Move out the GL calls from Set*State. Set*State writes the values to the update stateblock and updates the refcounts (maybe we should kick internal refcounting from wined3d altogether)
• Keep the stateblock and update stateblock structure as they are now. I think for recording stateblocks the idea is quite good

I just uploaded a simple wine ASIO driver to http://bugs.winehq.org/show_bug.cgi?id=2161 for testing and feedback.

Please look at it and give me feedback. Playback works. Recording is untested due to lack of software. Full duplex doesn't work for me but I'm not sure if it's a software issue or a problem with my hardware and OS setup.

The software is a long way from being ready for submission so any feedback or help would be appreciated.

Are you sure that those limited recipients were sufficient? (I don't think anyone here ever does a lot of ASIO app stuff)

Might want to include http://linuxaudio.org/en/contact.html and http://ladspavst.linuxaudio.org/ people, too...

Thanks for all your work on audio!!

I'm afraid submission (or integration in the Wine tree) will be problematic. The ASIO interface is copyrighted, and you need to sign an agreement to Steinberg for using the API. IANAL, but including derivative work of a copyrighted API will not be possible. But, this doesn't prevent you from creating a standalone audio driver.

As of right now, I'd estimate that over half of our users are using Wine from a terminal window to launch their applications, largely because their window manager doesn't put Wine's Start Menu entries into their applications menu.

Wine's been making .desktop files for some time, however it seems like they're being put in the wrong place. There's supposedly a proper, standard place to put them (or there should be), and perhaps a hack can be put in at the package-maintainer level, but in any case this is a pretty big usability issue at the moment.

I'm pretty confident that someone here knows the answer to how things should be, and I'm also pretty sure it's a fairly simple change to make. Either way, we need to have a discussion about it - what's the next step here?

Jeremy and I were at the meeting where the Portland project got started, and we've been following it off and on with great interest. I just posted a question about how xdg-desktop-menu would work compared to what Wine already does, let's see what they say.

I started up xfce today, and was surprised to see all the menu items for all the windows apps I'd installed over the last few months show up. Sadly, this was wrong, since I'd done "rm -rf .wine" many times. It'd be nice if the .desktop files were stored inside ~/.wine so they could go away when that directory did.

No need for any of that, just put 1 file in ~/.local/share/applications/ and it should work fine. Alternatively you could put them somewhere inside ~/.wine and set $XDG_CONFIG_HOME (put the files in ~/.wine/menu/share/applications and set $XDG_CONFIG_HOME to ~/.wine/menu/). I'm pretty sure you could add a line to some dot file (.xinitrc?) and have this set on login.

I was investigating the menu problems and now I'm back so I could try to fix it. The problem is with the support for the new freedesktop.org standard. In it the /usr/share/applications and ~/.local/share/applications contains a flat list of applications while the menu structure is controlled by XML files. Thus adding items to ~/.local/share/applications is harder than adding them to legacy directories as the XML files would need to be updated.

There is however a possibility to add an XML file that includes a "legacy" directory where the menu structure is given by the directory structure. That would be the easiest way to quickly fix this problem.

I've attached a simple menu file that could be created by wineprefixcreate. It should be copied to ~/.config/menus/applications-merged/ and ~/.config/menus/kde-applications-merged/ directories and the path in it should be fixed - "username" changed to the actual user name. After copying the files from ~/.kde/share/applnk/Wine to ~/.wine/menu the items should be visible in the menu (I think it's a good idea to keep the .desktop files in ~/.wine). If anyone would test it I would be glad to know how it works.

There is a small problem that KDE scans the ~/.kde/applnk directory (unlike Gnome that scans only the global directories /usr/share/applnk and /etc/X11/applnk and that's why the menu is not visible) and after this change will display the menu items twice. This can be fixed by creating the ".desktop" in legacy directories with "OnlyShowIn=Old;".

If this sounds good I can send patches to winecreateprefix and wineshelllink with these fixes.

When creating the wineprefix, create a directory for the menu and a configuration file that enables this menu in the freedesktop.org menu structure. As suggested on wine-devel the menu directory is a subdirectory of ~/.wine, so if the user deletes it, all menu items created there will be automatically removed.

When the $WINEPREFIX/menu directory is present a desktop item is created there. The desktop item in legacy directories are created with "ShowOnlyIn=Old;" so there will be no duplication of icons. If $WINEPREFIX/menu is not present (i.e. a wineprefix created with an old wineprefixcreate) the files are created as they used to be (without "ShowOnlyIn=Old;").

I think the DEVELOPERS-HINTS contents should really be moved to the Wiki, it would be a lot easier to keep up to date there. Does anybody feel like doing that?

I also put a link in https://wiki.winehq.org/HackingTips under Tips & Tricks.

Here's what I have: https://wiki.winehq.org/Developers-Hints

The codebase in "dlls/winspool.drv/info.c" is getting really large and the actual code path is: winspool.drv -> CUPS/LPR (with help from GDI).

A possible place to split the code is at the Printmonitor level. The Printmonitor for the standard "local ports" in Windows (COM*:, LPT*:, FILE:, Windows-File) was in localmon.dll and merged into localspl.dll with w2k.

On IRC, Alexandre already agreed to handle Wine-specific ports ( CUPS:*, LPR:*, pipe to a unix_app, /unix-File ) together with the standard Windows ports in a single Printmonitor: "localspl.dll"

The requirement that updating the system printers in Wine must work automatically needs some attention when the related code (LoadSystemPrinters) moves from winspool.drv to localspl.dll:

1. Changing the code path to "winspool.drv -> localspl.dll -> CUPS/LPR" and using the same memory functions for localspl.dll as done in Windows (the memory related exports from spoolss.dll) gives us a circular dependency when we load and call winspool.drv from spoolss.dll. For this reason, using HeapAlloc(GetProcessHeap(), ...) and Friends from kernel32.dll is a possible way to go for "localspl.dll".
2. To let printing in Wine work as similarly as possible as printing is done in Windows (but without RPC and without the spooler service), we can change the code path to "winspool.drv -> spoolss.dll -> localspl.dll -> CUPS/LPR" and use the exports from spoolss.dll.

Since we need the memory exports from spoolss.dll also for other Printmonitors and many names/prototypes of the other spoolss.dll exports are equal to the functions in winspool.drv, I prefer solution 2.

(Wine as an EMF-Printing-Backend for samba is only possible with 2)

As a Reference, what windows does, is:

winspool.drv --(RPC)-->
spoolsv.exe(Spooler Service) --(WINAPI)-->
spoolss.dll ->
localspl.dll ->
Driver for LPT*: / COM*:

Any comments please.

I'm trying to track down an issue that occurred between 0.9.19 and 0.9.20, and I am using git bisect to track the issue. In the process of trying to identify the cause of the issue, I would like to be able to get the code up till a certain patch, and then apply patches one by one as well.

I have not been able to find out how to do this, despite several web searches and man pages. Can anyone give me any pointers to this please?

What I do is to follow along with things on the shortlog:

http://source.winehq.org/git/?p=wine.git;a=shortlog

Let's say you want to move your current branch to my recent patch "riched20: Rewrite of scrolling and some redrawing code." - you'd click the link "commit" to the right of it. In the page that you'll be taken to, you'll see a line like this:

commit abecd9e393925e008449a80ec14682790b29042c

you can then do a:

git reset --hard abecd9e393925e008449a80ec14682790b29042c

and your git will be moved to the point in time right after that commit. If you then want to manually apply a patch, click "commitdiff" to the right of its entry in the shortlog, followed by "plain" on the top - this will take you to a plaintext diff of the patch, which you could save to a file and apply with the patch command. ("patch -p1 < thepatch.diff" usually works well for me)

There's easier ways to do the second bit.

1. Use git cherry-pick
   git branch master-20060913
git reset --hard abecd9e393925e00
   examine the log for commits
   git log master-20060913..abecd9e39392
   pull in commits
   git cherry -r 112810a480aaee4d6d8
git cherry -r aaca30cf039c227e
   etc
2. Use git format-patch to get all the patches in the tree before resetting:
   put them all in one file named mb
   git format-patch --stdout abecd9e39392 > mb
   
   or create multiple files
   git format-patch abecd9e393925e008
   
   Then reset (remember to have a clean tree!)
   git reset --hard abecd9e393925e
   
   Then edit "mb" and "git am" the patches you want:
   git am mb

You don't need the full SHA1 ID... just enough to make it unique in the tree.

My one win app that makes me a devotee of WINE is TablEdit (demo at www.tabledit.com/download/tabled32.exe ) has a custom font , tef260.ttf, that has failed to display since somewhere after ver 9.6. The program installs the font into c:\windows\font, but cannot display it within the program, instead displaying for the most part, empty squares.

I tried putting/removing tef260.ttf into /usr/local/share/wine/fonts, /usr/local/share/fonts, and the wine windows/fonts directories in all permutations. The only way I got it to display was to remove ALL fonts from these three directories and install tef260.ttf into an X11 font directory along with other win ttf fonts. This forces WINE to build a cachedmetrics file like it used to, and the font is displayed properly in the program.

Hope this is a clue for some developer, as I merely lurk here, looking for clues about wine behavior. I can't do a regression back to ver 9.6 (the version I was using that last worked) because my upgrades to freetype cause it to complain of missing functions.

current (pertinent ? ) specs

• libfreetype.so.6.3.7, built from source
• libfontconfig.so.1.0.4, built from source
• fontforge 20060715, built from source
• WINE 0.9.20, built from source
• kernel 2.6.17.11
• Slack current (10.2, with upgrades from "current" tree)