September 2007 - Wine-Devel

re: I need help, please

by Dan Kegel

David, sorry, Wine's not likely to be able to run Corel Draw X3 without several months worth of work, and nobody's focusing on it at the moment. - Dan

Sept. 27, 2007

Re: Alexandre Julliard : gdi32: Don' t pass a DC handle to WineEngGetFontUnicodeRanges.

by Robert Shearman

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

Sept. 27, 2007

Re: [PATCH 1/2] [try2] Allow completion object to be attached to an fd object

by Alexandre Julliard

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

Sept. 27, 2007

Re: gdi: Fix meaning and use of bidirectionality flags

by Shachar Shemesh

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

Sept. 27, 2007

Re: [5/5] WineD3D: Add sincos support to arb shaders

by Stefan Dösinger

Am Donnerstag, 27. September 2007 13:02:31 schrieb Ivan Gyurdiev: > Are you saying you intend to advertise 3.0 support on ARB only? > If not, then why add any 3.0 features at all ? No, I certainly do not intend to advertise 3.0 because we cannot implement things like branching, dsx/dsy or vertex textures, but I'll propably advertise 2.0 some day, if I feel like causing a lot of extensions(Or I think that our shader tests are good enough to safely do this). The ARB shader backend tries to eat everything it is fed with though, even 3.0 shaders. Some games require a specific shader model, but use only a subset of it that is supportable. Having the code to support some 3.0 specials makes my life easier since I can just go and lie about the caps on macos for specific games(e.g. in crossover). I don't put special focus on SM 3.0 support, but if I come across something that is easy to add, I'm adding it. Also, some day we may implement the 3.0 features using the NV extensions. Of course if it's preferred to keep the arb shader backend clean from version == 3.0 checks I can keep the things I have in my junk branch, as long as I don't have to explain why I'm not submitting $GAMEFIX to Wine. Pretending SM 3.0 support is a hack, implementing the parts of 3.0 we can implement properly isn't IMHO.

Sept. 27, 2007

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation

by Stefan Dösinger

Am Donnerstag, 27. September 2007 12:58:46 schrieb Alexandre Julliard: > 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? It is an extra download, but requires a WGA check.

Sept. 27, 2007

Re: [5/5] WineD3D: Add sincos support to arb shaders

by Ivan Gyurdiev

Stefan Dösinger wrote: > Am Donnerstag, 27. September 2007 02:57:01 schrieb Ivan Gyurdiev: > >> 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. >> > We can implement 2.0(but not 2.a/b). Whenever it's easy to do, I'm adding > 3.0-Specific behavior too. The reason is that GLSL is a bloody pain on MacOS, > with ARB I can bypass many abstraction layers that have a huge number of > software fallback pitfalls. > Are you saying you intend to advertise 3.0 support on ARB only? If not, then why add any 3.0 features at all ? Ivan

Sept. 27, 2007

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation

by Alexandre Julliard

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

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Anything else I missed? Are there are any better ways to solve these > problems? Any other ways at all? The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs. -- Alexandre Julliard julliard(a)winehq.org

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Stefan Dösinger

Am Donnerstag, 27. September 2007 08:04:30 schrieb Christoph Frick: > On Thu, Sep 27, 2007 at 04:48:23AM +0000, L. Rahyen wrote: > > On Thursday September 27 2007 04:07, Vitaliy Margolen wrote: > > > The point I'm trying to make is: can we once put our "right ways of > > > doing things" aside and fix something that never worked before? And > > > fix it _for good_! > so if the "evdev" path is a choice one can choose at compile time or > even by config: go for it! even if unofficial - the gamers out there are > used to hack stuff into wine to make their favourite games work > _at_once_ after patches or after release - no matter if they break > windows comptibility or other in their wine instance. You have my vote on an evdev dinput backend too, however, we get some problems which the X server used to solve for us: 1) Multiple Mice. If there are 2 mouse devices, the X server manages them and combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse. 2) Different devices: An USB mouse creates a /dev/input/eventX node, but other devices, like my synaptics touchpad do not. In the worst case we need a driver for each mouse type, USB, serial, PS2, Synaptics, busmouse, logitech, ... 3) Other OSes: This was mentioned already, but I wanted to add that the problem seems X11-only. MacOS reports relative mouse movements like Windows does, so a quartz driver will not have this issue. Perhaps the evdev reading should be implemented in winex11.drv? I think as a first step, we should ask the X11 developers for their advice. Maybe we're missing some option here? I doubt it, but we should give it a try.

