- Wine-Devel - list.winehq.org

Re: DirectX 9
by Hiji April 26, 2005

April 26, 2005

--- Tom Wickline <twickline(a)gmail.com> wrote: > On 4/26/05, Oliver Stieber > <oliver_stieber(a)yahoo.co.uk> wrote: > > Hi all, > > > > I've been moving house over the past couple of > weeks > > which is why I dropped off the face of the earth > for a > > while. > > > > Between moving I've managed to get a lot more > DirectX > > 9 work done, Roller coster tycoon, Warhammer 40K, > > tenage mutat ninja turtles and the increadables > are > > now the same under WINE as Windows. Evil genius, > Kohan > > 2 and Axis and Allies have a few graphics problems > but > > are still playable and colin McRea raley 2004 now > > plays ok, but there are lot of graphics issues. i > > expect Settlers Heritige of the King and Myst 4 > will > > work but I haven't been able to test since I lost > the > > demo disk. hopefully the problems with Halflife2 > and > > world of warcraft are fixed, but again I don't > have > > coppies to test. > > > > There was some funds in the "Wine Party Fund" that > Jeremy offered others > to purchase games for dev/testing. So you may want > to contact Jeremy about this. > > Tom Also, FYI: http://half.ebay.com and the amazon.com marketplace (used) usually have pretty good deals on games! :) Also, if you're in the U.S., Target's clearance endrack has good deals too. (I bought Spiderman, Catwoman, and The Hobbit for about $5 USD each!) Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: D3D9 Work?
by Oliver Stieber April 26, 2005

April 26, 2005

--- Benjamin Cutler <cutler(a)cs.colostate.edu> wrote: > I was discussing this with some others who hang out > in the #winehackers > channel, and I'm curious who else might be working > on the D3D9 portion > of Wine. I was unsure of how ready for inclusion > into the main branch > the unofficial patches are, but I've heard from a > couple sources that > most of the patch isn't. I'd like to get some > opinions on what's ready > and what's not. I'd hate to start submitting pieces > of the patch, only > to find out that person X was already working on > that part and had > something better in mind, or even worse to find out > that somebody's been > maintaining contact with Oliver and I'm just getting > overeager to see > the patches in Wine. > > Somebody also mentioned that there are others > waiting for Oliver's > patches to be submitted so that they can continue > their D3D9 work, so I > was curious if there were any of you out there that > fall into that category. > I too have been keen to merge the work with winehead, this hasn't happen todate for a couple of reasons. 1: I've been moving house so I an afford to continue directX 9 work. 2: Because a lot of the work I was doing involved interface a structure changes large areas of the code were affected, combining this with the day or two turn around with patches into wine cvs and I was spending more time merging with wine than developing directX. Because the patches I would send into winecvs would be outdated so quickly I was reluctant to send them in. The work has now stabalise a lot, so sending in patches should be troublesome, I never managed to figure out how to work svk properly. Oliver. Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: Add strncpyW to unicode.h
by Jeff Latimer April 26, 2005

April 26, 2005

I have just been reading the lists and realise that strncpyW/strncpy is bad news for some reason. Please consider this patch withdrawn. Wouldn't it be better to implement strncpyW as a wrapper for memcpy? Given that all the other string functions are implemeted with the (W) version, having strncpyW missing is a bit confusing. Jeff Latimer Jeff Latimer wrote: > An implementation of strncpyW. > > Jeff Latimer > >------------------------------------------------------------------------ > >Index: unicode.h >=================================================================== >RCS file: /home/wine/wine/include/wine/unicode.h,v >retrieving revision 1.31 >diff -u -r1.31 unicode.h >--- unicode.h 21 Apr 2005 17:18:50 -0000 1.31 >+++ unicode.h 25 Apr 2005 10:48:05 -0000 >@@ -191,6 +191,18 @@ > return dst; > } > >+static inline WCHAR *strncpyW( WCHAR *dst, const WCHAR *src, int maxlen ) >+{ >+ WCHAR *p = dst; >+ if (maxlen > 0 ) >+ { >+ maxlen--; >+ while (((*p++ = *src++) && maxlen--)); >+ } >+ if (*p) *p++ = (WCHAR) "\0"; >+ return dst; >+} >+ > static inline int strcmpW( const WCHAR *str1, const WCHAR *str2 ) > { > while (*str1 && (*str1 == *str2)) { str1++; str2++; } > >

2 3

ComboBoxEx focus bug
by felix.nawothnig＠t-online.de April 26, 2005

April 26, 2005

