May 2007 - wine-devel

Re: dbghelp[2]: Speed up vector_add. Remove no longer needed pool_realloc.
by Detlef Riekenberg 07 May '07

07 May '07

On Mo, 2007-05-07 at 05:46 +0200, Markus Amsler wrote: > + /* Don't even try to resize memory. Memory gain would be > minimal > + but speed hit significant with big vecotrs. * I have no Idea about the code, but found this Typo: vecotrs => vectors -- By by ... Detlef

1 0

Re: crypt32: fix a wrong test
by Laurent Vromman 07 May '07

07 May '07

> - ok(info->dwKeySpec == AT_SIGNATURE, > + ok(info->dwKeySpec == (AT_SIGNATURE|AT_KEYEXCHANGE), > "Expected AT_SIGNATURE, got %d\n", info->dwKeySpec); It could be a good idea to correct the error text "Expected AT_SIGNATURE" to add AT_KEYEXCHANGE in it. Laurent Vromman On Mon, 07 May 2007 16:05:35 +0200, Mounir IDRASSI <mounir.idrassi(a)idrix.fr> wrote: > Hi, > This patch corrects a test in crypt32 that was incorrectly written to > accommodate the bug in rsaenh dll we corrected in our previous patch. > > Mounir IDRASSI > IDRIX - Cryptography and IT Security Experts > http://www.idrix.fr > > >

1 0

crypt32: fix a wrong test
by Mounir IDRASSI 07 May '07

07 May '07

Hi, In the tests of the crypt32 dll, a test was written in a way that accommodates the bug we have corrected previously in the patch for rsaenh dll. The attached small patch corrects the value expected from this test to be consistent with the correct output. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From b2059ab820a37ef3129cd52c4a4048c9081d3bb9 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Mon, 7 May 2007 15:33:36 +0200 Subject: crypt32: fix a wrong test --- dlls/crypt32/tests/cert.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/crypt32/tests/cert.c b/dlls/crypt32/tests/cert.c index 345c9f5..bec65de 100644 --- a/dlls/crypt32/tests/cert.c +++ b/dlls/crypt32/tests/cert.c @@ -1212,7 +1212,7 @@ static void testCreateSelfSignCert(void) "Unexpected key container\n"); ok(!lstrcmpW(info->pwszProvName, MS_DEF_PROV_W), "Unexpected provider\n"); - ok(info->dwKeySpec == AT_SIGNATURE, + ok(info->dwKeySpec == (AT_SIGNATURE|AT_KEYEXCHANGE), "Expected AT_SIGNATURE, got %d\n", info->dwKeySpec); } HeapFree(GetProcessHeap(), 0, info); -- 1.4.4.2

1 0

[try 2] Move console input/output codepages to server - what's wrong?
by Kirill K. Smirnov 07 May '07

07 May '07

Hi, A week ago I've sent a patch which fixes console input/output codepages handling. http://www.winehq.org/pipermail/wine-patches/2007-April/038429.html It is still not applied, so please, explain, what is wrong with it? It even fixes 2 tests: $wine kernel32_test.exe.so process before: process: 510 tests executed (0 marked as todo, 6 failures), 0 skipped. after: process: 510 tests executed (0 marked as todo, 4 failures), 0 skipped. Thanks, -- Kirill

1 1

Can we catch access violation exceptions in tests?
by Mikołaj Zalewski 07 May '07

07 May '07

I'm trying to write a tests for invalid cbSize in Shell_NotifyIcon. The behaviour under Windows XP is to assume in such a case that the size is NOTIFYICONDATA_V1_SIZE. AFAIK Shell_NotifyIcon doesn't provide a way to read icon data to check that the data introduced after Win95 is not modified. So I'm using VirtualAlloc+VirtualProtect to make Shell_NotifyIcon fail if it tries to access this data. I'd like to catch the exception to make a tests fail if something goes wrong instead of crashing the testsuite. However __try doesn't work under gcc and using wine/exception.h gives an unresolved symbol '__wine_handle_exception'. Is it possible to catch exceptions in tests? Mikolaj Zalewski

3 2

Re: Implements NET START to control system services
by Dmitry Timoshkov 07 May '07

07 May '07

"Tim Schwartz" <tim(a)sanityinternet.com> wrote: > #include <stdio.h> > #include <string.h> > +#include <windows.h> > + > +int net_service(char *operation, char *service_name); It's better to properly arrange the code to avoid forward declarations. > +int net_service(char *operation, char *service_name) > +{ > + SC_HANDLE SCManager, serviceHandle; > + int result = 0; > + char service_display_name[4096]; service_display_name should be queried and dynamically allocated. > + > + 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"); > + return 0; > + } You are leaking SCManager handle here. > + > + if(!GetServiceDisplayName(SCManager, service_name, > service_display_name, NULL)) Are you sure that last parameter can be NULL here? MSDN seems to disagree. Also did you test your code under Windows? This kind of application can be and should be IMO developed/tested in Windows. > + 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); > + return result; > + } > + > + return 0; > } You are leaking the SCManager handle here as well, and both serviceHandle and SCManager are leaked if operation is not "start". Also the patch was wrapped by your mailer. -- Dmitry.

1 0

Re: [New]: Added wrapper dll for ct-api (CardTerminal API)
by Steven Edwards 07 May '07

07 May '07

I forgot to mention the inclusion of config.h and port.h should come before other headers in your source. Thanks Steven On 5/6/07, Christian Eggers <ceggers(a)gmx.de> wrote: > Hello, > > this wrapper dll permits access to chipcard readers which provides a ct-api (CardTerminal > API). > -- 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

1 0

Re: [New]: Added wrapper dll for ct-api (CardTerminal API)
by Steven Edwards 07 May '07

07 May '07

On 5/6/07, Christian Eggers <ceggers(a)gmx.de> wrote: > Hello, > > this wrapper dll permits access to chipcard readers which provides a ct-api (CardTerminal It looks really good. A couple of quick comments for future patches. Please use a standard LGPL license header in your patch for the header, don't use C++ comments and you don't have to add a Changelog entry. Alexandre's patch tools automatically adds it from your email/changeset. Thanks -- 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

1 0

Re: msi [3/4]: Set the text limit of the edit control if the limit isgiven
by Dmitry Timoshkov 07 May '07

07 May '07

"James Hawkins" <truiken(a)gmail.com> wrote: > + text = MSI_RecordGetString( rec, 10 ); > + if ( text ) > + { > + begin = strchrW( text, '{' ); > + end = strchrW( text, '}' ); Perhaps it would be cleaner to use end = strchrW( begin, '}' ); -- Dmitry.

1 0

Re: Fix keyboard focus issues
by Dmitry Timoshkov 07 May '07

07 May '07

"Bernhard Rosenkraenzer" <bero(a)arklinux.org> wrote: > The attached patch fixes bug #1798 (also known as 6986, 4042, 2819, 2149, and > 2926) -- some fullscreen applications not getting focus correctly. As I already pointed out in the bug using window/screen width in comparisons should allow to avoid that -1/+1 shift in left/top coordinate. -- Dmitry.

1 0

Old Autocad trials?
by Dan Kegel 06 May '07

06 May '07

http://wiki.winehq.org/LinuxApplicatonRequestSurvey says that Autocad is the #2 most requested application on Linux. The latest version might be a challenge to support, since it depends on .net 2.0, but we could start by supporting older versions. http://appdb.winehq.org/appview.php?iAppId=86 shows that R14 ran ok at one point, and I've seen a tutorial for how to run 2000 on wine, so there's hope. I couldn't find any source of Autocad R14 or '97, but looking on amazon.com I think books with trial CD-ROMs are available from autocad 2000 on (if only for LT and other hacked down variants, but I'm not picky). Before I go wild buying old autocad books from Amazon, does anyone out there have old copies of Autocad (full or trial) they'd be willing to send me for testing? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

Re: shell32: check cbSize in Shell_NotifyIconW to make apps sending garbage work (fixes bug #7940)
by Dmitry Timoshkov 06 May '07

06 May '07

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > + /* The validation is also done in explorer. However we must also do it > + * on the client size so that WM_COPYDATA doesn't crash the application > + */ > + if (nid->cbSize != NOTIFYICONDATAW_V1_SIZE && > + nid->cbSize != NOTIFYICONDATAW_V2_SIZE && > + nid->cbSize != NOTIFYICONDATAW_V3_SIZE && > + nid->cbSize != sizeof(NOTIFYICONDATAW)) > + { > + WARN("Invalid size\n"); > + return FALSE; > + } Do you have a test case for this? -- Dmitry.

