May 2007 - Wine-Devel - list.winehq.org

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS & incorrect GetLastError() codes fix

by Kirill K. Smirnov

+static void test_MultiByteToWideChar(void) +{ + int i, ret; + static char src[32]; + static WCHAR dst[32]; + static const WCHAR glyphed_dst[32] = { + 0x0000, 0x263A, 0x263B, 0x2665, 0x2666, 0x2663, 0x2660, 0x2022, + 0x25D8, 0x25CB, 0x25D9, 0x2642, 0x2640, 0x266A, 0x266B, 0x263C, + 0x25BA, 0x25C4, 0x2195, 0x203C, 0x00B6, 0x00A7, 0x25AC, 0x21A8, + 0x2191, 0x2193, 0x2192, 0x2190, 0x221F, 0x2194, 0x25B2, 0x25BC + }; + for (i=0;i<32;i++) src[i]=i; + memset(&dst, 0, sizeof(dst)); Char 0x7F should be tested too. + trace("originaldst: %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x\n", + dst[0],dst[1],dst[2],dst[3],dst[4],dst[5],dst[6],dst[7],dst[8],dst[9],dst[10],dst[11],dst[12],dst[13],dst[14],dst[15],dst[16], + dst[17],dst[18],dst[19],dst[20],dst[21],dst[22],dst[23],dst[24],dst[25],dst[26],dst[27],dst[28],dst[29],dst[30],dst[31]); + trace("glyphed_dst: %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x %.4x\n", + glyphed_dst[0],glyphed_dst[1],glyphed_dst[2],glyphed_dst[3],glyphed_dst[4],glyphed_dst[5],glyphed_dst[6],glyphed_dst[7],glyphed_dst[8],glyphed_dst[9],glyphed_dst[10],glyphed_dst[11],glyphed_dst[12],glyphed_dst[13],glyphed_dst[14],glyphed_dst[15],glyphed_dst[16], + glyphed_dst[17],glyphed_dst[18],glyphed_dst[19],glyphed_dst[20],glyphed_dst[21],glyphed_dst[22],glyphed_dst[23],glyphed_dst[24],glyphed_dst[25],glyphed_dst[26],glyphed_dst[27],glyphed_dst[28],glyphed_dst[29],glyphed_dst[30],glyphed_dst[31]); + } +} My notice may look like nitpicking, but these lines are too long.. Is it really necessary to dump entire array instead of just printing error message? -- Kirill

May 10, 2007

RE: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)

by Rolf Kalbermatter

Dmitry Timoshkov [mailto:dmitry(a)codeweavers.com] wrote: >"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > >> Please show me how an unsigned int can represent values greater than >> 2^32. This is why a float is used. > >Of course int can't, but neither float can. Perhaps you confuse it with double? I think float can represent integers larger than 2^32 but it will be not anymore fully accurate. In fact it will start getting inaccurate in representing every possible integer at around 2^22. But that does not mean that it can't represent 2^40 approximately. The maximum decimal range of a float is around +-4 * 10 ^ 38 compared to 4 * 10 ^ 9 for an unsigned 32 bit integer. So if full integer accuracy is not a concern, which I think isn't in this case, floats definitely have a range advantage over 32 bit integers. Even 64 bit integers can't cover that range although they might have a large enough range for this problem. Rolf Kalbermatter

May 10, 2007

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS & incorrectGetLastError() codes fix

by Dmitry Timoshkov

"Andrew O. Shadoura" <bugzilla(a)tut.by> wrote: > if (!src || (!dst && dstlen)) > { > @@ -1774,18 +1773,12 @@ INT WINAPI MultiByteToWideChar( UINT page, DWORD flags, LPCSTR src, INT srclen, > > if (srclen < 0) srclen = strlen(src) + 1; > > - if (!once && (flags & MB_USEGLYPHCHARS)) > - { > - once = 1; > - FIXME("MB_USEGLYPHCHARS not supported\n"); > - } > - > switch(page) > { > case CP_SYMBOL: > - if( flags) > + if(flags) > { If you decided to fix the formatting it would be better to send it as a separate patch, and follow the style of 'if' statements above. > case CP_UTF8: > + if (flags & (~MB_ERR_INVALID_CHARS)) > + { > + SetLastError( ERROR_INVALID_FLAGS ); > + return 0; > + } Mixed tabs/spaces. > --- a/dlls/kernel32/tests/locale.c > +++ b/dlls/kernel32/tests/locale.c > @@ -2255,6 +2255,42 @@ static void test_GetCPInfo(void) > ok(cpinfo.MaxCharSize == 4, "expected 5, got 0x%x\n", cpinfo.MaxCharSize); > } > > +static void test_MultiByteToWideChar(void) This test belongs to dlls/kernel32/tests/codepage.c. > + else > + res = mbstowcs_sbcs_decompose( &table->sbcs, src, srclen, dst, dstlen ); > + if (flags & MB_USEGLYPHCHARS) add_glyphs( dst, dstlen ); > + return res; Mixed tabs/spaces. > - return mbstowcs_dbcs_decompose( &table->dbcs, src, srclen, dst, dstlen ); > + res = mbstowcs_dbcs_decompose( &table->dbcs, src, srclen, dst, dstlen ); > + if (flags & MB_USEGLYPHCHARS) add_glyphs( dst, dstlen ); > + return res; Again mixed tabs/spaces. -- Dmitry.

May 9, 2007

Re: Correct VarBstrFromDate for dates between DATE_MIN and 1601

by Bill Medland

On Wed, 2007-09-05 at 19:32 +0200, Alexandre Julliard wrote: > Bill Medland <billmedland(a)shaw.ca> writes: > > > The only solutions I see are: > > > > + Leave it as it is (and hard luck to anyone who uses dates in the range > > 1/1/100 to 1/1/1601) > > That's certainly the best way, unless we find an app that depends on > these dates. > Sage Accpac ERP > > + Add support down in kernel32/ntdll to format dates in that range > > That cannot work unless you find a way to do it through the public > API. Adding private functions or flags is not acceptable. > > > + Duplicate and morph sufficient date formatting up in oleaut32 > > specifically for this case > > If none of the above work, then yes you have to do that. > OK. If that's what you insist on. Bill

May 9, 2007

Re: [5/5] WineD3D: Manage private data in a wine linked list

by H. Verbeet

On 09/05/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > (But this should go in a different patch, since the old code didn't free it > either. The patch is just fixing the data structure, not the behavior) > Yeah, it's just that this patch made me look at that part of the code.

May 9, 2007

Re: [1/5] wined3d: Unload vertex weight data in case of EXT_VERTEX_WEIGHTING as well

by Stefan Dösinger

Am Mittwoch 09 Mai 2007 19:07 schrieb H. Verbeet: > This set applies on top of Stefan's > > Changelog: > - Unload vertex weight data in case of EXT_VERTEX_WEIGHTING as well Actually I was thinking about removing the whole (disabled) vertex weighting code since I didn't find any card supporting this extension.

May 9, 2007

Re: [5/5] WineD3D: Manage private data in a wine linked list

by Stefan Dösinger

Am Mittwoch 09 Mai 2007 18:33 schrieb H. Verbeet: > On 09/05/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > Fixes an endless loop in the startup of Traffic Giant. > > Shouldn't you free the private data when the resource is destroyed? > (MSDN claims you should). Yes, this makes sense, especially since we allocate the memory for it. I'll write a test testing that with an IUnknown data storage. (But this should go in a different patch, since the old code didn't free it either. The patch is just fixing the data structure, not the behavior)

May 9, 2007

Re: Correct VarBstrFromDate for dates between DATE_MIN and 1601

by Alexandre Julliard

Bill Medland <billmedland(a)shaw.ca> writes: > The only solutions I see are: > > + Leave it as it is (and hard luck to anyone who uses dates in the range > 1/1/100 to 1/1/1601) That's certainly the best way, unless we find an app that depends on these dates. > + Add support down in kernel32/ntdll to format dates in that range That cannot work unless you find a way to do it through the public API. Adding private functions or flags is not acceptable. > + Duplicate and morph sufficient date formatting up in oleaut32 > specifically for this case If none of the above work, then yes you have to do that. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: Correct VarBstrFromDate for dates between DATE_MIN and 1601

by Bill Medland

On Wed, 2007-09-05 at 18:07 +0200, Alexandre Julliard wrote: > Bill Medland <billmedland(a)shaw.ca> writes: > > > On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote: > >> Bill Medland (billmedland(a)shaw.ca) > >> Correct VarBstrFromDate for dates between DATE_MIN and 1601 > >> > > > > Has this been rejected out of hand or is it still being considered? > > Rejected, adding a secret wine-only flag to GetDateFormat is ugly. You > need to find another way to do that. > I thought you might say that. Can you please look at the following and give me hints as to what you are prepared to accept: If I redo it like this will you accept it? + Add the secret wine-only flag privately within lcformat.c (as has already been done with the DATE_DATEVARSONLY and TIME_TIMEVARSONLY) + NLS_GetDateTimeFormatW as in the submitted patch + Add a wine-only function (e.g. wineGetDateTimeFormatFullRange) that calls NLS_GetDateTimeFormatW with the now-private wine-only flag If not, how about this? + Add an argument to NLS_GetDateTimeFormatW for the wine-specific flags (to avoid potential conflict with true flags, which we already have) + Add a wine-only function (e.g. wineGetDateTimeFormatFullRange) that calls NLS_GetDateTimeFormatW with the now-private wine-only flag Presumably this is not an option (I hate even to mention it but you are not leaving many options) + Copy the existing NLS_GetDateTimeFormatW up into oleaut32 and modify the copy to remove the restriction on dates. The fundamental problem is: + The ability to format dates and times is currently down in the kernel32 and ntdll + That code is structured around dates from 1601 upwards + oleaut32 handles dates from 1 January 100 upwards (up to a maximum) The only solutions I see are: + Leave it as it is (and hard luck to anyone who uses dates in the range 1/1/100 to 1/1/1601) + Add support down in kernel32/ntdll to format dates in that range + Duplicate and morph sufficient date formatting up in oleaut32 specifically for this case + Add some very magic code up in oleaut32 that does some really weird stuff like mapping the range 1/1/100 to 31/12/1600 into a valid range, calling the kernel32 functions and then patching up the result (e.g. figuring out where the year is in the string and changing it back). Which would you accept? Respectfully Bill Medland

May 9, 2007

Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)

by Mike Schaadt

An int value can be more precise then a float can, however a float can hold bigger numbers. It's the difference between having a 24 bit fraction with 8 bits of exponent and 1 of sign vs 31/32 bits of fraction data without exponent. Plus, integer operations are faster then floating point operations, even if just margionably. On 5/9/07, Vitaly Budovski <vbudovski(a)gmail.com> wrote: > Dmitry Timoshkov wrote: > > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > > > >> Please show me how an unsigned int can represent values greater than > >> 2^32. This is why a float is used. > > > > Of course int can't, but neither float can. Perhaps you confuse it with > > double? > > > > I'm pretty sure I'm not confusing it with double. > http://steve.hollasch.net/cgindex/coding/ieeefloat.html > http://en.wikipedia.org/wiki/IEEE_754#Single-precision_32_bit > > >

May 9, 2007

Re: [msi/tests] Properly cleanup after each test

by Paul Vriens

On 5/8/07, James Hawkins <truiken(a)gmail.com> wrote: > > Please don't change the names of variables. I chose the generic name > of path (which is used throught Wine), because that's exactly what the > variable contains throughout the functions. Also, msifile2 is a poor > choice of a variable name. > > Thanks, > James Hawkins > Hi, The choice for msifile2 was based on the fact that the other msi-file was called msifile :-). I'll resend without the variable changes. Cheers, Paul.

May 9, 2007

Re: [5/5] WineD3D: Manage private data in a wine linked list

by H. Verbeet

On 09/05/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Fixes an endless loop in the startup of Traffic Giant. > Shouldn't you free the private data when the resource is destroyed? (MSDN claims you should).

May 9, 2007

Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)

by Vitaly Budovski

Dmitry Timoshkov wrote: > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > >> Please show me how an unsigned int can represent values greater than >> 2^32. This is why a float is used. > > Of course int can't, but neither float can. Perhaps you confuse it with > double? > I'm pretty sure I'm not confusing it with double. http://steve.hollasch.net/cgindex/coding/ieeefloat.html http://en.wikipedia.org/wiki/IEEE_754#Single-precision_32_bit

May 9, 2007

Re: [PATCH] Uninstaller: Change hardcoded value for maximum subkey name length to a const.

by Tom Spear

On 5/8/07, Dan Hipschman <dsh(a)linux.ucla.edu> wrote: > I'm not sure what version of C wine is strictly trying to conform to, > but it's usually best to go with the lowest common denominator. This is > not C89. The const keyword doesn't actually make the variable constant > (I know it's not the greatest feature of C). The array size won't be > evaluated until runtime, so technically this is a variable length array > which weren't added until C99. You can make it C89 simply by using > #define instead of declaring it as a variable. Hi. Thanks for the comment. I looked thru resource.h in the same directory, and see MAX_STRING_LEN is defined at 255. Would using that be acceptable, or should I add a new define, something like #define MAX_SUBKEY_LEN 255 ? If I should add a new define, should I add it to resource.h or directly to main.c? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 9, 2007

Re: Correct VarBstrFromDate for dates between DATE_MIN and 1601

by Alexandre Julliard

Bill Medland <billmedland(a)shaw.ca> writes: > On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote: >> Bill Medland (billmedland(a)shaw.ca) >> Correct VarBstrFromDate for dates between DATE_MIN and 1601 >> > > Has this been rejected out of hand or is it still being considered? Rejected, adding a secret wine-only flag to GetDateFormat is ugly. You need to find another way to do that. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)