Sept. 27, 2007

Re: Total bidi regression

by Shachar Shemesh

Maarten Lankhorst wrote: > > I may have slightly misunderstood those flags then. I was under the > impression that the FORCE flags would be similar to LRO/RLO. The only thing that behaves like LRO and RLO are LRO and RLO. Believe you me, no one was more surprised than me when I found out that Windows actually respected them - they are as far away from an end user's experience as you might get (though useful, if you know about them). The Unicode algorithm keeps talking about setting the paragraph direction based on the first strong direction character in the paragraph (P2). As nice as that may have sound to the people drafting it, it only sort of works in real life. Either way, Window's BiDi doesn't work that way. The paragraph direction is set explicitly by the calling program (or, failing that, by the HDC, or, failing that, by an EXT_STYLE in the Window, you get the picture). This means the end of section 3.3.1, instructing implementors to ignore P2 and P3 in case of "higher-level protocol" apply here. Instead, the paragraph direction is explicitly passed to BIDI_Reorder through the "dwWineGCP_Flags" argument. > Instead > they are probably more like LRE/RLE. It's better to say that LRE and RLE allows one to switch paragraph direction for a specific part of the paragraph. In other words, LRE/RLE are like the paragraph direction, not vice versa. > If that is a real problem I will > send in a patch. If? > I would still rather prefer a real bidi implementation, > so that selecting and deleting characters would work properly. Lost you there completely. What do you mean by "selecting and deleting"? If you mean a BiDi editor, I think you have the tasks confused. Reordering characters in order to get them out on screen for printing has very little to do with string editing. It's one minor small step to start with. Bidi editing is a lot more complex. > To my > defense, there was no real clarification for them in the source. > The comments in the code used the same terminology used by Annex 9. The parameters were passed almost directly from the inputs in BIDI_Reorder to ICU's input functions, where they are documented in the ICU documentation. These parameters were also received, pretty directly, from ExtTextOut, again, where they are documented in MSDN. To my eyes, this is the level of documentation any Wine hacker should need. I don't believe code comments should start explaining algorithms, particularly algorithms implemented by a library and documented in an international standard. And I should warn you that edit control is several magnitudes more complicated. Questions such as cursor position when the cursor is between two letters that are, after reordering (i.e. - on display) not adjacent, what happens if a given cursor location is clicked which has two possible logical locations, and what to do if the user then clicks "del" or types a letter in an RTL or an LTR language. Editing is COMPLEX, and the road is not paved and documented. Matti Alluche wrote a document once that gives specifications for BiDi editing, but after Mozilla implemented it, I whole heartedly recommend that you avoid it. Your best course of action is to find out what Windows does for its edit control and copy that. > Cheers, > Maarten > Shachar

Sept. 27, 2007

Re: [5/5] WineD3D: Add sincos support to arb shaders

by Stefan Dösinger

Am Donnerstag, 27. September 2007 02:57:01 schrieb Ivan Gyurdiev: > 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. We can implement 2.0(but not 2.a/b). Whenever it's easy to do, I'm adding 3.0-Specific behavior too. The reason is that GLSL is a bloody pain on MacOS, with ARB I can bypass many abstraction layers that have a huge number of software fallback pitfalls.

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Christoph Frick

