June 2006 - Wine-Devel - list.winehq.org

Re: D3D9: Add a test for setting / getting vertex shader constants
by Raphael June 6, 2006

June 6, 2006

On Tuesday 06 June 2006 23:17, H. Verbeet wrote: > This is a test for Ivan's patch for shader constants > (http://source.winehq.org/git/?p=wine.git;a=commit;h=5f5969b3c5bd237277b8f2 >f1eaa4ddacce5fb63b) > > Changelog: > - Add a test for setting / getting vertex shader constants Simple testing :) can you add border tests in future: hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, MAX_VSHADER_CONSTANTS - 4, bool_in, 4); hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, MAX_VSHADER_CONSTANTS - 2, bool_in, 4); I'm interested to see how windows handle that :) Regards, Raphael

3 3

winedbg - setting breakpoint
by Stephen Clark June 6, 2006

June 6, 2006

Hello List, I am trying to get classic Myst to run again under wine. How do I set a breakpoint in it when it run by winevdm. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)

2 1

re: Hal and functions in setupapi
by Dan Kegel June 6, 2006

June 6, 2006

Christian wrote: > as I want to programm RegisterDeviceNotification also we > need a central way to handle hal stuff. > > So how should I go on? Use some own hal.c in setupapi or > add an global wine way to interact with hal? I think programs/explorer already registers for device notification with hal. You should look at that before you go on. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: APPDB patch
by Tony Lambregts June 6, 2006

June 6, 2006

EA Durbin wrote: > fixed typographical errors. > > > ------------------------------------------------------------------------ > > ? patch.diff > Index: TODO > =================================================================== > RCS file: /home/wine/appdb/TODO,v > retrieving revision 1.22 > diff -u -p -r1.22 TODO > --- TODO 12 Jun 2005 02:50:18 -0000 1.22 > +++ TODO 6 Jun 2006 02:19:34 -0000 > @@ -7,7 +7,7 @@ WineHQ Application Database TODO List > AppDB Todo: > > * Improve application/version submission process > - Currently a user submits an application/version and a admin reviews it and > + Currently a user submits an application/version and an admin reviews it and > either makes changes to it and accepts it or writes a comment and rejects it. Upon > rejection the submission is deleted > > There is no sense in keeping our todos in two places. We should probabably just point to the wiki in this file. http://wiki.winehq.org/AppdbInfo Tony Lambregts

1 0

Re: lstrlen(A/W) patch
by Andreas Mohr June 6, 2006

June 6, 2006

