March 2007 - Wine-devel - list.winehq.org

Re: wined3d: Replace inline static with static inline
by Ivan Gyurdiev 17 Mar '07

17 Mar '07

Why should "inline static" be replaced with "static inline". Does it improve compatibility with certain compilers? Also, does wine aim to be compliant with ANSI, C99, or somewhere in between (-gnu89)?

2 1

Bug [219] questions
by Vitaliy Margolen 17 Mar '07

17 Mar '07

I think people still having lots and lots of questions about why safedisc support is still not in Wine: > ------- Additional Comments From Speeddymon 2007-16-03 14:37 ------- > I think the problem (as is with most times a safedisc patch has been written) is > that the patch is either way too hacky, or is made by reverse engineering the > safedisc dll's from windows.. Most likely Ivan did not reverse the dll's as I > know he would not want to poison the tree, so my bet is that it is just too big > of a hack for Alexandre to commit, combined with the fact that it is nearly > impossible to break something like this up into smaller patches without > completely breaking everything. Can we get the "official" view on this? I'm tired of answering this sort of questions myself not knowing the exact reasoning behind. I know that there were plenty of "hacks" but there were number of reasonable pieces that could have been committed. Allowing other people continue work and improving upon. Also can we close that bug as LATER since Alexandre commented it will not be fixed until after 1.0? Vitaliy.

2 2

re: Hey all!!!!
by Dan Kegel 17 Mar '07

17 Mar '07

Stepha wrote: >To give a little info on my background, I've been programming for >roughly 10 years now...everything ranging from embedded & >microcontroller stuff (PIC / ARM) to high end MS Sloth Applications. > >Familiar with DirectX, OpenGL, C/C++, C#, x86/ARM/PIC Assembly... > >I am of course unfamiliar with the whole wine source code. >I did look over the rather daunting to-do list and wouldn't >even know where to start. =) I would suggest starting by doing a couple weeks of bug triage. See http://kegel.com/wine/qa/ Then, while still doing bug triage, start writing conformance tests to expose some of the bugs you're seeing. Getting conformance tests committed to the WineHQ tree is a good rite of passage :-) Then, once you have the hang of that, pick one of the bugs you've written a good conformance test for, and try to fix it. Have fun & stay in touch! - Dan

1 0

Re: [2/3] comctl32: Never draw item text with OPAQUE.
by Felix Nawothnig 17 Mar '07

17 Mar '07

(CCing wine-devel again) Dimi Paun wrote: >>Problem is that DrawText() for the subitems will also use the >>background color - which is wrong. > Why is it wrong? Because the "background color" isn't the background color of the list. And it's definitly not the text bkclr in gdi-context either - I hacked together an app to prove that: http://flexo.popuserv.org/test.c Now it seems getting rid of the OPAQUE completly is wrong, but for different reasons. > It seems to me that this is a bit of a problem: > > 3783 if (nSubItem == 0 || (cdmode & CDRF_NOTIFYITEMDRAW)) > 3784 prepaint_setup(infoPtr, hdc, &nmlvcd); > 3785 > 3786 /* in full row select, subitems, will just use main item's colors */ > 3787 if (nSubItem && uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)) > 3788 nmlvcd.clrTextBk = CLR_NONE; > > I guess the call to prepaint_setup should come _after_ the if > with FULLROWSELECT, no? Depends. Right now this code does nothing (and I was going to remove it anyway) - the only place where clrTextBk is read from is in prepaint_setup() - but prepaint_setup() is not called for subitems (and the CLR_NONE override is only done for subitems). > Also, I can't remember, but there was a reason why prepain_setup > was called just for the main item, why did you changed that? Because subitems can use different colors (see test app) and prepaint_setup() is where the colors are set up... Note that I don't change the notifications being passed or anything of their context (with the exception of the GDI context in the postpaint notification - but the GDI context should be saved & restored in between anyway, see the failing test I commited a few days ago) so I can't imagine how this could break anything. Felix

2 2

Re: This patch fixes bugzilla bug number 1001
by Dmitry Timoshkov 17 Mar '07

17 Mar '07

"Giles Cameron" <giles(a)gilesfreeserv.com> wrote: > +#define STATUS_DISCONNECTED ((NTSTATUS) 0x00000037) > +#define STATUS_NONEXISTENT_NET_NAME ((NTSTATUS) 0x00000037) > +#define STATUS_ENDPOINT_CLOSED ((NTSTATUS) 0x00000037) These defines don't look like proper status values, where did you find them from? -- Dmitry.

2 1

comctl32/tests: test failures
by Joris Huizer 17 Mar '07

17 Mar '07

