September 2007 - Wine-Devel

Re: msvcrt: move error condition before memory allocation (found by Smatch) [1/3, resend]
by Alexandre Julliard Sept. 28, 2007

Sept. 28, 2007

Lionel_Debroux <lionel_debroux(a)yahoo.fr> writes: > _wfullpath leaks some heap memory in an error paths. Found in Michael > Stefaniuc's list of Wine potential bugs detected by Smatch. > Fixed by moving the error treatment before the allocation, since the > error treatment doesn't fire up if there was a memory allocation (due to > size = MAX_PATH; assignment). > > Is there anything wrong with this patch ? Yes, you are using the size before checking if the buffer is NULL (in which case the size is meaningless), and as you said yourself the error treatment isn't used if there was an allocation, so there's no leak to fix here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine gets exposed in Norway :)
by Tomas Zijdemans Sept. 28, 2007

Sept. 28, 2007

The most visited and respected technology related site in Norway (210 000 unique norwegian hits a week), is now launching a series of articles where they will test 3 games thoroughly in wine each month! Today the first article tested Fahrenheit, Guild Wars: Nightfall and Civilization IV: Warlords. The results where good and focused on what users should do to make them work smoothly. Hope this is an encouragement for Stefan and all the others of you working to get games working :)

2 2

Re: version resource for ole2nls.dll
by Dmitry Timoshkov Sept. 27, 2007

Sept. 27, 2007

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > This patch fixes Bug 9747 > > ChangeLog > --------- > added version resource for ole2nls.dll > +#define WINE_FILEVERSION_STR "2.10.3050.1" > +#define WINE_FILEDESCRIPTION_STR "Wine OLE dll" > +#define WINE_FILENAME_STR "OLE2NLS.DLL" > + > +#include "wine/wine_common_ver.rc" Why do you define WINE_FILEVERSION_STR but not WINE_FILEVERSION? That not creates a confusion but could lead to hard debuggable problems with application which test only one of them. -- Dmitry.

1 1

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation
by Alexandre Julliard Sept. 27, 2007

Sept. 27, 2007

Roy Shea <roy(a)cs.hmc.edu> writes: > Resubmission of a bare bones bits implementation. There is no bits.dll on any Windows version I've checked. Where does this dll come from? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function
by Juan Lang Sept. 27, 2007

Sept. 27, 2007