On Thu, Sep 27, 2007 at 04:48:23AM +0000, L. Rahyen wrote: > On Thursday September 27 2007 04:07, Vitaliy Margolen wrote: > > The point I'm trying to make is: can we once put our "right ways of > > doing things" aside and fix something that never worked before? And > > fix it _for good_! > I strongly agree here with Vitaliy. Personally I think that using > evdev for this purpose IS the "right way". Yes it will not work with > remote X but Windows doesn't support this too (as far as I know at > least). WINE purpose is to conform with Windows behavior. Therefore > use of evdev will be correct. Even if above isn't true (I think it > is) full support of remote X by dinput component isn't something > useful for about 100% of users anyway. Of course everything above is > just my opinion. on the other hand what is the use of playing a game over a remote machine? or are there apps, that suffer from this too? i can only figure out two things: - running a game server (unlikely one uses a direct X session - maybe only for games that need a client to configure the server) - play multiplayer games on one machine exporting it to the network (i doubt many do this - excepcially with windows games; it is more likely the other way around: host a linux game to a buddy with a windows notebook) one other concern i have is compatibility with other platforms. wine runs more or less fine at least on freebsd and osx - and others. so we keep the "old" code around, right? in general i would like to point out, that we have already similar stuff going on with the joystick drivers. the /dev/js joystick was/is(?) not useable for serious sims, due to its dead zone coming from somewhere in the kernel. so the /dev/input option is there - linux only i asume - which works great. so if the "evdev" path is a choice one can choose at compile time or even by config: go for it! even if unofficial - the gamers out there are used to hack stuff into wine to make their favourite games work _at_once_ after patches or after release - no matter if they break windows comptibility or other in their wine instance. -- cu

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by L. Rahyen

On Thursday September 27 2007 04:07, Vitaliy Margolen wrote: > The point I'm trying to make is: can we once put our "right ways of doing > things" aside and fix something that never worked before? And fix it _for > good_! I strongly agree here with Vitaliy. Personally I think that using evdev for this purpose IS the "right way". Yes it will not work with remote X but Windows doesn't support this too (as far as I know at least). WINE purpose is to conform with Windows behavior. Therefore use of evdev will be correct. Even if above isn't true (I think it is) full support of remote X by dinput component isn't something useful for about 100% of users anyway. Of course everything above is just my opinion.

Sept. 27, 2007

DInput mouse - where to go from here?

by Vitaliy Margolen

As many of you know, Wine have number of serious problems when it comes down to games when using mouse. In fact big number of games suffer one or more of the following problems: 1. Mouse pointer escapes game window (for windowed programs) or confined to arbitrary rectangle (for full-screen) - bug 6971. 2. Mouse is being constantly re-centered (number of bugs). 3. Mouse lags, moves wrong direction or doesn't move at all (number of bugs). 4. Mouse is not smooth with high graphics/system load. There are lots of reasons for these bugs: a) Wine does not grab pointer (doesn't lock it to one particular window). b) Wine's dinput still doing mouse warping while it should not c) Wine relies on an application to process messages so new input events could be received. d) Wine's x11drv is not fine grained - it has only one lock that everything uses, d3d and wgl included. e) The path from x11drv to dinput for input events is long with big overhead. f) X events come from Wine windows for the current process only not whole screen. g) Motion events Wine receives are absolute not relative. Here is what me and others tried but failed: i) XEvIE - buggy, disabled by default, requires server round trip. ii) XInput - does not allow opening of keyboard or mouse devices. iii) Event Device (EvDev) - works perfectly, solves (a,b,c,d,e,f,g) but it's a client only solution (will not work on remote X, because it will try to open remote mouse, not local). iv) Virtualizing mouse pointer in x11drv - depends on (a) moves (b) from dinput into x11drv while same issues remain. v) Writing new X extension - last I've heard about this, it didn't get anywhere past initial proposals. Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all? As you see there are not much options available to solve mouse problems. However I personally do not want to turn this into another "child opengl saga". We ether solving it now, or putting a big red X on any game that's using dinput mouse, that's not already working. The point I'm trying to make is: can we once put our "right ways of doing things" aside and fix something that never worked before? And fix it _for good_! Yes it's a limited fix it will work only for 99% of users who play games on their PC, and not remotely. Vitaliy Margolen.

Sept. 27, 2007

Re: [5/5] WineD3D: Add sincos support to arb shaders

by Ivan Gyurdiev

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

Sept. 27, 2007

I need help, please

by David Outteridge

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

Sept. 26, 2007

Re: Total bidi regression

by Maarten Lankhorst

