Google's support for Wine in 2007
As you might know, I work for Google, and part of my
day job is to help improve Wine. Here's a little report
about what we've been up to.
Google uses Wine primarily as the basis for the Linux
port of our photo management software, Picasa.
In fact, the Linux version is exactly the Windows build
of Picasa, bundled with a lightly patched version of Wine.
Most of the work in that port was to improve Wine so it
could handle Picasa, and that work is still going on.
Codeweavers did the initial port, and Googlers
Lei Zhang, Nigel Liang, and Michael Moss are
improving Wine further for Picasa 2.7.
Beyond Picasa, a few of us (Lei Zhang, Alex Balut, and I)
have been fixing random Wine bugs in our 20% time.
I've also been doing regular Valgrind runs over the Wine test suite,
pestering developers who accidentally check in code that Valgrind
doesn't like. Hats off to the Valgrind team for a great tool, and
to the (non-Google) folks who work on Valgrind/Wine compatibility
(Eric Pouech, Tom Hughes, and John Reiser, among others).
Google also sponsored some work by Codeweavers to improve
support for Photoshop ('cause so many people want it) and
for Dragon Naturally Speaking ('cause even Linux users get RSI).
While not yet perfect, those apps are a lot more usable now
as a result. In particular, Photoshop CS and CS2 are quite usable
indeed. (See http://wiki.winehq.org/AdobePhotoshop for
details.)
I also had the pleasure of hosting eight students as
Google interns working on Wine throughout the year.
Here are their names, and roughly what they worked on:
Dan Hipschman: widl
Evan Stade: gdiplus, Powerpoint Viewer
James Hawkins: msi
Jennifer Lai: win16 conformance tests
Juan Lang: crypt32, iTunes
Matt Jones: mono testing
Mikolaj Zalewski: Photoshop, Limux
Roy Shea: svchost, BITS
So, you're wondering, what exactly does that all boil down to?
I tallied all our accepted patches recently; the list is now up
(along with the exact Wine source we use for Picasa) at
http://code.google.com/opensource/wine.html
I was pleasantly surprised at the size of the list.
Separately, Google also sponsored nine Summer of Code
students this year. Just to name two who remain active even
after the end of summer:
Alex Sørnes, who improved Wine's Wordpad, and
Maarten Lankhorst, who solved tons of sound problems.
(And oh, how nice it is to not have to change sound settings anymore!)
All that may sound like a lot, and perhaps it is, but it pales
compared to the work put in on Wine by the rest of the Wine developers.
Thanks, everybody! I'm really looking forward to Wine 1.0
(which, according to Alexandre, is planned for sometime in 2008).
Dan Kegel
Software Engineer
Google
Re: [RFC] winecfg enhancements
On Feb 13, 2008 2:29 PM, Reece Dunn <[EMAIL PROTECTED]> wrote: > And the other proposed improvements? Those were mentioned and can be > commented on. I've skimmed the discussion and while its important to me it bears much too verbose. Can we just get some mockup images of that the proposed changes would look like? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
ddraw / wined3d fighting over the resolution!
Hi Stefan/Devs. The funny old game "Insane" has a resolution bug when it exits. I am not sure exactly how to fix this. 1) It call SetDisplayMode() - switches from 1280 x 1024 -> 640 x 480. OK. 2) It creates a 3D surface which starts the SwapChain - swapchain saves current resolution. 3) Exit. It calls RestoreDisplayMode() - switches back to 1280 x 1024. OK. 4) SwapChain is destroyed. Switches "back" to 640 x 480 ! BAD! I presume the code guesses that the caller does this in another sequence (and it does work fine in other sequences). Why does the SwapChain-destroy function play around with the resolution at all. Is that really necessary? I think it should not do it if the caller is ddraw at least. How do i fix this? Thanks, /pedro
Weird failure in kernel32 volume test
Hi all, The latest update of trying to be the second person for which all tests succeed. I sent a bunch of patches that make some tests pass. At the moment I have 3 failures on a clean wineprefix, with no icons on my desktop, and with wine in native window mode on kde 3.5.x: user32: 'msg' test fails. The famous 'win' test passes. kernel32: I get a very weird bug on the 'volume' test. It only occurs when I run my mini script for running the tests. I have absolutely no idea why I get ERROR_FILE_NOT_FOUND on FindFirstVolumeA on the first time I run the whole testsuite, and not successive runs. Anyone has experienced the same, or have an idea what is going on? msi: multi-sz failure in msi install, I did a todo_wine on it so it doesn't stop the build. It seems to be a recent failure though because I know that it didn't bomb out on install a few days ago. Anyone else has some tests that consistently fail on make test? Cheers, Maarten. tests Description: Binary data
Re: gecko download not robust?
Austin English wrote: > On Feb 9, 2008 5:17 PM, marco <[EMAIL PROTECTED]> wrote: > >>> Hmm. gecko download hung for me once. I saw >>> fixme:urlmon:ProtocolStream_Read Read failed: 800c0008 >>> in the log, which makes me wonder if our download code >>> doesn't handle transient network errors well. >>> >>> Time to get rid of the download, and just bundle gecko outright, I say... >>> >> I make the mandriva rpms for wine. >> This would make the rpms 30% bigger. >> And you would download the same gecko binary over and over again with >> every new version. >> >> But if that is not a problem than it can be easily done. >> >> >> > > Why not have package maintainers package gecko like most do > development files. So you could have for example on ubuntu: > $ sudo apt-get install wine wine-dev wine-gecko > > Where wine-gecko wouldn't have to be upgraded very often. > > -Austin > > I looked into it. And there are some options. I can make a separate package of gecko that I can make it a dependencie of wine. Problem is people have to know where to find it or the get stuck. I can also make the package and make it not a dependencie on wine but the the people don't know it exist. And I can just put it in the wine package. I think this is the best option in this case. Its the easiest option because people only have to download en install one package. marco
Re: [RFC] winecfg enhancements
Reece Dunn googlemail.com> writes: > > Hi, > > I am looking at how we can make winecfg more useful. I have already > supplied patches to allow importing a ubuntu human theme to work :). > So I am now looking at how to build on that. > [...] > > - Reece > > I think this could probably do with some consideration http://bugs.winehq.org/show_bug.cgi?id=6233 , it describes how the Applications tab does not belong among the other tabs because it should be higher up in the hierarchy of things.
Re: [RFC] winecfg enhancements
On 13/02/2008, Juan Lang <[EMAIL PROTECTED]> wrote: > > Q: Should we provide a --simple mode for winecfg that has the work > > flow that Ubuntu is planning? Not specifying --simple would bring up > > the standard winecfg dialog. > > If you don't explain what that is, don't expect to many responses. At > least, I don't know what it is. >From https://wiki.ubuntu.com/BetterIntegratedWineSpec: System->Preferences->Windows Applications Here we reimplement only the Wine configuration options we need. * (Pulldown menu): "Default Windows version to emulate when launching Windows applications" o Windows 2000 is currently the upstream default, which works for most apps * (unchecked by default) Automatically launch applications upon inserting a disc o This is where the user can disable autorun by default if he enabled it with the checkbox in the autorun prompt * (radio button default): Allow full screen applications to change the resolution * (radio button alternate): Contain full screen applications in a window when smaller than the desktop o These are the two main use cases of Wine's various Window managing options. The latter might not be fully functional in time for Hardy. * (button) Advanced o Launches winecfg, or a similarly functional GTK application. We can consider removing this when Wine's defaults get good enough, however likely not by Hardy. To reimplement the configuration we need in GTK requires some upstream changes (see [WWW] ConsoleConfiguration on Wine's wiki. And the other proposed improvements? Those were mentioned and can be commented on. - Reece
Almost done...
Hi all, Right now I got down to only the user32 msg test failing (minus the todo's). I solved the user32 win test with a very high-tech solution: Remove all icons from my desktop, which prevents the stupid file description popup from failing the user32 win test. The other way would be to run it in a wine desktop which would also prevent this (I got no failures on runtest, except the todo's). The msg tests are more difficult. For some reason I accidentally passed them once, when I had the debug scrolling on. But after that there were always failures on my pc. Is there any way to sync those so that it is less prone to timing issues? Cheers, Maarten.
Re: d3d: Add a slight delay before testing the ddraw and d3d9 visual tests
OK. I still think he should put a FIXME remark in the test-case, and document why Sleep() is needed. Someone might fix the driver someday. The only reason i yelled "alert!", is that i have seen so much bad code which has come to a state where the are Sleep(143) here and Sleep(1332) there, where nobody can remember why they are there and what the Sleep count represents (most of the time no-one ever knew! :-)). In the mean time, the real bugs just getter harder to find, as they are covered by all the messy Sleeps(). I see allot of this kind of yap in telecom embedded software (mobile phones etc.). In this case Maarten probably knows what he is doing (he usually does). But thanks for the follow up! And now i will go to Sleep(). Thanks, /p On Wed, 2008-02-13 at 11:28 +0100, Stefan Dösinger wrote: > Am Mittwoch, 13. Februar 2008 03:11:24 schrieb Peter Dons Tychsen: > > Eh, this does not seem like a proper way to get a unit test to pass. > > > > Sleep()... that leads to the dark side! :-) > I talked to Maarten on IRC about this. The problem seems to be that his > monitor takes ages to mode switch, but ChangeDisplaySettings returns before > this modeswitch is done. Also the opengl driver attempts to draw before the > setup is ready, which fails and causes the test failures. > > So it sounds like a driver bug which will only affect the tests(since games > draw repeatedly and do not care if the first few frames do not render > properly)
Re: [PATCH] include: add ISampleGrabber interface
On Feb 13, 2008 3:03 PM, Lei Zhang <[EMAIL PROTECTED]> wrote: > Hi, > > This patch adds the ISampleGrabber interface, also needed by IMediaDet. > Bah, let me try again. Just realized I forgot to pass -n to git format-patch as well.
Re: Fixing the last failing tests
Dmitry wrote: >> An example is IsWindowUnicode. It always returns TRUE on XP, > >That's not true. The test you submitted that checks this, http://www.winehq.org/pipermail/wine-patches/2005-July/018839.html must have passed once on Windows, but it seems to be failing now; see e.g. http://test.winehq.org/data/200802131000/xp_rs-winxp-sp2/user32:win.txt which is full of lines like win.c:3656: Test failed: IsWindowUnicode expected to return FALSE Do you have a Windows system where that test passes currently? - Dan
Re: gecko download not robust?
On Feb 10, 2008 10:11 PM, Jacek Caban <[EMAIL PROTECTED]> wrote: > Compiling the package is quite tricky. I've compiled it on Windows XP > using MSVC. There is no other way ATM, so I think that my Gecko package > should be included as is in Linux packages. Where is the source package? Is it just from the normal firefox source tree with certain configuration options? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: gecko download not robust?
You could make it a suggested package, a la wine-dev. Including is also a possibility, but keep in mind that's several megabytes that don't change with each release (or that often) that have to be redownloaded each time. I've got high bandwith, so doesn't bother me, but a lot of people don't... -Austin On Feb 13, 2008 3:24 PM, marco <[EMAIL PROTECTED]> wrote: > > > Austin English wrote: > > On Feb 9, 2008 5:17 PM, marco <[EMAIL PROTECTED]> wrote: > > > >>> Hmm. gecko download hung for me once. I saw > >>> fixme:urlmon:ProtocolStream_Read Read failed: 800c0008 > >>> in the log, which makes me wonder if our download code > >>> doesn't handle transient network errors well. > >>> > >>> Time to get rid of the download, and just bundle gecko outright, I say... > >>> > >> I make the mandriva rpms for wine. > >> This would make the rpms 30% bigger. > >> And you would download the same gecko binary over and over again with > >> every new version. > >> > >> But if that is not a problem than it can be easily done. > >> > >> > >> > > > > Why not have package maintainers package gecko like most do > > development files. So you could have for example on ubuntu: > > $ sudo apt-get install wine wine-dev wine-gecko > > > > Where wine-gecko wouldn't have to be upgraded very often. > > > > -Austin > > > > > > I looked into it. > And there are some options. > > I can make a separate package of gecko that I can make it a > dependencie of wine. > Problem is people have to know where to find it or the get stuck. > > I can also make the package and make it not a dependencie on wine but > the the people don't know it exist. > > And I can just put it in the wine package. > > I think this is the best option in this case. Its the easiest option > because people only have to download en install one package. > > marco > > > > > > > > > > > > >
Re: msxml3: Implement IXMLDOMDocument IDispatch interface
Hi,
Was there anything wrong with this patch?
Dont commit this patch if nothing is wrong. I will submit a series of
patches, that will include these changes.
Best Regards
Alistair Leslie-Hughes
"Alistair Leslie-Hughes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> Fixes bug http://bugs.winehq.org/show_bug.cgi?id=11257
>
> Changelog:
> msxml3: Implement IXMLDOMDocument IDispatch interface
>
> Best Regards
> Alistair Leslie-Hughes
>
> From 7cc5228684ed6d9aaace829cc1b8ebb43e5f4325 Mon Sep 17 00:00:00 2001
> From: Alistair Leslie-Hughes <[EMAIL PROTECTED]>
> Date: Fri, 25 Jan 2008 22:34:36 +1100
> Subject: [PATCH] Implement IXMLDOMDocument IDispatch interface
> To: wine-patches <[EMAIL PROTECTED]>
>
> ---
> dlls/msxml3/domdoc.c| 53 +--
> dlls/msxml3/main.c | 58
> +++
> dlls/msxml3/msxml_private.h |8 ++
> 3 files changed, 111 insertions(+), 8 deletions(-)
>
> diff --git a/dlls/msxml3/domdoc.c b/dlls/msxml3/domdoc.c
> index 06388c8..9d6b94b 100644
> --- a/dlls/msxml3/domdoc.c
> +++ b/dlls/msxml3/domdoc.c
> @@ -416,16 +416,29 @@ static ULONG WINAPI domdoc_Release(
>
> static HRESULT WINAPI domdoc_GetTypeInfoCount( IXMLDOMDocument2 *iface,
> UINT* pctinfo )
> {
> -FIXME("\n");
> -return E_NOTIMPL;
> +domdoc *This = impl_from_IXMLDOMDocument2( iface );
> +
> +TRACE("(%p)->(%p)\n", This, pctinfo);
> +
> +*pctinfo = 1;
> +
> +return S_OK;
> }
>
> static HRESULT WINAPI domdoc_GetTypeInfo(
> IXMLDOMDocument2 *iface,
> UINT iTInfo, LCID lcid, ITypeInfo** ppTInfo )
> {
> -FIXME("\n");
> -return E_NOTIMPL;
> +domdoc *This = impl_from_IXMLDOMDocument2( iface );
> +HRESULT hr;
> +
> +TRACE("(%p)->(%u %u %p)\n", This, iTInfo, lcid, ppTInfo);
> +
> +hr = get_typeinfo(IXMLDOMDocument2_tid, ppTInfo);
> +if(SUCCEEDED(hr))
> +ITypeInfo_AddRef(*ppTInfo);
> +
> +return hr;
> }
>
> static HRESULT WINAPI domdoc_GetIDsOfNames(
> @@ -436,8 +449,21 @@ static HRESULT WINAPI domdoc_GetIDsOfNames(
> LCID lcid,
> DISPID* rgDispId)
> {
> -FIXME("\n");
> -return E_NOTIMPL;
> +domdoc *This = impl_from_IXMLDOMDocument2( iface );
> +ITypeInfo *typeinfo;
> +HRESULT hr;
> +
> +TRACE("(%p)->(%s %p %u %u %p)\n", This, debugstr_guid(riid),
> rgszNames, cNames,
> + lcid, rgDispId);
> +
> +if(!rgszNames || cNames == 0 || !rgDispId)
> +return E_INVALIDARG;
> +
> +hr = get_typeinfo(IXMLDOMDocument2_tid, &typeinfo);
> +if(SUCCEEDED(hr))
> +hr = ITypeInfo_GetIDsOfNames(typeinfo, rgszNames, cNames,
> rgDispId);
> +
> +return hr;
> }
>
>
> @@ -452,8 +478,19 @@ static HRESULT WINAPI domdoc_Invoke(
> EXCEPINFO* pExcepInfo,
> UINT* puArgErr)
> {
> -FIXME("\n");
> -return E_NOTIMPL;
> +domdoc *This = impl_from_IXMLDOMDocument2( iface );
> +ITypeInfo *typeinfo;
> +HRESULT hr;
> +
> +TRACE("(%p)->(%d %s %d %d %p %p %p %p)\n", This, dispIdMember,
> debugstr_guid(riid),
> + lcid, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr);
> +
> +hr = get_typeinfo(IXMLDOMDocument2_tid, &typeinfo);
> +if(SUCCEEDED(hr))
> +hr = ITypeInfo_Invoke(typeinfo, &(This->lpVtbl), dispIdMember,
> wFlags, pDispParams,
> +pVarResult, pExcepInfo, puArgErr);
> +
> +return hr;
> }
>
>
> diff --git a/dlls/msxml3/main.c b/dlls/msxml3/main.c
> index 62bf2b5..41afbe6 100644
> --- a/dlls/msxml3/main.c
> +++ b/dlls/msxml3/main.c
> @@ -21,6 +21,8 @@
>
> #include "config.h"
>
> +#define COBJMACROS
> +
> #include
> #include "windef.h"
> #include "winbase.h"
> @@ -34,6 +36,61 @@
>
> WINE_DEFAULT_DEBUG_CHANNEL(msxml);
>
> +
> +static ITypeLib *typelib;
> +static ITypeInfo *typeinfos[LAST_tid];
> +
> +static REFIID tid_ids[] = {
> +&IID_IXMLDOMDocument2
> +};
> +
> +HRESULT get_typeinfo(enum tid_t tid, ITypeInfo **typeinfo)
> +{
> +HRESULT hres;
> +
> +if(!typelib) {
> +ITypeLib *tl;
> +
> +hres = LoadRegTypeLib(&LIBID_MSXML2, 3, 0, LOCALE_SYSTEM_DEFAULT,
> &tl);
> +if(FAILED(hres)) {
> +ERR("LoadRegTypeLib failed: %08x\n", hres);
> +return hres;
> +}
> +
> +if(InterlockedCompareExchangePointer((void**)&typelib, tl, NULL))
> +ITypeLib_Release(tl);
> +}
> +
> +if(!typeinfos[tid]) {
> +ITypeInfo *typeinfo;
> +
> +hres = ITypeLib_GetTypeInfoOfGuid(typelib, tid_ids[tid],
> &typeinfo);
> +if(FAILED(hres)) {
> +ERR("GetTypeInfoOfGuid failed: %08x\n", hres);
> +return hres;
> +}
> +
> +if(InterlockedCompareExchangePointer((void**)(typeinfos+tid),
> typeinfo, NULL))
> +ITypeInfo_Release(typeinfo);
> +}
> +
> +*typeinfo = typeinfos[tid];
> +return S_OK;
> +}
> +
> +static void pro
Re: [PATCH] Environment variable to specify X11 window for desktop
On Feb 12, 2008 5:13 PM, Timothy Lee <[EMAIL PROTECTED]> wrote: > Dear all, > > The attached patch allows the WINE desktop to be embedded within an > existing X11 window, and is similar to the windowed mode in WINE. > > I've tested this feature using MS PowerPoint Viewer 2007, so that a > fullscreen slideshow can be fitted inside any X11 window. > > Regards, > Timothy Lee > > > > > Patches should be sent to [EMAIL PROTECTED] Please do not use C++ style comments. See: http://www.winehq.org/site/docs/winedev-guide/style-notes
Re: user32: correct the caption bar and it's buttons' sizes
On Mittwoch 13 Februar 2008, Divan Burger wrote:
>
What is the problem without the patch?
is the caption bar drawn too high 1 pixel?
I ask because i have a patch that restores the 1 pixel
high line between the caption bar and the client area
(and at the same time decreases the height of the caption bar)
see it attached
for the NC_DrawXXXButton functions:
you also need to update hittest calculation
else the wrong buttons are activated.
For example when you press the mouse down on the left side of the close
button, but maximize gets activated
> case SM_CYCAPTION:
> if (!spi_loaded[SPI_NONCLIENTMETRICS_IDX]) load_nonclient_metrics();
>- return nonclient_metrics.iCaptionHeight + 1;
>+ return nonclient_metrics.iCaptionHeight;
this breaks a test in sysparams.c:2416
ok_gsm( SM_CYCAPTION, ncm.iCaptionHeight+1);
and 5 other tests
Greetings Peter
From 62066e37c5a01155eff03b01af76010a521cd114 Mon Sep 17 00:00:00 2001
From: Peter Oberndorfer <[EMAIL PROTECTED]>
Date: Wed, 9 Jan 2008 17:22:39 +0100
Subject: [PATCH] fix caption bar being too high by 1 pixel
To: [EMAIL PROTECTED]
this problem was introduced in commit 567b6facab5623857b399c80c96db97d3344c8ac
Add support for drawing gradient captions.
---
dlls/user32/nonclient.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/user32/nonclient.c b/dlls/user32/nonclient.c
index 503f7c1..1cdcbf6 100644
--- a/dlls/user32/nonclient.c
+++ b/dlls/user32/nonclient.c
@@ -917,7 +917,7 @@ static void NC_DrawCaption( HDC hdc, RECT *rect, HWND hwnd, DWORD style,
r.bottom--;
SystemParametersInfoW (SPI_GETGRADIENTCAPTIONS, 0, &gradient, 0);
-NC_DrawCaptionBar (hdc, rect, style, active, gradient);
+NC_DrawCaptionBar (hdc, &r, style, active, gradient);
if ((style & WS_SYSMENU) && !(exStyle & WS_EX_TOOLWINDOW)) {
if (NC_DrawSysButton (hwnd, hdc, FALSE))
--
1.5.4
missed systray patches
Hello, Is there anything wrong with the serie of patches? systray[0/4]: systray improvements [try 2] http://www.winehq.org/pipermail/wine-patches/2008-February/049772.html -- Kirill
Re: [RFC] winecfg enhancements
> Q: Should we provide a --simple mode for winecfg that has the work > flow that Ubuntu is planning? Not specifying --simple would bring up > the standard winecfg dialog. If you don't explain what that is, don't expect to many responses. At least, I don't know what it is. --Juan
Re: Fixing the last failing tests
On Tuesday 12 February 2008, James Hawkins wrote: > On Feb 12, 2008 8:16 PM, Peter Dons Tychsen <[EMAIL PROTECTED]> wrote: > > Hello M. > > > > What is wrong with detecting the version, and branching the test code > > accordingly? Other tests do that IIRC. I think that is a better > > solution, if the version selector in winecfg is still going to be > > meaningful (registry). > > The only time the tests should check for the windows version is if we > know an app does the same thing, which is hardly ever. Well, if we have an old app from win9x times, it will expect windows 95 behavior, without checking for windows version of course. So if Wine is set to impersonate win95, then it should behave like on win95 and the tests should check windows (here: wine) version to select a proper test. Such a version-specific test should pass on win95 and wine with win95 personality chosen. It should also pass on other versions, by choosing a different path (and possibly doing nothing if it doesn't apply to that windows version). So, for example, methinks all applicable unicode tests should be disabled on the early win95 versions which had no such support (if so bolt-on unicode is detected). Wouldn't that make sense? Cheers, Kuba
Re: How is the testsuite built for windows
Hi Maarten, On Wednesday 13 February 2008 00:51:11 Maarten Lankhorst wrote: > Who managed to compile all wine tests for windows, and how is it done? Once a day, quisquiliae head-node (attempt to) build winetest.exe (and also the other Wine .exe and .dll files). Some details about this are available here: http://quisquiliae.physics.gla.ac.uk/cross/ The cron script builds winetest.exe and checks whether it has changed since last time. If so, registers the new build. (This is a slight over-simplification.) There are some notes on how to build a Windows PE cross-compiler available from here: http://www.astro.gla.ac.uk/~paulm/Cross/ There is also a script that automates building the cross-compiler. Wine is written exclusively in C, so by default, only the C frontend is built. The script should support building other language frontends, but this hasn't been tested much. This page also includes a set of patches for MinGW's Win32API package to allow MinGW to compile winetest.exe. This patch-set is almost exclusively the work of others: Stefan Leichter featuring most prominently (many thanks!) Hans Leidekker maintains a set of RPMs that should provide identical coverage of Win32API as Stefan, Hans, myself and others share the set of patches. Hans' RPMs are available from: http://mirzam.it.vu.nl/mingw/ Cheers, Paul.
[RFC] winecfg enhancements
Hi, I am looking at how we can make winecfg more useful. I have already supplied patches to allow importing a ubuntu human theme to work :). So I am now looking at how to build on that. On the Desktop Integration tab, I am planning on adding the following improvements: * Split the Appearance section into Theme and Appearance. The rationale behind this is while the two are linked, they are also distinct. It will make it possible to simplify "Install theme..." to just "Install...", and support enhancements below. * Pre-populate the Theme list with themes in WINDOWS/Resources/Themes and with other *.theme files added by the user. The rationale behind this is that it simplifies the workflow for the average usage (e.g. install a theme, then select it). * Rename "Install theme..." to "Add...". The rationale is that we are not installing a theme, but setting it as the theme being used. Having the theme appear in the Themes list in the future further supports this name change and workflow. * Rename "(No Theme)" to "Wine Default". The rationale behind this is that it isn't true that there is no theme installed (in the sense that a theme can be a set of colours and metrics). * Provide an "Export..." button to the Themes section. The rationale behind this is that it makes it easier to create, modify and preview themes being created. Therefore, you could create a Ubuntu Human or Oxygen theme from winecfg. * Make the theme importer read the themes [Theme]/DisplayName property. The rationale behind this is to make the display name user friendly. * Add --import-theme command line support to winecfg. The rationale behind this is to support loading a theme via a script (e.g. post-install configuration), without resorting to the winecfg GUI. * Make the shell folders a drop down list. The rationale behind this is that it is unclear what "link to" applies to. An alternative is to make the listview have the showselalways flag, so it is clearer what folder "link to" is relating to. Q: Should we provide a --simple mode for winecfg that has the work flow that Ubuntu is planning? Not specifying --simple would bring up the standard winecfg dialog. - Reece
Re: [PATCH #1] wininet: Added beginning support for HTTP cache files.
Jacek Caban wrote:
> +/* FIXME: Better check, when we have to create the cache file */
> +if(bSuccess && (lpwhr->hdr.dwFlags & INTERNET_FLAG_NEED_FILE)) {
> +WCHAR url[INTERNET_MAX_URL_LENGTH];
> +WCHAR cacheFileName[MAX_PATH+1];
> +BOOL b;
> +
> +b = HTTP_GetRequestURL(lpwhr, url);
> +if(!b) {
> +WARN("Could not get URL\n");
> +goto lend;
> +}
> +
> +b = CreateUrlCacheEntryW(url, lpwhr->dwContentLength > 0 ?
> lpwhr->dwContentLength : 0, NULL, cacheFileName, 0);
> +if(b) {
> +lpwhr->lpszCacheFile = WININET_strdupW(cacheFileName);
> +lpwhr->hCacheFile = CreateFileW(lpwhr->lpszCacheFile,
> GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE,
> + NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
> +if(lpwhr->hCacheFile == INVALID_HANDLE_VALUE) {
> +WARN("Could not create file: %u\n", GetLastError());
> +lpwhr->hCacheFile = NULL;
> +}
> +}else {
> +WARN("Could not create cache entry: %08x\n", GetLastError());
> +}
> +}
>
>
It may be beyond the scope of your patch, but you're creating the cache
file without committing the entry elsewhere so that it can be found at a
later time. According to MSDN, this should be done in HTTP_FinishedReading.
--
Rob Shearman
Re: d3d: Add a slight delay before testing the ddraw and d3d9 visual tests
Am Mittwoch, 13. Februar 2008 03:11:24 schrieb Peter Dons Tychsen: > Eh, this does not seem like a proper way to get a unit test to pass. > > Sleep()... that leads to the dark side! :-) I talked to Maarten on IRC about this. The problem seems to be that his monitor takes ages to mode switch, but ChangeDisplaySettings returns before this modeswitch is done. Also the opengl driver attempts to draw before the setup is ready, which fails and causes the test failures. So it sounds like a driver bug which will only affect the tests(since games draw repeatedly and do not care if the first few frames do not render properly)
Re: d3d: Add a slight delay before testing the ddraw and d3d9 visual tests
On Wednesday 13 February 2008 03:11:24 Peter Dons Tychsen wrote: > The string "This makes the tests pass on my pc" isn't very good either. > What system? Given that the default mode for the tests in the last years has been "Needs to pass on Alexandre's system", I don't think it's that bad. ;) Cheeers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patch: create a WinHttpDetectAutoProxyConfigUrl function
"Joshua Hudson" <[EMAIL PROTECTED]> wrote: > --- wine-0.9.54/dlls/winhttp/winhttp.spec 2008-02-11 20:54:39.0 > -0800 > +++ wine-0.9.54/dlls/winhttp/winhttp.spec.bak 2008-02-11 20:52:39.0 > -0800 The patch is wrapped. > @@ -8,7 +8,7 @@ > @ stub WinHttpConnect > @ stub WinHttpCrackUrl > @ stub WinHttpCreateUrl > -@ stdcall WinHttpDetectAutoProxyConfigUrl(long ptr) > +@ stub WinHttpDetectAutoProxyConfigUrl And this part seems to be reverted. -- Dmitry.
Re: Add a slight delay before testing the ddraw and d3d9 visual tests
"Maarten Lankhorst" <[EMAIL PROTECTED]> wrote: > This makes the tests pass on my pc. Perhaps there is something less hacky way like GdiFlush() which is more appropriate for this. -- Dmitry.
Re: How is the testsuite built for windows
Maarten Lankhorst wrote: > Hi all, > > I'm trying to get the tests to run in windows, but I'm not sure how to build > them. Any attempt to do mingw cross compiling fails badly. > > Who managed to compile all wine tests for windows, and how is it done? > > Cheers, > Maarten. > > > > > > Hi Maarten, I'm doing this all the time. Before I sent a patch I usually have it cross compiled and tested on different flavors of Windows. I'm running Fedora 8 and I'm using the RPM's provided via http://mirzam.it.vu.nl/mingw/packages. Mingw has to be very-up-to-date to be able to cross compile all tests. With the latest RPM's I can still cross compile all tests. Or are you talking about the full winetest.exe? -- Cheers, Paul.
[PATCH] Environment variable to specify X11 window for desktop
Dear all,
The attached patch allows the WINE desktop to be embedded within an
existing X11 window, and is similar to the windowed mode in WINE.
I've tested this feature using MS PowerPoint Viewer 2007, so that a
fullscreen slideshow can be fitted inside any X11 window.
Regards,
Timothy Lee
diff -Naur -wbBE wine-0.9.54-fe/dlls/winex11.drv/x11drv_main.c wine-0.9.54-fe.rootwin/dlls/winex11.drv/x11drv_main.c
--- wine-0.9.54-fe/dlls/winex11.drv/x11drv_main.c 2008-01-26 00:05:38.0 +0800
+++ wine-0.9.54-fe.rootwin/dlls/winex11.drv/x11drv_main.c 2008-02-12 23:20:33.0 +0800
@@ -447,6 +447,8 @@
Display *display;
XVisualInfo *desktop_vi = NULL;
const char *env;
+int new_root = -1;
+XWindowAttributes attr;
setup_options();
@@ -525,6 +527,22 @@
if (TRACE_ON(synchronous)) XSynchronize( display, True );
+// Handle WINEROOTWIN environment variable
+if (getenv( "WINEROOTWIN" ))
+{
+const char* root_str = getenv( "WINEROOTWIN" );
+if (0 == strncmp( root_str, "0x", 2 ))
+sscanf( root_str + 2, "%x", &new_root );
+else
+sscanf( root_str, "%d", &new_root );
+if ((new_root >= 0)
+&& XGetWindowAttributes( display, (Window)new_root, &attr ))
+root_window = (Window)new_root;
+}
+
+if (root_window != DefaultRootWindow( display ))
+xinerama_init( attr.width, attr.height );
+else
xinerama_init( WidthOfScreen(screen), HeightOfScreen(screen) );
X11DRV_Settings_Init();
diff -Naur -wbBE wine-0.9.54-fe/loader/wine.man.in wine-0.9.54-fe.rootwin/loader/wine.man.in
--- wine-0.9.54-fe/loader/wine.man.in 2008-01-26 00:05:38.0 +0800
+++ wine-0.9.54-fe.rootwin/loader/wine.man.in 2008-02-12 23:52:34.0 +0800
@@ -207,6 +207,14 @@
.I DISPLAY
Specifies the X11 display to use.
.TP
+.I WINEROOTWIN
+If set,
+.B
+wine
+will embed its desktop under an existing X11 window with the ID specified by
+this variable. This allows fullscreen Windows applications to be embedded
+inside X11 applications.
+.TP
OSS sound driver configuration variables
.TP
.I AUDIODEV
How is the testsuite built for windows
Hi all, I'm trying to get the tests to run in windows, but I'm not sure how to build them. Any attempt to do mingw cross compiling fails badly. Who managed to compile all wine tests for windows, and how is it done? Cheers, Maarten.
