LM: So, first of all, give us a little background on the Installer Challenge.

Yeah, and basically the challenge is that we're trying to take Wine to that next level, we have for the last several years, really focused on a fairly small footprint of applications, making those work well and being glad and hoping that other things would work as well, collateral damage, as I like to call it.

Now what we're doing is taking the next step, and that is taking the first step towards taking Wine to the promised land, where we want it to be, which is where it runs everything and the first step is before you can try an application, you've got to be able to install it.

What we're doing right now, is we've spent a great deal of energy over the last year, sort of a lot of unsexy, dirty, nasty, grinding work that has the very sexy, exciting work that has the result that we believe many applications will install, and we believe that those that won't install will be very easy to get install.

We're very hopeful that with this, if we can get some community participation and community help that we can go from right now, where you have a 50-50 chance having an app install, maybe a bit less than that, to you're pretty sure that your app will install.

I've sent a patch that makes MSHTML use Gecko to render HTML. Unfortunately, it uses Windows Gecko, not Linux one. Alexandre wrote me that it's impossible to get perfect support for XEmbed container, so, although my implementation was enough for Gecko, it can't go to CVS and I should use Windows one. So, as of now, support for the Linux version went into trash and I've sent this patch. Well, I don't give up with Linux version, I have another idea, but that's not for the nearest future. One plus is that the Windows version is much simpler...

Now it's time to write about this patch. For now it can use Gecko installed with Mozilla Suite or Mozilla ActiveX Control - it could use any Gecko-based product, but we have to be able to search for it (every Gecko-based product has its own registry settings for Gecko path). I'm planning to add Firefox support, but it doesn't work yet and I have to find why. If you think there should be support for any other application, please let me know. As our shdocvw still uses Mozilla ActiveX Control, I think it should be preferred (it's the first one on the search list and it's smallest). In future, when we'll implement shdocvw on top on MSHTML and get rid of Mozilla ActiveX Control dependency, I think it will be better to have a package like wine-gecko with an installer, downloaded automatically when needed (well, not automatically in MS sense, user will be informed about it ;-) ). We need a very limited version of Gecko, so it will be just small package.

What does this patch change? You may see IE working on Gecko engine! Not much of its functionality is implemented yet, but a HTML document is displayed. Soon there will be more! To see how it works for your program, probably you will have to set shdocvw to native (and usually urlmon, maybe wininet) and mshtml as builtin.

Changelog:

Detect force-feedback-capable linux event device joysticks and return DIDC_FORCEFEEDBACK when queried for capabilities.

This patch is exactly like try 2 except that this one actually works.

Changes from try 1:

1. Configure check has been changed from a custom compile check to an AC_CHECK_MEMBERS. I presume this is what Alexandre meant by "please use the existing macros for checking structure fields;" if not, please clarify.
2. An additional runtime check has been added to catch the case that it is compiled on a kernel with full FF support but run on one without it. In this case, the number of simultaneous effects query will fail, and the joystick will not be reported as FF. The #ifdef is still necessary to catch the opposite case.
3. Primary FF detection code has been moved from GetCapabilities to Acquire. Since the tests are getting more complex it's best to only run them once, and store the results for use elsewhere.

To recap, this patch basically adds three things:

1. Configure checks for the availability of a new enough linux/input.h to support force feedback. This pretty much means any kernel 2.6 or kernel 2.4.x with the ff patchset found at http://sourceforge.net/projects/libff/. Some of the structures were changed without changing the version define, so this check is necessary; although these structures are not yet used they will be in later patches, and it's best not to report that the joystick is FF unless it can actually handle FF effects.
2. The linuxinput dinput joystick driver tries to open the device in read/write mode, and falls back to read-only (with no ff support) if it fails.
3. The device is queried for the EV_FF capability bit and ffbits is filled with the specific supported effect types. If that all goes well, DIDC_FORCEFEEDBACK is added to the device flags.

Autoheader and Autoconf will of course need to be run after this patch is applied.

Executive summary: In order for effects to be played, the correct ff_effect structure will need to be present; if you can't play the effects it's better not to detect the joystick as FF, because it's really not.

The structure is not used *yet*, but will be. There was an older version of force feedback code before (in some of the stock 2.4 kernels) which had some of the same features (such as the EV_FF bit), but has incompatible structures, and afaik there were never any force feedback drivers written for it. The newer interface has working iForce (logitech, guillemot, et al) and MS sidewinder drivers written for it, so that's the one I was targetting. You can see them side by side if you have linux/input.h from an unpatched late 2.4 kernel and a 2.6 kernel.

Well, if you mean the Sidewinder Force Feedback 2, that driver seems to be only a stub. I am currently working on a new PID FF driver (which will cover that Sidewinder).

Also I'm planning some kernel internal FF interface updates and probably introducing FF interface to /dev/input/jsX also.

I put the Benchmark results that I posted to wine-devel back in April on the Wiki. http://wiki.winehq.org/BenchMark

I have but its been a day or two. You need two trees and to first build the Wine tools for your host platform and something like the following

cd /usr/src/wine-tools
./configure
make tools

then in another tree

cd /usr/src/wine
./configure --build=armv4 --with-wine-tools=/usr/src/wine-tools

Note there is no support for arm in Wineserver, kernel32 or ntdll so winelib won't run yet. Most everything else should compile as Winelib works on i386, PPC and SPARC. You might be able to get by stubbing the set_thread_context stuff out for simple apps.

somewhat recently I sent some code to wine-patches to add button theming; if you have glanced at it, despite utilizing subclassing, code was duplicated from the button code in user.

In particular, the themed button does its own state management. The reason is that upon state changes, the user32 button control does some repaints internally, ie calling the paint function directly - those can't obviously be hooked by subclassing alone. In early versions I had the themed button painted over after state-changing messages, but that causes visible flickering (since the button is first painted in "classic" style and the themed style is painted above that).

The basic problem - painting that is hard to hook into - will probably also arise on other controls.

There are some ideas and approaches to deal with the problem that came up (and the results from discussion with Kevin):

• Ignore. Have ugly flickering.
• Change the classic controls to use InvalidateRect() instead when internal painting functions are called, so painting messages can be hooked. That would deviate from native behaviour, though (and also occasionally less efficient when the control just paints some change).
• Use some magic message the control sends to itself to do some painting which is then hooked. Makes things more complex, could cause compatibility issues with apps that may not handle this message and is incompatible with native.
• Code duplication - e.g. in the case of buttons, do state management in the themed class as well.
• Static libraries - implement the standard controls in a static library and allow for hooks to override painting (in C++ you'd use virtual methods). Both user32 and comctl32 would link against that lib, and the latter would provide alternative painting functions. Binarily equivalent to code duplication, but not that bad in the source code. For me it looks like a good compromise, though, Kevin noted that "Historically static libs have not gone over very well".

I don't like the current code duplication for theming that much, but I'm a bit unsure what else could be done. Perhaps you have some comments or suggestions, and hopefully there will be some consent of what approach would be best for Wine.