Shachar Shemesh schreef: > Maarten Lankhorst wrote: > >> Shachar Shemesh schreef: >> >> >>> Maarten Lankhorst wrote: >>> >>> >>> >>>> If you want it back try replacing this in font.c: >>>> WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR >>>> change FORCE to LOOSE, it should work then. >>>> >>>> >>>> >>> I'm not sure what you are suggesting. >>> >>> WINE_GCPW_FORCE_RTL only appear on line 1089 of bidi.c, which reads >>> >>> >>>> case WINE_GCPW_FORCE_RTL: forcedir = R; baselevel = 1; break; >>>> >>>> >>>> >>> I'm not sure what you are suggesting I do with it. >>> >>> Either way, the change you are suggesting will only affect (if I >>> understand the code correctly) the paragraph direction setting, where as >>> I'm experiencing total lack of BiDi reordering of any kind. >>> >>> >>> >> Before arguing, you should really give it a try, it helps. ;-) >> > Sure thing. Just what, exactly, is "it"? What do you suggest I change, > and what to? I am really asking you to be less ambiguous. > > If you mean to change the "FORCE" to "LOOSE", then things are slightly > better in that same direction runs are at least now being reordered, but > things are still at a huge regression. Neutrals (at least some neutrals, > like space) seem to be incorrectly handled in mixed paragraphs (I'm not > sure, as this could be a font problem as well). Also, and this is > confirmed, there is now no way to request a right to left paragraph, at > all. Numbers I haven't checked. > > Again, I may have misunderstood what change you meant for me to try. If > you don't want to be misunderstood, try just sending a patch. I'm more > than willing to help, but not if it means trying to decrypt what code > changes you are suggesting, or where in the 1200 lines file they are > meant to be. > >> forcedir means basically force every not-control character to that >> direction. >> > Which doesn't ring a bell as far as the Annex 9. I don't recall any such > thing there. They had a notion of "paragraph direction", which did > affect NEUTRALS, and only if they were placed on the border between > conflicting direction runs (and also the initial nesting level, of > course). The ONLY thing I recall that could cause a hard RTL or hard LTR > character to be rendered in the opposite direction was an LRO/RLO, which > was never used here. Thus, I say again, the change you offer seem out of > place in relation to the place you offer it, and it seems to me that > there is an error in your implementation of Annex 9. > I may have slightly misunderstood those flags then. I was under the impression that the FORCE flags would be similar to LRO/RLO. Instead they are probably more like LRE/RLE. If that is a real problem I will send in a patch. I would still rather prefer a real bidi implementation, so that selecting and deleting characters would work properly. To my defense, there was no real clarification for them in the source. Cheers, Maarten

Sept. 26, 2007

Re: Total bidi regression

by Shachar Shemesh

Maarten Lankhorst wrote: > Shachar Shemesh schreef: > >> Maarten Lankhorst wrote: >> >> >>> If you want it back try replacing this in font.c: >>> WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR >>> change FORCE to LOOSE, it should work then. >>> >>> >> I'm not sure what you are suggesting. >> >> WINE_GCPW_FORCE_RTL only appear on line 1089 of bidi.c, which reads >> >>> case WINE_GCPW_FORCE_RTL: forcedir = R; baselevel = 1; break; >>> >>> >> I'm not sure what you are suggesting I do with it. >> >> Either way, the change you are suggesting will only affect (if I >> understand the code correctly) the paragraph direction setting, where as >> I'm experiencing total lack of BiDi reordering of any kind. >> >> > Before arguing, you should really give it a try, it helps. ;-) > Sure thing. Just what, exactly, is "it"? What do you suggest I change, and what to? I am really asking you to be less ambiguous. If you mean to change the "FORCE" to "LOOSE", then things are slightly better in that same direction runs are at least now being reordered, but things are still at a huge regression. Neutrals (at least some neutrals, like space) seem to be incorrectly handled in mixed paragraphs (I'm not sure, as this could be a font problem as well). Also, and this is confirmed, there is now no way to request a right to left paragraph, at all. Numbers I haven't checked. Again, I may have misunderstood what change you meant for me to try. If you don't want to be misunderstood, try just sending a patch. I'm more than willing to help, but not if it means trying to decrypt what code changes you are suggesting, or where in the 1200 lines file they are meant to be. > forcedir means basically force every not-control character to that > direction. > Which doesn't ring a bell as far as the Annex 9. I don't recall any such thing there. They had a notion of "paragraph direction", which did affect NEUTRALS, and only if they were placed on the border between conflicting direction runs (and also the initial nesting level, of course). The ONLY thing I recall that could cause a hard RTL or hard LTR character to be rendered in the opposite direction was an LRO/RLO, which was never used here. Thus, I say again, the change you offer seem out of place in relation to the place you offer it, and it seems to me that there is an error in your implementation of Annex 9. > Cheers, > Maarten > Shachar