Hi, On Mon, Jun 05, 2006 at 09:24:24PM -0600, Clinton Stimpson wrote: > > I encountered a crash when using PAF 5.2. > > The following patch will fix the crash. > MSDN documentation says "*lstrlen* assumes that /lpString/ is a > null-terminated string, or NULL" MSDN documentation says many things... most of them wrong. ;-) (only slightly exaggerated, given Wine's experience with MSDN "correctness" over the years) IOW, I severely doubt that this is indeed the way Windows behaves, otherwise it'd have been fixed in Wine a long time ago already since apps would rely on and fully expect this behaviour of such a central and important function. Most likely you encountered application misbehaviour (feeding a NULL parameter to a function expecting non-NULL) due to a different Wine bug which thus caused the app to mis-step. Would be interesting to figure out why this happened (e.g. via +relay trace). Andreas Mohr

1 0

Wine updated in Fedora Extras!
by Neal Gompa June 6, 2006

June 6, 2006

Wine has been updated to 0.9.14 on May 30, 2006! So, this release took 6 days... Still, generally 3-5 days is pretty good estimation...

1 0

Re: winedbg: remove unneeded states from grammar (take 2)
by Alexandre Julliard June 6, 2006

June 6, 2006

Juan Lang <juan_lang(a)yahoo.com> writes: > Oops, last one had a missing brace. Sorry about that. > > ChangeLog: many states in the command-line parser were unnecessary, so > remove them Won't that make it impossible to use command keywords as identifiers in commands that accept them, like disass? Come to think of it, your previous NOCMD patch probably has the same issue. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Re: wined3d: Another GLSL shader status update
by fenix＠club-internet.fr June 6, 2006

June 6, 2006

----Message d'origine---- >A: wine-devel(a)winehq.com >De: Mike Hearn <mike(a)plan99.net> >Date: Tue, 06 Jun 2006 12:31:06 +0100 >Sujet: Re: wined3d: Another GLSL shader status update > >On Sun, 04 Jun 2006 12:04:21 -0400, Jason Green wrote: >> > This is an elaborate scheme with linked lists in each shader - is that >> > really necessary? >> > I'm very confused after reading the code (but maybe that's just me :) >> >> If we link the programs together every time the Set__Shader() is called, >> it brings performance to a halt (that what my glsl_hack4.diff did). > >Re: the recent discussion on code commenting and documentation, it'd be >nice if the patch explained this somewhere. It'd be even nicer still if at >some point one of you guys could take a break from the codeface and write >a chapter for the Wine Developer Guide on shaders and how all this works >... it seems incredibly opaque and the last thing we want is a re-run of >the DCOM situation where the only people who understood it left or hacked >on other things for a while and we lost the knowledge of how it worked. I Aggree that adding more comments about current architecture (at least on http://wiki.winehq.com/DirectX-Shaders and http://wiki.winehq.com/WineD3D) can help to better understand for non-d3d introduced wine hackers :) I was the first who delivered that code and it's my fault for the initial poor comments about architecture (who was understandable for opengl/directx hackers). We'll try to improve it (maybe beginning with "WineD3D for dummies" :) ) Anyway we are many who understand this code (and reviewing the flood of wined3d patches) so "DCOM situation" cannot happen :) >thanks -mike Regards, Raphael

1 0

Re: Re: [WINED3D 5/5] Remove constant type field in stateblock.
by fenix＠club-internet.fr June 6, 2006

June 6, 2006

----Message d'origine---- >Date: Tue, 06 Jun 2006 04:54:17 -0400 >De: Ivan Gyurdiev <ivg2(a)cornell.edu> >A: fenix(a)club-internet.fr >Copie à: wine-devel(a)winehq.org >Sujet: Re: [WINED3D 5/5] Remove constant type field in stateblock. > >Hi Raphael, > >Strange, your email shows up as an attachment. Yes it's my webmail who have strange behaviors :( > > + int i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start > > + 1)); > > should be: > > if (start > MAX_VSHADER_CONSTANTS - 1) return WINED3DERR_INVALIDCALL; > > UINT i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start + 1)); > > > as count and start are UINT (better to avoid ugliy > > unsigned/signed bugs). > >The current code checks if cnt < 0 later on. Yes but it was buggy :) MAX_VSHADER_CONSTANTS - (start + 1) can result on an unsigned overflow > > Anyway what windows do if (start + count > > > MAX_VSHADER_CONSTANTS) ? > > The code seems handle this case truncating the input > >It's possible that this is buggy [ I always thought it was off by one ], >or not handling this case properly. However, I've just copied the code >that was already there - unrolled the existing SetConstant function into >its callers, and made the change I was interested in. Fixing other bugs >would go into a separate patch. Ok, fine for me Waiting for more patches to review :) I'm really waiting to get my new GC to test last impressive work on shaders. Regards, Raphael

1 0

To K&R or not
by Molle Bestefich June 6, 2006

June 6, 2006

EA Durbin wrote: > >K&R style brack placements > > They are an eyesore and make things difficult to read. Highly subjective. I think K&R has distinct advantages, namely it unites the scope begin token with the relevant control statement. For me, this makes code easier and faster to read, since I can follow the indentation and arrive immediately at the relevant control statement. Also I think that K&R is nice in that it saves screen real estate, which again for me makes code easier to read because I can see more of it at once. I personally consider non-K&R style an eyesore because of this. CMIIW, but the only thing that non-K&R has going for it is that you can visually make out whether you've made the correct number of opening versus closing braces. I don't think that's much of an advantage, especially considering that any modern source code editor will highlight the starting brace or relevant control statement for you. That said, I don't care what people do, I can read both... In my perfect world though, my SCM client would convert source code to my preferred format on checkout, and to whatever universal format the repository uses on checkin. Ho hum...

7 11