by Dmitry Timoshkov

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > Please show me how an unsigned int can > represent values greater than 2^32. This is why a float is used. Of course int can't, but neither float can. Perhaps you confuse it with double? -- Dmitry.

May 9, 2007

Re: Correct VarBstrFromDate for dates between DATE_MIN and 1601

by Bill Medland

On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote: > Bill Medland (billmedland(a)shaw.ca) > Correct VarBstrFromDate for dates between DATE_MIN and 1601 > Has this been rejected out of hand or is it still being considered? Bill

May 9, 2007

Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)

by Vitaly Budovski

Dmitry Timoshkov wrote: > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > >> +struct tinn >> +{ >> + /* Pointer to an element in the list. */ >> + const RGBQUAD *data; >> + /* Distance from the reference element. */ >> + float distance; >> +}; > > Vitaly, why do you keep resending the same patch which uses float > values internally? Again, float neither doesn't allow you to process > larger values, nor is acceptable for speed or adds more flexibility. > I actually discussed this with Alexandre on irc and he said that it was okay to leave it like that. Please show me how an unsigned int can represent values greater than 2^32. This is why a float is used.

May 9, 2007

Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)

by Dmitry Timoshkov

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > +struct tinn > +{ > + /* Pointer to an element in the list. */ > + const RGBQUAD *data; > + /* Distance from the reference element. */ > + float distance; > +}; Vitaly, why do you keep resending the same patch which uses float values internally? Again, float neither doesn't allow you to process larger values, nor is acceptable for speed or adds more flexibility. -- Dmitry.

May 9, 2007

Re: crypt32: remove hardcoded value AT_SIGNATURE from CertContext_SetKeyProvInfo

by Mounir IDRASSI

Hi Alexandre, I analyzed more deeply the code. The test is absolutely correct but the the implementation of the function CertContext_SetKeyProvInfo is definitely incorrect: in MSDN, it's stated that the dwKeySpec field of CRYPT_KEY_PROV_INFO is "the specification of the private key to retrieve". Or, in the code, it's computed as the key specification values supported by the CSP wich is not the same. So, the CertContext_SetKeyProvInfo must be modified to retrieve the key spec of the key related to the certificat, and it should not call CryptGetProvParam. I'm working on that and I'll send a correct patch soon. I analogize for my misunderstanding. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > > Like I said, the test currently passes on Windows, so you can't simply > change it. Tests are supposed to reflect the behavior of Windows, not > of Wine. > >

May 9, 2007

Re: crypt32: remove hardcoded value AT_SIGNATURE from CertContext_SetKeyProvInfo

by Alexandre Julliard

Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > Hi, > This patch removed a hardcoded value (AT_SIGNATURE) from > CertContext_SetKeyProvInfo. It also corrects a corresponding test. Like I said, the test currently passes on Windows, so you can't simply change it. Tests are supposed to reflect the behavior of Windows, not of Wine. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by richardvoigt＠gmail.com

> But I'm open to any ideas you may have as to how we could avoid using > floats, yet not run into the overflow situations so easily. We could > probably use division somewhere but I don't think that's actually any > better performance-wise. It is, when implemented via bit-shifts (very cheap). I know wine is written in pure C, but with a little C++ template magic you should be able to have fixed-point math that acts like floating, only having the compiler take care of the binary point at compile-time using the type system, and emitting only integer operations. Still wouldn't be as efficient as hand-designed fixed-point pumped through the optimizing compiler. I'm pretty sure ints are still much better performance-wise. That article you cited is not telling the whole story; no operation on a modern CPU is executed in a single cycle. The aggregate throughput when considering optimal pipelining may be one float instruction per cycle... but integer operations routinely achieve several (on a Core 2 I believe up to four instructions can be started into the pipelines per cycle, per core). There's also pipeline stalls and flushes to consider, where I believe further investigation will again show much bigger performance hits on floating-point. And no mention of SIMD was made whatsoever, which is capable of the highest performance in every discussion I've seen. Furthermore SIMD has built-in support for things like integer-multiply-keeping-only-the-most-significant-half and multiply-add, at least on x86 architecture, which if I'm not mistaken is still a wine requirement for running x86 PE files. And when you try to save space by using 32-bit float, you lose everywhere. 32-bit floating-point store involves rounding and is slow. As a result, compilers maintain high precision as long as possible, which means you lose repeatability (integer expressions tend to give the same results with or without optimizations, float -- do not). If you go to 64-bit floats, then you should compare against the range of 64-bit integers, which modern CPUs also support at full speed for basic operations.

May 9, 2007

Re: rsaenh: add support for mandatory parameters to RSAENH_CPGetProvParam

by Alexandre Julliard

Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > Hi Alexandre, > The problem comes from the file cert.c in crypt32 dll (the real one, not > the one in tests): at line 1976, the value AT_SIGNATURE is hardcoded in > case for failure of CryptGetProvParam. Without my patch, this function > definitely fail and the hardcoded value is written. So, a more complete > patch would include also a correction to this file. > Question: can a patch include corrections to different dlls? I can > submit it now. It's better to send separate patches for separate dlls. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: rsaenh: add support for mandatory parameters to RSAENH_CPGetProvParam

by Mounir IDRASSI

Hi Alexandre, The problem comes from the file cert.c in crypt32 dll (the real one, not the one in tests): at line 1976, the value AT_SIGNATURE is hardcoded in case for failure of CryptGetProvParam. Without my patch, this function definitely fail and the hardcoded value is written. So, a more complete patch would include also a correction to this file. Question: can a patch include corrections to different dlls? I can submit it now. Cheers Mounir IDRASSI IDRIX - Cryptography and IT Security Experts Alexandre Julliard wrote: > Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > > >> This patch adds support for mandatory parameters in >> RSAENH_CPGetProvParam. It also adds tests for them. >> The mandatory parameters are: PP_UNIQUE_CONTAINER, PP_PROVTYPE, >> PP_KEYSPEC, PP_KEYSET_TYPE, PP_KEYSTORAGE. >> > > Thanks for resending, but unfortunately this breaks make test: > > ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so cert.c && touch cert.ok > cert.c:1215: Test failed: Expected AT_SIGNATURE, got 3 > make: *** [cert.ok] Error 1 > > I know you sent a patch for that test, but since it currently succeeds > on Windows the change can't be right. > >

May 9, 2007

Re: rsaenh: add support for mandatory parameters to RSAENH_CPGetProvParam

by Alexandre Julliard

Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > This patch adds support for mandatory parameters in > RSAENH_CPGetProvParam. It also adds tests for them. > The mandatory parameters are: PP_UNIQUE_CONTAINER, PP_PROVTYPE, > PP_KEYSPEC, PP_KEYSET_TYPE, PP_KEYSTORAGE. Thanks for resending, but unfortunately this breaks make test: ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so cert.c && touch cert.ok cert.c:1215: Test failed: Expected AT_SIGNATURE, got 3 make: *** [cert.ok] Error 1 I know you sent a patch for that test, but since it currently succeeds on Windows the change can't be right. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: [PATCH 05/27] [Kernel32]: ActCtx: now storing path info for app & config in manifest

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > HeapFree(GetProcessHeap(), 0, actctx->assemblies); > - actctx->magic = 0; > + HeapFree(GetProcessHeap(), 0, (void*)actctx->config.info); > + HeapFree(GetProcessHeap(), 0, (void*)actctx->app.info); Please don't cast off const, we are trying to get rid of these warnings. If the strings need to be freed then they cannot be const. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: [PATCH 03/27] [Kernel32]: ActCtx: added basic structures for storing assembly information

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > +static struct assembly* add_assembly(struct actctx* actctx, enum assembly_type at) > +{ > + struct assembly* assembly; > + > + if (!actctx->num_assemblies) > + actctx->assemblies = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct assembly)); > + else > + actctx->assemblies = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + actctx->assemblies, > + (actctx->num_assemblies + 1) * sizeof(struct assembly)); Growable arrays should be grown by a multiple of the current size. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: hnetcfg: [1:10]Define icftype.idl