Sept. 26, 2007

Re: Total bidi regression

by Maarten Lankhorst

Shachar Shemesh schreef: > Maarten Lankhorst wrote: > >> If you want it back try replacing this in font.c: >> WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR >> change FORCE to LOOSE, it should work then. >> > I'm not sure what you are suggesting. > > WINE_GCPW_FORCE_RTL only appear on line 1089 of bidi.c, which reads >> case WINE_GCPW_FORCE_RTL: forcedir = R; baselevel = 1; break; >> > I'm not sure what you are suggesting I do with it. > > Either way, the change you are suggesting will only affect (if I > understand the code correctly) the paragraph direction setting, where as > I'm experiencing total lack of BiDi reordering of any kind. > Before arguing, you should really give it a try, it helps. ;-) forcedir means basically force every not-control character to that direction. Cheers, Maarten

Sept. 26, 2007

Re: [PATCH] [2/2] winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUse

by Peter Oberndorfer

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

Sept. 26, 2007

Re: Total bidi regression

by Shachar Shemesh

Maarten Lankhorst wrote: > > If you want it back try replacing this in font.c: > WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR > change FORCE to LOOSE, it should work then. > I'm not sure what you are suggesting. WINE_GCPW_FORCE_RTL only appear on line 1089 of bidi.c, which reads: > case WINE_GCPW_FORCE_RTL: forcedir = R; baselevel = 1; break; I'm not sure what you are suggesting I do with it. Either way, the change you are suggesting will only affect (if I understand the code correctly) the paragraph direction setting, where as I'm experiencing total lack of BiDi reordering of any kind. All codes taken from latest git. > Cheers, > Maarten > Thanks, Shachar

Sept. 26, 2007

Re: [PATCH 2/2] configure: Build wine-kthread on FreeBSD.

by Tijl Coosemans

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.

Sept. 26, 2007

Re: [PATCH 1/2] loader: Reduce data segment size in wine-pthread/kthread on FreeBSD.

by Tijl Coosemans

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.

Sept. 26, 2007

Re: [5/5] WineD3D: Add sincos support to arb shaders

by H. Verbeet

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?

Sept. 26, 2007

Re: RICHED20: EM_SETCHARFORMAT must return 0, not assert, on invalid struct size (try 2)

by Alexandre Julliard

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

Sept. 26, 2007

address space layout

by Tijl Coosemans

