General script for installing Wine build dependencies
I have in the past written one script per version of Ubuntu to install Wine's build dependencies. Many versions on, that's getting old, and I figure it'd be better to have a single script that handles all common versions on Linux. I've taken a first stab at that, combining my scripts for gutsy and hardy, and adding ibex. The result is at http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh If anyone wants to add support to that script for another OS, please do, and send me the patch. I'd like to see this in the wine tree sometime. It's kind of silly we have to direct people to a big, confusing wiki page (or set of them) to explain how to install the needed packages; let's just have a unified script and be done with it.
Re: D3DXMatrixstack: where to go....
2008/10/31 Jérôme Gardou <[EMAIL PROTECTED]>: > OK, patches will be sent soon. By the way, what if I call multiply on a new > stack, the push, then pop ? Will the top matrix be identity, or the one with > which I multiplied the first time ? > > I guess this calls a testcase ... > I think it should return the result of the multiplication, but tests wouldn't hurt, of course.
RE: [Re] Vertex pipeline replacement
Here is an updated version of the patches. Can you retest the games? (the ones that worked already as well as the broken ones) What are the differences? -> Proper handling of RHW vertices which do not come from a vbo(should fix Star Wars Jedi Knight 1) -> Proper handling of the alpha value in the lighting code(+ a test). Fixes the water in AoM. Those issues had a quite big effect potentially, so more games may be fixed now. arbvp2.tar.bz2 Description: Binary data
Re: D3DXMatrixstack: where to go....
2008/10/31 Jérôme Gardou <[EMAIL PROTECTED]>: > Henri Verbeet a écrit : >> >> Actually, I just cleaned up your patches, and will probably submit the >> first few later today. > > Are you going to finish it or can I send the few missing functions ? > Sure, go ahead. I sent all the patches I wrote for this.
Re: DIrectSound on top of openAL ?
On Friday 31 October 2008 10:11:12 am you wrote: > I think that your dsound->openAL wrapper could be used verbatim in wine, > if wine provides an openal32.dll <-> native openal wrapper (as with > opengl32). I have one of those, too, but it's not yet suitable for inclusion into Wine. In particular, I need to make wrapper functions for even all extension functions, which I haven't done yet (and unlike GL, there's no simple file I can parse to auto-generate such wrapper functions; but also unlike GL, there's not so many). > By the way, did you try your dll with vista, which dropped dsound > hardware acceleration ? I haven't, as I don't have Vista. I also don't think I have any cards that have a native OpenAL hardware driver. A problem with this is that a default OpenAL install will have an OpenAL->DSound wrapper as a fallback.. so if you have a DSound->OpenAL wrapper and a OpenAL->DSound wrapper at the same time, you obviously get some problems. ALchemy got around this by loading ct_oal.dll directly, bypassing the wrapper (at least in the free beta they had). So it can work in Wine, with an OpenAL32 DLL thunk and a bit more work on both sides, but it working in Windows without locking down to specific drivers will be a bit more difficult.
Please, look at my patch, I'm not sure it's correct
Hi,
This patch add a stub implementation of IMarshal interface.
I have no experience at implementing interfaces, so I'm not sure it's
implemented correctly.
Please, look at this patch. I'll be grateful for any remarks.
Thank you.
--
Best wishes,
Vitaly Perov
Russia, Saint-Petersburg. www.etersoft.ru
From b690702315a0365b12ac07664778ed084761ab11 Mon Sep 17 00:00:00 2001
From: Vitaly Perov <[EMAIL PROTECTED]>
Date: Fri, 31 Oct 2008 13:30:38 +0300
Subject: [PATCH] mshtml: Add stub implementation of IMarshal interface
---
dlls/mshtml/Makefile.in |1 +
dlls/mshtml/htmldoc.c|4 +
dlls/mshtml/marshal.c| 139 ++
dlls/mshtml/mshtml_private.h |4 +
4 files changed, 148 insertions(+), 0 deletions(-)
create mode 100644 dlls/mshtml/marshal.c
diff --git a/dlls/mshtml/Makefile.in b/dlls/mshtml/Makefile.in
index 016a75f..cd94c08 100644
--- a/dlls/mshtml/Makefile.in
+++ b/dlls/mshtml/Makefile.in
@@ -46,6 +46,7 @@ C_SRCS = \
install.c \
loadopts.c \
main.c \
+ marshal.c \
navigate.c \
nsembed.c \
nsevents.c \
diff --git a/dlls/mshtml/htmldoc.c b/dlls/mshtml/htmldoc.c
index 7948714..401500a 100644
--- a/dlls/mshtml/htmldoc.c
+++ b/dlls/mshtml/htmldoc.c
@@ -143,6 +143,9 @@ static HRESULT WINAPI HTMLDocument_QueryInterface(IHTMLDocument2 *iface, REFIID
*ppvObject = PERPROPBAG(This);
}else if(dispex_query_interface(&This->dispex, riid, ppvObject)) {
return *ppvObject ? S_OK : E_NOINTERFACE;
+}else if(IsEqualGUID(&IID_IMarshal, riid)) {
+FIXME("(%p)->(IID_IMarshal %p)\n", This, ppvObject);
+*ppvObject = MARSHAL(This);
}
if(*ppvObject) {
@@ -1624,6 +1627,7 @@ static HRESULT alloc_doc(HTMLDocument **ret)
HTMLDocument_Window_Init(doc);
HTMLDocument_Service_Init(doc);
HTMLDocument_Hlink_Init(doc);
+HTMLDocument_Marshal_Init(doc);
ConnectionPointContainer_Init(&doc->cp_container, (IUnknown*)HTMLDOC(doc));
ConnectionPoint_Init(&doc->cp_propnotif, &doc->cp_container, &IID_IPropertyNotifySink);
diff --git a/dlls/mshtml/marshal.c b/dlls/mshtml/marshal.c
new file mode 100644
index 000..dd0863c
--- /dev/null
+++ b/dlls/mshtml/marshal.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright 2008 Vitaly Perov
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+#include
+
+#define COBJMACROS
+
+#include "windef.h"
+#include "winbase.h"
+#include "winuser.h"
+#include "ole2.h"
+
+#include "wine/debug.h"
+#include "wine/unicode.h"
+
+#include "mshtml_private.h"
+
+WINE_DEFAULT_DEBUG_CHANNEL(mshtml);
+
+/**
+ * IMarshal implementation
+ */
+
+#define MARSHAL_THIS(iface) DEFINE_THIS(HTMLDocument, Marshal, iface)
+
+static HRESULT WINAPI Marshal_QueryInterface(IMarshal *iface, REFIID riid, void **ppv)
+{
+HTMLDocument *This = MARSHAL_THIS(iface);
+return IHTMLDocument2_QueryInterface(HTMLDOC(This), riid, ppv);
+}
+
+static ULONG WINAPI Marshal_AddRef(IMarshal *iface)
+{
+HTMLDocument *This = MARSHAL_THIS(iface);
+return IHTMLDocument2_AddRef(HTMLDOC(This));
+}
+
+static ULONG WINAPI Marshal_Release(IMarshal *iface)
+{
+HTMLDocument *This = MARSHAL_THIS(iface);
+return IHTMLDocument2_Release(HTMLDOC(This));
+}
+
+static HRESULT WINAPI Marshal_GetUnmarshalClass(
+IMarshal* This,
+REFIID riid,
+void *pv,
+DWORD dwDestContext,
+void *pvDestContext,
+DWORD mshlflags,
+CLSID *pCid)
+{
+FIXME("Not implemented\n");
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI Marshal_GetMarshalSizeMax(
+IMarshal* This,
+REFIID riid,
+void *pv,
+DWORD dwDestContext,
+void *pvDestContext,
+DWORD mshlflags,
+DWORD *pSize)
+{
+FIXME("Not implemented\n");
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI Marshal_MarshalInterface(
+IMarshal* This,
+IStream *pStm,
+REFIID riid,
+void *pv,
+DWORD dwDestContext,
+void *pvDestContext,
+DWORD mshlflags)
+{
+FIXME("Not implemented\n");
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI Marshal_UnmarshalInterface(
+IMarshal* This,
+IStream *pStm,
+REFIID riid,
+void **ppv)
+{
+FIXME("Not implemented\n");
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI Marshal_ReleaseMarsha
RE: [Re] Vertex pipeline replacement
> What about opening a metabug and adding all apps what break with the > new > code? Or do you wanna have all this in separate bug reports? Just file a bug report, assign it to me, and make it clear that this new code breaks things. I have one reported problem fixed already, and I am currently working on AoM. I'll send an updated set of patches later today. My sense is that there aren't many bugs, but more like 2-3 problems breaking a lot of games.
re: patchwatcher problem
Vitaly Perov wrote: >Today I sent the patch "netapi32: add stub for NetShareAdd" > On the old patchwatcher it fails: > winspool.drv:info.c:1281: Test failed: Parameter size wrong! 4 expected got 0 > My patch changes only netapi32. > I have no idea why the winespool.drv test can fail. Sorry, I think that was my fault. I accidentally ran wine on the patchwatcher account by hand around then. - Dan
Re: [Re] Vertex pipeline replacement
Stefan Dösinger wrote: >> If you know which patch might have broken this, start there. If you do >> not, a normal regression test is a good idea. > It will always be the last patch. This patch does the real thing, the others > are just making the infrastructure more flexible. So a regression test in > this case is mostly useless > > > So what should I do then? What about opening a metabug and adding all apps what break with the new code? Or do you wanna have all this in separate bug reports? Greets, Tobias
Re: wininet: let automated testers force all DNS lookups to return localhost
On Fri, Oct 31, 2008 at 8:51 AM, Henri Verbeet <[EMAIL PROTECTED]> wrote: > 2008/10/31 Dan Kegel <[EMAIL PROTECTED]>: >> How would we do this on Windows? (We need the >> winetest results to be reliable, too.) >> That was the main reason I didn't go for LD_PRELOAD... >> I guess we do some sort of DLL injection, but I haven't done >> it personally before. >> > You could patch the IAT, but that's quite a bit less nice than > LD_PRELOAD, of course. The thing is, I want to support running tests on Windows as well. May as well do it the same way everywhere... - Dan
Re: wininet: let automated testers force all DNS lookups to return localhost
2008/10/31 Dan Kegel <[EMAIL PROTECTED]>: > How would we do this on Windows? (We need the > winetest results to be reliable, too.) > That was the main reason I didn't go for LD_PRELOAD... > I guess we do some sort of DLL injection, but I haven't done > it personally before. > - Dan > You could patch the IAT, but that's quite a bit less nice than LD_PRELOAD, of course.
Re: malloc to HeapAlloc in dlls/kernel32/process.c
Hello Pete, Pete Myers wrote: > Hi, this is my first ever commit to the Wine project. > > In line with http://wiki.winehq.org/ReplaceMalloc this is a small patch > that changes all malloc calls in ./dlls/kernel32/process.c to HeapAlloc. > > Changelog: > * malloc calls in dlls/kernel32/process.c have been change to HeapAlloc as you might have seen Alexandre removed today those malloc calls himself as those weren't trivial patches. bye michael
RE: [Re] Vertex pipeline replacement
> If you know which patch might have broken this, start there. If you do > not, a normal regression test is a good idea. It will always be the last patch. This patch does the real thing, the others are just making the infrastructure more flexible. So a regression test in this case is mostly useless
Re: wininet: let automated testers force all DNS lookups to return localhost
On Fri, Oct 31, 2008 at 8:11 AM, Henri Verbeet <[EMAIL PROTECTED]> wrote: > 2008/10/31 James Mckenzie <[EMAIL PROTECTED]>: >> This would not work on Macs as /etc/hosts is locked to admins only and would >> be a problem to implement. >> > I don't see how that's a problem, or how that's different from eg. Linux. > > More on-topic, I don't think it would be hard to do some LD_PRELOAD > hacks on getaddrinfo(), gethostbyname(), and whatever else is > appropriate. How would we do this on Windows? (We need the winetest results to be reliable, too.) That was the main reason I didn't go for LD_PRELOAD... I guess we do some sort of DLL injection, but I haven't done it personally before. - Dan
Re: wininet: let automated testers force all DNS lookups to return localhost
On Fri, Oct 31, 2008 at 6:15 AM, Hans Leidekker <[EMAIL PROTECTED]> wrote: > Yes, I think this could use a bit of standardization. Perhaps > we could have a scheme like this: > > http.test.winehq.org > ftp.test.winehq.org > ldap.test.winehq.org > pop3.test.winehq.org > ... > > And mandate that networked tests use those. Then you would > have a predictable list of hostnames to redirect. That sounds like a great idea regardless of what else we do. - Dan
Re: wininet: let automated testers force all DNS lookups to return localhost
On Friday 31 October 2008 15:52:43 James Mckenzie wrote: > >What happened to your /etc/hosts proposal? It has the > >advantage that we don't need changes to Wine source code. > > > This would not work on Macs as /etc/hosts is locked to admins only and would > be a problem to implement. That's true for Unix in general, but I think we require admin rights already because the services need to bind ports below 1024 for example. -Hans
Re: wininet: let automated testers force all DNS lookups to return localhost
2008/10/31 James Mckenzie <[EMAIL PROTECTED]>: > This would not work on Macs as /etc/hosts is locked to admins only and would > be a problem to implement. > I don't see how that's a problem, or how that's different from eg. Linux. More on-topic, I don't think it would be hard to do some LD_PRELOAD hacks on getaddrinfo(), gethostbyname(), and whatever else is appropriate.
Re: wininet: let automated testers force all DNS lookups to return localhost
Hans Leidekker <[EMAIL PROTECTED]> at Oct 31, 2008 5:32 AM wrote about Re: wininet: let automated testers force all DNS lookups to return localhost >> Only include this in debugging builds. > >What happened to your /etc/hosts proposal? It has the >advantage that we don't need changes to Wine source code. > This would not work on Macs as /etc/hosts is locked to admins only and would be a problem to implement. James McKenzie
Re: [Re] Vertex pipeline replacement
James Hawkins <[EMAIL PROTECTED]> at Oct 30, 2008 9:22 PM wrote about Re: [Re] Vertex pipeline replacement > >On Thu, Oct 30, 2008 at 10:07 PM, James McKenzie ><[EMAIL PROTECTED]> wrote: >> Tobias Jakobi wrote: >>> Short feedback: >>> - Max Payne 2: works as expected, I don't see any visual changes >>> - Morrowind: 3D rendering breaks completly, minor (blending?) issues in >>> the menu as well - however ingame scenes are fully black now >>> >>> How should I report this? Open a bug? Should I do any regression testing >>> (since your patchset consists of more than one patch)? >>> >>> >> Do a regression test to locate which patch breaks Morrowmind. >> >> If you know which patch might have broken this, start there. If you do >> not, a normal regression test is a good idea. >> > >Tobias is referring to Stefan's RFC concerning his vertex pipeline >replacement patch. Stefan asked for users to test the patch to see if >any games break. Thank you. This is a 'good thing' to do before sending the patch through to wine-patches. It looks like this patch needs more work. James McKenzie
Re: wininet: let automated testers force all DNS lookups to return localhost
On Friday 31 October 2008 13:39:36 Dan Kegel wrote: > On Fri, Oct 31, 2008 at 5:32 AM, Hans Leidekker <[EMAIL PROTECTED]> wrote: > > What happened to your /etc/hosts proposal? It has the > > advantage that we don't need changes to Wine source code. > > But the disadvantage that we need to know > which servers the test code is going to look up. > I guess I should change my patch to log the actual > name being looked up, then we can get a list. > Do we have any sort of policy about which hostnames > can be used during tests? Yes, I think this could use a bit of standardization. Perhaps we could have a scheme like this: http.test.winehq.org ftp.test.winehq.org ldap.test.winehq.org pop3.test.winehq.org ... And mandate that networked tests use those. Then you would have a predictable list of hostnames to redirect. -Hans
patchwatcher problem
Hi! Today I sent the patch "netapi32: add stub for NetShareAdd" On the old patchwatcher it fails: > winspool.drv:info.c:1281: Test failed: Parameter size wrong! > 4 expected got 0 My patch changes only netapi32. I have no idea why the winespool.drv test can fail. On the new patchwatcher it have passed. -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru
Re: wininet: let automated testers force all DNS lookups to return localhost
On Fri, Oct 31, 2008 at 5:32 AM, Hans Leidekker <[EMAIL PROTECTED]> wrote: > What happened to your /etc/hosts proposal? It has the > advantage that we don't need changes to Wine source code. But the disadvantage that we need to know which servers the test code is going to look up. I guess I should change my patch to log the actual name being looked up, then we can get a list. Do we have any sort of policy about which hostnames can be used during tests? > You would need to duplicate this code in every dll that > does networking, if possible. I don't think it will work > for wldap32, where there is no lookup call to hook into. That's ok, I'd happily duplicate it. - Dan
Re: wininet: let automated testers force all DNS lookups to return localhost
On Friday 31 October 2008 12:45:58 Dan Kegel wrote: > The public internet can (and does) go pear-shaped > in the middle of test runs, which means any test > that tries to access the public internet is de facto > flaky, even if it tries to protect itself by skipping > if the internet is down. > > So let's provide a way for automated testers to > force all hostname resolution requests to > return the same result (say, 'localhost' or 'mytestserver'). > Only include this in debugging builds. What happened to your /etc/hosts proposal? It has the advantage that we don't need changes to Wine source code. You would need to duplicate this code in every dll that does networking, if possible. I don't think it will work for wldap32, where there is no lookup call to hook into. -Hans
Re: [Re] Vertex pipeline replacement
2008/10/31 Austin English <[EMAIL PROTECTED]>: > > Apply a single patch at a time until it breaks. > You'll probably just end up with patch 12, which is huge and enables the entire thing.
Re: [Re] Vertex pipeline replacement
On Thu, Oct 30, 2008 at 11:22 PM, James Hawkins <[EMAIL PROTECTED]> wrote: > On Thu, Oct 30, 2008 at 10:07 PM, James McKenzie > <[EMAIL PROTECTED]> wrote: >> Tobias Jakobi wrote: >>> Short feedback: >>> - Max Payne 2: works as expected, I don't see any visual changes >>> - Morrowind: 3D rendering breaks completly, minor (blending?) issues in >>> the menu as well - however ingame scenes are fully black now >>> >>> How should I report this? Open a bug? Should I do any regression testing >>> (since your patchset consists of more than one patch)? >>> >>> >> Do a regression test to locate which patch breaks Morrowmind. >> >> If you know which patch might have broken this, start there. If you do >> not, a normal regression test is a good idea. >> > > Tobias is referring to Stefan's RFC concerning his vertex pipeline > replacement patch. Stefan asked for users to test the patch to see if > any games break. > > -- > James Hawkins > > > Apply a single patch at a time until it breaks. -- -Austin