by Alexandre Julliard

Jeff L <lats(a)yless4u.com.au> writes: > My mistake. I had not got to a point where they were used, so they > were untested. The reason I initialised them in the first place I was > worried about copyright. I since saw something from about there is no > copyright when defining an interface as there is only one way to do > it. How far does that extend? I rewrote these but is possible to > just copy them? Rewriting them is fine, but there's no reason to add unneeded stuff, that doesn't make any difference wrt copyright. > Did you have any more to offer about the other patches? I didn't look much at them, but you need to do more work on the sequence, for instance the makefile changes are in patch 7/10 this means the code in previous patches doesn't even get compiled, that's very wrong. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: rsaenh: fix bug in RSAENH_CPGetProvParam (corrected again)

by Alexandre Julliard

Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> > Date: Wed, 9 May 2007 03:33:45 +0200 > Subject: rsaenh: fix bug in RSAENH_CPGetProvParam Could you please provide a more meaningful subject line to describe your patch? "fix bug" applies to just about every commit... -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: shell32: handle invalid cbSize in Shell_NotifyIcon[AW] (fixed, with testcase)

by Alexandre Julliard

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > As I've understood from wine-devel to catch exceptions in tests I > need to write my own handler. My handler is more compilcated than in > ntdll/tests/exception.c as I can't assume the next instruction after > the invalid one will be a 'ret' but is simplier than wine > __TRY/__EXCEPT as I don't try to filter exception but catch all of > them (I hope this is not a problem with stack guard pages or something > like that). I'm also not using siglongjump but longjmp to be able to > compile it with msvcrt. It won't work when not using msvcrt, and it's really too ugly. That sort of thing might be acceptable in an exception test in ntdll, but not in shell32 tests. Please find another way to write the test that doesn't rely on deliberately triggering a crash. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2007

Re: hnetcfg: [1:10]Define icftype.idl

by Jeff L

Alexandre Julliard wrote: > There's no reason to initialize the enum values explicitly, > particularly since all your values are wrong... My mistake. I had not got to a point where they were used, so they were untested. The reason I initialised them in the first place I was worried about copyright. I since saw something from about there is no copyright when defining an interface as there is only one way to do it. How far does that extend? I rewrote these but is possible to just copy them? Did you have any more to offer about the other patches? Jeff Latimer

May 9, 2007

RE: Resend of Adds NET START to net.exe

by Rolf Kalbermatter

Tim Schwartz wrote: + if(!strcasecmp(operation, "start")) + { + printf("The %s service is starting.\n", service_display_name); + result = StartService(serviceHandle,0,NULL); + CloseServiceHandle(serviceHandle); + if(!result) printf("The %s service failed to start.\n", service_display_name); + else printf("The %s service was started successfully.\n", service_display_name); + + HeapFree(GetProcessHeap(), 0, service_display_name); + CloseServiceHandle(SCManager); + return result; + } + + CloseServiceHandle(serviceHandle); + CloseServiceHandle(SCManager); + HeapFree(GetProcessHeap(), 0, service_display_name); + return 0; +} I think with a little rearrangment of the code and returning result at the end you could avoid duplicating those CloseServiceHandle() and HeapFree() calls. int main(int argc, char *argv[]) { - int ret = 0; if (argc < 2) { printf("The syntax of this command is:\n\n"); - printf("NET [ HELP ]\n"); + printf("NET [ HELP | START ]\n"); return 1; } @@ -35,7 +88,24 @@ int main(int argc, char *argv[]) printf("The syntax of this command is:\n\n"); printf("NET HELP command\n -or-\nNET command /HELP\n\n"); printf(" Commands available are:\n"); - printf(" NET HELP\n"); + printf(" NET HELP NET START\n"); } - return ret; + + if(!strcasecmp(argv[1], "start")) + { + if(argc < 3) + { + printf("Specify service name to start.\n"); + return 1; + } + + if(!net_service(argv[1], argv[2])) + { + return 1; + } + return 0; + } + + + return 0; } Me thinks it would be cleaner to only string test for the command in the main() and pass in a constant you define somewhere to net_service() that specifies the operation to perform. That will allow you to use a switch statement in net_service() and make the code a lot easier to read. Also adding new commands won't make the whole such a big mess as it would now. Also consider to use TRUE and FALSE as return value. This being a Windows tool and not a Unix one it seems clearer to me. Rolf Kalbermatter

May 9, 2007

RE: Drop-in replacement of windows dll's?

by Rolf Kalbermatter

Tom Spear [mailto:speeddymon(a)gmail.com] wrote: >I just remembered reading somewhere (wiki, perhaps?) that the ultimate goal of wine >(aside from documenting the windows api, etc) was to provide open-source drop-in >replacements for windows' core dll's. If that is the case, do we have a framework >setup for building the wine dlls as windows .dll files, so that we could test the >actual status of this? > >I think it would be interesting to see how much of windows will run with wine's dlls >in their current state. Obviously it would be bad to test this with something like >user32.dll, etc, but something like riched32 and maybe some of the common controls >dlls should be ok to test with? There is a winapi/msvcmaker perl script in Wine which can create the Visual C 6.0 make files for most (probably not all anymore since the directory structure changed a lot in the last years) DLLs and support libraries in Wine. Patrik Stridvall put a lot of effort into this and for most non core DLLs it actually did work at some point fairly well. You just had to make sure to either use Perl tools under Windows or configure the Unix directory that contained Wine to be shared to the Windows box with DOS end of line translation since the Visual C 6.0 IDE is very picky about those .dsp and .dsw files and simply crashes in a fatal way (leaving a zombie process you have to kill before you can restart it again) if those files do not look exactly as it expects them. At some point I tried to adapt those tools to some changes in the Wine directory structure but more would have been needed including certain changes to include file order and such to make it work well. In general since there are not many people using that approach it tends to be an uphill battle to keep it working with Wine internal changes and new PSDK releases and I have not followed that anymore for maybe 2 years. I believe that the use of MingW will be probably more successful since it is both used to create the crosstests and for Winlib applications/libraries but I haven't done anything with Winelib and only tried once to build the crosstests. Rolf Kalbermatter

May 9, 2007