2 1

change generic.ppd file
by Alisson Gomes 06 May '07

06 May '07

Mrs, I do can recompile wine with change generic.ppd file? only change the generic.ppd? Or exist a version of wine i can configure? thanks, Alisson Gomes

2 1

Re: Console output with different codepages - the result.
by Kirill K. Smirnov 06 May '07

06 May '07

> just a dummy question... does the different fonts your tests refer to > have all the glyphs required ? (or said differently, isn't this a font > issue about the required glyphs for russian ?) > A+ By default (in 866 OEM codepage) wine console renderer behaves just like windows does, the difference appears iff I change codepage to 1251 ANSI. So it is not missing glyphs problem - I do not change font while changing codepage. -- Kirill

1 0

dbghelp performance
by Markus Amsler 06 May '07

06 May '07

I've played around with dbghelp performance. My test case was breaking at an unknown symbol (break gaga) while WoW was loaded in the debugger (wine winedbg WoW.exe). The time was hand stopped, memory usage measured with ps -AF and looked at the RSS column. Test Time(s) Memory Usage(MB) current git 4.5 54 pool_heap.patch 4.5 63 process_heap.patch 4.5 126 insert_first.patch 4.5 54 current git, r300 115 146 pool_heap.patch, r300 17 119 process_heap.patch, r300 17 260 insert_first.patch, r300 27 167 insert_first is the patch from Eric Pouech. r300 means with the debug version of Mesas r300_dri.so, which has a total compilation unit size of around 9.2M (compared to the second biggest Wines user32 with 1.1M). Conclusions: - current git wins with small debug files (<2M or so), pool_heap wins with bigger files. insert_first, process_heap are out. - small pools have less memory overhead than small heaps - big pools have more memory overhead than big heaps. - big pools are a lot slower than big heaps. IMO the best results would give removing the pools (like in process_heap) and freeing unused memory manually, the other way round it was allocated. But at a first glance it looks like quite a bit of work, which I'm not sure is worth the result. I think the best approach would be to code some destroy functions in storage.c which would free the allocated vector, sparse_array and hash_table memory. And then gradually replace pool_alloc calls with HeapAlloc/HeapFree pairs. Markus

2 6

Re: Initial Mixer support on Mac OS X (1/7)
by Maarten Lankhorst 06 May '07

06 May '07

"Emmanuel Maillard" <mahanuu(a)free.fr> wrote: > Changelog : > - inital Mixer support on Mac OS X > - find all lines and initialize controls Looking through it you seemed to have used OSS as base, which means some of the comments on my earlier code also apply to your code: - 64 bits safety (use DWORD_PTR's) - the code that normalizes to 65535 should be changed by a MulDiv if possible. Also if coreaudio has a way to notify the sound driver that a mixer control has changed you might want to notify the program, see elem_callback in alsa's mixer, and alsa's mix_open. Cheers, Maarten

1 0

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)
by Dmitry Timoshkov 06 May '07

06 May '07

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > Make use of the Triangle Inequality Nearest Neighbour algorithm to find the > nearest colour more efficiently than a simple linear search. The improvements > are most noticeable with a palette of 256 colours. Testing shows approximately > 3-4x performance increase for 256 colours. Now that you got rid of sqrt calls usage of float numbers internally doesn't look justified (to me) anymore. -- Dmitry.

1 0

InternetCanonicalizeURLA / W - Missing some flags?
by Chris Howe 06 May '07

06 May '07

I noticed a FIXME cropping up in the logs when working on EQ2, related to InternetCanonicalizeURL not fully parsing the flags that it is called with. Looking a bit closer, it offloads the grunt work to UrlCanonicalize anyway, and the missing flags seem to have analogs defined for UrlCanonicalize to use, and adding support for them makes the message go away: no problems that I can see, either. However, I seem to be having trouble running the test for wininet, as it just hangs for me (before I made the alterations, that is)... would somebody care to check that the attatched patch is correct?

1 0

RE: Initial Mixer support on Mac OS X (2/7)
by Amy Fox 06 May '07

06 May '07

oi >From: Emmanuel Maillard <mahanuu(a)free.fr> >Reply-To: wine-devel(a)winehq.org >To: wine-patches(a)winehq.org >Subject: Initial Mixer support on Mac OS X (2/7) >Date: Sun, 6 May 2007 11:53:48 +0200 > >Changelog : > - implement MIX_Open and MIX_GetNumDevs > ><< 0002-implement-MIX_Open-and-MIX_GetNumDevs.patch >> > _________________________________________________________________ Reserve your place in history - Email Britain! http://www.emailbritain.co.uk/

1 0

Re: winmm: Use a pipe for timer
by Steven Edwards 06 May '07

06 May '07

Hi, On 5/5/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > This avoids expensive server calls in a time critical timer. > > Without priority patch it drops stddev in winmm timer tests to < 2 ms as > compared to ~7 ms before. With priority patch it drops to < .20 ms. > > Backwards compatibility code is kept just in case. Even though backward compatibility is kept I worry about a couple of things. A lot of work was done on WinMM to make it portable to windows for testing and I don't like seeing new code to tie it back to unix even with the old code left in place. Also shouldn't there be a way to speed up the server performance instead? If this is accepted here then what about other areas of wine such as directx where timers similar may be used? Should we make this sort of patch global? I don't think so but then I don't know enough to no what the proper fix would be. Thanks -- 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

3 2

Writing an interactive test
by Andrew Riedi 06 May '07

06 May '07

I would like to know if there is a way to write an interactive test for my cursor code (will add it to dlls/d3d9/tests). The biggest problem I am having is trying to keep a window drawn. Of course I could use sleep(), but then that soft-freezes my computer. I would like to make it part of our test-suite if possible. Perhaps I should use some sort of loop? Anyhow, thanks for any response. -- Andrew Riedi

1 0

Newbie question: WineLib DLLs
by Christian Eggers 05 May '07

05 May '07

Hello, I've created a (very) simple wine dll as described in "Building WineLib DLLs". This dll is a wrapper for the "ct-api" interface used for chipcard readers [1]. With this dll it's possible to use HBCI chipcards (for german online banking, [2]) together with Windows homebanking applications (for example "StarMoney", [3]). Usage: card reader - ct-api driver (hw specific) - symlink (libctapi.so) - wine dll - Windows application Problem: The dll is linked against an external (non-wine) shared lib. How can my dll be integrated in wine without forcing other users to get the external library in order to compile wine? Regards Christian [1] https://www.secure.trusted-site.de/Download/CTAPI/CTAPI11EN.PDF [2] http://www.hbci-zka.de/english/index.htm [3] http://www.starmoney.de

2 1

RE: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.
by Vitaliy Margolen 05 May '07

05 May '07

Vitaly Budovski wrote: > Make use of the Triangle Inequality Nearest Neighbour algorithm to find the > nearest colour more efficiently than a simple linear search. The improvements > are most noticeable with a palette of 256 colours. Testing shows approximately > 3-4x performance increase for 256 colours. > --- Overall idea looks good, however the big problem with it is use of float point numbers. Fortunately you can get rid of them and use integers instead. Because you never use the distance in the calculations, but only to compare against other distances, you can skip "sqrt" and just compare squares, as the original code does. That will give you even more speed improvements. Few more nitpicks about this and other patches in the series: > +static int compare_distance(const void *left, const void *right) > +{ > + const struct tinn *l = left; > + const struct tinn *r = right; Please don't use void pointers. Use typed pointers, especially that you cast them to a hard-coded type. > +const void *init_tinn(struct tinn *dest, const void *buf, size_t num, > + size_t size, float (*distance)(const void *, const void *)) > +{ > + size_t i; > + size_t ref = rand() % num; I'm not so sure using random reference point really necessary. > +static struct tinn tinnPalette[256]; > + This won't work well with multi-threaded apps. You probably should make it on the stack for each X11DRV_DIB_SetImageBits_* function. Especially that some need only 2 elements. Btw, how big of the gain/loss whill there be for 1-bit and 4-bit DIBs? > + q.rgbRed = srcval.peRed; > + q.rgbGreen = srcval.peGreen; > + q.rgbBlue = srcval.peBlue; Looks much better, if written as: q = srcval; > - ((srcval >> 7) & 0xf8) | /* r */ > - ((srcval >> 12) & 0x07), > - ((srcval >> 2) & 0xf8) | /* g */ > - ((srcval >> 7) & 0x07), > - ((srcval << 3) & 0xf8) | /* b */ > - ((srcval >> 2) & 0x07) ) << (7-(x&7)) ); > + > + q.rgbRed = ((srcval >> 7) & 0xf8) | > + ((srcval >> 12) & 0x07); > + q.rgbGreen = ((srcval >> 2) & 0xf8) | > + ((srcval >> 7) & 0x07); > + q.rgbBlue = ((srcval << 3) & 0xf8) | > + ((srcval >> 2) & 0x07); What happened to the comments and alignment? Vitaliy Margolen.

3 4

Re: Fix xcopy so output is either unicode (console) or oem (file)
by Kirill K. Smirnov 05 May '07

05 May '07

В сообщении от 23 апреля 2007 16:11 вы написали: > "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > >> >> The written strings in 866 and 1251 code pages are only readable > >> >> when output console code page matches the string encoding. > >> > > >> > This is in wine. > >> > In windows only cp866 is readable regardless of ConsoleOutputCP. > >> > >> As I said I tested under Windows (XP) only, and SetConsoleOutputCP > >> does change the behaviour of WriteConsoleA for me. If it wouldn't > >> I'd call it a bug. > > > > I tested under Windows 2003 and SetConsoleOutputCP does NOT change the > > behaviour of WriteConsoleA for me. > > Does Windows play us a trick? > > No the difference in observed behaviour was caused by the fact that I ran > the test under FAR, once I run it under cmd.exe I see what you do. Ahhh, I understood!!! You test does not return codepage back to 866. My version of your test does it. Far Manager somehow checks codepage and converts characters accordingly. I've removed the last convertion back to cp866 and observed the same behaviur as you. Thus, I can proclaim WriteConsoleA buggy. -- Kirill

2 2

RE: wine.inf: Add AllUsersProfile and associated entries to the registry [try 2].
by Vitaliy Margolen 05 May '07

05 May '07

Anything wrong with this 3 liner? Vitaliy Margolen wrote: > --- > tools/wine.inf | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) >

2 3

USB device support in wine
by Jon Burgess 05 May '07

05 May '07

Hi, I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it. I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device. Any ideas, or anyone else who would be interested in helping me? Regards, Jono

6 12

RE: Linuxworld San Francisco?
by Scott Ritchie 04 May '07

04 May '07

Oooh, I'll do it! Now I just need to come up with a specific topic other than "Wine" Thanks, Scott Ritchie On Fri, 2007-05-04 at 10:30 -0500, Jeremy White wrote: > Well, we'll be there with a booth. > > I think I've given enough Wine talks through the years at LinuxWorld > that they're tired of me :-/. But, to be honest, I don't think I submitted > a proposal this year. I think if someone else wanted to give the talk, > they'd probably appreciate a fresh face. > > Cheers, > > Jeremy > > > -----Original Message----- > > From: wine-devel-bounces(a)winehq.org > > [mailto:wine-devel-bounces@winehq.org] On Behalf Of Dan Kegel > > Sent: Friday, May 04, 2007 10:13 AM > > To: wine-devel(a)winehq.org > > Subject: Linuxworld San Francisco? > > > > Is anyone going to Linuxworld, August 6-9 in San Francisco? > > A guy working on a possible large migration > > said he'd be there, and was wondering if there's > > going to be a Wine BOF. > > I might go just to chat with him. > > > > Also, I see no Wine-related talks on the program. > > http://www.linuxworldexpo.com/live/12/events/12SFO07A/conferen > > ce/tracks > > If all the great stuff I expect actually happens > > this summer, there's going to be a lot to talk about, > > seems like a good year for a Wine talk there...? > > > > > > > > >

3 2

Re: [1/5] WineD3D: Software vertex blending
by H. Verbeet 04 May '07

04 May '07

On 04/05/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This patch makes a copy of the strided data from the device if needed, and it > explicitly fixes the fixed function data. > I still think messing with the strided data like that is rather hacky :-/

2 1

Re: [PATCH 2/3] Implement TINN algorithm.
by Michael Stefaniuc 04 May '07

04 May '07

Vitaly Budovski wrote: > > Implement the Triangle Inequality Nearest Neighbour algorithm as > described in > http://post.queensu.ca/~greensm/papers/tinn.pdf > --- > include/wine/tinn.h | 154 Do you need that somewhere else then in the X driver? If not putting that directly into dlls/winex11.drv/ makes more sense. > +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 154 insertions(+), 0 deletions(-) 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

3 2

Linuxworld San Francisco?
by Dan Kegel 04 May '07

04 May '07

Is anyone going to Linuxworld, August 6-9 in San Francisco? A guy working on a possible large migration said he'd be there, and was wondering if there's going to be a Wine BOF. I might go just to chat with him. Also, I see no Wine-related talks on the program. http://www.linuxworldexpo.com/live/12/events/12SFO07A/conference/tracks If all the great stuff I expect actually happens this summer, there's going to be a lot to talk about, seems like a good year for a Wine talk there...?

2 2

re: Implement MsiBreak Feature - Bug 8243
by Dan Kegel 04 May '07

04 May '07

> Do we really need to write out unix pid? > AFAIK Winedbg can attach to windows process IDs just fine. Hrmph. The author did say in http://bugs.winehq.org/show_bug.cgi?id=8243 that he needed Windows PIDs, didn't say he needed Unix pids. so maybe you're right. Let's ask him. Hey, Anastasius, do you really need the unix pid? - Dan

1 1

OLE2A
by Bill Medland 04 May '07

04 May '07

Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space? Bill Medland

3 5

kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS & incorrect GetLastError() codes fix
by Kirill K. Smirnov 04 May '07

04 May '07

+/* 0x00..0x1f chars glyph map */ +static const WCHAR glyph_xlat[32] = { + 0x0000, 0x263A, 0x263B, 0x2665, 0x2666, 0x2663, 0x2662, 0x2219, + 0x25D8, 0x25CB, 0x25D9, 0x2642, 0x2640, 0x266A, 0x266B, 0x263C, + 0x25BA, 0x25C4, 0x2195, 0x203C, 0x00B6, 0x00A7, 0x25AC, 0x21A8, + 0x2191, 0x2193, 0x2192, 0x2190, 0x221F, 0x2194, 0x25B2, 0x25BC +}; + +/* adds glyphs to the string */ +static inline void add_glyphs( WCHAR *str, unsigned int length ) +{ + unsigned int i; + for (i=0; i!=length; i++) { + if (str[i]<0x20) str[i]=glyph_xlat[str[i]]; + } +} I propose to make this routine extern, because it is the simpliest way to make console renderer (I mean user backend of wineconsole) display the characters below 0x20 correct. The test: #include <windows.h> int main(void) { DWORD d; char str[32]; int i; GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &d); d &= ~ENABLE_PROCESSED_OUTPUT; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), d); for (i = 0; i < 32; i++) str[i] = i; WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE), str, 32, &d, 0); d |= ENABLE_PROCESSED_OUTPUT; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), d); return 0; } Under wine we get strange symbols, under windows we get correct glyphs. If we perform the same character conversion in wineconsole/user.c just before actual text output, we get almost the same result that Windows does. The only difference is handling \0 symbol. -- Kirill

1 1

Re: [05/10] d3d: Fix the surface locking rectangle validation
by Stefan Dösinger 04 May '07

04 May '07

Am Donnerstag 03 Mai 2007 20:58 schrieb H. Verbeet: > Validation on the rectangle passed to LockRect/Lock is inconsistent > across ddraw/d3d8/d3d9. D3d9 doesn't do any validation at all, d3d8 > doesn't allow empty, flipped, mirrored, or out of bounds rectangles, > while ddraw does allow empty rectangles, but not flipped, mirrored or > out of bounds ones. Tests for this are in the next few patches in this > set. You have to take care for IDirectDrawSurface::Blt and BltFast too, because parts of the Blt rectangle checks were done by Lock()

1 0

Re: [4/5] WineD3D: Implement vertex blending using GL_ARB_vertex_blend
by H. Verbeet 04 May '07

04 May '07

Actually, I only thought about this just now, but you should also call glDisableClientState(GL_WEIGHT_ARRAY); in unloadVertexData().

2 1

Re: Unsecured API functions
by Tom Spear 04 May '07

04 May '07

On 5/3/07, Robert Shearman <rob(a)codeweavers.com> wrote: > Tom Spear wrote: > > I was writing up a Hello World with input program for a demonstration > > for a non-developer coworker last week, and used the unsecured getch() > > and got the standard warning about how it was unsecured and dangerous > > to use that. That prompted me to look up the basic secured functions > > on the MS website, and compare to wine code. According to MSDN, > > things like gets have been replaced with gets_s. However, as far as I > > can tell, wine still only implements gets for Windows programs to > > use.. Do we implement secured versions of other functions, and if > > not, how come? > > Q: Why doesn't Wine implement X? > A: Because not many programs use it and no-one has felt interested in > implementing it for fun. So in other words, most programs use insecure functions (like gets) instead of using secure functions (like gets_s), leaving themselves vulnerable to all sorts of buffer overflows? I wonder if microsoft doesn't silently convert gets calls to gets_s calls, then, and maybe didn't document that? Otherwise I assume there would be thousands of buffer overflows that (malicious) people would exploit. I understand that most programs dont use either of those functions, but there are others that are used by nearly every program that ms deprecated in favor of secure versions. -- 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

5 6

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS & incorrectGetLastError() codes fix
by Dmitry Timoshkov 04 May '07

04 May '07

"Andrew O. Shadoura" <bugzilla(a)tut.by> wrote: > This patch implements MB_USEGLYPHCHARS flag in MultiByteToWideChar function > and fixes incorrect error codes (in case of CP_SYMBOL charset non-zero dwFlags > should give ERROR_INVALID_FLAGS, not ERROR_INVALID_PARAMETER, almost the same > with CP_UTF8, but "dwFlags must be set to either 0 or MB_ERR_INVALID_CHARS" > according to MSDN: http://msdn2.microsoft.com/en-us/library/ms776413.aspx > Also, test case is added. Please follow the existing code style of the files you're changing (indentation, braces, spaces), don't mix tabs and spaces. > + for (i=0; i!=length; i++) { > + if (str[i]<0x20) str[i]=glyph_xlat[str[i]]; > + } This is rather an unusual style of breaking out of the loop, 'i < length' is less confusing IMO. -- Dmitry.

1 0

dinput : crash of Pro Evolution Soccer 3 with a joystick
by Sébastien GRIPON 04 May '07

04 May '07

Hi, I try to play to Pro Evolution Soccer 3 on my Ubuntu Fesity Fawn and it's not far to be possible. Every wine release brings a lots of wined3d improvements and pes3 is almost playable. Many textures are missing, but it's on a good way. Congratulations ! However, I have a problem with my joystick. I have a Microsoft Sidewinder and a Thrustmaster and when any of them is plugged on an USB port, the exe pes3.exe or the PES configuration tool setting.exe crash. This crash doesn't occur when joysticks are not pluggued. I tried to debug this crash, but it is a very hard work. I think dinput is involved but I can't be sure. If you're interesting in this game, this is the crash dump. Thank you, Seb. $ wine setting.exe fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:00000000 ESP:0033f518 EBP:0058b2a8 EFLAGS:00210246( - 00 -RIZP1) EAX:00182c18 EBX:00000000 ECX:7da5bc00 EDX:00181bfc ESI:0058ad38 EDI:00000000 Stack dump: 0x0033f518: 00407eab 00182c18 004363fc 00000000 0x0033f528: 0043e4c0 0043fac4 00000000 0040814e 0x0033f538: 00181bf8 00000003 7da58b08 0033fa20 0x0033f548: 7da5af6c 0058ad38 00007734 90234a8d 0x0033f558: f7bdb63f 00003020 0033f658 7da4bc9f 0x0033f568: 7e4fa15f 7e4c2cd0 0033fa78 0042f0bb Backtrace: =>1 0x00000000 (0x0058b2a8) 2 0x00000000 (0x00182c18) 3 0x00000001 (0x7da5bc00) 4 0x00000000 (0x00000000) 0x00000000: addb %al,0x0(%eax) Modules: Module Address Debug info Name (96 modules) PE 400000- 464000 Deferred setting ELF 7b800000-7b927000 Deferred kernel32<elf> \-PE 7b820000-7b927000 \ kernel32 ELF 7bc00000-7bc96000 Deferred ntdll<elf> \-PE 7bc10000-7bc96000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7ccdb000-7ccf0000 Deferred midimap<elf> \-PE 7cce0000-7ccf0000 \ midimap ELF 7ccf0000-7cd16000 Deferred msacm32<elf> \-PE 7cd00000-7cd16000 \ msacm32 ELF 7cd16000-7cd2e000 Deferred msacm32<elf> \-PE 7cd20000-7cd2e000 \ msacm32 ELF 7cd2e000-7cd6a000 Deferred wineoss<elf> \-PE 7cd40000-7cd6a000 \ wineoss ELF 7cd6a000-7cdbb000 Deferred libgcrypt.so.11 ELF 7cdbb000-7cdd0000 Deferred libtasn1.so.3 ELF 7cdd0000-7cdfe000 Deferred libcrypt.so.1 ELF 7ce11000-7ce81000 Deferred libgnutls.so.13 ELF 7ce81000-7ceb2000 Deferred libcups.so.2 ELF 7d1e7000-7d1eb000 Deferred libgpg-error.so.0 ELF 7d1eb000-7d21d000 Deferred uxtheme<elf> \-PE 7d1f0000-7d21d000 \ uxtheme ELF 7d21f000-7d224000 Deferred libxfixes.so.3 ELF 7d224000-7d22d000 Deferred libxcursor.so.1 ELF 7d22d000-7d233000 Deferred libxrandr.so.2 ELF 7d233000-7d23b000 Deferred libxrender.so.1 ELF 7d23b000-7d23e000 Deferred libxinerama.so ELF 7d764000-7d7f3000 Deferred winex11<elf> \-PE 7d770000-7d7f3000 \ winex11 ELF 7d89c000-7d8bc000 Deferred libexpat.so.1 ELF 7d8bc000-7d8e7000 Deferred libfontconfig.so.1 ELF 7d8e7000-7d8fb000 Deferred libz.so.1 ELF 7d8fb000-7d966000 Deferred libfreetype.so.6 ELF 7d966000-7d97a000 Deferred oleacc<elf> \-PE 7d970000-7d97a000 \ oleacc ELF 7d97a000-7d997000 Deferred imm32<elf> \-PE 7d980000-7d997000 \ imm32 ELF 7d997000-7da26000 Deferred winmm<elf> \-PE 7d9a0000-7da26000 \ winmm ELF 7da26000-7da5c000 Deferred dinput<elf> \-PE 7da30000-7da5c000 \ dinput ELF 7da5c000-7da75000 Deferred dinput8<elf> \-PE 7da60000-7da75000 \ dinput8 ELF 7dad8000-7e35e000 Deferred libglcore.so.1 ELF 7e35e000-7e3de000 Deferred libglu.so.1 ELF 7e3de000-7e46a000 Deferred libgl.so.1 ELF 7e46a000-7e55b000 Deferred libx11.so.6 ELF 7e55b000-7e569000 Deferred libxext.so.6 ELF 7e569000-7e581000 Deferred libice.so.6 ELF 7e581000-7e642000 Deferred wined3d<elf> \-PE 7e590000-7e642000 \ wined3d ELF 7e642000-7e66a000 Deferred d3d8<elf> \-PE 7e650000-7e66a000 \ d3d8 ELF 7e66a000-7e705000 Deferred oleaut32<elf> \-PE 7e680000-7e705000 \ oleaut32 ELF 7e705000-7e718000 Deferred libresolv.so.2 ELF 7e718000-7e736000 Deferred iphlpapi<elf> \-PE 7e720000-7e736000 \ iphlpapi ELF 7e736000-7e78b000 Deferred rpcrt4<elf> \-PE 7e740000-7e78b000 \ rpcrt4 ELF 7e78b000-7e828000 Deferred ole32<elf> \-PE 7e7a0000-7e828000 \ ole32 ELF 7e828000-7e84a000 Deferred oledlg<elf> \-PE 7e830000-7e84a000 \ oledlg ELF 7e84a000-7e87d000 Deferred winspool<elf> \-PE 7e850000-7e87d000 \ winspool ELF 7e87d000-7e939000 Deferred comctl32<elf> \-PE 7e890000-7e939000 \ comctl32 ELF 7e939000-7e991000 Deferred shlwapi<elf> \-PE 7e950000-7e991000 \ shlwapi ELF 7e991000-7ea8c000 Deferred shell32<elf> \-PE 7e9a0000-7ea8c000 \ shell32 ELF 7ea8c000-7eb2c000 Deferred comdlg32<elf> \-PE 7ea90000-7eb2c000 \ comdlg32 ELF 7eb2c000-7eb73000 Deferred advapi32<elf> \-PE 7eb40000-7eb73000 \ advapi32 ELF 7eb73000-7eb7f000 Deferred libgcc_s.so.1 ELF 7eb81000-7eb86000 Deferred libxdmcp.so.6 ELF 7eb86000-7eb89000 Deferred libxau.so.6 ELF 7eb89000-7eb92000 Deferred libsm.so.6 ELF 7ec7c000-7ed3a000 Deferred gdi32<elf> \-PE 7ec90000-7ed3a000 \ gdi32 ELF 7ed3a000-7ee76000 Deferred user32<elf> \-PE 7ed60000-7ee76000 \ user32 ELF 7efa4000-7efaf000 Deferred libnss_files.so.2 ELF 7efaf000-7efc6000 Deferred libnsl.so.1 ELF 7efc6000-7efed000 Deferred libm.so.6 ELF 7efed000-7eff7000 Deferred libnss_nis.so.2 ELF 7eff7000-7f000000 Deferred libnss_compat.so.2 ELF b7d51000-b7d56000 Deferred libxxf86vm.so.1 ELF b7d57000-b7d5b000 Deferred libdl.so.2 ELF b7d5b000-b7e9c000 Deferred libc.so.6 ELF b7e9d000-b7eb4000 Deferred libpthread.so.0 ELF b7eb4000-b7eb6000 Deferred libnvidia-tls.so.1 ELF b7ec7000-b7fd8000 Deferred libwine.so.1 ELF b7fda000-b7ff5000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) C:\Program Files\KONAMI\Pro Evolution Soccer 3\setting.exe 0000000d 0 00000009 0 <==

2 1

Unsecured API functions
by Tom Spear 04 May '07

04 May '07

I was writing up a Hello World with input program for a demonstration for a non-developer coworker last week, and used the unsecured getch() and got the standard warning about how it was unsecured and dangerous to use that. That prompted me to look up the basic secured functions on the MS website, and compare to wine code. According to MSDN, things like gets have been replaced with gets_s. However, as far as I can tell, wine still only implements gets for Windows programs to use.. Do we implement secured versions of other functions, and if not, how come? -- 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

3 2

Re: Boundary test cases for SystemTimeToFileTime and GetDateFormat
by James Hawkins 03 May '07

03 May '07

On 5/3/07, Bill Medland <billmedland(a)shaw.ca> wrote: > Bill Medland (billmedland(a)shaw.ca) > Lower boundary test cases for SystemTimeToFileTime and GetDateFormat > > Index: wine/dlls/kernel32/tests/locale.c > =================================================================== > RCS file: /home/wine/wine/dlls/kernel32/tests/locale.c,v > retrieving revision 1.11 > diff -u -r1.11 locale.c > --- wine/dlls/kernel32/tests/locale.c 2 Apr 2007 11:24:36 -0000 1.11 > +++ wine/dlls/kernel32/tests/locale.c 3 May 2007 22:21:55 -0000 > @@ -424,6 +424,34 @@ > STRINGSW("dddd d MMMM yyyy","Wednesday 23 October 2002"); /* Incorrect DOW and time */ > ret = GetDateFormatW (lcid, 0, &curtime, input, buffer, COUNTOF(buffer)); > EXPECT_VALID; EXPECT_LENW; EXPECT_EQW; > + > + /* Limit tests */ > + > + curtime.wYear = 1601; > + curtime.wMonth = 1; > + curtime.wDay = 1; > + curtime.wDayOfWeek = 0; /* Irrelevant */ > + curtime.wHour = 0; > + curtime.wMinute = 0; > + curtime.wSecond = 0; > + curtime.wMilliseconds = 0; > + STRINGSW("dddd d MMMM yyyy","Monday 1 January 1601"); > + SetLastError(0xdeadbeef); > + ret = GetDateFormatW (lcid, 0, &curtime, input, buffer, COUNTOF(buffer)); > + EXPECT_VALID; EXPECT_LENW; EXPECT_EQW; > + > + curtime.wYear = 1600; > + curtime.wMonth = 12; > + curtime.wDay = 31; > + curtime.wDayOfWeek = 0; /* Irrelevant */ > + curtime.wHour = 23; > + curtime.wMinute = 59; > + curtime.wSecond = 59; > + curtime.wMilliseconds = 999; > + STRINGSW("dddd d MMMM yyyy","Friday 31 December 1600"); > + SetLastError(0xdeadbeef); > + ret = GetDateFormatW (lcid, 0, &curtime, input, buffer, COUNTOF(buffer)); > + EXPECT_INVALID; > } > > > Index: wine/dlls/kernel32/tests/time.c > =================================================================== > RCS file: /home/wine/wine/dlls/kernel32/tests/time.c,v > retrieving revision 1.3 > diff -u -r1.3 time.c > --- wine/dlls/kernel32/tests/time.c 4 Jan 2007 10:46:26 -0000 1.3 > +++ wine/dlls/kernel32/tests/time.c 3 May 2007 22:22:04 -0000 > @@ -73,6 +73,23 @@ > (st).wSecond = 32; \ > (st).wMilliseconds = 123; > > +#define SETUP_ZEROTIME(st) \ > + (st).wYear = 1601; \ > + (st).wMonth = 1; \ > + (st).wDay = 1; \ > + (st).wHour = 0; \ > + (st).wMinute = 0; \ > + (st).wSecond = 0; \ > + (st).wMilliseconds = 0; > + > +#define SETUP_EARLY(st) \ > + (st).wYear = 1600; \ > + (st).wMonth = 12; \ > + (st).wDay = 31; \ > + (st).wHour = 23; \ > + (st).wMinute = 59; \ > + (st).wSecond = 59; \ > + (st).wMilliseconds = 999; > > > static void test_conversions(void) > @@ -82,6 +99,12 @@ > > memset(&ft,0,sizeof ft); > > + SETUP_EARLY(st) > + ok ((!SystemTimeToFileTime(&st, &ft) && GetLastError() == ERROR_INVALID_PARAMETER), "Conversion failed EARLY\n"); > + > + SETUP_ZEROTIME(st) > + ok (SystemTimeToFileTime(&st, &ft) && ft.dwHighDateTime == 0 && ft.dwLowDateTime == 0, "Conversion failed ZERO_TIME\n"); > + You need to check each part of those conditions separately in their own ok()'s. -- James Hawkins

1 0

tools/winegcc solaris link options patch
by sol11x86＠comcast.net 03 May '07

03 May '07

Please comment on this patch: This patch adds two options to toool/winegcc to allow Solaris linker flags to be passed through and recognized. Prior to this patch, libraries compiled with winegcc (despite overloading every link related env variable I could think of), had a single RPATH when evaulated with elfdump (which was the primary library from the compiler). The effect was that I was required to set an LD_LIBRARY_PATH prior to running any of the wine applications, since the RPATH was not fully populated. With this patch, and proper configuration of LDFLAGS, I am now able to build wine on Solaris without having to resort to an LD_LIBRARY_PATH when I run wine. The two flags that are added to winegcc.c are: -R <libdir> -z <linker flags> (-z allows me to control the link phase a little better for performance reasons). Thanks to Steleman who quickly recognized the problem, despite the facts were staring me in the face. Ben

1 0

Re: Implement MsiBreak Feature - Bug 8243
by James Hawkins 03 May '07

03 May '07

On 5/2/07, EA Durbin <ead1234(a)hotmail.com> wrote: > patch created by Anastasius Focht for Bug 8243. > + /* check "MsiBreak" environment variable */ + if( GetEnvironmentVariableW( envMsiBreakW, envMsiBreakValueW, MAX_PATH)) + { I think we need more investigation into this before accepting this patch. One of the things that needs to be checked is whether the windows installer checks the environment variable every single time a custom action is called, or if the environment variable is stored at the beginning of the installation and just the custom action name is checked every time a custom action is called. This can be tested on windows by setting MsiBreak to a certain custom action, and then change the environment variable to a different custom action while the message box is still asking to break. If the installer breaks on the next custom action, we'll know that it checks the environment variable each time. -- James Hawkins

1 0

Re: Implement MsiBreak Feature - Bug 8243
by Peter Oberndorfer 03 May '07

03 May '07

On Thursday 03 May 2007 05:45, EA Durbin wrote: Hi, > patch created by Anastasius Focht for Bug 8243. > >+#include <sys/types.h> /* for getpid() */ >+#include <unistd.h> /* for getpid() */ Do we really need to write out unix pid? AFAIK Winedbg can attach to windows process IDs just fine. >+ if( MessageBoxW( NULL, dbgMsgW, CustomActionName, MB_OKCANCEL) == IDOK) >+ { >+ return TRUE; >+ } nitpick: maybe remove {} to be consistent with rest of file? >+ if( IsMsiBreak( info->target)) >+ DebugBreak(); extra nitpick: maybe remove space before argument or place additional space before closing ) like foo( baz ); / foo(baz); It also seems like the patch is line wrapped. Greetings Peter

1 0

Re: Some Spanish translation updates
by Alexandre Julliard 03 May '07

03 May '07

José Manuel Ferrer Ortiz <jmfo1982(a)yahoo.es> writes: > By the way, I've changed the license of the files > 'oledlg/oledlg_Es.rc' and 'shdoclc/Es.rc' (I was the creator of > these two files) to LPGL version 2.1 (and not any later). Please don't do that. All of Wine should be under the same license, otherwise it will create major confusion. -- Alexandre Julliard julliard(a)winehq.org

1 0

What's the long term plan for 64 bit support?
by Scott Ritchie 03 May '07

03 May '07

In the (distant) future, will we support building Wine with both 64 bit and 32 bit libraries, and then the same Wine installation will run both 64 bit and 32 bit apps? As I understand it, this is the way Windows does in its 64 bit versions. I ask because there's a question of how to name the Wine packages for the 64 bit distribution - there's a standard of naming 32 bit packages something like "wine32", but if we're eventually going to have a unified multiarch package then we can still go with just keeping it as "wine" Thanks, Scott Ritchie

3 3

Re: [5/5] WineD3D: Software vertex blending
by H. Verbeet 03 May '07

03 May '07

>+ for(i = 0; i < 16 /* Max vertex attribs */; i++) { I think you should be using MAX_ATTRIBS there. Changing the strided data like that in drawPrimitive looks rather hacky to me.

2 2

Bug in Advapi32: CryptEnumProviderTypesA and CryptEnumProvidersA
by Mounir IDRASSI 02 May '07

02 May '07

Hi, During our tests of wine with our cryptographic suite, we have found a bug in the functions CryptEnumProviderTypesA and CryptEnumProvidersA in advapi32 dll: In case of failure, they both report a wrong last error through GetLastError. We have found and corrected the source of the bug: They both call their wide-char counterpart but they don't test the success of this call. The correction is simple: add an if statement and return immediately in case of error. I have attached a small patch with our correction. Should we fill a bugzilla report before submitting the patch? Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From ab7323952138e725700ded1bad4afd17e42717e7 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Wed, 2 May 2007 20:20:59 +0200 Subject: Correct bug in CryptEnumProviderTypesA and CryptEnumProvidersA: They report wrong last error in case of failure --- dlls/advapi32/crypt.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/dlls/advapi32/crypt.c b/dlls/advapi32/crypt.c index 1fd16c3..a7273b9 100644 --- a/dlls/advapi32/crypt.c +++ b/dlls/advapi32/crypt.c @@ -1139,7 +1139,8 @@ BOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD *pdwReserved, TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags, pdwProvType, pszProvName, pcbProvName); - CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen); + if(!CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen)) + return FALSE; if ( pszProvName && !(str = CRYPT_Alloc(strlen)) ) { SetLastError(ERROR_NOT_ENOUGH_MEMORY); @@ -1267,7 +1268,8 @@ BOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD *pdwReserved, TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags, pdwProvType, pszTypeName, pcbTypeName); - CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen); + if(!CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen)) + return FALSE; if ( pszTypeName && !(str = CRYPT_Alloc(strlen)) ) { SetLastError(ERROR_NOT_ENOUGH_MEMORY); -- 1.4.4.2

2 1

Any way to get the current code besides git?
by Tom Spear 02 May '07

02 May '07

I'm having an issue using git at work, where it will start downloading the packs, and then just stalls out at the same pack every time.. This has occurred since I first started working here Maybe someone knows the problem, and a solution? If not, is there a way to get git to show file names instead of md5 sums, like cvs did, back when we used it, so I can at least know what file is causing the problem? If there is no solution, then maybe someone does know where I can get current code aside from git? -- 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

3 7

Patch question
by Tom Spear 02 May '07

02 May '07

Just curious if there was something wrong with the regedit patch I sent on Friday, or if maybe there is a particular reason that the /C was left out of the code in the first place, that I am missing, and would help me to understand. http://www.winehq.org/pipermail/wine-patches/2007-April/038652.html -- 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

1 0

Re: Adding header files for the implementation of Winscard dll (Smart Cards support)
by Dmitry Timoshkov 02 May '07

02 May '07

"Mounir IDRASSI" <mounir.idrassi(a)idrix.fr> wrote: > diff --git a/include/scarderr.h b/include/scarderr.h > new file mode 100755 > index 0000000..c07833e > --- /dev/null > +++ b/include/scarderr.h ... > diff --git a/include/winscard.h b/include/winscard.h > new file mode 100755 > index 0000000..f302a9f > --- /dev/null > +++ b/include/winscard.h ... > diff --git a/include/winsmcrd.h b/include/winsmcrd.h > new file mode 100755 > index 0000000..cc03a35 > --- /dev/null > +++ b/include/winsmcrd.h This is a notice more for Alexandre this time, but next time please make sure to send the files with exec bits turned off (755 -> 644). -- Dmitry.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2007