Hi all! I had a user running FreeBSD 6.2, Xorg 7.3, ATI r200 DRI driver report a problem where running Warcraft3 crashed because it ran out of malloc heap space. The error was: Assertion failed: (texObj->DriverData != NULL), function r200BindTexture, file r200_tex.c, line 1098. fixme:ntdll:FILE_GetNtStatus Converting errno 12 to STATUS_UNSUCCESSFUL This error happens inside the r200 driver, errno 12 means ENOMEM. There was a bug report with a patch over at http://bugs.freedesktop.org/show_bug.cgi?id=12184 The patch gets rid of the assertion failure by doing proper error checking, but it doesn't solve the underlying problem of course, causing a NULL pointer dereference in Wine somewhat later: wine: Unhandled page fault on read access to 0x00000058 at address 0x7e99cc84 (thread 0009), starting debugger... This isn't the first time such a problem appears, especially with games, so ultimately a solution has to be found. The problem is that the way Wine wants to setup the address space is really somewhat incompatible with the way FreeBSD mmap and malloc work. FreeBSD mmap allocates from the end of a process data segment upwards towards the stack. Linux mmap allocates from the stack downwards. FreeBSD (<7.x) malloc doesn't fall back to mmap when it runs out of space in the data segment. Linux malloc does (I've been told). Because the wine process loads itself at 0x7bf00000, this means on FreeBSD with mmap going up, both the data segment and all shared objects (like builtin dlls) sit squeezed between that address and 0x80000000 since addresses above 0x80000000 can't be used for builtin dlls. It's about 64Mb which is currently split 50/50 between heap space and shared objects. This works in a lot of cases, but sometimes a 32Mb heap isn't enough like in the example above, where I assume it's been taken up by textures and other graphics data. Linux doesn't have this problem because mmap allocates shared objects from 0x80000000 downwards and can go beyond the address where wine is loaded if necessary. It can allocate extra heap space this way too when needed. Alexandre and I discussed this a couple weeks ago, but didn't really come up with anything. The problem back then (WoW) has since gone away (turned out to be a memory leak somewhere) so everything was left the way it was. Now it has turned up again however with a different program on a different setup, so it's something that really needs to be looked at. It could again be a memory leak in some other project's code, but then that just means the current situation isn't robust enough to deal with that, since it all does work on Linux. It appears that the only solution is to locate wine somewhere after 0x80000000 instead of at 0x7bf00000 and to allow mmap to allocate memory there. Then the data segment size limit can be set to 256Mb or something instead of 32Mb. The problem is then that builtin dlls are mmapped (by the runtime linker) well beyond 0x80000000. Now I'm thinking, would it be possible to load dummy dlls somewhere in the first 2Gb of address space? Through which API calls can a program determine a dll is above 0x80000000 by the way?

Sept. 26, 2007

Re: Total bidi regression

by Maarten Lankhorst

Shachar Shemesh schreef: > 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 > If you want it back try replacing this in font.c: WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR change FORCE to LOOSE, it should work then. Cheers, Maarten

Sept. 26, 2007

Re: Cannot compile wine due to recent changes

by Chris Robinson

Hi. Thanks, I sent a patch to wine-patches which should fix this. If anyone has an older version of XOrg with XComposite and can verify there's no other missing functions, that'd be great.

Sept. 26, 2007

Total bidi regression

by Shachar Shemesh

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

Sept. 26, 2007

Cannot compile wine due to recent changes

by Kirill K. Smirnov

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

Sept. 26, 2007

Re: services.exe[2/8]: load services list from registry

by Alexandre Julliard

"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

Sept. 26, 2007

Re: [PATCH 4/6] Make ntdll I/O function to generate completion events

by Alexandre Julliard

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

Sept. 26, 2007

Re: [PATCH 2/6] Allow completion object to be attached to a fd object

by Alexandre Julliard

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

Sept. 26, 2007

Re: services.exe/advapi32[5/8]: move QueryServiceConfig to services.exe

by Robert Shearman

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

Sept. 26, 2007

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

by Konstantin Kondratyuk