I was looking at comctl32 files for signedness fixes (there's a lot of signedness warnings, though many can't be fixed easily) Just to be sure, I now and then check with `make test` just to catch mistakes I might have made -- though on this dll 'header' tests fail: header.c:1310: Test failed: Tests will fail as header size is 1x0 instead of 670x18 header.c:1199: Test failed: Invalid rect (0,0) (670,18) vs (0,0) (670,17) header.c:1217: Test failed: Invalid rect (0,0) (670,18) vs (0,0) (670,17) header.c:1220: Test failed: Invalid rect (0,0) (50,18) vs (0,0) (50,17) header.c:1223: Test failed: Invalid rect (50,0) (150,18) vs (50,0) (150,17) header.c:1226: Test failed: Invalid rect (150,0) (300,18) vs (150,0) (300,17) header.c:1244: Test failed: Invalid rect (0,0) (670,18) vs (0,0) (670,17) header.c:1247: Test failed: Invalid rect (0,0) (50,18) vs (0,0) (50,17) header.c:1250: Test failed: Invalid rect (50,0) (150,18) vs (50,0) (150,17) header.c:1253: Test failed: Invalid rect (150,0) (300,18) vs (150,0) (300,17) header.c:1256: Test failed: Invalid rect (0,0) (670,18) vs (0,0) (670,17) header.c:1275: Test failed: Invalid rect (0,0) (670,18) vs (0,0) (670,17) header.c:1278: Test failed: Invalid rect (0,0) (50,18) vs (0,0) (50,17) header.c:1281: Test failed: Invalid rect (150,0) (300,18) vs (150,0) (300,17) header.c:1284: Test failed: Invalid rect (0,0) (670,18) vs (0,0) (670,17) header.c:921: Test succeeded inside todo block: expected 1, got 1 err:header:HEADER_WindowProc unknown msg 1216 wp=0001 lp=00000064 err:header:HEADER_WindowProc unknown msg 1218 wp=0000 lp=00000001 err:header:HEADER_WindowProc unknown msg 1217 wp=0001 lp=00000000 Is something wrong on my computer? Should I add todo_wine to those lines? (That macro TEST_NMCUSTOMDRAW used in many of the lines makes adding that harder -- the macro itself needs tweaking for that) ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/

1 0

fixme:d3d_surface:IWineD3DSurfaceImpl_LoadTexture Surface in texture is only supported for level 0
by Kapila De Silva 17 Mar '07

17 Mar '07

Hi All, Im getting a lot of these errors when trying to run Everquest 2, and I was wondering if its something I could fix. Does anyone know why only level 0 is supported for this? I put some additional debug, and find EQ2 is calling this with levels up 1 - 9. Thanks in advance Kapila.

1 0

re: Benchmark quandary
by Dan Kegel 17 Mar '07

17 Mar '07

Tom wrote: >I have some benchmarks posted here: >http://wiki.winehq.org/BenchMark-0.9.5 >as well as here: http://wiki.winehq.org/BenchMark-0.9.6 > >And I have all the Graphics test in PCMark 04 running, >but the app is crashing between test, but if I run them >one at a time they will complete. I'm interested in the crashes. I don't see any bugzilla entries for PCMark; can you file one? Thanks! >The quandary is would posting the test results >from each test while not run as a whole but separately >be of use? and would this be unfair when comparing >the results against XP??? I think it would be of use, as long as you run the tests the same way on XP (or show that running them all at once gives the same results). You just have to add a disclaimer ("Tests run separately on Linux to avoid bug <insert link to bugzilla bug here>"). - Dan

2 1

IDirectInputAImpl_GetDeviceStatus
by Tom Spear 17 Mar '07

17 Mar '07

Hi all, I was looking at bug 3747, about the game Motorhead. This game crashes because IDirectInputAImpl_GetDeviceStatus always returns DI_OK due to being a stub.. The reporter came up with a <10 line hack to fix it, but a proper implementation would be better. There may be other games that suffer problems due to this not being implemented.. Perhaps someone could look into the feasibility of this as a GSoC project, or possibly could come up with a minimal non-stub implementation to keep games like that from crashing just because of a joystick? I made a bug for the stub function.. Bug 7770.. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

2 1

Tomb Raider Legends wine segfault with /dev/input/event*
by Tom Spear 16 Mar '07

16 Mar '07

Looking at bug 5721, the final comment has found the problem that causes this. The original issue in the bug is fixed, but a new one cropped up. Basically if the user doesn't have r/w access to /dev/input/event* then wine segfaults. What should happen is that wine should print an error on the console about it so that users that read the console output can fix this problem.. I dont know of the risks of allowing global r/w access to /dev/input/event* so maybe the error shouldnt necessarily say that, but if there are no problems with giving global r/w then it could say that.. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

1 0