Re: Resend of Adds NET START to net.exe

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: >> + if(!buffer_size) >> + { > > The check above is wrong. Please ignore this one. -- Dmitry.

May 8, 2007

Re: Resend of Adds NET START to net.exe

by Dmitry Timoshkov

"Tim Schwartz" <tim(a)sanityinternet.com> wrote: > + GetServiceDisplayName(SCManager, service_name, NULL, &buffer_size); You need to check GetServiceDisplayName return value here and later. > + /* until GetServiceDisplayName() is implemented, buffer_size will always be zero so the service short name will > be used instead */ GetServiceDisplayName *is* implemented. > + if(!buffer_size) > + { The check above is wrong. -- Dmitry.

May 8, 2007

Re: rsaenh: fix bug in RSAENH_CPGetProvParam (corrected)

by Mounir IDRASSI

Hi Juan, Thanks for your explanations. I'm resubmitting the patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Juan Lang wrote: > Yes, certainly. See e.g. recent patches from Paul Vriens to get the tests > succeeding on Win9x. > --Juan >

May 8, 2007

Re: rsaenh: fix bug in RSAENH_CPGetProvParam (corrected)

by Juan Lang

Hi again Mounir, > For CRYPT_SEC_DESCR, my previous implementation of the patch tested for > it with an "&" as you are suggesting. But, after Alexandre Julliard > comment, I no more check the current version of windows and return > always CRYPT_SEC_DESCR in RSAENH_CPGetProvParam. So, that's why I put an > "==" instead to stick with wine implementation. The "&" you used before checked the Windows version in rsaenh.dll, and produced different results based on that. We avoid making our DLLs behave differently based on Windows version, unless applications also expect differing behavior based on Windows versions. Your change in the DLL (not in the tests) appears sound. The "&" I am suggesting is to allow the test to succeed on WinXP and Wine -- where PP_KEYSTORAGE returns precisely CRYPT_SEC_DESCR -- and on Win9x -- where PP_KEYSTORAGE returns CRYPT_SEC_DESCR | other flags we don't care to emulate. > Question: are wine tests meant to be run on Windows? This is the only > case for the test to fail. Yes, certainly. See e.g. recent patches from Paul Vriens to get the tests succeeding on Win9x. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

May 8, 2007

Re: rsaenh: fix bug in RSAENH_CPGetProvParam (corrected)

by Mounir IDRASSI

For CRYPT_SEC_DESCR, my previous implementation of the patch tested for it with an "&" as you are suggesting. But, after Alexandre Julliard comment, I no more check the current version of windows and return always CRYPT_SEC_DESCR in RSAENH_CPGetProvParam. So, that's why I put an "==" instead to stick with wine implementation. Well, I think the two views are equivalent even if my first patch containing the version check seemed more logical to me but ,as I am new to wine, I prefer following the advise of more experienced wine developers. Question: are wine tests meant to be run on Windows? This is the only case for the test to fail. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Juan Lang wrote: > Hi Mounir, > > + case PP_KEYSTORAGE: > + dwTemp = CRYPT_SEC_DESCR; > > This looks fine.. > > + result = CryptGetProvParam(prov, PP_KEYSTORAGE, (LPBYTE)&dwParam, > &dataLen, 0); > + ok(result && dataLen == sizeof(dwParam) && (dwParam == > CRYPT_SEC_DESCR), > + "Expected CRYPT_SEC_DESCR to be set, got 0x%08X\n",dwParam); > > but this test will now fail on Win9x, yes? > > A simple fix would be to check (dwParam & CRYPT_SEC_DESCR) rather than > (dwParam == CRYPT_SEC_DESCR). > > --Juan > > > > ____________________________________________________________________________________ > Don't pick lemons. > See all the new 2007 cars at Yahoo! Autos. > http://autos.yahoo.com/new_cars.html > > >

May 8, 2007

rsaenh: fix bug in RSAENH_CPGetProvParam (corrected)

by Juan Lang

Hi Mounir, + case PP_KEYSTORAGE: + dwTemp = CRYPT_SEC_DESCR; This looks fine.. + result = CryptGetProvParam(prov, PP_KEYSTORAGE, (LPBYTE)&dwParam, &dataLen, 0); + ok(result && dataLen == sizeof(dwParam) && (dwParam == CRYPT_SEC_DESCR), + "Expected CRYPT_SEC_DESCR to be set, got 0x%08X\n",dwParam); but this test will now fail on Win9x, yes? A simple fix would be to check (dwParam & CRYPT_SEC_DESCR) rather than (dwParam == CRYPT_SEC_DESCR). --Juan ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html

May 8, 2007

Re: RSAENH_CPGetProvParam

by Mounir IDRASSI

Actually, the only application I know that uses this expects only CRYPT_SEC_DESCR. So, as you advised, I'll rewrite the patch to remove the version check. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > > >> + case PP_KEYSTORAGE: >> + dwTemp = GetVersion(); >> + /* for Windows NT, 95,98, Me, return CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR >> + * for the others, return CRYPT_SEC_DESCR >> + */ >> + if(dwTemp < 0x80000000 && ((dwTemp & 0x000000FF) != 0x00000004)) >> + dwTemp = CRYPT_SEC_DESCR; >> + else >> + dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR; >> > > You shouldn't add such version checks, unless you have a real life app > that depends on the difference. > >

May 8, 2007

Re: Drop-in replacement of windows dll's?

by Tom Spear

On 5/8/07, Thorsten Kani <beebix(a)gmx.net> wrote: > Hi Tom > > Please read through wwn244 and 245. > > If i remenber correctly, at that time common controls from wine wont > work out of the box. > I had to apply reactos patches to them and had to binary patch sfc.dll > on windows. Thanks for the info. I have sfc completely removed from my windows system (as in sfc.dll doesnt even exist) via a nifty little windows component remover. I didnt expect for the common controls to work out of the box, but it would be interesting to see how close we come. I'll try the various things mentioned here when I get time (dont know when that will be), and post results on the wiki, unless someone beats me to the punch. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 8, 2007

Re: [msi/tests] Properly cleanup after each test

by James Hawkins

On 5/8/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > All files in the destination directory (usually 'Program Files') are cleaned up, > but sometimes not the files/directories in the temp directory. We have to make > sure we have a clean start for every test. > > I've also changed a filename from 'path' to a clearer one (me thinks). > - CHAR path[MAX_PATH]; + CHAR msifile2[MAX_PATH]; CreateDirectoryA("msitest", NULL); CreateDirectoryA("msitest\\msitest", NULL); @@ -1451,9 +1460,9 @@ static void test_concurrentinstall(void) create_database(msifile, ci_tables, sizeof(ci_tables) / sizeof(msi_table)); - lstrcpyA(path, CURR_DIR); - lstrcatA(path, "\\msitest\\concurrent.msi"); - create_database(path, ci2_tables, sizeof(ci2_tables) / sizeof(msi_table)); + lstrcpyA(msifile2, CURR_DIR); + lstrcatA(msifile2, "\\msitest\\concurrent.msi"); + create_database(msifile2, ci2_tables, sizeof(ci2_tables) / sizeof(msi_table)); Please don't change the names of variables. I chose the generic name of path (which is used throught Wine), because that's exactly what the variable contains throughout the functions. Also, msifile2 is a poor choice of a variable name. Thanks, James Hawkins

May 8, 2007

Re: Drop-in replacement of windows dll's?

by Stefan Dösinger

> I think it would be interesting to see how much of windows will run > with wine's dlls in their current state. Obviously it would be bad to > test this with something like user32.dll, etc, but something like > riched32 and maybe some of the common controls dlls should be ok to > test with? There is a windows build available for wine(or used to be) where you can get PE builds of Wine's DLLs. I think Wine's mshtml.dll allows you to run Internet Explorer 6 using the gecko engine on Windows, but I never tried this.

May 8, 2007

(no subject) (WAS: Re: Drop-in replacement of windows dll's?)

by Tom Spear

On 5/8/07, Brian Vincent <brian.vincent(a)gmail.com> wrote: > On 5/8/07, Tom Spear <speeddymon(a)gmail.com> wrote: > > That would be the framework. I appreciate the response. Is this > > something that either now or in the future will be officially > > supported by wine, or even a true goal of wine, or is it more of a > > side project for you and some others? > > It's not an explicit goal, but it does work, and it is a configuration > that we want to keep working. It's just not a configuration that gets > tested every day, so there might be some little issues. Previously > ReactOS was the big consumer of Wine DLL's as PE. Ok, thanks for the input. Thanks to all of the developers for their hard work, and dedication. Unfortunately I am going to have to mute myself on the list (I can hear the sighs of relief now), as I dont think I am getting anywhere trying to get even trivial patches committed. I sent a patch over a week ago to correct a trace message (not the one for winecfg, but one for uninstaller), and it never got committed. Then I get told to send all of my patches to a developer privately for review before I send them to the patches list, and when I send them to that developer, I _basically_ get told that I should bother submitting them. I know I'm not good enough to even write conformance tests right now, which is why I dont work on the major API's or even on the conformance tests, but sheesh, what do I have to do to get one problematic trace fixed? I'll send that patch one more time, just to make sure it got to the list, and I would appreciate someone offering some comment if there is a reason that it should not be committed. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 8, 2007

Re: Drop-in replacement of windows dll's?

by Tom Spear

On 5/8/07, Steven Edwards <winehacker(a)gmail.com> wrote: > On 5/8/07, Tom Spear <speeddymon(a)gmail.com> wrote: > > I just remembered reading somewhere (wiki, perhaps?) that the ultimate > > goal of wine (aside from documenting the windows api, etc) was to > > provide open-source drop-in replacements for windows' core dll's. If > > that is the case, do we have a framework setup for building the wine > > dlls as windows .dll files, so that we could test the actual status of > > this? > > Google around for posts by me and other about build wine with mingw. > I've been meaning to document it for years but never gotten around to > it. You either need to build on windows with a mingw or have two trees > on Linux, one with the host tools and the other configured for the > cross-compiler. That would be the framework. I appreciate the response. Is this something that either now or in the future will be officially supported by wine, or even a true goal of wine, or is it more of a side project for you and some others? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 8, 2007

Re: Drop-in replacement of windows dll's?

by Steven Edwards

On 5/8/07, Tom Spear <speeddymon(a)gmail.com> wrote: > I just remembered reading somewhere (wiki, perhaps?) that the ultimate > goal of wine (aside from documenting the windows api, etc) was to > provide open-source drop-in replacements for windows' core dll's. If > that is the case, do we have a framework setup for building the wine > dlls as windows .dll files, so that we could test the actual status of > this? Google around for posts by me and other about build wine with mingw. I've been meaning to document it for years but never gotten around to it. You either need to build on windows with a mingw or have two trees on Linux, one with the host tools and the other configured for the cross-compiler. Thanks Steven -- 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

May 8, 2007

Re: blizzard conference

by Kai Blin

On Tuesday 08 May 2007 19:27, Tom Spear wrote: > I kinda tend to agree, but the question on their end would be > something along the lines of "with most users using dynamic ip's, how > do you propose that we link the hostname to the current ip?" Personally I don't know if I'd like to have that. I prefer the "least amount of surprise" approach. > One idea would be to setup a cron job that checks ifconfig for the ip > of ethx, and then changes /etc/hosts accordingly. But then how would > you handle users that either a) dont have cron installed, or b) dont > use an ethernet card (i.e. they use wireless, or are hooked to the > cable modem via usb cable, or are using dialup).. Maybe inetd/xinetd > need to be rewritten from the ground up? lol I dont think that will > happen any time soon. I'm not quite sure how (x)inetd would come into play here, or what that would have to do with IP addresses. However, the solution chosen should not be dependent on the name of the interface. > The best bet is for wine to work with what it has and build in support > somehow for each scenario as we come to it. We're currently investigating a couple of possible solutions, Dylan seems to have a good idea using a registry setting. That might work until we can think of something better. Keep an eye out for comments on bug #7929. On a sidenote, I don't really fancy people with no valuable input telling me how to write my code. Please, if you don't know what we're doing here, you're welcome to ask some questions and I'll be happy to explain my rationale, don't come and offer suggestions that are plain useless. No one will have any benefit from that. Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton.

May 8, 2007

Re: [setupapi/tests] SetupQueryInfOriginalFileInformationA is not available on win98

by Paul Vriens

Robert Shearman wrote: > Paul Vriens wrote: >> Hi, >> >> This makes the setupapi tests run again on win98. >> >> Changelog >> SetupQueryInfOriginalFileInformationA is not available on win98 > > Weird. From http://msdn2.microsoft.com/en-us/library/aa377417.aspx: > "Requires Windows Vista, Windows XP, Windows 2000 Professional, Windows > NT Workstation 4.0, Windows Me, Windows 98, or Windows 95" > > Looks like MSDN is wrong about which versions of Windows support this > function and possibly others. > Yeah, again it seems that MSDN is just a nice starting point :-). It's a good thing we have all these tests. Cheers, Paul.

May 8, 2007

Re: hnetcfg: [1:10]Define icftype.idl

by Alexandre Julliard

Jeff Latimer <lats(a)yless4u.com.au> writes: > +typedef enum NET_FW_PROFILE_TYPE_ > +{ > + NET_FW_PROFILE_DOMAIN = 1, > + NET_FW_PROFILE_STANDARD = 2, > + NET_FW_PROFILE_CURRENT = 3, > + NET_FW_PROFILE_TYPE_MAX = 4 > +} NET_FW_PROFILE_TYPE; > + > +typedef enum NET_FW_IP_VERSION_ > +{ > + NET_FW_IP_VERSION_V4 = 1, > + NET_FW_IP_VERSION_V6 = 2, > + NET_FW_IP_VERSION_ANY = 3, > + NET_FW_IP_VERSION_MAX = 4 > +} NET_FW_IP_VERSION; There's no reason to initialize the enum values explicitly, particularly since all your values are wrong... -- Alexandre Julliard julliard(a)winehq.org

May 8, 2007

Re: [PATCH] Uninstaller: Change hardcoded value for maximum subkey name length to a const.

by Dan Hipschman

On Tue, May 08, 2007 at 11:19:16AM -0500, Tom Spear wrote: > static const DWORD MAXSUBKEYNAMELEN = 255; > WCHAR subKeyName[MAXSUBKEYNAMELEN + 1]; I'm not sure what version of C wine is strictly trying to conform to, but it's usually best to go with the lowest common denominator. This is not C89. The const keyword doesn't actually make the variable constant (I know it's not the greatest feature of C). The array size won't be evaluated until runtime, so technically this is a variable length array which weren't added until C99. You can make it C89 simply by using #define instead of declaring it as a variable.

May 8, 2007

Re: RSAENH_CPGetProvParam

by Alexandre Julliard

Mounir IDRASSI <mounir.idrassi(a)idrix.fr> writes: > + case PP_KEYSTORAGE: > + dwTemp = GetVersion(); > + /* for Windows NT, 95,98, Me, return CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR > + * for the others, return CRYPT_SEC_DESCR > + */ > + if(dwTemp < 0x80000000 && ((dwTemp & 0x000000FF) != 0x00000004)) > + dwTemp = CRYPT_SEC_DESCR; > + else > + dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR; You shouldn't add such version checks, unless you have a real life app that depends on the difference. -- Alexandre Julliard julliard(a)winehq.org

May 8, 2007

Re: blizzard conference

by Jesse Allen