Hi. I'm trying to fix PR 1114 and ran into the following problem: The listbox of WinRAR isn't updated because CBN_SELENDOK isn't sent. CBN_SELENDOK is supposed to be sent by CBRollUp() called by the LBN_SELCHANGE handler but isn't because the listbox (of the combobox) is already rolled up when LBN_SELCHANGE is received. The premature CBRollUp() is caused by a click into the combo/listbox which SetFocus()es the listbox which causes a KILLFOCUS sent to the edit control which was holding the focus before and then forwards the KILLFOCUS to it's parent (the ComboLBox) which rolls the listbox up and issues CBN_SELENDCANCEL. (This causes also a visible difference between native and builtin comctl32 - native ComboBoxEx rolls up on mouseup, ours rolls up on mousedown) So the problem is that the editbox has the focus although the listbox is rolled down - this is the case for DROPDOWN comboboxes but only possible since the listbox takes care of this special case and forwards the focus to the edit control. Since a ComboBoxEx is a DROPDOWNLIST with an edit control drawn itself the editbox has to lose the focus when the listbox is rolled down. The listbox code actually takes care of that and sets the focus to the listbox if it's not child of a DROPDOWN CB but the CBN_SETFOCUS handling in comboex.c sets the focus back to the edit control for some reason, stating: * We also need to set the focus back to the Edit control * after passing the command to the parent of the ComboEx. Putting an "case CBN_SETFOCUS:" before the CBN_SELENDOK case (making sure that the focus isn't set to the edit control after a CBN_SETFOCUS) makes WinRAR work, makes the listbox roll up on mouseup (looks exactly like native comctl32) and doesn't seem to cause any problems. However, if the ComboBoxEx receives another CBN_* (except those handled by case statements which all *don't* set the focus to the edit box) I think it will set the focus back to the edit control (although the listbox is still rolled down) and when the user then selects an item it will again roll up and send CBN_SELENDCANCEL. So would it be right to completly remove the focus-forwarding to the edit control? (Since I know nothing about Win32 programming, the comments talk about MSIE4 expecting some specific behaviour and I don't wanna cause a regression I decided to ask here first :) -flexo

1 0

Re: Bug 2904
by Juan Lang April 26, 2005

April 26, 2005

> Hey guys, can one of you have a look at bug 2904? Isn't this the same thing? http://www.winehq.org/hypermail/wine-devel/2005/04/0494.html Whether or not the patch Michael attached is the "real" fix, it should solve the immediate problem (the assert failure.) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Exception in DefWindowProcA
by Paul Vriens April 26, 2005

April 26, 2005

Hi, when running proces explorer (V9.0.3) and some hacks, I get an exception in DefWindowProcA: trace:message:SPY_EnterMessage (0x20022) DefWindowProc32: WM_GETTEXT [000d] wp=00000100 lp=00000000 Call kernel32.WideCharToMultiByte(00000000,00000000,6b2592e0 L"Process Explorer - Sysinternals: www.sysinternals.com",ffffffff,00000000,00000100,00000000,00000000) ret=61b8be5 Ret kernel32.WideCharToMultiByte() retval=00000000 ret=61b8be52 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x61b8be5c It somewhat boils down to this piece of code in defwnd.c: line:754 if (wndPtr->text) { if (!WideCharToMultiByte( CP_ACP, 0, wndPtr->text, -1, dest, wParam, NULL, NULL )) dest[wParam-1] = 0; result = strlen( dest ); } else dest[0] = '\0'; WIN_ReleasePtr( wndPtr ); dest = NULL in my case so I added some tests for this: if (wndPtr->text) { if (!WideCharToMultiByte( CP_ACP, 0, wndPtr->text, -1, dest, wParam, NULL, NULL )) { if (dest) dest[wParam-1] = 0; } if (dest) result = strlen( dest ); else result = 0; } This makes the GUI appear but I want to find out if the call is valid or that we indeed should check for dest being NULL. Any ideas? Cheers, Paul.

1 0

Re: OLEAUT32: (resend) Floating point locale, no negative zero
by Alexandre Julliard April 26, 2005

April 26, 2005

Alex Villacis Lasso <a_villacis(a)palosanto.com> writes: > Changelog: > * Force Single|Double conversion to BSTR to use the decimal separator > defined by the current locale, because that is what native oleaut32 > does, and to be consistent with later parsing of floating-point > numbers, which uses current locale. Failure to apply this patch causes > vartype test to fail in non-US locales with a decimal separator other > than a period. > * The number form "-0" is *not* allowed to be returned in a > Single|Double conversion to BSTR in case of numeric undeflow, use > unsigned zero instead. Some applications depend on this. Test included. That's ugly, I think we really want to do our own formatting instead of using the system printf and hacking the string afterwards. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PATCH: gcc4 alias fixes
by Dan Kegel April 26, 2005

April 26, 2005

Dimitrie O. Paun wrote: >> This is the patch I use for gcc4.0 here. >> >> I am not really sure why this aliasing was introduced, >> but it will not work this way anymore. > > I still don't understand why it doesn't work. > > It was introduced because using macros it not always acceptable. > Some source uses these functions in ways that break if they are > defined as macros. > > Defining them as inline functions work, but we can't do so for > varargs, in which case we used aliases. > > What was the reason to break them, and why they don't work? > They are aliasing to things that _are_ defined, so I'm not > sure what is going on there. http://www.gnu.org/software/gcc/gcc-4.0/changes.html says (not that I really understand it totally): --- snip --- Given __attribute__((alias("target"))) it is now an error if target is not a symbol, defined in the same translation unit. This also applies to aliases created by #pragma weak alias=target. This is because it's meaningless to define an alias to an undefined symbol. On Solaris, the native assembler would have caught this error, but GNU as does not. --- snip --- - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

How to deal with different struct sizes per OS
by Paul Vriens April 26, 2005

April 26, 2005

Hi, while dealing with the SYSTEM_PROCESS_INFORMATION struct in winternl.h I found that the struct has different sizes for NT/W2K/W2K3. How do we deal with this? Have a struct per OS and deal with it in the handling part (ntdll/nt.c in this case) for what *version* returns? Should the default one be the most extensive one? We obviously need a run-time check. While I'm at it, this struct contains another struct (VM_COUNTERS). Do we want the seperate items in SYSTEM_PROCESS_INFORMATION or a reference to VM_COUNTERS? (VM_COUNTERS looks cleaner). Cheers, Paul Vriens.

1 0

Bug 2904
by Dustin Navea April 25, 2005

April 25, 2005

Hey guys, can one of you have a look at bug 2904? The reporter left a slightly barebones report, but I was able to find the patch that caused the problem, and posted all the relevant info I could find in my comments. Hopefully someone can write up a quick fix.. Thanks Dustin P.S. It's great to be back maintaining the database.. Now for all those bugs Ive missed over the last couple of years! ;-)

1 0