Re: oleaut32: Dynamic invocation for x86
2009/8/21 Juan Lang juan.l...@gmail.com: Personally, I don't think the cut-and-paste approach we've been taking to fix this works all that well for a 126-argument function, so it seems like an assembly approach is the only tenable method. I'm not certain whether Jon's approach is the correct one, but since it didn't get any comment before, I'd like to know: if it isn't acceptable, why not? I don't know if there's a reason the general approach couldn't work, but the code in the patch is gcc specific, so I think it should at least be protected by __GNUC__ in addition to __i386__. This won't work on OS X either, it requires 16 byte alignment for the stack. Also: + subl %eax, %esp\n\t \ ... + 0:\n\t \ + pushl (%ecx, %eax)\n\t \ + subl $4, %eax\n\t \ + jns 0b\n\t \ ... + leal (%esp, %ecx, #pop_size ), %esp\n\t \ This look like a somewhat questionable way to handle both cdecl and stdcall with the same code to me. You should probably look at call_entry_point() in dlls/ntdll/relay.c for an example, although I also guess an argument could be made that something like this should be in libwine. (That would probably break functions that check their return address, not sure if that's an issue here.)
Re: kernel32: test GetPrivateProfileString with empty string as key and section
Hello Stefan,
Stefan Leichter wrote:
Problem spotted from Claudio Fontana on wine-devel
tested on Win2K
diff -ruw wine-git/dlls/kernel32/tests/profile.c
wine-build/dlls/kernel32/tests/profile.c
--- wine-git/dlls/kernel32/tests/profile.c2009-06-04 19:00:09.0
+0200
+++ wine-build/dlls/kernel32/tests/profile.c 2009-08-16 23:03:37.0
+0200
@@ -41,6 +41,13 @@
UINT result9x;
};
+static const char *debugstr_w(LPCWSTR str)
you don't need to add a local debugstr_w implementation anymore.
Alexandre added wine_dbgstr_w() to test.h two days ago with commit
ee868cce5b412b103ff167deb59c3d5237363199.
+{
+static char buf[1024];
+WideCharToMultiByte(CP_ACP, 0, str, -1, buf, sizeof(buf), NULL, NULL);
+return buf;
+}
+
static void test_profile_int(void)
{
struct _profileInt profileInt[]={
bye
michael
Re: (resend) shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces [3rd]
Stefan Leichter stefan.leich...@camline.com writes:
@@ -1711,32 +1713,35 @@
}
else
{
- /* If the executable name is not quoted, we have to use this search
loop here,
+/* FIXME: what versions support this? Fails on 2000/XP
+ If the executable name is not quoted, we have to use this
search loop here,
that in CreateProcess() is not sufficient because it does not
handle shell links. */
WCHAR buffer[MAX_PATH], xlpFile[MAX_PATH];
- LPWSTR space, s;
+LPWSTR space;
- LPWSTR beg = wszApplicationName/*sei_tmp.lpFile*/;
- for(s=beg; (space=strchrW(s, ' ')); s=space+1) {
- int idx = space-sei_tmp.lpFile;
- memcpy(buffer, sei_tmp.lpFile, idx * sizeof(WCHAR));
+lstrcpynW(buffer, wszApplicationName,
sizeof(buffer)/sizeof(WCHAR));
+space = buffer + strlenW(buffer);
+do
Searching from the end doesn't look right. This would need a test case.
--
Alexandre Julliard
julli...@winehq.org
Re: mshtml: Implement IHTMLStyle get/put wordSpacing
Hi Alistair,
Alistair Leslie-Hughes wrote:
Hi,
Changelog:
mshtml: Implement IHTMLStyle get/put wordSpacing
static HRESULT WINAPI HTMLStyle_put_wordSpacing(IHTMLStyle *iface, VARIANT v)
{
-HTMLStyle *This = HTMLSTYLE_THIS(iface);
-FIXME((%p)-(v%d)\n, This, V_VT(v));
-return E_NOTIMPL;
+ HTMLStyle *This = HTMLSTYLE_THIS(iface);
+ TRACE((%p)-(v%d)\n, This, V_VT(v));
+ return set_nsstyle_attr_var(This-nsstyle, STYLEID_WORD_SPACING, v, 0);
The indention here is wrong.
+hres = IHTMLStyle_get_wordSpacing(style, v);
+ok(hres == S_OK, get_wordSpacing: %08x\n, hres);
+ok(!strcmp_wa(V_BSTR(v), 10px), expected 10px = %s\n,
wine_dbgstr_w(V_BSTR(v)));
+VariantClear(v);
Please add a test for V_VT(v) == VT_BSTR.
Jacek
Re: (resend) shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces [3rd]
Am Friday 21 August 2009 11:37:56 schrieb Alexandre Julliard:
Stefan Leichter stefan.leich...@camline.com writes:
@@ -1711,32 +1713,35 @@
}
else
{
- /* If the executable name is not quoted, we have to use this search
loop here, +/* FIXME: what versions support this? Fails on
2000/XP + If the executable name is not quoted, we have to
use this search loop here, that in CreateProcess() is not sufficient
because it does not handle shell links. */ WCHAR buffer[MAX_PATH],
xlpFile[MAX_PATH];
- LPWSTR space, s;
+LPWSTR space;
- LPWSTR beg = wszApplicationName/*sei_tmp.lpFile*/;
- for(s=beg; (space=strchrW(s, ' ')); s=space+1) {
- int idx = space-sei_tmp.lpFile;
- memcpy(buffer, sei_tmp.lpFile, idx * sizeof(WCHAR));
+lstrcpynW(buffer, wszApplicationName,
sizeof(buffer)/sizeof(WCHAR)); +space = buffer +
strlenW(buffer);
+do
Searching from the end doesn't look right. This would need a test case.
This tests needs an additional program/binary, that does not need command line
parameters (therefore shell32_test.exe can not be used), to be build in the
test directory.
A possible way might be to create a recource from the second program, and
extract this during runtime, for winetest.
The source for this is attached. It misses the modifications to Makefile.in
and to fix the build dependencies, what i did not manage.
i give up here.
Stefan
diff -uw wine-git/dlls/shell32/tests/rsrc.rc wine-mingw/dlls/shell32/tests/rsrc.rc
--- wine-git/dlls/shell32/tests/rsrc.rc 2009-06-01 15:06:52.0 +0200
+++ wine-mingw/dlls/shell32/tests/rsrc.rc 2009-08-21 12:52:32.0 +0200
@@ -26,3 +26,6 @@
{
1 Folder Name Resource
}
+
+/* @makedep: shlexec_child.exe */
+child_program RCDATA shlexec_child.exe
diff -uw wine-git/dlls/shell32/tests/shlexec.c wine-mingw/dlls/shell32/tests/shlexec.c
--- wine-git/dlls/shell32/tests/shlexec.c 2009-08-03 19:00:16.0 +0200
+++ wine-mingw/dlls/shell32/tests/shlexec.c 2009-08-21 13:34:34.0 +0200
@@ -57,6 +57,8 @@
static char child_file[MAX_PATH];
static DLLVERSIONINFO dllver;
+/* get the shared code of shlexec.c and shlexec_child.c */
+#include shlexec.h
/***
*
@@ -65,14 +67,6 @@
***/
static void dump_child(void);
-static HANDLE hEvent;
-static void init_event(const char* child_file)
-{
-char* event_name;
-event_name=strrchr(child_file, '\\')+1;
-hEvent=CreateEvent(NULL, FALSE, FALSE, event_name);
-}
-
static void strcat_param(char* str, const char* param)
{
if (param!=NULL)
@@ -402,26 +396,6 @@
*
***/
-static const char* encodeA(const char* str)
-{
-static char encoded[2*1024+1];
-char* ptr;
-size_t len,i;
-
-if (!str) return ;
-len = strlen(str) + 1;
-if (len = sizeof(encoded)/2)
-{
-fprintf(stderr, string is too long!\n);
-assert(0);
-}
-ptr = encoded;
-for (i = 0; i len; i++)
-sprintf(ptr[i * 2], %02x, (unsigned char)str[i]);
-ptr[2 * len] = '\0';
-return ptr;
-}
-
static unsigned decode_char(char c)
{
if (c = '0' c = '9') return c - '0';
@@ -450,18 +424,6 @@
return ptr;
}
-static void childPrintf(HANDLE h, const char* fmt, ...)
-{
-va_list valist;
-charbuffer[1024];
-DWORD w;
-
-va_start(valist, fmt);
-vsprintf(buffer, fmt, valist);
-va_end(valist);
-WriteFile(h, buffer, strlen(buffer), w, NULL);
-}
-
static void doChild(int argc, char** argv)
{
char* filename;
@@ -682,7 +644,9 @@
%s\\masked file.shlexec,
%s\\masked,
%s\\test file.sde,
+%s\\test.exe,
%s\\test file.exe,
+%s\\test file two.exe,
%s\\test2.exe,
NULL
};
@@ -1147,8 +,15 @@
static void test_exes(void)
{
char filename[MAX_PATH];
+char filename2[MAX_PATH];
char params[1024];
int rc;
+DWORD size, wsize;
+HRSRC rsrc;
+LPVOID rsrcbin;
+HGLOBAL rsrch;
+BOOL bres;
+HANDLE hfile;
sprintf(params, shlexec \%s\ Exec, child_file);
@@ -1167,6 +1138,76 @@
ok(rc==SE_ERR_NOASSOC, %s succeeded: rc=%d\n, shell_call, rc);
}
}
+
+/* create test.exe, test file.exe and test file two.exe in the
+ * test directory. Check the filename passed to ShellExecuteA is
+ * started and not one of the other two files (see bug 19666)
+ */
+rsrc = FindResourceA(GetModuleHandle(NULL), child_program, RT_RCDATA);
+ok(NULL != rsrc, Resource not found %d\n, GetLastError());
+if(!rsrc) return;
+
+size = SizeofResource(GetModuleHandle(NULL), rsrc);
+ok(0 != size, SizeofResource failed %d\n, GetLastError());
+if(!size) return;
+
+rsrch = LoadResource(GetModuleHandle(NULL), rsrc);
+ok(NULL != rsrch, LoadResource failed %d\n, GetLastError());
+if(!rsrch) return;
+
+rsrcbin = LockResource(rsrch);
+ok(NULL
Re: Bug for beginners
Thanks to both of you Andrew and Juan. I think though I'll with Andrew's suggestion. ;-) On Thu, Aug 20, 2009 at 11:58 PM, Andrew Eikum and...@brightnightgames.comwrote: Alexandros Dermenakis wrote: Hi all, I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future. thank you Hi Alexandros, When I began working on Wine, I found that the easiest way for me was to implement parts of Wine that have no implementation yet. Implementing new functions means you don't have to worry about breaking old tests or re-arranging and understanding someone else's code. It also gives you the opportunity to write new tests from the ground up, so you get used to exactly what the unit tests are for and how they work. Look around in Wine for functions that are labeled with FIXMEs indicating that they are stubs, or look in the .spec files for functions declared as stubs. Find a function that has an easy to understand purpose: a very clear input and output. Then, write unit tests in that DLL's test suite that prove all of the important features of that function. Run your tests on an actual Windows OS (look into crosstests) and verify that they are correct. Finally, implement that function in Wine to make it also pass your tests. If you want a suggestion for where to look for small stubs, take a look at gdi32 and gdiplus. I know they still have some smallish, unimplemented or half-implemented functions. If graphics don't interest you, there are plenty of stubs elsewhere. Once you've got the hang of how the unit tests work (I mean it, the test cases are the most important part of getting patches into Wine), try looking into bugs on WineHQ until you find one you think you might be able to handle. Then gear up for the most fun you'll ever have reading pages and pages debug logs :) No matter where you begin your work, remember that Wine is a difficult project to work on. Because even very subtle changes can cause breakages in seemingly unrelated parts of Wine, the standard for patches is very high. You will need to prove that your patch is correct using the test suites. No provable tests means it's not getting in. Good luck and thanks for your interest, Andrew
Re: (resend) shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces [3rd]
Stefan Leichter stefan.leich...@camline.com writes:
Am Friday 21 August 2009 11:37:56 schrieb Alexandre Julliard:
Stefan Leichter stefan.leich...@camline.com writes:
@@ -1711,32 +1713,35 @@
}
else
{
- /* If the executable name is not quoted, we have to use this search
loop here, +/* FIXME: what versions support this? Fails on
2000/XP + If the executable name is not quoted, we have to
use this search loop here, that in CreateProcess() is not sufficient
because it does not handle shell links. */ WCHAR buffer[MAX_PATH],
xlpFile[MAX_PATH];
- LPWSTR space, s;
+LPWSTR space;
- LPWSTR beg = wszApplicationName/*sei_tmp.lpFile*/;
- for(s=beg; (space=strchrW(s, ' ')); s=space+1) {
- int idx = space-sei_tmp.lpFile;
- memcpy(buffer, sei_tmp.lpFile, idx * sizeof(WCHAR));
+lstrcpynW(buffer, wszApplicationName,
sizeof(buffer)/sizeof(WCHAR)); +space = buffer +
strlenW(buffer);
+do
Searching from the end doesn't look right. This would need a test case.
This tests needs an additional program/binary, that does not need command
line
parameters (therefore shell32_test.exe can not be used), to be build in the
test directory.
What you need to test is things like test file.exe two.exe where both
exe files exist. I don't see why you can't pass arguments too, you just
have to make the child a bit smarter to ignore args like two.exe.
--
Alexandre Julliard
julli...@winehq.org
Re: (resend) shell32: fix program search in ShellExecuteEx, quote program name if it contains spaces [3rd]
Am Friday 21 August 2009 14:22:14 schrieb Alexandre Julliard:
Stefan Leichter stefan.leich...@camline.com writes:
Am Friday 21 August 2009 11:37:56 schrieb Alexandre Julliard:
Stefan Leichter stefan.leich...@camline.com writes:
@@ -1711,32 +1713,35 @@
}
else
{
-/* If the executable name is not quoted, we have to use this
search loop here, +/* FIXME: what versions support this?
Fails on 2000/XP + If the executable name is not quoted,
we have to use this search loop here, that in CreateProcess() is not
sufficient because it does not handle shell links. */ WCHAR
buffer[MAX_PATH], xlpFile[MAX_PATH];
-LPWSTR space, s;
+LPWSTR space;
-LPWSTR beg = wszApplicationName/*sei_tmp.lpFile*/;
-for(s=beg; (space=strchrW(s, ' ')); s=space+1) {
-int idx = space-sei_tmp.lpFile;
-memcpy(buffer, sei_tmp.lpFile, idx * sizeof(WCHAR));
+lstrcpynW(buffer, wszApplicationName,
sizeof(buffer)/sizeof(WCHAR)); +space = buffer +
strlenW(buffer);
+do
Searching from the end doesn't look right. This would need a test case.
This tests needs an additional program/binary, that does not need command
line parameters (therefore shell32_test.exe can not be used), to be build
in the test directory.
What you need to test is things like test file.exe two.exe where both
exe files exist. I don't see why you can't pass arguments too, you just
have to make the child a bit smarter to ignore args like two.exe.
When i pass arguments the code path you objects all the time is not executed.
Ignoring unknow args is not possible in the shell32 tests. This must be done
in include/wine/test.h. I don't like to test what breaks, when i do
modifications there.
--
Stefan
Re: Bug for beginners
On Fri, Aug 21, 2009 at 12:58 AM, Andrew Eikum and...@brightnightgames.comwrote: Alexandros Dermenakis wrote: Hi all, I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future. thank you Hi Alexandros, When I began working on Wine, I found that the easiest way for me was to implement parts of Wine that have no implementation yet. Implementing new functions means you don't have to worry about breaking old tests or re-arranging and understanding someone else's code. It also gives you the opportunity to write new tests from the ground up, so you get used to exactly what the unit tests are for and how they work. Look around in Wine for functions that are labeled with FIXMEs indicating that they are stubs, or look in the .spec files for functions declared as stubs. Find a function that has an easy to understand purpose: a very clear input and output. Then, write unit tests in that DLL's test suite that prove all of the important features of that function. Run your tests on an actual Windows OS (look into crosstests) and verify that they are correct. Finally, implement that function in Wine to make it also pass your tests. If you want a suggestion for where to look for small stubs, take a look at gdi32 and gdiplus. I know they still have some smallish, unimplemented or half-implemented functions. If graphics don't interest you, there are plenty of stubs elsewhere. Once you've got the hang of how the unit tests work (I mean it, the test cases are the most important part of getting patches into Wine), try looking into bugs on WineHQ until you find one you think you might be able to handle. Then gear up for the most fun you'll ever have reading pages and pages debug logs :) No matter where you begin your work, remember that Wine is a difficult project to work on. Because even very subtle changes can cause breakages in seemingly unrelated parts of Wine, the standard for patches is very high. You will need to prove that your patch is correct using the test suites. No provable tests means it's not getting in. Good luck and thanks for your interest, Andrew As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be which application requires this function?. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Re: Bug for beginners
As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be which application requires this function?. We certainly prioritize functions that an application needs, but we don't prohibit code that doesn't identify an application that needs it. It's true that we often ask on this mailing list which application needs a function, but I think that's generally when a patch looks strange for some other reason. One of the usual reasons is that it's lacking a test. So, going back to the original advice: if you can write good test cases for a function, then there's a decent chance you can implement it, and both tests and the implementation can find their way into Wine. If you can't write good test cases, you'll have a much harder time getting your code into Wine. --Juan
Re: Bug for beginners
On Fri, Aug 21, 2009 at 12:58 AM, Andrew Eikum and...@brightnightgames.comwrote: Alexandros Dermenakis wrote: Hi all, I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future. thank you Hi Alexandros, When I began working on Wine, I found that the easiest way for me was to implement parts of Wine that have no implementation yet. Implementing new functions means you don't have to worry about breaking old tests or re-arranging and understanding someone else's code. It also gives you the opportunity to write new tests from the ground up, so you get used to exactly what the unit tests are for and how they work. Look around in Wine for functions that are labeled with FIXMEs indicating that they are stubs, or look in the .spec files for functions declared as stubs. Find a function that has an easy to understand purpose: a very clear input and output. Then, write unit tests in that DLL's test suite that prove all of the important features of that function. Run your tests on an actual Windows OS (look into crosstests) and verify that they are correct. Finally, implement that function in Wine to make it also pass your tests. If you want a suggestion for where to look for small stubs, take a look at gdi32 and gdiplus. I know they still have some smallish, unimplemented or half-implemented functions. If graphics don't interest you, there are plenty of stubs elsewhere. Once you've got the hang of how the unit tests work (I mean it, the test cases are the most important part of getting patches into Wine), try looking into bugs on WineHQ until you find one you think you might be able to handle. Then gear up for the most fun you'll ever have reading pages and pages debug logs :) No matter where you begin your work, remember that Wine is a difficult project to work on. Because even very subtle changes can cause breakages in seemingly unrelated parts of Wine, the standard for patches is very high. You will need to prove that your patch is correct using the test suites. No provable tests means it's not getting in. Good luck and thanks for your interest, Andrew As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be which application requires this function?. One idea is to look at Bugzilla for a problem report that exists because a specific function does not exist. For instance, I have been working on a bug with EM_FORMATRANGE and trying to update the fix included to work with the current Wine version as several programs rely on the ability to change fonts in specific windows. I have a working fix for 0.9.59 and my time was and continues to be diverted to other efforts, not necessarily this fix. However, I would like assistance in moving the patch forward and into Wine. There are other bug reports where the fix is 'hacky' and needs to be cleaned up so, in many cases a conformance/compliance test is all that is needed. This would be a great place to start where you can look at the current Wine code base, what someone came up with as a fix and what needs to make the fix workable. You don't have to look for an application that requires a certain function that works in a specific manner. James McKenzie
Re: Bug for beginners
On Fri, Aug 21, 2009 at 12:25 PM, Juan Lang juan.l...@gmail.com wrote: As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be which application requires this function?. We certainly prioritize functions that an application needs, but we don't prohibit code that doesn't identify an application that needs it. It's true that we often ask on this mailing list which application needs a function, but I think that's generally when a patch looks strange for some other reason. One of the usual reasons is that it's lacking a test. So, going back to the original advice: if you can write good test cases for a function, then there's a decent chance you can implement it, and both tests and the implementation can find their way into Wine. If you can't write good test cases, you'll have a much harder time getting your code into Wine. --Juan Thanks for the clarification. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Re: (try 2) [1/4] d3d10: Partially implement ID3D10Effect::GetDesc.
Am 21.08.2009 17:46, schrieb Rico Schüller:
---
dlls/d3d10/d3d10_private.h |3 ++-
dlls/d3d10/effect.c| 25 ++---
2 files changed, 20 insertions(+), 8 deletions(-)
Hi,
the previous patch was wrong, take this one instead of the other one.
Rico
diff --git a/dlls/d3d10/d3d10_private.h b/dlls/d3d10/d3d10_private.h
index 535a82d..16a09df 100644
--- a/dlls/d3d10/d3d10_private.h
+++ b/dlls/d3d10/d3d10_private.h
@@ -114,7 +114,8 @@ struct d3d10_effect
ID3D10Device *device;
DWORD version;
DWORD local_buffer_count;
-DWORD localobjects_count;
+DWORD local_buffer_variable_count;
+DWORD local_variable_count;
DWORD sharedbuffers_count;
DWORD sharedobjects_count;
DWORD technique_count;
diff --git a/dlls/d3d10/effect.c b/dlls/d3d10/effect.c
index a5a32e1..dcd3be6 100644
--- a/dlls/d3d10/effect.c
+++ b/dlls/d3d10/effect.c
@@ -547,12 +547,11 @@ static HRESULT parse_fx10(struct d3d10_effect *e, const char *data, DWORD data_s
read_dword(ptr, e-local_buffer_count);
TRACE(Local buffer count: %u.\n, e-local_buffer_count);
-/* Number of variables in local buffers? */
-read_dword(ptr, unknown);
-FIXME(Unknown 0: %u\n, unknown);
+read_dword(ptr, e-local_buffer_variable_count);
+TRACE(Local buffer variable count: %u\n, e-local_buffer_variable_count);
-read_dword(ptr, e-localobjects_count);
-TRACE(Localobjects count: %u\n, e-localobjects_count);
+read_dword(ptr, e-local_variable_count);
+TRACE(Local variable count: %u\n, e-local_variable_count);
read_dword(ptr, e-sharedbuffers_count);
TRACE(Sharedbuffers count: %u\n, e-sharedbuffers_count);
@@ -823,9 +822,26 @@ static HRESULT STDMETHODCALLTYPE d3d10_effect_GetDevice(ID3D10Effect *iface, ID3
static HRESULT STDMETHODCALLTYPE d3d10_effect_GetDesc(ID3D10Effect *iface, D3D10_EFFECT_DESC *desc)
{
-FIXME(iface %p, desc %p stub!\n, iface, desc);
+struct d3d10_effect *This = (struct d3d10_effect *)iface;
-return E_NOTIMPL;
+TRACE(iface %p, desc %p stub!\n, iface, desc);
+
+if( !desc )
+{
+return E_INVALIDARG;
+}
+
+FIXME(IsChildEffect is not handled!\n);
+desc-IsChildEffect = FALSE;
+desc-ConstantBuffers = This-local_buffer_count;
+FIXME(SharedConstantBuffers is not handled!\n);
+desc-SharedConstantBuffers = 0;
+desc-GlobalVariables = This-local_buffer_variable_count + This-local_variable_count;
+FIXME(SharedGlobalVariables is not handled!\n);
+desc-SharedGlobalVariables = 0;
+desc-Techniques = This-technique_count;
+
+return S_OK;
}
static struct ID3D10EffectConstantBuffer * STDMETHODCALLTYPE d3d10_effect_GetConstantBufferByIndex(ID3D10Effect *iface,
Re: oleaut32: Dynamic invocation for x86
Thanks for the review, Henri. I don't know if there's a reason the general approach couldn't work, but the code in the patch is gcc specific, so I think it should at least be protected by __GNUC__ in addition to __i386__. We don't protect by __GNUC__ for any of our other assembly either, even though it all uses GNU assembly syntax. So personally I think that part's okay. --Juan
Re: oleaut32: Dynamic invocation for x86
On Fri, Aug 21, 2009 at 12:31 PM, Juan Langjuan.l...@gmail.com wrote: We don't protect by __GNUC__ for any of our other assembly either, even though it all uses GNU assembly syntax. So personally I think that part's okay. There are a few instances of it, at least in code we care about sharing with a mingw build sedwa...@sedwards-desktop:~/source/wine$ find -name *.c | xargs grep (__i386__) defined(__GNUC__) ./libs/wine/port.c:#if defined(__i386__) defined(__GNUC__) ./dlls/ntdll/large_int.c:#if defined(__i386__) defined(__GNUC__) ./dlls/kernel32/instr.c:#if defined(__i386__) defined(__GNUC__) ./dlls/winex11.drv/dib.c:#if defined(__i386__) defined(__GNUC__) ./dlls/winex11.drv/dib.c:#if defined(__i386__) defined(__GNUC__) ./dlls/ddraw/device.c:#if defined(__i386__) defined(__GNUC__) ./dlls/ddraw/device.c:#if defined(__i386__) defined(__GNUC__) -- 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: oleaut32: Dynamic invocation for x86
There are a few instances of it, at least in code we care about sharing with a mingw build Ah, fair enough, and clearly oleaut32 belongs in that category. Thanks. --Juan
Re: (try 2) [1/4] d3d10: Partially implement ID3D10Effect::GetDesc.
Rico: Which patch is the correct one? Please send it in with (try 3). James McKenzie -Original Message- From: Rico Schüller kgbric...@web.de Sent: Aug 21, 2009 9:16 AM To: wine-patc...@winehq.org Subject: Re: (try 2) [1/4] d3d10: Partially implement ID3D10Effect::GetDesc. Am 21.08.2009 17:46, schrieb Rico Schüller: --- dlls/d3d10/d3d10_private.h |3 ++- dlls/d3d10/effect.c| 25 ++--- 2 files changed, 20 insertions(+), 8 deletions(-) Hi, the previous patch was wrong, take this one instead of the other one. Rico
Re: oleaut32: Dynamic invocation for x86
On Fri, Aug 21, 2009 at 1:42 PM, Juan Langjuan.l...@gmail.com wrote: Ah, fair enough, and clearly oleaut32 belongs in that category. Thanks. I should have said Windows as technically mingw is still __GNUC__ but you got the idea. -- 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
CPPCheck Run for Friday August 21
[../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of bounds [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map Chris
Appinstall strikes again!
So, I've been on vacation this past week. Before leaving, I ran 'daily
; daily ; daily ; daily ; daily' to make sure they daily build scripts
still ran while I was gone.
Looking at the logs, I found something interesting:
wordviewer03-result.txt:wordview_en-us.exe didn't crash. Bug 19185 TODO_FIXED.
wordviewer03-result.txt:C:\users\austin\Application
Data\Microsoft\Installer\{90850409-6000-11D3-8CFE-0150048383C9}
doesn't exist. Bug 19318 TODO_FIXED.
Some TODO_FIXED...investigate!
(from http://austinenglish.com/logs/appinstall-2009-08-21/summary.txt)
Looking at the git log, there were only a couple msxml commits, so I
tried reverting them to see which one fixed it. Apparently this one
did:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=38c0667334d7b929607a3b2d7e6ed4856f65f718
So thanks Jacek, you fixed a 1.2.0 bug and probably didn't even know it ;-).
Now, everyone write some tests for your favorite downloadable application! :-)
--
-Austin
Re: CPPCheck Run for Friday August 21
On Fri, Aug 21, 2009 at 9:21 PM, chris ahrendtceltich...@yahoo.com wrote: [../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of bounds False positive. Doesn't like the FIELD_OFFSET macro for alloc. [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries This is probably the only one here that sticks out, but afaict, it's not a leak. There's somewhat convoluted logic involved (if count==table-count, we don't reallocate; if reallocation fails...the previous pointer shouldn't be deallocated, and new_entries=NULL anyway). Its a false positive. This seems like something it shouldn't catch though, so might want to report this bug to cppcheck devs. [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map Chris Thanks for running these, keeps the code nicely in check. Mike.
Re: CPPCheck Run for Friday August 21
Mike Kaplinskiy wrote: On Fri, Aug 21, 2009 at 9:21 PM, chris ahrendtceltich...@yahoo.com wrote: [../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of bounds False positive. Doesn't like the FIELD_OFFSET macro for alloc. [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries This is probably the only one here that sticks out, but afaict, it's not a leak. There's somewhat convoluted logic involved (if count==table-count, we don't reallocate; if reallocation fails...the previous pointer shouldn't be deallocated, and new_entries=NULL anyway). Its a false positive. This seems like something it shouldn't catch though, so might want to report this bug to cppcheck devs. [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map Chris Thanks for running these, keeps the code nicely in check. Mike. I reran it on 1.1.28 and the result is the same so will report the false positive to cpp guys... Your welcome ... its something to do for the devs =D chris