On 5/8/07, Tom Spear <speeddymon(a)gmail.com> wrote: > On 5/8/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > > On 5/7/07, Kai Blin <kai.blin(a)gmail.com> wrote: > > > On Tuesday 08 May 2007 05:34, Dan Kegel wrote: > > > > Hey, that's only an hour away, maybe I / Lei / Nigel can drop by. > > > > > > > > But what's the "itchy /etc/hosts bug"? Is that > > > > http://bugs.winehq.org/show_bug.cgi?id=7929 ? > > > > > > I would assume so. I don't know if telling them is going to fix anything, > > > though. For new games, I hope they're not using gethostbyname(gethostname()) > > > anyway. For the other issues that are hitting us with that bug, all seem to > > > be valid winsock programming. I'd rather have someone talk to them about > > > better overall wine compatibility. > > > > > > > > > Right, Diablo 2 does use gethostbyname in a bad way. But I think > > distros should just manage the /etc/hosts file better. > I kinda tend to agree, but the question on their end would be > something along the lines of "with most users using dynamic ip's, how > do you propose that we link the hostname to the current ip?" > > One idea would be to setup a cron job that checks ifconfig for the ip > of ethx, and then changes /etc/hosts accordingly. But then how would > you handle users that either a) dont have cron installed, or b) dont > use an ethernet card (i.e. they use wireless, or are hooked to the > cable modem via usb cable, or are using dialup).. Maybe inetd/xinetd > need to be rewritten from the ground up? lol I dont think that will > happen any time soon. > > The best bet is for wine to work with what it has and build in support > somehow for each scenario as we come to it. > It can be done with the network configuration scripts, at boot, or when you change the configuration. You don't need to periodically scan using cron. (*Yes some connections change frequently, but you can still get it done right when the change occurs.) Since most users don't know what the /etc/hosts file is, the various distros need to be better at managing it. I don't know which ones do better. I use slackware I manage the file myself :D

May 8, 2007

Re: [setupapi/tests] SetupQueryInfOriginalFileInformationA is not available on win98

by Robert Shearman

Paul Vriens wrote: > Hi, > > This makes the setupapi tests run again on win98. > > Changelog > SetupQueryInfOriginalFileInformationA is not available on win98 Weird. From http://msdn2.microsoft.com/en-us/library/aa377417.aspx: "Requires Windows Vista, Windows XP, Windows 2000 Professional, Windows NT Workstation 4.0, Windows Me, Windows 98, or Windows 95" Looks like MSDN is wrong about which versions of Windows support this function and possibly others. -- Rob Shearman

May 8, 2007

Re: blizzard conference

by Tom Spear

On 5/8/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > On 5/7/07, Kai Blin <kai.blin(a)gmail.com> wrote: > > On Tuesday 08 May 2007 05:34, Dan Kegel wrote: > > > Hey, that's only an hour away, maybe I / Lei / Nigel can drop by. > > > > > > But what's the "itchy /etc/hosts bug"? Is that > > > http://bugs.winehq.org/show_bug.cgi?id=7929 ? > > > > I would assume so. I don't know if telling them is going to fix anything, > > though. For new games, I hope they're not using gethostbyname(gethostname()) > > anyway. For the other issues that are hitting us with that bug, all seem to > > be valid winsock programming. I'd rather have someone talk to them about > > better overall wine compatibility. > > > > > Right, Diablo 2 does use gethostbyname in a bad way. But I think > distros should just manage the /etc/hosts file better. I kinda tend to agree, but the question on their end would be something along the lines of "with most users using dynamic ip's, how do you propose that we link the hostname to the current ip?" One idea would be to setup a cron job that checks ifconfig for the ip of ethx, and then changes /etc/hosts accordingly. But then how would you handle users that either a) dont have cron installed, or b) dont use an ethernet card (i.e. they use wireless, or are hooked to the cable modem via usb cable, or are using dialup).. Maybe inetd/xinetd need to be rewritten from the ground up? lol I dont think that will happen any time soon. The best bet is for wine to work with what it has and build in support somehow for each scenario as we come to it. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 8, 2007

Re: blizzard conference

by Jesse Allen

On 5/7/07, Kai Blin <kai.blin(a)gmail.com> wrote: > On Tuesday 08 May 2007 05:34, Dan Kegel wrote: > > Hey, that's only an hour away, maybe I / Lei / Nigel can drop by. > > > > But what's the "itchy /etc/hosts bug"? Is that > > http://bugs.winehq.org/show_bug.cgi?id=7929 ? > > I would assume so. I don't know if telling them is going to fix anything, > though. For new games, I hope they're not using gethostbyname(gethostname()) > anyway. For the other issues that are hitting us with that bug, all seem to > be valid winsock programming. I'd rather have someone talk to them about > better overall wine compatibility. > Right, Diablo 2 does use gethostbyname in a bad way. But I think distros should just manage the /etc/hosts file better.

May 8, 2007

Drop-in replacement of windows dll's?

by Tom Spear

I just remembered reading somewhere (wiki, perhaps?) that the ultimate goal of wine (aside from documenting the windows api, etc) was to provide open-source drop-in replacements for windows' core dll's. If that is the case, do we have a framework setup for building the wine dlls as windows .dll files, so that we could test the actual status of this? I think it would be interesting to see how much of windows will run with wine's dlls in their current state. Obviously it would be bad to test this with something like user32.dll, etc, but something like riched32 and maybe some of the common controls dlls should be ok to test with? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 8, 2007

Re: winegcc: gcc failed

by Eric Pouech

Zalmay A-khaliq a écrit : > Respected Developers of the wine > My name is Zalmay And I am a BCS student. > I have been assigned to port windows(VC++) application into linux. > After a thorough searching and researching I found that "wine:" is the > resource I can use to port a windows 32 bit application to Linux. > I downloaded and installed wine as according to the winehq developers > instruction and every thing went well. > Then I started to test the winelib samples (notepad) to compile on > Redhat Linux 9 according to winelib user guide but in the process I > got the following error message > -------------------------------------------------------------------------------------------------------------------------- > wrc -I. -forsrc.res rsrc.rc > winegcc -mwindows -mno-cygwin -o notepad2.exe.so dialog.o main.o > rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -luuid > dialog.o(.text+0x1a5): In function `DIALOG_StringMsgBox': > : undefined reference to `wnsprintfW' > collect2: ld returned 1 exit status > winegcc: gcc failed. > make: *** [notepad2.exe.so] Error 2 > -------------------------------------------------------------------------------------------------------------- > I will be greatefull to you sir for your help in this. > That how can I overcome these errors and run my application successfully. > thanking you in anticipation > > Zalmay Gul > > ------------------------------------------------------------------------ > Ahhh...imagining that irresistible "new car" smell? > Check out new cars at Yahoo! Autos. > <http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc…> > > ------------------------------------------------------------------------ > > > add -lshlwapi to the command line HTH A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 8, 2007

Re: kernel32: Implement most of CopyFileEx

by Dan Kegel

On 5/7/07, Andrey Turkin <andrey.turkin(a)gmail.com> wrote: > Dan, CopyFileA does not leaks a string (note BOOL flags). Instead first > call use static TEB-based buffer so this is OK, given that recursion is > impossible in this case. Whoops! Sorry, I should have remembered that. (And I meant to insert "seems to" before sending, but forgot.) - Dan

May 8, 2007

Re: volume names of mounted iso images

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > I've looked into the problem a bit more. It seems the only way to add > a dos device is through explorer, by way of hal. This works fine for > a CD in the physical drive, as hal notifies explorer that there is a > CD in the drive, and explorer adds the CD to the list of dos devices. > Mounted ISO files, on the other hand, are not reported by hal, as > loopback devices are not supported by hal. When winecfg, or any other > app for that matter, calls GetVolumeInformation("D:\\"), we attempt to > open the device using CreateFile("\\\\.\\D:"). This fails because the > mounted ISO drive has not been added to the dos device list. No, as long as you have a drive for it the device should be autodetected. It probably fails because you don't have permission to open the corresponding device (something like /dev/loop0). -- Alexandre Julliard julliard(a)winehq.org

May 8, 2007

Re: GetDispParam discriminate b/w VT_EMPTY & zero VT_I4

by Robert Shearman

Misha Koshelev wrote: > Hi, thank you very much for your help. > > I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart > a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this > function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for > that matter; specifically I made a little test to check every single type and find one that could be coerced > to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a > VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 > variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I > am using DispGetParam for everything else. Installer::RegistryValue will probably be different from the vast majority of other functions in the MSI OLE automation interface because registry values themselves have different types. I would expect it to not use DispGetParam and for the following conversions to take place: VT_I4 -> REG_DWORD VT_BSTR -> REG_SZ VT_EMPTY -> REG_NONE? Everything else or just arrays -> REG_BINARY -- Rob Shearman

May 8, 2007

Re: kernel32: Implement most of CopyFileEx

by Kevin Koltzau

On Tuesday 08 May 2007 2:39 am, Andrey Turkin wrote: > Kevin, you are setting file size before copy starts. I'm not sure > Windows does so; also how would that work if destination file system > does not support sparse files? This is what windows does (at least XP) SetEndOfFile does not create a sparse file, a file must be explicitly declared as sparse. http://msdn2.microsoft.com/en-us/library/aa365566.aspx

May 8, 2007

Re: GetDispParam discriminate b/w VT_EMPTY & zero VT_I4

by Michael Stefaniuc

Michael Stefaniuc wrote: > Misha Koshelev wrote: > >>Hi, thank you very much for your help. >> >>I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart >>a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this >>function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for >>that matter; specifically I made a little test to check every single type and find one that could be coerced >>to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a >>VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 >>variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I >>am using DispGetParam for everything else. > > Dumb question: if you already have the variant why don't you use the > V_VT() macro on it to its type? to _get_ its type /me needs more coffee. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 8, 2007

Re: GetDispParam discriminate b/w VT_EMPTY & zero VT_I4

by Michael Stefaniuc

Misha Koshelev wrote: > Hi, thank you very much for your help. > > I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart > a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this > function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for > that matter; specifically I made a little test to check every single type and find one that could be coerced > to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a > VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 > variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I > am using DispGetParam for everything else. Dumb question: if you already have the variant why don't you use the V_VT() macro on it to its type? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 8, 2007

Re: ddraw: DllCanUnloadNow

by Stefan Dösinger

Am Dienstag 08 Mai 2007 02:13 schrieb Christian Gmeiner: > Add support for DllCanUnloadNow and eliminates a FIXME As I understand it, all DirectDraw objects also have to be freed, so you have to check the global ddraw object list too.

May 8, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Vitaly Budovski

