Re: mshtml #5: Set default print template in exec_print.
Frank Richter wrote: On 14.12.2006 00:21, Jacek Caban wrote: --- a/dlls/mshtml/resource.h +++ b/dlls/mshtml/resource.h @@ -28,6 +28,9 @@ #define IDS_MESSAGE_BOX_TITLE 2213 +#define IDS_PRINT_HEADER_TEMPLATE 8403 +#define IDS_PRINT_FOOTER_TEMPLATE 8404 + Could it be you forgot to submit the .rc file changes for these new strings? .rc changes are in an other patch: http://www.winehq.org/pipermail/wine-patches/2006-December/033782.html Thanks, Jacek
Re: Removed as super maintainer
All of the maintainers for EVE Online ( http://appdb.winehq.org/appview.php?iVersionId=6278) have been removed. On 12/14/06, Tony Lambregts [EMAIL PROTECTED] wrote: Aaron Slunt wrote: So do we have to reapply now, or can you just readd me as supermaintainer to half-life sound selector? My email I use on there is the same as this one. It looks we lost all of the entries for supermaintainers some time between yesterday and 11:37:22 today. I have no idea what went wrong but Jeremy Newman has backup so we should be able to restore the data. You shouldn't have to reapply to become a supermaintainer. Jeremy: Could you let us ([EMAIL PROTECTED]) have the sql for appMaintainers from last night we should be able get something for you to restore. -- Tony Lambregts
Re: [1/2] tests: Add skip_wine, a standard way to skip tests that would cause Wine to crash.
Francois Gouget [EMAIL PROTECTED] writes: Currently there is no standard way of adding a test that works on Windows but is known to cause Wine to crash. For instance this is the case for bug 6827: Bug 6827: The SimSig installer crashes http://bugs.winehq.org/show_bug.cgi?id=6827 This essentially means that such tests just don't get written, or get put inside '#if 0' or 'if (0)' sections so that they are never executed, not even on Windows. This means we won't get good Windows coverage until Wine has been 'fixed'. It's not really better with skip_wine; since the test will never be run on Wine it's useless for regression testing, and we won't even notice when the bug gets fixed. If the test doesn't crash on Windows, the right way is to fix Wine to not crash either, that's usually not too hard (making the test succeed may be harder, but that's why we have todo_wine). -- Alexandre Julliard [EMAIL PROTECTED]
Re: Add ddrawex dll
Ulrich Czekalla [EMAIL PROTECTED] writes: diff --git a/dlls/dxguid/dxguid.c b/dlls/dxguid/dxguid.c index c2c102f..7ea8d17 100644 --- a/dlls/dxguid/dxguid.c +++ b/dlls/dxguid/dxguid.c @@ -44,3 +44,4 @@ #include ddrawi.h #include dxfile.h #include d3drm.h +#include ddrawex.h There's no ddrawex.h in your patch (note that there isn't one either in recent SDKs, so you may want to keep these definitions private). -- Alexandre Julliard [EMAIL PROTECTED]
Re: [1/2] tests: Add skip_wine, a standard way to skip tests that would cause Wine to crash.
On Thu, 14 Dec 2006, Alexandre Julliard wrote: [...] It's not really better with skip_wine; since the test will never be run on Wine it's useless for regression testing, and we won't even notice when the bug gets fixed. I see some advantages though: * the code exists rather than not being written in the first place * it is compiled, which is better than putting it inside an '#if 0' * 'skip_wine' clearly indicates that the test needs to be fixed in Wine, which a basic '#if 0' or 'if (0)' does not do * the test statistics will clearly indicate that one of the tests fails in Wine, rather than show that every test succeeds * the test will be run on Windows If the test doesn't crash on Windows, the right way is to fix Wine to not crash either, that's usually not too hard (making the test succeed may be harder, but that's why we have todo_wine). I found quite a few other places in our tests where we could use skip_wine(), but I am really not sure fixing the crashes is alway that simple. See for instance dlls/winmm/tests/wave.c or dlls/rpcrt4/tests/ndr_marshall.c. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
Re: [1/2] tests: Add skip_wine, a standard way to skip tests that would cause Wine to crash.
Francois Gouget [EMAIL PROTECTED] writes: I see some advantages though: * the code exists rather than not being written in the first place * it is compiled, which is better than putting it inside an '#if 0' * 'skip_wine' clearly indicates that the test needs to be fixed in Wine, which a basic '#if 0' or 'if (0)' does not do * the test statistics will clearly indicate that one of the tests fails in Wine, rather than show that every test succeeds * the test will be run on Windows Doing it right would involve running the test on Wine inside an exception handler, and verify that it actually crashes. That's not trivial to do in the tests though. Also I'm concerned that adding a mechanism like this will encourage writing tests that pass garbage pointers, since in most cases this doesn't crash on Windows. But passing bad pointers isn't an interesting test unless a real app depends on it, and if it does then we have to prevent Wine from crashing, adding skip_wine in the test won't help the app. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msxml.dll: nextNode and reset functions
On Thu, Dec 14, 2006 at 11:41:25AM +0100, Colin Pitrat wrote: Change Log: Add an iterator to _xmlnodemap struct Implement nextNode function that give nodes one by one Implement resetNode that reset the iterator It's my first patch, so please tell me if something is wrong. I saw on http://www.winehq.com/site/sending_patches that I should write a test case, but I don't know how to do this (do I need windows ? because I don't have it). Yes, you really should write a test for this. For this dll you could even use a (legal) native version of msxml3.dll run under Wine. Some specific points about your patch: * You seem to have your editor set to display tabs as width 4, please don't do this. Don't use tabs at all and use 4 spaces per indent level. * You don't initialize the iterator member of xmlnodemap, this should be done in create_nodemap. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: mshtml #5: Set default print template in exec_print.
On 14.12.2006 09:10, Jacek Caban wrote: Could it be you forgot to submit the .rc file changes for these new strings? .rc changes are in an other patch: http://www.winehq.org/pipermail/wine-patches/2006-December/033782.html Ah sorry, didn't notice. -f.r. signature.asc Description: OpenPGP digital signature
oleaut32: bypass conversion to string in R4/R8 - DECIMAL conversion (RESEND)
Alex Villacís Lasso escribió:
Alexandre Julliard escribió:
Alex Villacís Lasso [EMAIL PROTECTED] writes:
This patch added the setlocale(LC_ALL, ) line to
dlls/kernel32/locale.c . The oleaut32 tests for vartype.c have been
failing since that time on non-English locales. I see now that setting
the locale around calls of sprintfW() is not thread-safe. However, I
think there is no big problem on going through a string in order to
convert a floating-point number into a DECIMAL, since otherwise, we
would need to implement our own bit-splicer for floating-point
numbers. As long as the starting locale for sprintfW() is known to be
the LC_NUMERIC=C, all other parsing should work as before the MacOS
patch. Therefore I propose the attached patch. This patch simply sets
setlocale(LC_NUMERIC, C) at the end of LOCALE_Init() in
dlls/kernel32/locale.c in order to guarantee that sprintfW will always
use periods as decimal separators.
I put this in for now, but oleaut32 should really be fixed, we can't
force the whole process to format number in English just because
oleaut32 is broken. It doesn't matter too much for Wine itself, but
any Unix library that we load should be able to behave properly
according to the locale that the user has selected.
Well, here is an attempt to fix part of the breakage in oleaut32 that
ties it to LC_NUMERIC being C. This patch decomposes floats and
doubles into the component bitfields, then copies the values into
DECIMAL structures and manipulates them to get the corresponding
DECIMAL value. This removes the step of converting the floating-point
number into a string and therefore eliminates two uses of sprintfW on
floats. This particular patch passes all tests, but I am not really
sure about the rounding - I might be overdoing it. Please comment.
Changelog:
* Remove uses of sprintfW to convert floats into DECIMAL by directly
parsing the floating-point representation.
Alex Villacís Lasso
Resending since there was no response since Monday.
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
--- wine-0.9.27-cvs/dlls/oleaut32/vartype.c 2006-12-07 13:38:15.0 -0500
+++ wine-0.9.27-cvs-patch/dlls/oleaut32/vartype.c 2006-12-10 16:30:02.0 -0500
@@ -4143,6 +4143,21 @@
#define LOCALE_EN_US (MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_US),SORT_DEFAULT))
+/* internal representation of the value stored in a DECIMAL. The bytes are
+ stored from LSB at index 0 to MSB at index 11
+ */
+typedef struct DECIMAL_internal
+{
+DWORD bitsnum[3]; /* 96 significant bits, unsigned */
+unsigned char scale; /* number scaled * 10 ^ -(scale) */
+unsigned int sign : 1; /* 0 - positive, 1 - negative */
+} VARIANT_DI;
+
+static HRESULT VARIANT_DI_FromR4(float source, VARIANT_DI * dest);
+static HRESULT VARIANT_DI_FromR8(double source, VARIANT_DI * dest);
+static void VARIANT_DIFromDec(const DECIMAL * from, VARIANT_DI * to);
+static void VARIANT_DecFromDI(VARIANT_DI * from, DECIMAL * to);
+
/
* VarDecFromR4 (OLEAUT32.193)
*
@@ -4157,10 +4172,12 @@
*/
HRESULT WINAPI VarDecFromR4(FLOAT fltIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szFloatFormatW, fltIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR4(fltIn, di);
+ if (hres == S_OK) VARIANT_DecFromDI(di, pDecOut);
+ return hres;
}
/
@@ -4177,10 +4194,12 @@
*/
HRESULT WINAPI VarDecFromR8(double dblIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szDoubleFormatW, dblIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR8(dblIn, di);
+ if (hres == S_OK) VARIANT_DecFromDI(di, pDecOut);
+ return hres;
}
/
@@ -4596,16 +4615,6 @@
return hRet;
}
-/* internal representation of the value stored in a DECIMAL. The bytes are
- stored from LSB at index 0 to MSB at index 11
- */
-typedef struct DECIMAL_internal
-{
-DWORD bitsnum[3]; /* 96 significant bits, unsigned */
-unsigned char scale; /* number scaled * 10 ^ -(scale) */
-unsigned int sign : 1; /* 0 - positive, 1 - negative */
-} VARIANT_DI;
-
/* translate from external DECIMAL format into an internal representation */
static void VARIANT_DIFromDec(const
Re: usp10: implement ScriptStringAnalyse, ScriptStringFree, ScriptStringXtoCP, ScriptStringCPtoX
Hi,
Can I get some feedback on this patch?
It appears to have been rejected.
Thanks,
Clinton
Clinton Stimpson wrote:
This patch implements ScriptStringAnalyse, ScriptStringFree,
ScriptStringXtoCP, ScriptStringCPtoX.
Also, many todo_wine's are removed.
Thanks,
Clinton Stimpson
ChangeLog
Implement ScriptStringAnalyse, ScriptStringFree,
ScriptStringXtoCP, ScriptStringCPtoX
Index: dlls/usp10/usp10.c
===
RCS file: /home/wine/wine/dlls/usp10/usp10.c,v
retrieving revision 1.45
diff -u -r1.45 usp10.c
--- dlls/usp10/usp10.c 12 Dec 2006 20:30:48 - 1.45
+++ dlls/usp10/usp10.c 13 Dec 2006 03:28:30 -
@@ -73,6 +73,46 @@
HDC hdc;
} Scriptcache;
+typedef struct {
+ int numGlyphs;
+ WORD* glyphs;
+ WORD* pwLogClust;
+ int* piAdvance;
+ SCRIPT_VISATTR* psva;
+ GOFFSET* pGoffset;
+ ABC* abc;
+} StringGlyphs;
+
+typedef struct {
+ BOOL invalid;
+ HDC hdc;
+ int cItems;
+ int cMaxGlyphs;
+ SCRIPT_ITEM* pItem;
+ int numItems;
+ StringGlyphs* glyphs;
+ SIZE* sz;
+} StringAnalysis;
+
+static void ME_StringAnalysisFree(StringAnalysis* analysis)
+{
+ int i;
+ for(i=0; ianalysis-numItems; i++)
+ {
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].glyphs);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].pwLogClust);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].piAdvance);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].psva);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].pGoffset);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].abc);
+ }
+
+ HeapFree(GetProcessHeap(), 0, analysis-glyphs);
+ HeapFree(GetProcessHeap(), 0, analysis-pItem);
+
+ HeapFree(GetProcessHeap(), 0, analysis);
+}
+
/***
* DllMain
*
@@ -448,9 +488,16 @@
const BYTE *pbInClass,
SCRIPT_STRING_ANALYSIS *pssa)
{
- FIXME((%p,%p,%d,%d,%d,0x%x,%d,%p,%p,%p,%p,%p,%p): stub\n,
- hdc, pString, cString, cGlyphs, iCharset, dwFlags,
- iReqWidth, psControl, psState, piDx, pTabdef, pbInClass, pssa);
+ HRESULT hr;
+ StringAnalysis* analysis;
+ int numItemizedItems;
+ int i;
+ SCRIPT_CACHE* sc = 0;
+
+ TRACE((%p,%p,%d,%d,%d,0x%x,%d,%p,%p,%p,%p,%p,%p)\n,
+hdc, pString, cString, cGlyphs, iCharset, dwFlags,
+iReqWidth, psControl, psState, piDx, pTabdef, pbInClass, pssa);
+
if (1 cString || NULL == pString) {
return E_INVALIDARG;
}
@@ -458,7 +505,64 @@
return E_PENDING;
}
- return E_NOTIMPL;
+ analysis = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ sizeof(StringAnalysis));
+
+ analysis-hdc = hdc;
+ numItemizedItems = 255;
+ analysis-pItem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ numItemizedItems*sizeof(SCRIPT_ITEM)+1);
+
+ hr = ScriptItemize(pString, cString, numItemizedItems, psControl,
+ psState, analysis-pItem, analysis-numItems);
+
+ while(hr == E_OUTOFMEMORY)
+ {
+numItemizedItems *= 2;
+HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, analysis-pItem,
+numItemizedItems*sizeof(SCRIPT_ITEM)+1);
+hr = ScriptItemize(pString, cString, numItemizedItems, psControl,
+ psState, analysis-pItem, analysis-numItems);
+ }
+
+ analysis-glyphs = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ sizeof(StringGlyphs)*analysis-numItems);
+ sc = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(SCRIPT_CACHE));
+
+ for(i=0; ianalysis-numItems; i++)
+ {
+int cChar = analysis-pItem[i+1].iCharPos - analysis-pItem[i].iCharPos;
+int numGlyphs = 1.5 * cChar + 16;
+WORD* glyphs = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(WORD)*numGlyphs);
+WORD* pwLogClust = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(WORD)*cChar);
+int* piAdvance = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(int)*numGlyphs);
+SCRIPT_VISATTR* psva = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(SCRIPT_VISATTR)*cChar);
+GOFFSET* pGoffset = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(GOFFSET)*numGlyphs);
+ABC* abc = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(ABC));
+int numGlyphsReturned;
+
+/* FIXME: non unicode strings */
+WCHAR* pStr = (WCHAR*)pString;
+hr = ScriptShape(hdc, sc, pStr[analysis-pItem[i].iCharPos],
+ cChar, numGlyphs, analysis-pItem[i].a,
+ glyphs, pwLogClust, psva, numGlyphsReturned);
+hr = ScriptPlace(hdc, sc, glyphs, numGlyphsReturned, psva,
analysis-pItem[i].a,
+ piAdvance, pGoffset, abc);
+
+analysis-glyphs[i].numGlyphs = numGlyphsReturned;
+analysis-glyphs[i].glyphs = glyphs;
+
Re: usp10: implement ScriptStringAnalyse, ScriptStringFree, ScriptStringXtoCP, ScriptStringCPtoX
Am Donnerstag 14 Dezember 2006 15:58 schrieb Clinton Stimpson: Hi, Can I get some feedback on this patch? It appears to have been rejected. I don't know about the details of usp10, but from the topic of your mail I think you should send 4 patches, one for each function. pgp4pwx8XvVj4.pgp Description: PGP signature
Re: usp10: implement ScriptStringAnalyse, ScriptStringFree, ScriptStringXtoCP, ScriptStringCPtoX
Hi,
It may be because you need to split it into smaller individual patches.
Its rather a one big patch.
Cheers,
VJ
On 12/14/06, Clinton Stimpson [EMAIL PROTECTED] wrote:
Hi,
Can I get some feedback on this patch?
It appears to have been rejected.
Thanks,
Clinton
Clinton Stimpson wrote:
This patch implements ScriptStringAnalyse, ScriptStringFree,
ScriptStringXtoCP, ScriptStringCPtoX.
Also, many todo_wine's are removed.
Thanks,
Clinton Stimpson
ChangeLog
Implement ScriptStringAnalyse, ScriptStringFree,
ScriptStringXtoCP, ScriptStringCPtoX
Index: dlls/usp10/usp10.c
===
RCS file: /home/wine/wine/dlls/usp10/usp10.c,v
retrieving revision 1.45
diff -u -r1.45 usp10.c
--- dlls/usp10/usp10.c12 Dec 2006 20:30:48 - 1.45
+++ dlls/usp10/usp10.c13 Dec 2006 03:28:30 -
@@ -73,6 +73,46 @@
HDC hdc;
} Scriptcache;
+typedef struct {
+ int numGlyphs;
+ WORD* glyphs;
+ WORD* pwLogClust;
+ int* piAdvance;
+ SCRIPT_VISATTR* psva;
+ GOFFSET* pGoffset;
+ ABC* abc;
+} StringGlyphs;
+
+typedef struct {
+ BOOL invalid;
+ HDC hdc;
+ int cItems;
+ int cMaxGlyphs;
+ SCRIPT_ITEM* pItem;
+ int numItems;
+ StringGlyphs* glyphs;
+ SIZE* sz;
+} StringAnalysis;
+
+static void ME_StringAnalysisFree(StringAnalysis* analysis)
+{
+ int i;
+ for(i=0; ianalysis-numItems; i++)
+ {
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].glyphs);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].pwLogClust);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].piAdvance);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].psva);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].pGoffset);
+HeapFree(GetProcessHeap(), 0, analysis-glyphs[i].abc);
+ }
+
+ HeapFree(GetProcessHeap(), 0, analysis-glyphs);
+ HeapFree(GetProcessHeap(), 0, analysis-pItem);
+
+ HeapFree(GetProcessHeap(), 0, analysis);
+}
+
/***
* DllMain
*
@@ -448,9 +488,16 @@
const BYTE *pbInClass,
SCRIPT_STRING_ANALYSIS *pssa)
{
- FIXME((%p,%p,%d,%d,%d,0x%x,%d,%p,%p,%p,%p,%p,%p): stub\n,
- hdc, pString, cString, cGlyphs, iCharset, dwFlags,
- iReqWidth, psControl, psState, piDx, pTabdef, pbInClass, pssa);
+ HRESULT hr;
+ StringAnalysis* analysis;
+ int numItemizedItems;
+ int i;
+ SCRIPT_CACHE* sc = 0;
+
+ TRACE((%p,%p,%d,%d,%d,0x%x,%d,%p,%p,%p,%p,%p,%p)\n,
+hdc, pString, cString, cGlyphs, iCharset, dwFlags,
+iReqWidth, psControl, psState, piDx, pTabdef, pbInClass, pssa);
+
if (1 cString || NULL == pString) {
return E_INVALIDARG;
}
@@ -458,7 +505,64 @@
return E_PENDING;
}
- return E_NOTIMPL;
+ analysis = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ sizeof(StringAnalysis));
+
+ analysis-hdc = hdc;
+ numItemizedItems = 255;
+ analysis-pItem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ numItemizedItems*sizeof(SCRIPT_ITEM)+1);
+
+ hr = ScriptItemize(pString, cString, numItemizedItems, psControl,
+ psState, analysis-pItem, analysis-numItems);
+
+ while(hr == E_OUTOFMEMORY)
+ {
+numItemizedItems *= 2;
+HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, analysis-pItem,
+numItemizedItems*sizeof(SCRIPT_ITEM)+1);
+hr = ScriptItemize(pString, cString, numItemizedItems, psControl,
+ psState, analysis-pItem, analysis-numItems);
+ }
+
+ analysis-glyphs = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ sizeof(StringGlyphs)*analysis-numItems);
+ sc = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(SCRIPT_CACHE));
+
+ for(i=0; ianalysis-numItems; i++)
+ {
+int cChar = analysis-pItem[i+1].iCharPos - analysis-pItem[i].iCharPos;
+int numGlyphs = 1.5 * cChar + 16;
+WORD* glyphs = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(WORD)*numGlyphs);
+WORD* pwLogClust = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(WORD)*cChar);
+int* piAdvance = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(int)*numGlyphs);
+SCRIPT_VISATTR* psva = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(SCRIPT_VISATTR)*cChar);
+GOFFSET* pGoffset = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(GOFFSET)*numGlyphs);
+ABC* abc = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(ABC));
+int numGlyphsReturned;
+
+/* FIXME: non unicode strings */
+WCHAR* pStr = (WCHAR*)pString;
+hr = ScriptShape(hdc, sc, pStr[analysis-pItem[i].iCharPos],
+ cChar, numGlyphs, analysis-pItem[i].a,
+
Re: [5/5] usp10: remote todo_wine
On 12/14/06, Clinton Stimpson [EMAIL PROTECTED] wrote: Hi, Part 5 of 5. Remove many todo_wine's from the tests, now that the functions are implemented. You have to remove the todo_wine's in the same patch that fixes the tests, or the tests will fail for at least one commit. Patches have to be atomic and error free, and a failing test is an error. -- James Hawkins
Re: Removed as super maintainer
Edward Savage wrote: All of the maintainers for EVE Online (http://appdb.winehq.org/appview.php?iVersionId=6278) have been removed. Their back. We have restored all the supermaintainers now. If we have missed anyone somehow we would like to know. -- Tony Lambregts
Re: [5/5] usp10: remote todo_wine
On 12/15/06, Clinton Stimpson [EMAIL PROTECTED] wrote: Ok. There are 4 functions that have to be implemented at the same time in order to not break any tests, because of how the tests were written. A few days ago, I sent a single patch that implemented those 4 functions, including an update of the tests. It wasn't accepted, and it was suggested to break the patch up. But, I can't break it up without breaking the tests. I do have more patches coming after this batch, and those will be smaller and atomic. So I guess I'm back to asking why my original patch wasn't accepted. ?? Should I resend it? I don't understand what the problem is. If you implement a function and a test now passes, remove the todo_wine from the test. Similarly, if the test now fails, add a todo_wine around the test (and explain that a later patch in the series makes the test pass again). There's nothing wrong with sending an implementation of a function that doesn't fix the tests, assuming later functions change that. P.S. Please bottom-post on mailing lists, it makes the conversation easier to read. -- James Hawkins
Re: usp10: fix tests to allow atomic patches for new implementation
On 12/15/06, Clinton Stimpson [EMAIL PROTECTED] wrote: Hi, Here's a patch to make unimplemented functions return E_NOTIMPL instead of S_OK. Even dependent functions already return E_NOTIMPL. Also fixing tests to check that the return value is S_OK before testing the 'out' parameters. This fix allows piecemeal patches to follow with implementation for each function in a separate patch. Thanks, Clinton Stimpson ChangeLog Return E_NOTIMPL where appropriate. And only check out parameters when appropriate. There are a couple things wrong with this patch. First, you've made it so the tests won't be run for these functions (because they don't return S_OK as it stands). Second, there are probably applications that depend on these functions returning S_OK. You're really making it a lot harder than it should be. Implement each function one at a time. If tests start to succeed, just remove the todo_wine from them. So the implemented function and removed/added go in one patch. You just do that for each function you're implementing. -- James Hawkins