Hi Konstantin, - providerTable->table[index].dwEnumScopes & dwScope) + providerTable->table[index].dwEnumScopes & WNNC_ENUM_GLOBAL) This change looks correct, but it should be changed in the next block as well: ret = providerTable->table[index].openEnum( dwScope, dwType, dwUsage, lpNet, &handle); It also looks incorrect in _enumerateGlobalPassthroughW: ret = providerTable->table[enumerator->providerIndex]. openEnum(enumerator->dwScope, enumerator->dwType, enumerator->dwUsage, enumerator->lpNet, &enumerator->handle); In fact, all of these usages of dwScope look to confuse the two meanings. (D'oh.) --Juan

2 4

WineD3D surface management cleanup
by Stefan Dösinger Sept. 27, 2007

Sept. 27, 2007

Hi, This mail is mainly addressed at Henri and Roderick, but I'll send it here to allow others to read it too. These patches contain some cleanups of the d3d surface loading code. It's main aim is to put the code that copies the surface between system memory, texture and drawable into a centralized place, make LockRect simpler and pbo creation and surface memory allocation in one place(surface allocation is not completely there yet). It also makes other parts of the code simpler, avoids playing with the surface flags in other places, and it will allow us to centralize the logic that in the case of fbo offscreen rendering the drawable is the same as the texture(This is also not implemented yet). The patches don't aim at fixing any bugs themselves, and I hardly tested them, so there may be a truckload of regressions. I'm mainly showing them to show the general direction I'm heading into.

4 6

Re: Alexandre Julliard : gdi32: Don' t pass a DC handle to WineEngGetFontUnicodeRanges.
by Robert Shearman Sept. 27, 2007

Sept. 27, 2007

Alexandre Julliard wrote: > -DWORD WineEngGetFontUnicodeRanges(HDC hdc, LPGLYPHSET glyphset) > +DWORD WineEngGetFontUnicodeRanges(GdiFont *font, LPGLYPHSET glyphset) > { > FIXME("(%p, %p): stub\n", hdc, glyphset); > You forgot to change hdc to font in the FIXME call. -- Rob Shearman

1 0

Re: [PATCH 1/2] [try2] Allow completion object to be attached to an fd object
by Alexandre Julliard Sept. 27, 2007

Sept. 27, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > +DECL_HANDLER(set_completion_info) > +{ > + struct fd *fd = get_handle_fd_obj( current->process, req->handle, 0 ); > + > + if (fd) > + { > + if (fd->completion) > + release_object( fd->completion ); > + fd->completion = get_completion_obj( current->process, req->chandle, IO_COMPLETION_MODIFY_STATE ); > + fd->comp_key = req->ckey; > + release_object( fd ); You need to check that the completion object is valid before you start modifying the fd. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi: Fix meaning and use of bidirectionality flags
by Shachar Shemesh Sept. 27, 2007

Sept. 27, 2007

Maarten Lankhorst wrote: > According to shachar shamesh they have a slightly different meaning. > This should fix it. > First of all, things seem much much better with this patch. I would direct your attention to the fact that, when I run it, I get: > $ programs/notepad/notepad > fixme:bidi:mirror stub: mirroring of characters not yet implemented > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 As far as I can tell, an assert should not be a "fixme", but that's something else. Shachar

1 0

Re: [5/5] WineD3D: Add sincos support to arb shaders
by Ivan Gyurdiev Sept. 27, 2007

Sept. 27, 2007

Aren't most of these 2.0 and 3.0 instructions ? What's the goal of adding them to ARB - you won't be able to implement full 2.0/3.0 support in ARB. I think most of these were left unimplemented on purpose. Ivan

2 3

Total bidi regression
by Shachar Shemesh Sept. 27, 2007

Sept. 27, 2007

Hi Maarten, It seems that since your last changes to the Bidi implementation, BiDi suffered total regression. At least on my system, no BiDi related text (neither Hebrew nor Arabic) gets reordered, at all. Placing breakpoints suggest that BIDI_Reorder is still getting called, so I can only assume that the problem is somewhere inside it (or in the classification) I haven't traced inside to see where things went wrong, nor do I know whether your work on that matter is done. I just wanted to point out that Wine, at the moment, performs no BiDi at all as far as the user is concerned. Shachar

2 6

I need help, please
by David Outteridge Sept. 26, 2007

Sept. 26, 2007

Hello All, I am new to Wine. I need to use corelDRAW for non-central reasons that I will explain if asked. I prefer to host on *nix (currently Mandriva 2007.0), but I can host on MS XP as a backup. I bought the latest and greatest corelDRAW X3 (version 13) and now have spent about a week learning Wine and trying to get corelDRAW working. There are some problems with installation, not completely solved yet; but I am hopeful that execution will be successful since earlier versions are reported in the Wine application database as running well. I have reached a point where I am beginning to understand what is going on with the hosting, and, also, I am getting a glimmer of *how* Wine works. But, as everyone knows, Wine needs a lot of study to get any siginificant grasp of *what* is happening, and I am very aware of how little I know. I need help and guidance to go further, otherwise I shall have to revert to MS XP. I should like very much to use Wine, but I am concerned that to get it going, without help, I shall have to resort to hacks that will be of no use to anyone in the long term, or become engulfed in a never-ending sea of detail. So, here I describe what has happened, and I invite anyone to point me in the right direction, etc., for further work. I am a programmer of many years, but I have not used C for a long time, my preference is for another language. I have no knowledge of Windows internals, and not much about using it except at a fairly remote C++ application programming level when I used Visual Dev Studio (name?) in the past. I have downloaded the Wine source, and have learnt how to manipulate trace messages to see what is happening. The first problem, with corelDRAW out of the box, with Wine 0.9.45 from rpm, or with my downloaded/compiled code, is summarized like this: fixme:msi:ACTION_PerformAction unhandled msi action L"InstallIEFullUI" err:msi:ITERATE_Actions Execution halted, action L"_InstallIE" returned 1602 Notice that there is a leading "_" on one of these actions, and that part of the other is FullUI, which seems to relate very well with one of the MS User Interface Levels. Can anyone tell me the significance of the leading "_", in particular, where does it come from? Also any help on how InstallIEFullUI is split up (my assumption) into _InstallIE and FullUI would be helpful. After much stirring around, hacking at everything in sight, what I have done to deal with this error is cut-and-paste ACTION_InstallInitialize code in msi/actions.c, and modify it suitably, to satisfy InstallIEFullUI and _InstallIE. And this gets me past the err:msg above; which may or may not enable me, ultimately, to install corelDRAW. This do-nothing-really is something of a cop-out, of course. I would make the effort to do something useful, rather than simply returning a deceptive value, but there are two reasons for not doing so. One is that I do not know enough about Wine code/structure/policy, etc., and I could see simply producing garbage, albeit working, code through ignorance. The second reason is that, I read on the Wine website, one should not try to install IE. What is more, Wine (from the rpm) puts a copy of iexplore.exe in my .wine directory anyway. So the question here is: what should I do wrt IE and InstallIEFullUI to follow Wine policy? The second problem seems to me to be rather far-reaching; I think I have run into the problem in three different ways, the last occurrence turns out to be the next fatal step for corelDRAW installation. The first run-in: I have run the distribution iexplore, also I have installed three other IEs, using ies4linux. All of these behave in the same way: they come up properly, and the right-click/wineicon menu that closes the application, moves it to different desktops, etc., also works, so exiting the application is done properly, too. My guess is that this is all done by the window manager, however. The problem is that IE displays no toolbar, so it is quite useless as a browser; it is, indeed, a software boat-anchor. The second run-in: When I ran winecfg, irfanview, regedit, etc.. under the rpm distribution they worked well enough, although the font used was, well, horrible, and almost unreadable. When I moved to the source version of Wine, the apps worked somewhat like iexplore above, except that the menus were available, but contained MangleFont - totally unreadable, with lots of Xs in the text. I posted to comp.emulators.ms-windows.wine and some kind sole suggested loading the MS core fonts, which I had never heard of; but, bingo!, not only did this - utterly magically - solve the problem, but the font(s) used is nice and readable. The third run-in: The corelDRAW installation popups (dialogs?) do not display well, in particular they appear not to refresh when appropriate. The fatal part comes with the license agreement box, where, in addition to most of the popup content not displaying (mouse intervention brings up *some* things), the "Next" button used to continue the installation does not show, nor is it present in the popup. Curiously, the "Cancel" button, right next to it, does show - after its, blank, location is clicked on. I know where the Next button is because I cheated and ran the corelDRAW CD on the XP box, where it works, of course. Not being able to transmit Next to the popup is a stalemate position. But here is some trace output from the same time, you will need to imagine the trace positions in the code. Necessarily, as above, I clicked the "Cancel" button toward the end of this trace fragment. trace:dajo:ITERATE_Actions POS 61 L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 21 0 0 trace:dajo:ACTION_HandleStandardAction POS 31 0 1 trace:dajo:ACTION_HandleStandardAction UNHANDLED STD ACTION L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 22 0 trace:dajo:ACTION_HandleCustomAction UNHANDLED CTM ACTION L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 23 0 trace:dajo:ACTION_DialogBox POS 81 L"LicenseAgreement" trace:dajo:event_do_dialog POS 91 L"LicenseAgreement" trace:dajo:event_do_dialog POS 92 L"LicenseAgreement" trace:dajo:WineEngCreateFontInstance POS 51 L"System" trace:dajo:WineEngCreateFontInstance POS 52 L"System" trace:dajo:WineEngCreateFontInstance POS 51 L"Tahoma" trace:dajo:WineEngCreateFontInstance POS 52 L"Tahoma" trace:dajo:WineEngCreateFontInstance POS 51 L"ArialMT" fixme:font:WineEngCreateFontInstance Untranslated charset 77 trace:dajo:WineEngCreateFontInstance POS 53 L"ArialMT" trace:dajo:WineEngCreateFontInstance POS 52 L"ArialMT" trace:dajo:WineEngCreateFontInstance POS 51 L"Tahoma" trace:dajo:WineEngCreateFontInstance POS 52 L"Tahoma" trace:dajo:event_do_dialog POS 91 L"CancelSetup" trace:dajo:event_do_dialog POS 92 L"CancelSetup" trace:dajo:ACTION_DialogBox POS 82 L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 24 1 trace:dajo:ACTION_PerformUIAction HANDLED MSI ACTION L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 25 1 err:msi:ITERATE_Actions Execution halted, action L"LicenseAgreement" returned 1602 So, it appears that the untranslated character set 77 (ArialMT) is preventing the corelDRAW popup from displaying properly - that, of course, is a wild guess at the moment. But, in a curious way, it ties in with the other problems with fonts that I have experienced. OK, so I should fix the FIXME. But now I am back to the code/structure/policy problem. Is the solution as simple as hacking up ArialMT to work, or does this need some proper action to solve a more general problem? So this marks the point where I decided to write what you are reading. I need guidance on policy mainly, I think. I should like help on how this error, and its solution, fits in to the larger Wine picture. I hope that I have presented, what is becoming, my dilemma. I *really* want to handled these problems, and, now that I started to find my way around in Wine, maybe do some other things, all with one objective of helping the Wine project. But I have other pressures on me, and I have this uncomfortable feeling of opening ever-widening boxes of worms. I cannot continue to spend days of time without some feeling that the scope of the task is going to contract rather than expand further. In conclusion, I can report that corelDRAW X3 does not install (also see the appDB for confirmation), which is regressive wrt version 11, which is rated as Gold. Some of the reasons are given above. The required OS is either XP or 2000, an attempt to use soemthing else brings up a message stating that. Thanks for reading this. David

1 0

Re: [PATCH] [2/2] winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUse
by Peter Oberndorfer Sept. 26, 2007

Sept. 26, 2007

On Wednesday 26 September 2007, Peter Oberndorfer wrote: > --- > dlls/winhttp/main.c | 25 +++++++++++++++++++++++++ > dlls/winhttp/winhttp.spec | 2 +- > 2 files changed, 26 insertions(+), 1 deletions(-) > There is a 'r' missing in the patch title. it should be: winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUser Greetings Peter

1 0

Re: [PATCH 2/2] configure: Build wine-kthread on FreeBSD.
by Tijl Coosemans Sept. 26, 2007

Sept. 26, 2007

On Wednesday 26 September 2007 19:24:24 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.

1 0

Re: [PATCH 1/2] loader: Reduce data segment size in wine-pthread/kthread on FreeBSD.
by Tijl Coosemans Sept. 26, 2007

Sept. 26, 2007

On Wednesday 26 September 2007 19:17:44 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.

1 0

Re: [5/5] WineD3D: Add sincos support to arb shaders
by H. Verbeet Sept. 26, 2007

Sept. 26, 2007

On 26/09/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* dst.w = src[0].w * 1 / (src.x^2 + src.y^2 + src.z^2)^(1/2) according to msdn*/ That comment looks a bit out of place for sincos. Copy-paste from nrm?

1 0

Re: RICHED20: EM_SETCHARFORMAT must return 0, not assert, on invalid struct size (try 2)
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

a_villacis(a)palosanto.com writes: > I considered doing this at first, but ME_ToCF2W is used in three other > places beside handling EM_SETCHARFORMAT (all in style.c), and those places > might get a null-pointer exception instead of an assert if something went > wrong. A null-pointer exception serves the same purpose as an assert, and they both result in a debugger backtrace, so there's no reason to add more asserts here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Cannot compile wine due to recent changes
by Kirill K. Smirnov Sept. 26, 2007

Sept. 26, 2007

Hi, I got the following error message during compile fresh git-current wine: gcc -c -I../../../dlls/winex11.drv -I. -I../../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o x11drv_main.o ../../../dlls/winex11.drv/x11drv_main.c In file included from ../../../dlls/winex11.drv/x11drv_main.c:52: ../../../dlls/winex11.drv/xcomposite.h:40: error: `XCompositeGetOverlayWindow' undeclared here (not in a function) ../../../dlls/winex11.drv/xcomposite.h:40: warning: type defaults to `int' in declaration of `pXCompositeGetOverlayWindow' ../../../dlls/winex11.drv/xcomposite.h:41: error: `XCompositeReleaseOverlayWindow' undeclared here (not in a function) ../../../dlls/winex11.drv/xcomposite.h:41: warning: type defaults to `int' in declaration of `pXCompositeReleaseOverlayWindow' ../../../dlls/winex11.drv/x11drv_main.c:389: warning: type defaults to `int' in declaration of `pXCompositeGetOverlayWindow' ../../../dlls/winex11.drv/x11drv_main.c:390: warning: type defaults to `int' in declaration of `pXCompositeReleaseOverlayWindow' make[2]: *** [x11drv_main.o] Ошибка 1 make[2]: Leaving directory `/home/lich/wine/wine/build/dlls/winex11.drv' make[1]: *** [winex11.drv] Ошибка 2 make[1]: Leaving directory `/home/lich/wine/wine/build/dlls' make: *** [dlls] Ошибка 2 X is Xorg 6.9.0 -- Kirill

2 1

Re: services.exe[2/8]: load services list from registry
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > + buf = HeapAlloc(GetProcessHeap(), 0, size + 4); > + if ((err = RegQueryValueExW(hKey, szValue, 0, &type, (LPBYTE)buf, &size)) != 0) > + goto failed; > + buf[size/2] = 0; > + buf[size/2 + 1] = 0; Please use sizeof(WCHAR) instead of hardcoding values like 2 and 4. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/6] Make ntdll I/O function to generate completion events
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > This has to be done in client because server does not > know about actual operation details (e.g. io.Information), > and moreover some operations does not use server at all. The needed information can be sent to the server along with the normal async status. We shouldn't add yet another server call for this, async I/O already requires too many server roundtrips. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/6] Allow completion object to be attached to a fd object
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > +struct compl_map *create_completion_map( obj_handle_t handle, unsigned long completion_key ) > +{ > + struct completion *completion; > + struct compl_map *map; > + > + if ((completion = get_completion_obj( current->process, handle, IO_COMPLETION_MODIFY_STATE )) == NULL) > + return NULL; > + if ((map = mem_alloc( sizeof(*map) )) == NULL) > + { > + release_object( completion ); > + return NULL; > + } > + map->completion = completion; > + map->completion_key = completion_key; > + return map; > +} There doesn't seem to be a need for a separate compl_map type here, you could just as well store the completion object in the fd structure directly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: services.exe/advapi32[5/8]: move QueryServiceConfig to services.exe
by Robert Shearman Sept. 26, 2007

Sept. 26, 2007

Mikolaj Zalewski wrote: > My QueryServiceConfig is not compatible with Windows one - I haven't > tried hard but I couldn't tune the parameters to connect with Windows > services.exe. So I'm not trying to store the structure in the on the > server side buffer but pass it all through the RPC and put in into the > buffer in advapi32. As I understand in near future Wine will not be a > member of Windows domains so on-the-wire compatibility is not very > important. > You don't need to be a member of a domain to use remote interfaces like the one for services or the one for the registry. On-the-wire compatibility will be important once we get remote named pipe support, but getting the right architecture is the goal at the moment, and your patches are a step towards that. I believe that the QUERY_SERVICE_CONFIGW parameter should be a byte_count one, but this is not implemented yet, both in the RPC runtime and in widl. -- Rob Shearman

1 0

Re: RICHED20: EM_SETCHARFORMAT must return 0, not assert, on invalid struct size
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

a_villacis(a)palosanto.com writes: > Changelog: > * EM_SETCHARFORMAT must not assert on invalid structure size. Instead, it > should just fail and return 0. It would be better to do that in ME_ToCF2W since it already has to check the size, simply make it return NULL on error or something like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: pdh: add tests for XP variant of api call
by Hans Leidekker Sept. 26, 2007

Sept. 26, 2007

On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > This patch adds the variations to the api that XP implements. My > assumption is that these changes will, mostly, be reflected in 2003 and > Vista. I can't check them so if someone could give them a run and let > know, that would be fine. I will get on with adding the variations to pdh.c All tests succeed here on 2003 without your patch. Even if APIs return different values on different versions of Windows we should not add version checks. Instead we should accept all possible return values or remove the test altogether when it's clear that you cannot depend on specific return values. -Hans

2 5

Recent BiDi changes
by Shachar Shemesh Sept. 26, 2007

Sept. 26, 2007

Hi Maarten, Can you, please, explain the advantage of creating our own implementation of the BiDi algorithm over using existing implementations? I know ICU sucks (especially as far as linkage is concerned), but there are other implementations, major among which is fribidi, which are free, are C based, and have a compatible license. Is there any need to Wine to be aware of the inside working of the algorithm? Also, so long as you are picking up the BiDi glove I dropped oh so many years ago, it seems to me that the proper place to implement BiDi would be in unscribe, where it is for Windows. The GDI implementation Wine has is a hack that reached it's useful end the moment you realize that DrawText needs its own implementation, independent of ExtTextOut (mostly due to line breaking code). Thanks, Shachar

3 6