Dmitry Timoshkov wrote: > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > >> Both floats and integers have their share of problems. Since the square >> root operation has been removed, we are dealing with much larger >> numbers, potentially larger than can fit into unsigned int without >> looping back around. This is why I think keeping distances as floats is >> a good idea, since they can represent a much larger range of values. > > Not really. sizeof(float) == 4, i.e. same as sizeof(int), but a float > type carries much more information, therefore can't "deal with much > larger numbers". > Yes, but you agree that a float can represent much larger values than 4294967295? This is the point I'm trying to make. >> As >> I mentioned earlier, there is no noticeable performance difference >> between using floats and integers (cheap operations +-*) for the >> distances so I really don't see the reason for all the resistance. > > Even if it looks like a "cheap" operation, floating point operations > are much slower than an integer ones. > Really, the performance difference is not noticeable in this instance. But I'm open to any ideas you may have as to how we could avoid using floats, yet not run into the overflow situations so easily. We could probably use division somewhere but I don't think that's actually any better performance-wise.

May 8, 2007

Re: kernel32: Implement most of CopyFileEx

by Andrey Turkin

Sorry for jumping in, but I have some comments as well. Dan, CopyFileA does not leaks a string (note BOOL flags). Instead first call use static TEB-based buffer so this is OK, given that recursion is impossible in this case. Kevin, you are setting file size before copy starts. I'm not sure Windows does so; also how would that work if destination file system does not support sparse files? Dan Kegel wrote: > Nice to see somebody filling in the gaps like this. > > A few nits based on a superficial reading: > > CopyFileA leaks a string. (I know, it did before your change, too.) > > copy_file_open_dest's interface comment has the wrong name. > > + for(i = 0; i < sizeof(flags) / sizeof(flags[0]); i++) > + { > + if(for_write) { > > Please use the same whitespace conventions as in the > rest of the file (in particular, leave a space after keywords like > for and if). > > + if ((h1 = copy_file_open_source(source, copyFlags & > COPY_FILE_OPEN_SOURCE_FOR_WRITE)) == INVALID_HANDLE_VALUE) > > That line's too long... try to keep them under 80 chars. > > + // FIXME: total_file_size should include the sum of all streams > > Use C comments, not C++ comments. > > + DWORD result = progressRoutine(total_file_size, > total_bytes_transferred, stream_size, stream_bytes_transferred, > + stream_number, > CALLBACK_STREAM_SWITCH, h1, h2, appData); > > Another instance of line longer than 80 chars. (You have several.) > > You don't have a conformance test, nor was there one for CopyFile. > Maybe you should consider writing one, and making sure it passes > both on Wine and Windows. > > Say, what app is this for? > - Dan > > >

May 8, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Dmitry Timoshkov

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > Both floats and integers have their share of problems. Since the square > root operation has been removed, we are dealing with much larger > numbers, potentially larger than can fit into unsigned int without > looping back around. This is why I think keeping distances as floats is > a good idea, since they can represent a much larger range of values. Not really. sizeof(float) == 4, i.e. same as sizeof(int), but a float type carries much more information, therefore can't "deal with much larger numbers". > As > I mentioned earlier, there is no noticeable performance difference > between using floats and integers (cheap operations +-*) for the > distances so I really don't see the reason for all the resistance. Even if it looks like a "cheap" operation, floating point operations are much slower than an integer ones. -- Dmitry.

May 8, 2007

Re: blizzard conference

by Kai Blin

On Tuesday 08 May 2007 05:34, Dan Kegel wrote: > Hey, that's only an hour away, maybe I / Lei / Nigel can drop by. > > But what's the "itchy /etc/hosts bug"? Is that > http://bugs.winehq.org/show_bug.cgi?id=7929 ? I would assume so. I don't know if telling them is going to fix anything, though. For new games, I hope they're not using gethostbyname(gethostname()) anyway. For the other issues that are hitting us with that bug, all seem to be valid winsock programming. I'd rather have someone talk to them about better overall wine compatibility. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton.

May 8, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Vitaly Budovski

Jesse Allen wrote: > On 5/7/07, Duane Clark <fpga(a)pacbell.net> wrote: >> Dmitry Timoshkov wrote: >> > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: >> > >> >>> Now that you got rid of sqrt calls usage of float numbers internally >> >>> doesn't look justified (to me) anymore. >> >>> >> >> Only because in this instance it is used with integer data. It >> doesn't >> >> need to be limited to just integer values. Besides, what would be >> gained >> >> by changing it to integers as you suggest? >> > >> > What would be gained is an additional speed. Since this code is >> supposed >> > to be used to handle palette/color data there is no need to use >> floats at >> > all. >> >> While I cannot vouch for the accuracy, this might be of interest: >> http://lua-users.org/wiki/FloatingPoint >> >> > > Vitaly, > > I think I recommend using just integers, and make this private for > DIBs. Speed is nice for what we can use it for. If someone later needs > the float use, then we can create a separate float version and > included where-ever it's used. There is nothing wrong with having two > versions when each is justified. If you can get your code accepted > I'll probably move it over to the DIB engine eventually. If the > wined3d people want to use it, I could make it available somehow? > > Jesse > Both floats and integers have their share of problems. Since the square root operation has been removed, we are dealing with much larger numbers, potentially larger than can fit into unsigned int without looping back around. This is why I think keeping distances as floats is a good idea, since they can represent a much larger range of values. As I mentioned earlier, there is no noticeable performance difference between using floats and integers (cheap operations +-*) for the distances so I really don't see the reason for all the resistance. As for making this private for dibs, are you suggesting that I move the algorithm into the winex11 directory? I'm certain it could be useful in other areas too. There is a nearest colour function in gdi32 also, so once this patch gets accepted I will probably make use of it there too. Stefan also mentioned a possible use for the algorithm in wined3d.

May 8, 2007

winegcc: gcc failed

by Zalmay A-khaliq

Respected Developers of the wine My name is Zalmay And I am a BCS student. I have been assigned to port windows(VC++) application into linux. After a thorough searching and researching I found that "wine:" is the resource I can use to port a windows 32 bit application to Linux. I downloaded and installed wine as according to the winehq developers instruction and every thing went well. Then I started to test the winelib samples (notepad) to compile on Redhat Linux 9 according to winelib user guide but in the process I got the following error message -------------------------------------------------------------------------------------------------------------------------- wrc -I. -forsrc.res rsrc.rc winegcc -mwindows -mno-cygwin -o notepad2.exe.so dialog.o main.o rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -luuid dialog.o(.text+0x1a5): In function `DIALOG_StringMsgBox': : undefined reference to `wnsprintfW' collect2: ld returned 1 exit status winegcc: gcc failed. make: *** [notepad2.exe.so] Error 2 -------------------------------------------------------------------------------------------------------------- I will be greatefull to you sir for your help in this. That how can I overcome these errors and run my application successfully. thanking you in anticipation Zalmay Gul --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.

May 8, 2007

GetDispParam discriminate b/w VT_EMPTY & zero VT_I4

by Misha Koshelev

Hi, thank you very much for your help. I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for that matter; specifically I made a little test to check every single type and find one that could be coerced to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I am using DispGetParam for everything else. Thanks a lot for your advice. Misha

May 8, 2007

RE: [PATCH] Adds NET START to net.exe

by Rolf Kalbermatter

Rolf Kalbermatter [mailto:r.kalbermatter(a)hccnet.nl] >+ GetServiceDisplayName(SCManager, service_name, NULL, buffer_size); >+ if(!buffer_size) >+ { > >Apart from GetServiceDisplayName() currently not being implemented in Wine, this won't work! >*buffer_size won't be allocated by the function but has to be provided by the caller and its >pointer shouldn't be NULL ever. It should and proabably will just return with an error if it >is a NULL pointer. I actually just tested this and no it does not return an error in that case but simply crashes on Windows XP SP2. As do apparantly many other service functions that take such a parameter. >+ service_display_name = HeapAlloc(GetProcessHeap(), 0, strlen(service_name)); >+ strcpy(service_display_name, service_name); >+ } >+ else >+ { >+ service_display_name = HeapAlloc(GetProcessHeap(), 0, *buffer_size); > >MSDN says: When the function returns, lpcchBuffer contains the size of the service's display >name, excluding the null-terminating character, so your buffer is in fact one character to small. MSDN is quite unclear here. On XP SP2 the function returns this size when the buffer was NULL or the input size was to small. Otherwise it seems to leave this parameter alone! Seems we should start to add some tests for service functions too. This however would probably require a dummy service that can be installed for testing and removed afterwards. Are there any administrator right limitations to installing services in Wine? Rolf Kalbermatter

May 8, 2007

Re: volume names of mounted iso images

by James Hawkins

On 5/7/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > "James Hawkins" <truiken(a)gmail.com> writes: > > > I have a patch ready to go that fixes a problem with the media > > switching code in msi. According to tests and msdn, the presence of a > > required media (usually a CD or DVD) is confirmed using only the > > volume name listed in the Media table of the msi file. The patch > > simplifies the existing media checking code and also fixes a few > > installers. The problem is that, on my system at least, the volume > > name and serial of mounted ISO files (using a loopback device) are not > > available, and any call to GetVolumeInformation returns an empty > > string for the volume name. Because of this, I'm hesitant to get the > > patch committed for fear of restricting installs to only using > > physical media. That would include me, because my CD drive is borked. > > Setting the volume name in winecfg doesn't work, probably because of > > permissions and the fact that the mount is read only. 'Autodetect > > from Device' is apparently not implemented. Can someone enlighten me > > on the situation and possible solutions? > > Autodetect from device is the default behavior, and it should work > fine for ISO images. Probably Wine cannot open the corresponding iso > file for some reason. > I've looked into the problem a bit more. It seems the only way to add a dos device is through explorer, by way of hal. This works fine for a CD in the physical drive, as hal notifies explorer that there is a CD in the drive, and explorer adds the CD to the list of dos devices. Mounted ISO files, on the other hand, are not reported by hal, as loopback devices are not supported by hal. When winecfg, or any other app for that matter, calls GetVolumeInformation("D:\\"), we attempt to open the device using CreateFile("\\\\.\\D:"). This fails because the mounted ISO drive has not been added to the dos device list. We then fallback to the "default strategy" which tries to create the file "D:\\.windows-label", which obviously won't work because D:\ is a read-only filesystem. After all this, GetVolumeInformation returns an empty label and serial. Back in the days of the config file, we used to be able to define drives like so: [Drive D] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "IMALABEL" "Device" = "/dev/cdrom" "Filesystem" = "msdos" Using hal is obviously the better way to go, but this leaves us in the dark for mounted ISO files. Any ideas? I'm attaching the relevant portions of a +all log running winecfg after adding the ISO mount point as drive D:\. Thanks, James Hawkins

May 8, 2007

Re: [3/4] Add tests for console codepages

by Dmitry Timoshkov

"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > + /* Try to set invalid CP */ > + ok(!SetConsoleCP(0), "Shouldn't succeed\n"); > + ok(GetLastError()==ERROR_INVALID_PARAMETER, "GetLastError: expecting %u got %u\n", ERROR_INVALID_PARAMETER, > GetLastError()); > + ok(!SetConsoleOutputCP(0), "Shouldn't succeed\n"); > + ok(GetLastError()==ERROR_INVALID_PARAMETER, "GetLastError: expecting %u got %u\n", ERROR_INVALID_PARAMETER, > GetLastError()); You need to set last error value to something (usually 0xdeadbeef) before calling an API if you're planning to check last error value after the call. Also keeping code lines in a reasonable limit would be nice. -- Dmitry.

May 7, 2007

re: kernel32: Implement most of CopyFileEx

by Dan Kegel

Nice to see somebody filling in the gaps like this. A few nits based on a superficial reading: CopyFileA leaks a string. (I know, it did before your change, too.) copy_file_open_dest's interface comment has the wrong name. + for(i = 0; i < sizeof(flags) / sizeof(flags[0]); i++) + { + if(for_write) { Please use the same whitespace conventions as in the rest of the file (in particular, leave a space after keywords like for and if). + if ((h1 = copy_file_open_source(source, copyFlags & COPY_FILE_OPEN_SOURCE_FOR_WRITE)) == INVALID_HANDLE_VALUE) That line's too long... try to keep them under 80 chars. + // FIXME: total_file_size should include the sum of all streams Use C comments, not C++ comments. + DWORD result = progressRoutine(total_file_size, total_bytes_transferred, stream_size, stream_bytes_transferred, + stream_number, CALLBACK_STREAM_SWITCH, h1, h2, appData); Another instance of line longer than 80 chars. (You have several.) You don't have a conformance test, nor was there one for CopyFile. Maybe you should consider writing one, and making sure it passes both on Wine and Windows. Say, what app is this for? - Dan

May 7, 2007

re: blizzard conference

by Dan Kegel

Hey, that's only an hour away, maybe I / Lei / Nigel can drop by. But what's the "itchy /etc/hosts bug"? Is that http://bugs.winehq.org/show_bug.cgi?id=7929 ? - Dan

May 7, 2007

Re: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam

by Detlef Riekenberg

On Mo, 2007-05-07 at 18:29 +0200, Mounir IDRASSI wrote: > Thanks for your reply. I'm rewriting the patches and sending them back. > > Mounir IDRASSI > IDRIX - Cryptography and IT Security Experts > http://www.idrix.fr > > Detlef Riekenberg wrote: > > I have no Idea about the code, but the missing defines should > > be a seperate patch. > > > > Your idention looks broken. > > Wine is using 4 Space, when possible. > > An Idention of 4, while using Space... (as you can see in the other Code) ---example 1 -- #define PP_KEYSPEC 39 #define PP_ENUMEX_SIGNING_PROT 40 /* Values returned by CryptGetProvParam of PP_KEYSTORAGE */ #define CRYPT_SEC_DESCR 0x00000001 #define CRYPT_PSTORE 0x00000002 #define CRYPT_UI_PROMPT 0x00000004 /* Crypt{Get/Set}KeyParam */ #define KP_IV 1 #define KP_SALT 2 ------ ---example 2 -- #define PP_KEYSPEC 39 #define PP_ENUMEX_SIGNING_PROT 40 /* Values returned by CryptGetProvParam of PP_KEYSTORAGE */ #define CRYPT_SEC_DESCR 0x00000001 #define CRYPT_PSTORE 0x00000002 #define CRYPT_UI_PROMPT 0x00000004 /* Crypt{Get/Set}KeyParam */ #define KP_IV 1 #define KP_SALT 2 ------ ---example 3 -- #define PP_KEYSPEC 39 #define PP_ENUMEX_SIGNING_PROT 40 /* Values returned by CryptGetProvParam of PP_KEYSTORAGE */ #define CRYPT_SEC_DESCR 0x00000001 #define CRYPT_PSTORE 0x00000002 #define CRYPT_UI_PROMPT 0x00000004 /* Crypt{Get/Set}KeyParam */ #define KP_IV 1 #define KP_SALT 2 ------ Sorry for not type my Message so clean as needed. (I'm silent now ...) -- By by ... Detlef

May 7, 2007

Re: ddraw: DllCanUnloadNow

by James Hawkins

On 5/7/07, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > Add support for DllCanUnloadNow and eliminates a FIXME > You need to add (Un)LockModule calls to all the objects in ddraw. See [1] et al. [1] http://www.winehq.org/pipermail/wine-cvs/2005-January/013741.html -- James Hawkins

May 7, 2007

Serial port working with +relay but not normal

by Aleš Rom

Hello, again. Two months ago I posted a message http://www.winehq.org/pipermail/wine-devel/2007-March/054710.html to this list. Now I'm using wine-0.9.36, but the serial port problem is still the same. After port initialization (19200,8N1-it's OK I think) no data is received from serial device. (snip) trace:file:get_dos_device L"COM1" -> "/home/romcek/.wine/dosdevices/com1" trace:file:CreateFileW returning 0x13c trace:comm:GetCommState handle 0x13c, ptr 0x34f9b8 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x34f988 4 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x34f98d 3 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x34f970 16 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_CHARS (nil) 0 0x34f982 6 0x34f914 trace:comm:GetCommState OK trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=1 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:io_control 0x13c IOCTL_SERIAL_SET_BAUD_RATE 0x34f988 4 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_LINE_CONTROL 0x34f98d 3 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_HANDFLOW 0x34f970 16 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_CHARS 0x34f982 6 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_QUEUE_SIZE 0x34f98c 8 (nil) 0 0x34f930 fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 trace:file:ReadFile 0x13c 0x61a2377c 0 0x61a23708 0xede5bc trace:file:WriteFile 0x13c 0xede5d0 18 0x61b327e8 0x61b327d4 trace:file:WriteFile 0x13c 0xede5d0 19 0x61b327e8 0x61b327d4 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 trace:file:ReadFile 0x13c 0x61a2377c 0 0x61a23708 0xede5bc trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 trace:file:ReadFile 0x13c 0x61a2377c 0 0x61a23708 0xede5bc trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 Last two lines repeats... The interesting part is that if I run wine with +relay option, I can transfer data from serial device to PC. Has this set_queue_size message anything to do with this problem? Can someone please help and put me to the right direction. Aleš Rom

May 7, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Jesse Allen

On 5/7/07, Duane Clark <fpga(a)pacbell.net> wrote: > Dmitry Timoshkov wrote: > > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > > > >>> Now that you got rid of sqrt calls usage of float numbers internally > >>> doesn't look justified (to me) anymore. > >>> > >> Only because in this instance it is used with integer data. It doesn't > >> need to be limited to just integer values. Besides, what would be gained > >> by changing it to integers as you suggest? > > > > What would be gained is an additional speed. Since this code is supposed > > to be used to handle palette/color data there is no need to use floats at > > all. > > While I cannot vouch for the accuracy, this might be of interest: > http://lua-users.org/wiki/FloatingPoint > > Vitaly, I think I recommend using just integers, and make this private for DIBs. Speed is nice for what we can use it for. If someone later needs the float use, then we can create a separate float version and included where-ever it's used. There is nothing wrong with having two versions when each is justified. If you can get your code accepted I'll probably move it over to the DIB engine eventually. If the wined3d people want to use it, I could make it available somehow? Jesse

May 7, 2007

RE: [PATCH] Adds NET START to net.exe

by Rolf Kalbermatter

Tim Schwartz [tim(a)sanityinternet.com] wrote: diff --git a/programs/net/net.c b/programs/net/net.c index f77c820..ef08250 100644 --- a/programs/net/net.c +++ b/programs/net/net.c @@ -18,15 +18,66 @@ #include <stdio.h> #include <string.h> +#include <windows.h> + +int net_service(char *operation, char *service_name) { + SC_HANDLE SCManager, serviceHandle; + int result = 0; + unsigned int *buffer_size = NULL; + char *service_display_name = NULL; + + SCManager = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); + if(!SCManager) + { + printf("Couldn't get handle to SCManager.\n"); + return 0; + } + serviceHandle = OpenService(SCManager, service_name, SC_MANAGER_ALL_ACCESS); + if(!serviceHandle) + { + printf("Couldn't get handle to service.\n"); + CloseServiceHandle(SCManager); + return 0; + } + + GetServiceDisplayName(SCManager, service_name, NULL, buffer_size); + if(!buffer_size) + { Apart from GetServiceDisplayName() currently not being implemented in Wine, this won't work! *buffer_size won't be allocated by the function but has to be provided by the caller and its pointer shouldn't be NULL ever. It should and proabably will just return with an error if it is a NULL pointer. + service_display_name = HeapAlloc(GetProcessHeap(), 0, strlen(service_name)); + strcpy(service_display_name, service_name); + } + else + { + service_display_name = HeapAlloc(GetProcessHeap(), 0, *buffer_size); MSDN says: When the function returns, lpcchBuffer contains the size of the service's display name, excluding the null-terminating character, so your buffer is in fact one character to small. + GetServiceDisplayName(SCManager, service_name, service_display_name, buffer_size); + } Your mail client wrapped the patch again it seems. Sending as an attachment might work better. Rolf Kalbermatter

May 7, 2007

Re: Initial Mixer support on Mac OS X (1/7)

by Emmanuel Maillard

Hi, I will see whether I have time this week to check this on winecoreaudio.drv. Emmanuel Le 6 mai 07 à 13:37, Dmitry Timoshkov a écrit : > "Emmanuel Maillard" <mahanuu(a)free.fr> wrote: > >> Changelog : >> - inital Mixer support on Mac OS X >> - find all lines and initialize controls > > Could you please while you are working on winecoreaudio.drv make > all public > entry points (CoreAudio_widMessage, CoreAudio_wodMessage, > CoreAudio_midMessage, > CoreAudio_modMessage) 64-bit safe (by using a proper DRVCALLBACK > prototype for > the driver callback, and using proper data types for passing in/out > parameters > around)? > > -- > Dmitry.

May 7, 2007

Re: blizzard conference

by Tom Spear

On 5/7/07, Bryan Haskins <kingofallhearts999(a)gmail.com> wrote: > Oi, If only I could go =[ > > I would like to point out to any players who would go there "on the behald > of the wine project" wink wink nudge nudge, that they generally give away > some sick in game prizes! If you go and arent a player, you could easily > sell the codes they give out (at least last time) for a heap of cash to go > towards the project in some form. I'm definitely going to try to go, but I can't promise anything as yet, due to that being a 2-day drive and on a Friday and Saturday, and also due to having to schedule it with work first. Once (and if) I confirm that I am going, could someone fill me in on the details of the /etc/hosts bug, or point me to a link that has all of the information I'll need, and I'll be happy to mention it. If you would rather someone more experienced with developing bring it up, just let me know, and I'll keep my mouth shut. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 7, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Duane Clark

Dmitry Timoshkov wrote: > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > >>> Now that you got rid of sqrt calls usage of float numbers internally >>> doesn't look justified (to me) anymore. >>> >> Only because in this instance it is used with integer data. It doesn't >> need to be limited to just integer values. Besides, what would be gained >> by changing it to integers as you suggest? > > What would be gained is an additional speed. Since this code is supposed > to be used to handle palette/color data there is no need to use floats at > all. While I cannot vouch for the accuracy, this might be of interest: http://lua-users.org/wiki/FloatingPoint

May 7, 2007

Re: dbghelp[2]: Speed up vector_add. Remove no longer needed pool_realloc.

by Eric Pouech

Markus Amsler a écrit : > Thanks to Eric for the idea. > --- > dlls/dbghelp/dbghelp_private.h | 3 +- > dlls/dbghelp/storage.c | 47 > ++++++++++++++------------------------- > 2 files changed, 18 insertions(+), 32 deletions(-) Markus, could you try what gives starting the bucket array size at 2, 4, or 8 instead of 1 ? given the amount of memory improvement we have with this patch, this would certainly help the large debug file (and perhaps hurt a little the small ones) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 7, 2007

Re: blizzard conference

by Bryan Haskins

Oi, If only I could go =[ I would like to point out to any players who would go there "on the behald of the wine project" wink wink nudge nudge, that they generally give away some sick in game prizes! If you go and arent a player, you could easily sell the codes they give out (at least last time) for a heap of cash to go towards the project in some form. On 5/7/07, Robert Millan <rmh(a)aybabtu.com> wrote: > > > Sorry for the OT, but I thought this might be of your interest, > considering > some of the Blizzard game developers will attend: > > http://www.blizzard.com/press/070412.shtml > > Maybe someone in California feels like dropping by to do some lobbying > about > that itchy /etc/hosts bug? :-) > > -- > Robert Millan > > My spam trap is honeypot(a)aybabtu.com. Note: this address is only intended > for spam harvesters. Writing to it will get you added to my black list. > > > -- Cheers, Bryan

May 7, 2007

Re: [5/5] D3D: Move Clippers from DDraw to wined3d

by H. Verbeet

On 07/05/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Needed to handle them properly there What exactly was the problem?

May 7, 2007

blizzard conference

by Robert Millan

Sorry for the OT, but I thought this might be of your interest, considering some of the Blizzard game developers will attend: http://www.blizzard.com/press/070412.shtml Maybe someone in California feels like dropping by to do some lobbying about that itchy /etc/hosts bug? :-) -- Robert Millan My spam trap is honeypot(a)aybabtu.com. Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list.

May 7, 2007

Re: "Installer already running"

by Tom Spear

On 5/7/07, Pavel Troller <patrol(a)sinus.cz> wrote: > > Hi Tom, > there is the installer file. > With regards, Pavel Troller Hi Pavel, I looked into the file. It is a 7-zip compressed Nullsoft installer. What that means is that if you decide to file a bug on bugzilla (highly recommended), make sure to include that information in the summary or body of the bug somewhere, so that others with the same problem with this type of installer can find your bug easily, and so that developers who are looking for this type of installer to test patches against can contact you to get it... With that being said: I downloaded the file on my linux box, and was able to run it all the way up to the point of hitting next to actually install, without any problems. Here are a couple of things you can try: - Run wineboot to make sure all runonce entries are cleared from the registry, and then restart the computer, to make sure that all running copies of wine are cleared. - If that does not work, rename ~/.wine to something like ~/.wine.bak and then run winecfg and re-setup all of your options. Then try running the PhysX installer again. If that does not fix it, you will probably have to do a fully clean install of wine, where you need to delete all copies of wine on your system, and everything that you have installed in wine (I'm trying to avoid you having to do this, for obvious reasons), and then reinstall it all, starting with JTF2 and the PhysX drivers. If that still does not fix the problem, then there is a misconfig somewhere else in the system, or you somehow have a stale wineserver process hanging around.. Hope that helps, and maybe someone else has some other things for you to try..? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 7, 2007

Re: "Installer already running"

by Tom Spear

On 5/7/07, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Pavel Troller wrote: > >>> it chokes on SECDRV.SYS). > > That is all you need to see to know this is SafeDisk. >> (for anybody who would like to >> try this too, the game itself has to be patched by nocd crack first, otherwise >> it chokes on SECDRV.SYS). If you read that part again, it says the game itself needs the patch. He is writing about an installer issue with the installer for the PhysX card. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 7, 2007

Re: "Installer already running"

by Pavel Troller

> Pavel Troller wrote: > >>> it chokes on SECDRV.SYS). > > That is all you need to see to know this is SafeDisk. > > Vitaliy. > Hi Vitaliy, sorry but you are wrong. If you want to judge the others, please be so kind and read at least the sentence in which your keyword appears. I'm quoting myself: > (for anybody who would like to try this too, the game itself has to > be patched by nocd crack first, otherwise it chokes on SECDRV.SYS). This sentence is just a quick note for those, who would eventually like to reproduce my problem as a whole. However, it's not related to the problem I was asking about. I know you are working very hard on wine; I would like to thank you as well as all the others million times and over and over :-). However, please, if you decide to reply to a mail, please don't use grep or any other kind of keyword match instead of reading at least the most important parts :-). With regards, Pavel Troller

May 7, 2007

Re: wine-patch implement ClassFactory_LockServer in browseui dll

by James Hawkins

On 5/7/07, Bernard Ladenthin <bernard(a)ladenthin.net> wrote: > Hello, > sorry about the patch before, it was the false one. > > This one is the right. > Your first patch was already committed, so you might want to send in another patch fixing the mistake. -- James Hawkins

May 7, 2007

Re: "Installer already running"

by Vitaliy Margolen

Pavel Troller wrote: >>> it chokes on SECDRV.SYS). That is all you need to see to know this is SafeDisk. Vitaliy.

May 7, 2007

Re: "Installer already running"

by Pavel Troller

Hi Tom! > On 5/7/07, Pavel Troller <patrol(a)sinus.cz> wrote: > >Dear Vitaliy, > > I'm very sorry for my total stupidity, ignorance and maybe even debility, > >but I can't find nothing common between Bug# 219 and my question. > > The PhysX installer doesn't check for any *ICE components present in the > >system, doesn't output any strings to wine console, which are described in > >the bug desc, and the message "The installer is already running", which is > >typical for my problem, is not mentioned in the bug description at all. > > So please be patient with me and explain me in the deeper detail, why are > >you thinking that I'm asking for #219. > > With regards, Pavel Troller > > I agree, this is not an issue with Copy Protection, this is an issue > where the installer thinks that the installer is already running. > > A couple of questions > > -Have you tried running the PhysX installer manually, after the game > is installed? Yes. It's stated in my original mail. The results are identical. > -Have you tried running wineboot to make sure any run entries are > cleared and then running the PhysX installer manually? No, because the game installer neither didn't warn me that the windows will reboot, nor asked me to do it manually. And I tried to install the PhysX driver on another machine, independently on the previous attempts on the first one, and it also did exactly the same. > -Any idea what brand of installer it is (InstallShield, MSI, WISE, or > some other)? If you aren't sure, I can always take a look at the > installer, if you will bzip and send to me (less than 10mb). The package is provided as a single executable file. It doesn't identify itself, it just pops up the dialog that it's already running. The only trace is the window title, which says "AGEIA PhysX V2.5.1 Setup". I think that it's something special, not a classic brands of installers. I will send you the file privately. > > -- > Thanks > > Tom > With regards, Pavel Troller

May 7, 2007

Re: rsaenh: fix critical bug in read_key_container

by Mounir IDRASSI

I'll take you advice from now and I apologize for any annoyance caused by my previous emails. I would also thank all the people who took time to review our patches and sent me their comments/remarks. Regards, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Vitaliy Margolen wrote: > No, that adds more pollution to the place which should not have it. > Please send all patches to wine-patches(a)winehq.org. If you think that > all of your patches need work, then don't send them at all. Do this > extra work. And when you have a patch that _you_ think is as good as it > can be, send it to wine-patches(a)winehq.org. > > Vitaliy Margolen. >

May 7, 2007

Re: Linuxtag 2007 in Berlin

by Stephan Hermann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am Wed, 25 Apr 2007 17:44:57 +0200 schrieb Stefan Munz <stefan.munz(a)itomig.de>: > Hi, > > finally we got a Wine booth at Linuxtag 2007 in Berlin. Everybody who > wants to participate is welcome. I have to order exhibitor passes, so > anyone you wants to help out please contact me :-) > > And maybe if anyone has a draft for Wine-posters, this would help too. If someone is interested in talking about Wine and Ubuntu Colaboration, please do. I'll be at the Kubuntu/Ubuntu booth during Linuxtag (or somewhere near FAI booth of Debian). Just FYI :) Cu @ LT 2007 in Berlin - -- Stephan Hermann Ubuntu Developer http://launchpad.net/~shermann shermann(a)ubuntu.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGP183wYnnM8CY76gRAoZRAJ9oY6sP5UQnTDIkzBzzT7X4wp92WgCfQeGA JoLkwXXwLzsj8AKygOo01W8= =TjQE -----END PGP SIGNATURE-----