Hello! > Your patch should probably fix both of those, then (and please ignore > my earlier comment.) I have resent my patch, having added in it the passed corrections. I have one more question. To add realization of new function, I can add it in struct WNetProvider? For example: typedef struct _WNetProvider { HMODULE hLib; PWSTR name; PF_NPGetCaps getCaps; DWORD dwSpecVersion; DWORD dwNetType; DWORD dwEnumScopes; PF_NPOpenEnum openEnum; PF_NPEnumResource enumResource; PF_NPCloseEnum closeEnum; PF_NPGetResourceInformation getResourceInformation; //my added function } WNetProvider, *PWNetProvider; It is correct? -- Best regards, Konstantin Kondratyuk.

Sept. 26, 2007

Re: RICHED20: EM_SETCHARFORMAT must return 0, not assert, on invalid struct size

by Alexandre Julliard

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

Sept. 26, 2007

Re: pdh: add tests for XP variant of api call

by Jeff Latimer

Hans Leidekker wrote: >> I am happy with that though the tests I added relate to the following >> paragraph where it says that XP requires the buffer parameter as well as >> the size at all times and testing shows that it returns >> PDH_INVALID_ARGUMENT. It also returns PDH_INSUFFICIENT_BUFFER instead >> of PDH_MORE_DATA. >> > Then I suggest to remove tests with a NULL buffer parameter and > accept both PDH_INSUFFICIENT_BUFFER and PDH_MORE_DATA in tests where > the specified buffer size is too small. > > I will give it a whirl. Ta Jeff

Sept. 26, 2007

Re: Recent BiDi changes

by Shachar Shemesh

Maarten Lankhorst wrote: >> On a related note - I haven't been able to get an answer to that one, >> not even through experimentation. Does anyone know whether Windows' >> Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates >> is crucially important when reordering characters. >> >> Shachar >> >> > I'm guessing utf-16, not 100% sure though. > Ok. Just so you know, this means the reordering code is buggy for UTF-16 aggregates. I suspect the classification code is too. From the recent changes to bidi.c: > if (odd(levels[lastgood])) > for (k = j - 1; k >= lastgood; --k) > lpOrder[done + k] = done + j - 1 - k; > An aggregate in an odd level will have its two part reversed, making it meaningless at best (at worst, the trailing part will match the leading part of the previous character, creating a totally unrelated legal character). I suspect you have a similar problem in the classification part of the code. I've gone over the tables (cursory glance), and haven't been able to find characters in the aggregate area that are naturally likely to receive an odd level. I also asked on the fribidi list several times, and got the reply that there are such letters, but no specifics. This has a lot to do with my inability to empirically test whether Windows handle these. My latest test was an attempt to run a string that has RLO through GetCharacterPlacement, but even that fails at the moment (not to mention that GetCharacterPlacement is an old interface under Windows, and is slightly depracated, despite not being documented as such). While it is true that the very fact that I'm having such a hard time in finding out whether aggregates are supported on Windows means that any bug we introduce because of lack of support for aggregates will be a rare one, I still would prefer not introducing bugs into Wine if they can be avoided. > Maarten > Shachar

Sept. 26, 2007

Re: shell32[1/2]: shlview: make the shell view control Unicode (fixesbuf #9767)

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > When the control class is Unicode the listview will be sending > LVN_GETDISPINFOW instead of LVN_GETDISPINFOA and filenames with > charactes outside of the ACP will display properly. > I'm changing the type of a define from the include/ directory but > that's a define not present in the Windows SDK. If that define doesn't present in SDK it shouldn't be in Wine either. > --- a/include/shlobj.h > +++ b/include/shlobj.h > @@ -149,7 +149,7 @@ typedef struct > */ > > typedef GUID SHELLVIEWID; > -#define SV_CLASS_NAME ("SHELLDLL_DefView") > +#define SV_CLASS_NAME ((const WCHAR[]){'S','H','E','L','L','D','L','L','_','D','e','f','V','i','e','w',0}) This construct is not portable. Please move this to appropriate source file, and use 'static const WCHAR ...' syntax. -- Dmitry.

Sept. 26, 2007

Re: comctl32: remove unneeded todo_wine, because test pass

by Dmitry Timoshkov

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > On Wednesday 26 September 2007 02:11:21 Lei Zhang wrote: > >> I can pick a new coordinate to fix this, but then the new hit test >> will be just as brittle as the current one. Anyone have better ideas >> on how to make these coordinate based tests more robust? > > I'd say we need to ship a set of fonts with compatible metrics at some point. All our bitmap fonts are from that category. -- Dmitry.

Sept. 26, 2007

Re: comctl32: remove unneeded todo_wine, because test pass

by Hans Leidekker

On Wednesday 26 September 2007 02:11:21 Lei Zhang wrote: > I can pick a new coordinate to fix this, but then the new hit test > will be just as brittle as the current one. Anyone have better ideas > on how to make these coordinate based tests more robust? I'd say we need to ship a set of fonts with compatible metrics at some point. -Hans

Sept. 26, 2007

Re: comctl32: remove unneeded todo_wine, because test pass

by Mikołaj Zalewski

> > I can pick a new coordinate to fix this, but then the new hit test > will be just as brittle as the current one. Anyone have better ideas > on how to make these coordinate based tests more robust? > For the toolbar tests I have been sending WM_SETFONT with GetStockObject(SYSTEM_FONT) . It seems to work fine. For the default font the results will vary depending on if corefonts are installed or not. Mikolaj

Sept. 26, 2007

Re: comctl32: remove unneeded todo_wine, because test pass

by Lei Zhang

On 9/25/07, James Hawkins <truiken(a)gmail.com> wrote: > On 9/25/07, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > > I am running make test an a fresh git fetch; git rebase origin and am > > getting this: > > > > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > > comctl32_test.exe.so monthcal.c && touch monthcal.ok > > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000000 lp=00000000 > > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > > monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 > > make[2]: *** [monthcal.ok] Fehler 1 > > > > This patch removes the todo_wine.. as it seems to work now. If this > > patch gets not accepted, please tell me why. > > > > Becuase it doesn't pass for other people, particularly Julliard; > otherwise, it would have been fixed by now. > > -- > James Hawkins > > > The monthcal layout is definitely incorrect. See http://bugs.winehq.org/attachment.cgi?id=4485 for an example. Commit 7495d814954420c16e21de40c3031a9c95385f56 (gdi32: Using a bitmap font as the fallback sans serif is a very bad idea.) change the fonts used for many people. This made the test pass for some simply because they got lucky. I see this because the monthcal test fails on my work machine but works on my home machine. I can pick a new coordinate to fix this, but then the new hit test will be just as brittle as the current one. Anyone have better ideas on how to make these coordinate based tests more robust?

Sept. 26, 2007

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

by Juan Lang

> The following condition in _globalEnumeratorAdvance() looks incorrect: > > for (; enumerator->providerIndex < providerTable->numProviders && > !(enumerator->dwScope & providerTable->table > [enumerator->providerIndex].dwEnumScopes); > enumerator->providerIndex++) I agree, that's not correct. > Other conditions and parameters look correctly. For example, function > NPOpenEnum() expects a dwScope, containing RESOURCE_CONNECTED, > RESOURCE_GLOBALNET or RESOURCE_CONTEXT. Ah, you're right. It's only where dwEnumScopes is used that it's being used incorrectly. Your patch should probably fix both of those, then (and please ignore my earlier comment.) Thanks, --Juan

Sept. 25, 2007

Re: Wine GSoC 2007 project membership

by Alexander Nicolaysen Sørnes

On Wednesday 26 September 2007 00:36:20 Juan Lang wrote: > > I received a passing evaluation in this year's GSoC, but I was not added > > to the Wine project hosting for 2007, does anyone here have the power to > > add me? > > If you mean on the wine wiki, you can edit that yourself, of course. > If you mean somewhere on Google's SoC site, you'll need to contact the > Google folks, e.g. Leslie. > --Juan Tanks for the short reply, man. I did contact Google, and they told me to contact our admin, whichh from the Google page appeared to be Dan Kegel, but he never replied to my mail. Alexander N. Sørnes

Sept. 25, 2007

Re: Wine GSoC 2007 project membership

by Juan Lang

> I did contact Google, and they told me to contact our admin, whichh from the Google > page appeared to be Dan Kegel, but he never replied to my mail. Ah, right. He's probably the right person, and he reads this list, so hopefully you've got his attention now ;) --Juan

Sept. 25, 2007

Re: Wine GSoC 2007 project membership

by Juan Lang

> I received a passing evaluation in this year's GSoC, but I was not added to > the Wine project hosting for 2007, does anyone here have the power to add me? If you mean on the wine wiki, you can edit that yourself, of course. If you mean somewhere on Google's SoC site, you'll need to contact the Google folks, e.g. Leslie. --Juan

Sept. 25, 2007

Wine GSoC 2007 project membership

by Alexander Nicolaysen Sørnes

Hello all, I received a passing evaluation in this year's GSoC, but I was not added to the Wine project hosting for 2007, does anyone here have the power to add me? Alexander N. Sørnes

Sept. 25, 2007

Re: comctl32: remove unneeded todo_wine, because test pass

by James Hawkins

On 9/25/07, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > I am running make test an a fresh git fetch; git rebase origin and am > getting this: > > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > comctl32_test.exe.so monthcal.c && touch monthcal.ok > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 > make[2]: *** [monthcal.ok] Fehler 1 > > This patch removes the todo_wine.. as it seems to work now. If this > patch gets not accepted, please tell me why. > Becuase it doesn't pass for other people, particularly Julliard; otherwise, it would have been fixed by now. -- James Hawkins

Sept. 25, 2007