May 7, 2007

Re: rsaenh: fix critical bug in read_key_container

by Vitaliy Margolen

No, that adds more pollution to the place which should not have it. Please send all patches to wine-patches(a)winehq.org. If you think that all of your patches need work, then don't send them at all. Do this extra work. And when you have a patch that _you_ think is as good as it can be, send it to wine-patches(a)winehq.org. Vitaliy Margolen. Mounir IDRASSI wrote: > yes but I prefer sending patches first to the devel list for comments. > Once no major issue is raised, I send it to the patches list. I think > this helps prevent polluting the patches list. > > Mounir IDRASSI > IDRIX - Cryptography and IT Security Experts > http://www.idrix.fr > > Stefan Dösinger wrote: >> Hi, >> Patches should go to wine-patches(a)winehq.org :-) >> > > >

May 7, 2007

Re: rsaenh: fix critical bug in read_key_container

by Mounir IDRASSI

yes but I prefer sending patches first to the devel list for comments. Once no major issue is raised, I send it to the patches list. I think this helps prevent polluting the patches list. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Stefan Dösinger wrote: > Hi, > Patches should go to wine-patches(a)winehq.org :-) >

May 7, 2007

Re: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam

by Mounir IDRASSI

Thanks for your reply. I'm rewriting the patches and sending them back. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Detlef Riekenberg wrote: > I have no Idea about the code, but the missing defines should > be a seperate patch. > > Your idention looks broken. > Wine is using 4 Space, when possible. >

May 7, 2007

Re: rsaenh: fix critical bug in read_key_container

by Stefan Dösinger

Hi, Patches should go to wine-patches(a)winehq.org :-)

May 7, 2007