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

Re: Wine VM86 exception handling bug?

by Detlef Riekenberg

Am Montag, den 05.06.2006, 11:58 +0100 schrieb Mike Hearn: > On 6/5/06, Robert Shearman <rob(a)codeweavers.com> wrote: > > It depends whether it's in a convenient form. For a 100-byte COM file, > > it is probably already in its most convenient form. > > If, like Rob, you are an i386 ninja master who wields a disassembler > as most of us wield a knife and fork then yes maybe :) For the rest of > us source code can be occasionally convenient <chuckle> bin86 (BCC, together with as86 and ld86) might help wine. Bruce Evans C Compiler can create COM-Files Updates are done by Robert de Bath Homepage: http://freshmeat.net/redir/bin86/743/url_homepage/~mayday -- By By ... ... Detlef

June 5, 2006

Re: msi patch submission - cond.y

by EA Durbin

Then what are the conditional statements in cond.y used for? Though they may not be SQL errors, if IGE and ILEmeans IS Greater than or equal to, or Is Less than or Equal to then it's still and error, even if it doesn't pertain to SQL. Do these not mean IS Greater than or equal to, or Is Less than or Equal to ? >From: Mike McCormack <mike(a)codeweavers.com> >To: wine-devel(a)winehq.org >CC: ead1234(a)hotmail.com >Subject: Re: msi patch submission - cond.y >Date: Mon, 05 Jun 2006 22:43:09 +0900 > > >EA Durbin wrote: >>fixed various SQL errors in COND_GetOperator() and compare_int() > >Unfortunately cond.y has nothing to do with SQL. > >Mike

June 5, 2006

Re: msi patch submission - cond.y

by Hans Leidekker

On Monday 05 June 2006 15:33, EA Durbin wrote: > Is IGE not is greater than or equal to, and shouldn't the sign for that be > >= rather than <=, or does IGE mean something else, perfect example of > were comments should be, after all the function should be written perfectly I don't think that's entirely fair to Mike, IMO his code is about the most readable I have encountered in Wine. The meaning of the constant IGE can be easily deduced from reading the code. Furthermore, a little searching turned up this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/… i.e. an overview of msi condition operators. -Hans

June 5, 2006

Re: To <space> or <tab> or not :-)

by Molle Bestefich

Robert Shearman wrote: > Perhaps you could post your coding style rants on a blog somewhere, Yeah, sorry. It was a joke on the K&R discussion - hence the smiley in the subject ;-).

June 5, 2006

Re: To <space> or <tab> or not :-)

by Stephen Clark

Molle Bestefich wrote: >>isn't it rather insane to require specific editor settings >>just to be able to *view* the code? >> >> > >It's a necessity for some editors. > >The TAB setting can be embedded in ASCII files, there are various >magic comments that will cause vim and emacs to switch to a readable >tabs setting. > >What is insane is 8 characters per tab. > >IMHXP 2 characters is too little to quickly make out the indentation. >3 and 4 are both fine choices. 4 wastes slightly more horizontal >space, so I prefer 3. > >8 is just nuts, it was probably written by someone who hates tabs and >wants to use it as an argument to convince everybody to convert to >spaces. > >Using spaces in place of tabs is bad, because you have to press ><backspace> and <space> so much the more, wasting your time and >tearing your fingers. And there's a higher risk of misaligning >something - you have to pay more attention, which again is a waste of >your time. > >You loose fine-grained control when you use tabs instead of spaces, >but fine-grained control also means a jungle of bizarre rules about >when-and-where-to-do-fine-grained-indenting, so it never pays off, >rather it always ends up ruining the indentation anyway. By far the >easiest solution is to just use tabs, and just indent codelines that >span more than a screenful (7x chars or what not) with an extra tab. > > > > I agree with this 100%. With tabs you can set the indentation to whatever you want. Cheers, 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)

June 5, 2006

Re: msi patch submission - cond.y

by Mike McCormack

EA Durbin wrote: > fixed various SQL errors in COND_GetOperator() and compare_int() Unfortunately cond.y has nothing to do with SQL. Mike

June 5, 2006

Re: To <space> or <tab> or not :-)

by Robert Shearman

Molle Bestefich wrote: >> isn't it rather insane to require specific editor settings >> just to be able to *view* the code? > > > It's a necessity for some editors. > > The TAB setting can be embedded in ASCII files, there are various > magic comments that will cause vim and emacs to switch to a readable > tabs setting. > > What is insane is 8 characters per tab. This argument is pointless. Until you add a new file to Wine you should use the existing coding style. Perhaps you could post your coding style rants on a blog somewhere, rather than on wine-devel? -- Rob Shearman

June 5, 2006

Re: msi patch submission - cond.y

by EA Durbin

Is IGE not is greater than or equal to, and shouldn't the sign for that be >= rather than <=, or does IGE mean something else, perfect example of were comments should be, after all the function should be written perfectly so it can be interpreted without any comments in the code. After all Hans fixed the ILE in compare-int() so he must have assumed the same thing I did from that block of code. Or does ILE and IGE mean something totally different than is Greater than or equal to, or is less than or equal to? We don't know we didn't write the code and we're trying to view it from an outside perspective to determine how it works. >From: Mike McCormack <mike(a)codeweavers.com> >To: EA Durbin <ead1234(a)hotmail.com> >CC: wine-devel(a)winehq.org >Subject: Re: msi patch submission - cond.y >Date: Mon, 05 Jun 2006 19:37:43 +0900 > > >EA Durbin wrote: >>fixed various SQL errors in COND_GetOperator() and compare_int() > >IMO, both of your patches are incorrect. I'm waiting for your test case. > >Mike

June 5, 2006

Re: How are we doing?

by Molle Bestefich

Dmitry Timoshkov wrote: > I'd suggest to return and carefully reread the whole paragraph I've > quoted and replied to. It has nothing to do with a constructive talk > about commenting the code, instead it's full of insults and hits. It has everything to do with a constructive talk about comments. I strongly disagreed with Mike at the time, and I told him so. It never induces a nice and fuzzy feeling to be told by someone else that they think you're very wrong, but I was in no way imposing insults or hits. If I wanted to insult someone, I'd say: "Dmitry, go see the doctor about that layer of dirt you have between your eyes and your brain that is grossly obscuring your view on anything I say." Honestly, I think that you just don't like me and that's why you comprehend everything I write in an extremely prejudicious, negative manner. That's fine, you do that. But reading people's attitude from a simple email is tough to get right (as you've clearly shown). Therefore it would make me very happy if you could keep your very wrong conception of my attitude and person to yourself. Thank you. > I'm not even talking about using the word "foreigners" for the > contributors to the open source international project. Apologies if that was insulting, perhaps I was too short on words. I meant "speakers of english where that language is not their first language / mother's tongue", not necessarily foreigners in relation to whatever country it was that you thought I meant. I'm not even sure what you're accusing me of (racism?), but I hope that was better? > I'd call the foreigners that kind of people who sends messages like the one > I replied to, clearly that people absolutely don't understand what they are > talking about. Don't make such accusations without backing it up with some proof. You might have a point, who knows, but if you just shout out rants like the above, you're going to present yourself as just being full of BS. > I apologize for my harsh wording, but I just can't stay aside when I see > accusations like that one. I think you're the one who's full of accusations. > When people are interested to contribute > code they ask *technical* questions. What exactly is that supposed to mean? Jeremy White wrote: > Fair enough; I did reread that paragraph, > and I can see a case for you being offended. I still don't see it, so if anyone could enlighten me, that would be nice. Just making guesses, is it this?: | You may need to perfect the english phrasing from | some of the foreigners around here once they learn | to actually write the comments, but that's a minor nit. That could be interpreted as "only native english speakers know how to write good comments". I didn't think about it that way, because that's so utterly absurd that it would never occur to me. Obviously (to me), _that_ wasn't what I meant. What I meant by "they" was "everyone". Apologies for the unthoughtful wording above, if that indeed was your problem (Dmitry). > I don't think it was meant that way; I think it was more > of a canonical rant, but it was nevertheless a poor > choice of words. Perhaps it was too canonical. I felt that Mike's upfront and total dismissal of the request for useful comments with a simple joke was uncalled for. Sorry about that. > But I don't know Molle, and I do know you, so I > feel more comfortable yelling at you. Sorry :-/. Don't be sorry, you were just being fair - Dmitry is the one who's ranting and accusing here.

June 5, 2006

To <space> or <tab> or not :-)

by Molle Bestefich

> isn't it rather insane to require specific editor settings > just to be able to *view* the code? It's a necessity for some editors. The TAB setting can be embedded in ASCII files, there are various magic comments that will cause vim and emacs to switch to a readable tabs setting. What is insane is 8 characters per tab. IMHXP 2 characters is too little to quickly make out the indentation. 3 and 4 are both fine choices. 4 wastes slightly more horizontal space, so I prefer 3. 8 is just nuts, it was probably written by someone who hates tabs and wants to use it as an argument to convince everybody to convert to spaces. Using spaces in place of tabs is bad, because you have to press <backspace> and <space> so much the more, wasting your time and tearing your fingers. And there's a higher risk of misaligning something - you have to pay more attention, which again is a waste of your time. You loose fine-grained control when you use tabs instead of spaces, but fine-grained control also means a jungle of bizarre rules about when-and-where-to-do-fine-grained-indenting, so it never pays off, rather it always ends up ruining the indentation anyway. By far the easiest solution is to just use tabs, and just indent codelines that span more than a screenful (7x chars or what not) with an extra tab.

June 5, 2006

Re: rpcrt4: Introduce a new function, safe_multiply, which will raise an exception if a multiply overflows a 4-byte integer.

by Robert Shearman

Alexandre Julliard wrote: >Robert Shearman <rob(a)codeweavers.com> writes: > > > >>+ unsigned char overflow; >>+#if defined(__i386__) && defined (__GNUC__) >>+ __asm__( >>+ "mull %3\n\t" >>+ "seto %%cl" >>+ : "=a" (ret), "=c" (overflow) /* outputs: eax, cl */ >>+ : "%a" (a), "rm" (b) /* inputs: eax, any register or memory >>+ * address (params are interchangable) */ >>+ : "edx" /* edx clobbered */); >>+#else >>+ ret = a * b; >>+ overflow = (b && (ret / b != a)); >>+#endif >> >> > >That asm seems really overkill. Something like: > > ULONGLONG ret = (ULONGLONG)a * b; > if (ret > 0xffffffff) > >will generate pretty much the same code with a recent gcc, and it's a >lot more readable. > > Indeed it does. I'll resubmit the patch set with this change. -- Rob Shearman

June 5, 2006

Re: rpcrt4: Introduce a new function, safe_multiply, which will raise an exception if a multiply overflows a 4-byte integer.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > + unsigned char overflow; > +#if defined(__i386__) && defined (__GNUC__) > + __asm__( > + "mull %3\n\t" > + "seto %%cl" > + : "=a" (ret), "=c" (overflow) /* outputs: eax, cl */ > + : "%a" (a), "rm" (b) /* inputs: eax, any register or memory > + * address (params are interchangable) */ > + : "edx" /* edx clobbered */); > +#else > + ret = a * b; > + overflow = (b && (ret / b != a)); > +#endif That asm seems really overkill. Something like: ULONGLONG ret = (ULONGLONG)a * b; if (ret > 0xffffffff) will generate pretty much the same code with a recent gcc, and it's a lot more readable. BTW could you please add a sequence number in the subject line for your patches? It makes things a lot easier for me when the mails arrive out of order. Thanks. -- Alexandre Julliard julliard(a)winehq.org

June 5, 2006

Re: Wine VM86 exception handling bug?

by Andrey Turkin

I believe it is better to store binaries as arrays and use temporary files than drop many small .com binaries all over the code tree (for now I have 3 test programs about 30 bytes each). It is possible to comment/disassemble test cases instruction by instruction, if needed. Also, not everyone can use git, and I believe diff/patch would fail to produce patchable diffs with binary files in them. Mike Hearn wrote: > On 6/5/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: >> > I'd rather we got out of the habit of doing this seeing as I think >> git can >> > deal with binaries better than cvs can. >> >> There is no point in storing the binaries in the *source* tree, besides >> tiny .com file which shows the bug shouldn't take more than 100 bytes >> of an array in the .c file. > > Sure it might be small, but it's still a binary no matter how we store > it. It's not more useful as an array than as a true binary file on > disk. Why obfuscate and expand it by embedding it into a text file? > > thanks -mike > > >

June 5, 2006

Re: userenv: Add a stub implementation of userenv.dll

by Detlef Riekenberg

Am Montag, den 05.06.2006, 19:42 +0900 schrieb Mike McCormack: > > For mingw, this is in "include/userenv.h" > > Right. It's in include/userenv.h in the platform SDK too, however Wine > still doesn't have that header, > and I don't feel motivated to add it right yet... I know such Situations, but: It would be very nice. Please ..... -- By By ... ... Detlef

June 5, 2006

Re: Wine VM86 exception handling bug?

by Mike Hearn

On 6/5/06, Robert Shearman <rob(a)codeweavers.com> wrote: > It depends whether it's in a convenient form. For a 100-byte COM file, > it is probably already in its most convenient form. If, like Rob, you are an i386 ninja master who wields a disassembler as most of us wield a knife and fork then yes maybe :) For the rest of us source code can be occasionally convenient <chuckle> thanks -mike

June 5, 2006

Re: Wine VM86 exception handling bug?

by Robert Shearman

Mike McCormack wrote: > > Mike Hearn wrote: > >> Sure it might be small, but it's still a binary no matter how we store >> it. It's not more useful as an array than as a true binary file on >> disk. Why obfuscate and expand it by embedding it into a text file? > > > An LGPL'ed binary is a bit of a contradiction, isn't it? It depends whether it's in a convenient form. For a 100-byte COM file, it is probably already in its most convenient form. -- Rob Shearman

June 5, 2006

Re: userenv: Add a stub implementation of userenv.dll

by Mike McCormack

Detlef Riekenberg wrote: > For mingw, this is in "include/userenv.h" Right. It's in include/userenv.h in the platform SDK too, however Wine still doesn't have that header, and I don't feel motivated to add it right yet... Mike

June 5, 2006

Re: userenv: Add a stub implementation of userenv.dll

by Detlef Riekenberg

Am Montag, den 05.06.2006, 14:01 +0900 schrieb Mike McCormack: > +++ b/dlls/userenv/userenv_main.c > +typedef struct _PROFILEINFOA { ... > +} PROFILEINFOA, *LPPROFILEINFOA; For mingw, this is in "include/userenv.h" -- By By ... ... Detlef

June 5, 2006

Re: msi patch submission - cond.y

by Mike McCormack

EA Durbin wrote: > fixed various SQL errors in COND_GetOperator() and compare_int() IMO, both of your patches are incorrect. I'm waiting for your test case. Mike

June 5, 2006

Re: Wine VM86 exception handling bug?

by Mike McCormack

Mike Hearn wrote: > Sure it might be small, but it's still a binary no matter how we store > it. It's not more useful as an array than as a true binary file on > disk. Why obfuscate and expand it by embedding it into a text file? An LGPL'ed binary is a bit of a contradiction, isn't it? Mike

June 5, 2006

Re: Wine VM86 exception handling bug?

by Mike Hearn

On 6/5/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > I'd rather we got out of the habit of doing this seeing as I think git can > > deal with binaries better than cvs can. > > There is no point in storing the binaries in the *source* tree, besides > tiny .com file which shows the bug shouldn't take more than 100 bytes > of an array in the .c file. Sure it might be small, but it's still a binary no matter how we store it. It's not more useful as an array than as a true binary file on disk. Why obfuscate and expand it by embedding it into a text file? thanks -mike

June 5, 2006

Re: acad 2004 license file bug

by Jaap Stolk

On 6/5/06, Dan Kegel <dank(a)kegel.com> wrote: > Don't use winetools, please. As you noticed, it does bad things to > your ~/.wine. Ok. removed winetools and build a new ~/.wine/ > > (can wine fake internet explorer, > >so i don't need to install the real thing?) > > Yes. Here's what I do: > > # Fake IE per workaround in http://bugs.winehq.org/show_bug.cgi?id=3453 > wineserver -k > cat >> $HOME/.wine/system.reg <<"_EOF_" > > [Software\\Microsoft\\Internet Explorer] > "Version"="6.0.2900.2180" > _EOF_ > > - Dan Thanks. but it doesn't seem to fool autocad. I tried: WINEDEBUG=+server wine setup.exe > ~/mywinelog.txt but it still logs to stout and my system can't keep up with the scrolling. Is there a way to watch just the registry read/write ?

June 5, 2006

Feedback requested on an OpenAL audio driver patch

by Nick Burns

I finally figured out my dsound HEL problem (was making too many buffers) -- now I wait and only use a few buffers. It seemed to work well for GTA3, Tribes2 and FlatOut(requires a binary patch to run) (dsound) -- and for SndRec32 (win/wout) (Games and ...App... tested under Mac OSX x86 -- Mac Book Pro) Remove the disable 'OPENAL_DISABLE_IN' to test wavein. (Forced off due to some issues of my OpenAL framework (I could only record at 44k -- could not figure out how to force 44k only for wavein) -- others may have better luck) So here is my patch -- It adds it to winecfg, the makefile.in, configure.ac And it adds the new files (the actual driver why not) I would like any feedback ppl out there may have. (It is missing a ChangeLog thingy -- that would look like the below) ---- 2006-06-04 Nick Burns <adger44(a)hotmail.com> * configure.ac: Added checks for OpenAL (Mac OSX and linux). * dlls/Makefile.in: Added OpenAL to build thingy. * include/config.h.in: Added OpenAL to config -- using autoheader (may not be needed). * programs/winecfg/audio.c: Added OpenAL to winecfg for choosing. * dlls/winmm/wineopenal/openal.c, dlls/winmm/wineopenal/openal.h, dlls/winmm/wineopenal/audio.c, dlls/winmm/wineopenal/wineopenal.drv.spec, dlls/winmm/wineopenal/Makefile.in: Initial checkin of OpenAL driver. ---- - Nick

June 5, 2006

Light reading about .net framework 1.1 installer

by Dan Kegel

I just ran across an nice description of what the .net framework 1.1 installer uses during its execution: http://blogs.msdn.com/astebner/archive/2004/08/02/205936.aspx That's going to be a bit of a challenge. - Dan

June 5, 2006

Re: Added initial version of Wine OleView

by Dan Kegel

On 6/4/06, James Hawkins <truiken(a)gmail.com> wrote: > > Say, does it *do* anything useful yet? > > I advised Piotr to send in small-sized patches that implement a > feature at a time. For example, the first patch would just add enough > functionality to create a window, and possibly the menu bar. The next > couple of patches would start implementing the functionality. I see. It would help if he said in the preamble to the patch what functionality the patch adds. In this case it would have been "just adds skeleton, can't even create a window". IMHO that's not really enough functionality to be worth submitting by itsellf, but if part of a series, e.g. "OleView (patch 1 of 5)", it would be fine. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 4, 2006

Re: Added initial version of Wine OleView

by James Hawkins

On 6/4/06, Dan Kegel <dank(a)kegel.com> wrote: > Hi Piotr! > > Say, does it *do* anything useful yet? Might be worth > waiting until it does before submitting it. > - Dan > I advised Piotr to send in small-sized patches that implement a feature at a time. For example, the first patch would just add enough functionality to create a window, and possibly the menu bar. The next couple of patches would start implementing the functionality. Of course, all these patches can be sent at once, just one feature per patch to keep patch size down. -- James Hawkins

June 4, 2006

Re: Wine VM86 exception handling bug?

by Dmitry Timoshkov

"Mike Hearn" <mike(a)plan99.net> wrote: > On Fri, 02 Jun 2006 08:01:55 -0700, Dan Kegel wrote: >> You can embed a trivial DOS executable as data in the .c file > > I'd rather we got out of the habit of doing this seeing as I think git can > deal with binaries better than cvs can. There is no point in storing the binaries in the *source* tree, besides tiny .com file which shows the bug shouldn't take more than 100 bytes of an array in the .c file. -- Dmitry.

June 4, 2006

re: Added initial version of Wine OleView

by Dan Kegel

Hi Piotr! Say, does it *do* anything useful yet? Might be worth waiting until it does before submitting it. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 4, 2006

re: acad 2004 license file bug

by Dan Kegel

Jaap wrote: >The autocad installer indicated that I needed internet explorer 6.0, >so I installed that using winetools. Don't use winetools, please. As you noticed, it does bad things to your ~/.wine. Or, if you do use it, please report problems to the winetools developer, not here. > (can wine fake internet explorer, >so i don't need to install the real thing?) Yes. Here's what I do: # Fake IE per workaround in http://bugs.winehq.org/show_bug.cgi?id=3453 wineserver -k cat >> $HOME/.wine/system.reg <<"_EOF_" [Software\\Microsoft\\Internet Explorer] "Version"="6.0.2900.2180" _EOF_ - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 4, 2006

Re: GetDIBits() with a bitmap that is selected in a device context

by Dmitry Timoshkov

"Michael Kaufmann" <hallo(a)michael-kaufmann.ch> wrote: > The application "Fritz 5.32" calls GetDIBits() with a bitmap that is > still selected in a device context (see bug 3893). The bitmap has a > color table. GetDIBits() creates a memory DC, selects the bitmap into > this DC, and calls GetDIBColorTable(). But this fails, because Wine > can't select this bitmap in a memory device context again. According to > MSDN, calling GetDIBits with a bitmap that is selected in a device > context is not allowed. But surprisingly it works on Windows. > > Does anybody have an idea how to solve this problem? A very first step should be to write a test case and integrate it into the Wine GDI tests. -- Dmitry.

June 4, 2006

Re: How are we doing?

by Jeremy White

> I'd suggest to return and carefully reread the whole paragraph I've > quoted and replied to. It has nothing to do with a constructive talk > about commenting the code, instead it's full of insults and hits. I'm > not even talking about using the word "foreigners" for the contributors > to the open source international project. I'd call the foreigners that > kind of people who sends messages like the one I replied to, clearly > that people absolutely don't understand what they are talking about. > > I apologize for my harsh wording, but I just can't stay aside when I see > accusations like that one. When people are interested to contribute code > they ask *technical* questions. > Fair enough; I did reread that paragraph, and I can see a case for you being offended. I don't think it was meant that way; I think it was more of a canonical rant, but it was nevertheless a poor choice of words. But I don't know Molle, and I do know you, so I feel more comfortable yelling at you. Sorry :-/. Cheers, Jeremy

June 4, 2006

Re: Ecco Pro hangs when accessing "2nd level" dialogs

by Detlef Riekenberg

Hi Don. > I'm a long-time programmer with good (if rusty) knowledge of C/C++ and > Unix, just getting up to speed on Linux. I'm at the point where I might > be willing to tackle this myself, if the learning curve isn't too steep. Great, that you want to help wine. Did you already got some guidance? > least, if there's a good way to get more information on the hangup, I'm > definitely willing to add to the bug report. Wine has support for a lot of Debug-Options: WINEDEBUG="+relay,+seh" wine yourapp.exe 2>&1 >logfile.txt Wine will log every API-Call and the Result for any DLL, that is present in wine (+relay) and every exception (+seh). You can get a GB logfile very fast .... -- By By ... ... Detlef

June 4, 2006

Feedback requested for Mac OSX x86 stack patch

by Nick Burns

(notes are at the top of the patch) I would like some feedback on my stack fix patch I do not know how it interacts with linux -- no access to a linux box This has been confirmed to fix numerous app issues (due to stack alignment) I am starting to think it would be better to have these options configured at config time -- e.g. If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer Any ideas/thoughts? - Nick

June 4, 2006

Re: Prospects of an OpenAL audio driver...

by Nick Burns

OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes) -- My driver handles this atm -- it checks for recording capabilities and supports accordingly The OpenAL api is rather simple - For playback : you make buffers and queue them then poll them (to find out when they are done) There are some extensions that cut out copies/support eax/... (I have not looked at em yet) (support 2d and 3d audio) - For recording (1.1 only) : start capturing -- poll (get data -- if there) -- stop recording The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good) PortAudio looks like a good choice as well -- afaict -- but I dont have any exp with it (not that I had any openal exp when i started that driver hehe) ----- Should I just submit my driver to wine-devel and see what people think? It does work for wavein/waveout (still trying to flesh out a few issues) - Nick

June 4, 2006

Re: wined3d: Another GLSL shader status update

by H. Verbeet

On 04/06/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > Well, it seems to store a bit more than that. If I create pshaders A,B, > and vshaders C,D, and do: > set_pixel(A); set_vertex(C); > draw_stuff(); > set_pixel(B); set_vertex(D); > draw_stuff(); > set_pixel(NULL), set_vertex(NULL) > > Won't this create...5 different programs, all kept in memory for the > entire lifetime of the program, while we only need 2 [1 active]? > (A, NULL), (A,C), (B,C), (B,D), (NULL, D) I think it should be possible to change the code in such a way that the programs are only created once they're actually used. > Also, is it necessary to store link pair info in both shaders - isn't > this redundant somehow? Well, yes. When a shader is released, the programs it's linked to should be destroyed. However, it's probably not neccesary to point to the other shader. We could probably just link to a program struct that contains the program id and a list of linked shaders. It doubt it will make much of a difference wrt amount of memory used though, at least not as long as there are only two shaders involved. On the other hand, for d3d10 we'll also need geometry / primitive shaders.

June 4, 2006

acad 2004 license file bug

by Jaap Stolk

Hi, I'm new to wine, but I have used the wine source in the past as "unofficial" windows api documentation, to write decompilers etc. I would like to thank all the developers, I'm very impressed! I'm trying to install/run autocad 2004, or at least see where possible problems are. I first uninstalled the old rpm wine package in redhat, then I compiled from CVS and it al worked (apart from the waring about freetype not being detected) Compiling took almost 1.5 hours on an AMD Athlon 1200 Mhz 640Mb. The autocad installer indicated that I needed internet explorer 6.0, so I installed that using winetools. (can wine fake internet explorer, so i don't need to install the real thing?) The winetools RPM failed because i installed wine from CVS, so i installed winetools from source. winetools failed to detect my existing ~/.wine/drive_c/ and it seems to have overwritten everything i had in there. :-( anyway, the autocad installer now complains that the licence file could not be found, but this bug report indicates that this problem is supposed to be fixed: http://bugs.winehq.org/show_bug.cgi?id=3226 is it possible that it's fixed but the patch is not yet in CVS ? Should I try the suggested "fix": copy the bin/acadfeui/eula directory from the cd-rom to the c:\ root ? I would like to avoid native software if at all possible (like native MSI), and rather fix wine instead. Linux 2.4.20, RedHat 9, GCC 3.2.2, CVS 1.11.2, Wine 0.9.14 (today's cvs) Jaap.

June 4, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

I still can't fix it, perhaps you could have a deeper look Hans. >From: "EA Durbin" <ead1234(a)hotmail.com> >To: ead1234(a)hotmail.com, hans(a)it.vu.nl, mike(a)codeweavers.com >CC: wine-devel(a)winehq.org >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 04 Jun 2006 12:49:41 -0500 > > >Why when i edit the code to change this, does it revert back when i compile >it? > >>From: "EA Durbin" <ead1234(a)hotmail.com> >>To: ead1234(a)hotmail.com, hans(a)it.vu.nl, mike(a)codeweavers.com >>CC: wine-devel(a)winehq.org >>Subject: Re: FW: RE: My 1.0 wish list >>Date: Sun, 04 Jun 2006 12:12:18 -0500 >> >>I think i might actually see the problem. Let me test it. >> >>In cond.tab.c the regexes are all wrong for matching the comparison >>tests. >> >> >>{ {'~','<','=',0}, COND_IGE }, >> >>This should be parsing as >> >>{ {'~','>','=',0}, COND_IGE }, >> >> >> >>and >> { {'~','<',0}, COND_IGT }, >> >>we're matching a less than sign, so if it is matching the "<" it runs >>COND_IGT it should be >> >> { {'~','>',0}, COND_IGT }, >> >>>From: "EA Durbin" <ead1234(a)hotmail.com> >>>To: hans(a)it.vu.nl, mike(a)codeweavers.com >>>CC: wine-devel(a)winehq.org >>>Subject: Re: FW: RE: My 1.0 wish list >>>Date: Sun, 04 Jun 2006 11:59:25 -0500 >>> >>> >>>Nice Catch!!! >>> >>>But unfortunately no, it doesn't fix the problem, the test SELECT * FROM >>>TABLE WHERE testcondition >= testinteger is still returning the wrong >>>results. >>> >>>are we using the case COND_ILE when we compare for greater than or equal >>>to? Or just when less than or equal to? >>> >>>or does SELECT * FROM TABLE WHERE >= or > only call IGE or IGT? >>> >>> >>> >>>>From: Hans Leidekker <hans(a)it.vu.nl> >>>>To: "EA Durbin" <ead1234(a)hotmail.com> >>>>CC: wine-devel(a)winehq.org >>>>Subject: Re: FW: RE: My 1.0 wish list >>>>Date: Sun, 4 Jun 2006 11:29:49 +0200 >>>> >>>>On Sunday 04 June 2006 11:01, EA Durbin wrote: >>>> >>>> > It shouldnt matter whether its >= or >, they both return the wrong >>>>results >>>> > in the actual msi installer and the right results in db.c. >>>> >>>>Does this patch help? >>>> >>>> -Hans >>>> >>>>diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y >>>>index b32c417..47f858a 100644 >>>>--- a/dlls/msi/cond.y >>>>+++ b/dlls/msi/cond.y >>>>@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera >>>> return a >= b; >>>> case COND_LE: >>>> case COND_ILE: >>>>- return a >= b; >>>>+ return a <= b; >>>> case COND_SS: >>>> case COND_ISS: >>>> return ( a & b ) ? 1 : 0; >>> >>> >>> >>> >> >> > >

June 4, 2006

Re: wined3d: Another GLSL shader status update

by Ivan Gyurdiev

>> >> + if (wined3d_settings.shader_mode == SHADER_GLSL) >> + shader_glsl_add_instruction_modifiers(&hw_arg); >> >> If you choose to pull modifier handling out of the per-opcode function, >> this should be done for SHADER_ARB as well, imho. >> > > All of the ARB modifiers are run prior to the command. Whereas, (at > least so far), the GLSL instruction modifiers are necessary to run > after the command. Well, _SAT needs to go on the same opcode, but shifts for example go "after" the command. I have no idea how to do centroid right now. Anyway, it just seemed to me that they should be in the same place - either both in the generation fn, or both out of it, for consistency. There's a lot of SHADER_ARB opcodes right now that don't handle modifiers, while they need to do that, so we should think about centralized modifier processing [ or at least add modifier processing on the opcodes where it is missing ]. >> >> Those limits aren't checked against GL capabilities yet. >> The current 3.0 limit is 224 float constants - does this work properly? >> > > The limits should be checked against the caps in the functions that > set all of the limits based on the shader version. We should probably > do something like set all of the limits as they "should" be, then do a > min() against the GL caps. No, I think we need to do error reporting as well - a min would hide the bugs. If the app uses too many constants, we should probably abort and report that to the application somehow. Right now our shader function doesn't even return a status code - maybe it should ? >> +void shader_glsl_add_instruction_modifiers(SHADER_OPCODE_ARG* arg >> >> Doesn't seem to handle multiple modifiers - I think I changed this >> elsewhere recently. >> > > Possibly not. I just haven't hit (or noticed) that test case yet. I see _centroid with _pp sometimes, so since we ignore _pp that's not really an issue. Anyway, the spec says multiple output modifiers are allowed, so they should be supported. > >> + SHADER_PARAM_FCT_T param_fct; >> >> Please don't add any more fields that do not need to persist into base >> shader. Why are two different param functions needed? >> > > This method avoids the base class having to know about its subclasses. If the param functions aren't too different they should probably be merged together somehow. Also, fields like these would better go into the SHADER_OPCODE_ARG, not into the shader class - they're only used during generation. There's really no problem adding new fields into the arg structure - some of those don't need to be reset on every instruction, so they should just be set at the beginning when you start to generate code. >> 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). Everything was roughly 100 times slower that way. So, this > method stores the program for every combination which is used in the > app. Well, it seems to store a bit more than that. If I create pshaders A,B, and vshaders C,D, and do: set_pixel(A); set_vertex(C); draw_stuff(); set_pixel(B); set_vertex(D); draw_stuff(); set_pixel(NULL), set_vertex(NULL) Won't this create...5 different programs, all kept in memory for the entire lifetime of the program, while we only need 2 [1 active]? (A, NULL), (A,C), (B,C), (B,D), (NULL, D) Also, is it necessary to store link pair info in both shaders - isn't this redundant somehow? > That way, when the shaders are set, we already have a linked > program to use. Linking is a very expensive operation. Keeping a > list of them seems like the best method that we could come up with. Ok... I guess maybe it's necessary. > On a separate topic, we've learned that the reason that some of these > pixel shaders fail is because I've hard-coded texture2D() and just > assumed that the textures would be 2-dimensional (which is what the > ARB programs do now, too). > However, in ARB, only the instructions > that reference the 3D texture are failing. In GLSL, the entire shader > fails if one of the textures is wrong. So, this will have to be > thought out some more, since prior to PS 2.0, the app doesn't have to > declare if it's a 2D or a 3D texture ahead of time. Yes, I'm not really sure how this is handled prior to ps2, but surely there's tutorials online that explain this. Maybe the shader does its own per-type processing using those texreg2ar, and other instructions (tex matrix instructions?). For 2.0+ I can send you a patch, which probably works, but needs more testing. It stores the sampler types in the SHADER_OPCODE_ARG - I just changed the hw_tex function a little bit.

June 4, 2006

Re: FW: RE: My 1.0 wish list

by Huw Davies

On Sun, Jun 04, 2006 at 12:49:41PM -0500, EA Durbin wrote: > > Why when i edit the code to change this, does it revert back when i compile > it? You need to edit cond.y (bison generates cond.tab.c). Huw.

June 4, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

disregard that last stupid question, I looked at the Makefile. Like i said I'm not a C hacker, had to edit cond.y and not cond.tab.c. >From: "EA Durbin" <ead1234(a)hotmail.com> >To: ead1234(a)hotmail.com, hans(a)it.vu.nl, mike(a)codeweavers.com >CC: wine-devel(a)winehq.org >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 04 Jun 2006 12:49:41 -0500 > > >Why when i edit the code to change this, does it revert back when i compile >it? > >>From: "EA Durbin" <ead1234(a)hotmail.com> >>To: ead1234(a)hotmail.com, hans(a)it.vu.nl, mike(a)codeweavers.com >>CC: wine-devel(a)winehq.org >>Subject: Re: FW: RE: My 1.0 wish list >>Date: Sun, 04 Jun 2006 12:12:18 -0500 >> >>I think i might actually see the problem. Let me test it. >> >>In cond.tab.c the regexes are all wrong for matching the comparison >>tests. >> >> >>{ {'~','<','=',0}, COND_IGE }, >> >>This should be parsing as >> >>{ {'~','>','=',0}, COND_IGE }, >> >> >> >>and >> { {'~','<',0}, COND_IGT }, >> >>we're matching a less than sign, so if it is matching the "<" it runs >>COND_IGT it should be >> >> { {'~','>',0}, COND_IGT }, >> >>>From: "EA Durbin" <ead1234(a)hotmail.com> >>>To: hans(a)it.vu.nl, mike(a)codeweavers.com >>>CC: wine-devel(a)winehq.org >>>Subject: Re: FW: RE: My 1.0 wish list >>>Date: Sun, 04 Jun 2006 11:59:25 -0500 >>> >>> >>>Nice Catch!!! >>> >>>But unfortunately no, it doesn't fix the problem, the test SELECT * FROM >>>TABLE WHERE testcondition >= testinteger is still returning the wrong >>>results. >>> >>>are we using the case COND_ILE when we compare for greater than or equal >>>to? Or just when less than or equal to? >>> >>>or does SELECT * FROM TABLE WHERE >= or > only call IGE or IGT? >>> >>> >>> >>>>From: Hans Leidekker <hans(a)it.vu.nl> >>>>To: "EA Durbin" <ead1234(a)hotmail.com> >>>>CC: wine-devel(a)winehq.org >>>>Subject: Re: FW: RE: My 1.0 wish list >>>>Date: Sun, 4 Jun 2006 11:29:49 +0200 >>>> >>>>On Sunday 04 June 2006 11:01, EA Durbin wrote: >>>> >>>> > It shouldnt matter whether its >= or >, they both return the wrong >>>>results >>>> > in the actual msi installer and the right results in db.c. >>>> >>>>Does this patch help? >>>> >>>> -Hans >>>> >>>>diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y >>>>index b32c417..47f858a 100644 >>>>--- a/dlls/msi/cond.y >>>>+++ b/dlls/msi/cond.y >>>>@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera >>>> return a >= b; >>>> case COND_LE: >>>> case COND_ILE: >>>>- return a >= b; >>>>+ return a <= b; >>>> case COND_SS: >>>> case COND_ISS: >>>> return ( a & b ) ? 1 : 0; >>> >>> >>> >>> >> >> > >

June 4, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

Why when i edit the code to change this, does it revert back when i compile it? >From: "EA Durbin" <ead1234(a)hotmail.com> >To: ead1234(a)hotmail.com, hans(a)it.vu.nl, mike(a)codeweavers.com >CC: wine-devel(a)winehq.org >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 04 Jun 2006 12:12:18 -0500 > >I think i might actually see the problem. Let me test it. > >In cond.tab.c the regexes are all wrong for matching the comparison tests. > > >{ {'~','<','=',0}, COND_IGE }, > >This should be parsing as > >{ {'~','>','=',0}, COND_IGE }, > > > >and > { {'~','<',0}, COND_IGT }, > >we're matching a less than sign, so if it is matching the "<" it runs >COND_IGT it should be > > { {'~','>',0}, COND_IGT }, > >>From: "EA Durbin" <ead1234(a)hotmail.com> >>To: hans(a)it.vu.nl, mike(a)codeweavers.com >>CC: wine-devel(a)winehq.org >>Subject: Re: FW: RE: My 1.0 wish list >>Date: Sun, 04 Jun 2006 11:59:25 -0500 >> >> >>Nice Catch!!! >> >>But unfortunately no, it doesn't fix the problem, the test SELECT * FROM >>TABLE WHERE testcondition >= testinteger is still returning the wrong >>results. >> >>are we using the case COND_ILE when we compare for greater than or equal >>to? Or just when less than or equal to? >> >>or does SELECT * FROM TABLE WHERE >= or > only call IGE or IGT? >> >> >> >>>From: Hans Leidekker <hans(a)it.vu.nl> >>>To: "EA Durbin" <ead1234(a)hotmail.com> >>>CC: wine-devel(a)winehq.org >>>Subject: Re: FW: RE: My 1.0 wish list >>>Date: Sun, 4 Jun 2006 11:29:49 +0200 >>> >>>On Sunday 04 June 2006 11:01, EA Durbin wrote: >>> >>> > It shouldnt matter whether its >= or >, they both return the wrong >>>results >>> > in the actual msi installer and the right results in db.c. >>> >>>Does this patch help? >>> >>> -Hans >>> >>>diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y >>>index b32c417..47f858a 100644 >>>--- a/dlls/msi/cond.y >>>+++ b/dlls/msi/cond.y >>>@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera >>> return a >= b; >>> case COND_LE: >>> case COND_ILE: >>>- return a >= b; >>>+ return a <= b; >>> case COND_SS: >>> case COND_ISS: >>> return ( a & b ) ? 1 : 0; >> >> >> >> > >

June 4, 2006

Re: DAZ Studio

by Willie Sippel

Am Samstag, 3. Juni 2006 14:14 schrieb Andrew Neil Ramage: > After running winecfg and setting winver for DAZStudio.exe to XP, I get > the following. You're a user, not a developer I assume? If that's the case, let me tell you that DAZ|Studio won't work, anyway. Not even if you get beyond the crash dialog. Wine can't handle OpenGL viewports, which makes DAZ|Studio (and pretty much every other non-game 3D application) useless. -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

June 4, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

I think i might actually see the problem. Let me test it. In cond.tab.c the regexes are all wrong for matching the comparison tests. { {'~','<','=',0}, COND_IGE }, This should be parsing as { {'~','>','=',0}, COND_IGE }, and { {'~','<',0}, COND_IGT }, we're matching a less than sign, so if it is matching the "<" it runs COND_IGT it should be { {'~','>',0}, COND_IGT }, >From: "EA Durbin" <ead1234(a)hotmail.com> >To: hans(a)it.vu.nl, mike(a)codeweavers.com >CC: wine-devel(a)winehq.org >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 04 Jun 2006 11:59:25 -0500 > > >Nice Catch!!! > >But unfortunately no, it doesn't fix the problem, the test SELECT * FROM >TABLE WHERE testcondition >= testinteger is still returning the wrong >results. > >are we using the case COND_ILE when we compare for greater than or equal >to? Or just when less than or equal to? > >or does SELECT * FROM TABLE WHERE >= or > only call IGE or IGT? > > > >>From: Hans Leidekker <hans(a)it.vu.nl> >>To: "EA Durbin" <ead1234(a)hotmail.com> >>CC: wine-devel(a)winehq.org >>Subject: Re: FW: RE: My 1.0 wish list >>Date: Sun, 4 Jun 2006 11:29:49 +0200 >> >>On Sunday 04 June 2006 11:01, EA Durbin wrote: >> >> > It shouldnt matter whether its >= or >, they both return the wrong >>results >> > in the actual msi installer and the right results in db.c. >> >>Does this patch help? >> >> -Hans >> >>diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y >>index b32c417..47f858a 100644 >>--- a/dlls/msi/cond.y >>+++ b/dlls/msi/cond.y >>@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera >> return a >= b; >> case COND_LE: >> case COND_ILE: >>- return a >= b; >>+ return a <= b; >> case COND_SS: >> case COND_ISS: >> return ( a & b ) ? 1 : 0; > > > >

June 4, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

Nice Catch!!! But unfortunately no, it doesn't fix the problem, the test SELECT * FROM TABLE WHERE testcondition >= testinteger is still returning the wrong results. are we using the case COND_ILE when we compare for greater than or equal to? Or just when less than or equal to? or does SELECT * FROM TABLE WHERE >= or > only call IGE or IGT? >From: Hans Leidekker <hans(a)it.vu.nl> >To: "EA Durbin" <ead1234(a)hotmail.com> >CC: wine-devel(a)winehq.org >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 4 Jun 2006 11:29:49 +0200 > >On Sunday 04 June 2006 11:01, EA Durbin wrote: > > > It shouldnt matter whether its >= or >, they both return the wrong >results > > in the actual msi installer and the right results in db.c. > >Does this patch help? > > -Hans > >diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y >index b32c417..47f858a 100644 >--- a/dlls/msi/cond.y >+++ b/dlls/msi/cond.y >@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera > return a >= b; > case COND_LE: > case COND_ILE: >- return a >= b; >+ return a <= b; > case COND_SS: > case COND_ISS: > return ( a & b ) ? 1 : 0;

June 4, 2006

Re: wined3d: Another GLSL shader status update

by Jason Green

On 6/4/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > > + /* Declare textures samplers */ > + for(i = 0; i < /*This->baseShader.limits.texture */ 4; i++) { > +// if (reg_maps->texcoord & (1 << i)) > + shader_addline(buffer,"uniform sampler2D mytex%lu;\n", i); > + } > > What's the problem here? A lot of this is just from debugging. The code is still in the proof of concept phase. > > + if (wined3d_settings.shader_mode == SHADER_GLSL) > + shader_glsl_add_instruction_modifiers(&hw_arg); > > If you choose to pull modifier handling out of the per-opcode function, > this should be done for SHADER_ARB as well, imho. > All of the ARB modifiers are run prior to the command. Whereas, (at least so far), the GLSL instruction modifiers are necessary to run after the command. > + for (i=0; i<max_constants; ++i) { > ... > - for (i = 0; i <= WINED3D_VSHADER_MAX_CONSTANTS; ++i) { > > Is this fixing off-by-one bug in the old code in the process (or > introducing one)? > Possibly introducing - nice catch. > + loadConstants(iface, GL_VERTEX_PROGRAM_ARB, constants, > NULL, > + > vshader->baseShader.limits.constant_float, programId, TRUE); > > What's the purpose of the "skip_type_check" parameter - TRUE here. > Doesn't the current code only work for float constants anyway? > It's passing NULL as the type array (because VertexDeclaration constants are always floats and they don't have one). > + /* Update the constants */ > + loadConstants(iface, GL_FRAGMENT_PROGRAM_ARB, > This->stateBlock->pixelShaderConstantF, > + This->stateBlock->pixelShaderConstantT, > pshader->baseShader.limits.constant_float, > + programId, FALSE); > > Those limits aren't checked against GL capabilities yet. > The current 3.0 limit is 224 float constants - does this work properly? > The limits should be checked against the caps in the functions that set all of the limits based on the shader version. We should probably do something like set all of the limits as they "should" be, then do a min() against the GL caps. > +void shader_glsl_add_instruction_modifiers(SHADER_OPCODE_ARG* arg > > Doesn't seem to handle multiple modifiers - I think I changed this > elsewhere recently. > Possibly not. I just haven't hit (or noticed) that test case yet. > + SHADER_PARAM_FCT_T param_fct; > > Please don't add any more fields that do not need to persist into base > shader. Why are two different param functions needed? > This method avoids the base class having to know about its subclasses. I'm sure there's a better way to do it, still, though. > > + /* Set constants for the temporary argument */ > > I'm not sure I like how the mnxn functions use a temporary argument > structure and re-invoke the gen. functions. Do they initialize every > field necessary in the arg? I might have added new fields and missed the > initialization part in there - maybe this arg should be 0-ed first with > memcpy. > Agreed. > + GLhandleARB objList[4]; /* There should never be more than 2 > objects attached > + (one pixel shader and one vertex > shader), but we'll be safe */ > > This doesn't make sense to me - either you know that there are 2 objects > attached exactly, or you don't. In either case, it's wrong to cover up a > potential bug with a 4-element array. Yeah, I must have been tired. :-) > + * Note: The downside to this method is that we may end up compiling > and linking > + * programs that will not be used. Linking is expensive, but it's > typically better to > + * create more programs than necessary and just bind them when needed > than it is > + * to create a new program every time you set the shaders > + */ > > 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). Everything was roughly 100 times slower that way. So, this method stores the program for every combination which is used in the app. That way, when the shaders are set, we already have a linked program to use. Linking is a very expensive operation. Keeping a list of them seems like the best method that we could come up with. > If I call: > > X = CreatePixelShader(dev); > Y = CreateVertexShader(dev); > Z = CreateVertexShader(dev); > SetPixelShader(dev, X); > SetVertexShader(dev, Y); > SetVertexShader(dev, Z); > > How many programs are being created? 3 > What objects are attached to each? Program: Pixel Shader: Vertex Shader: 1 X NULL 2 X Y 3 X Z > Which linked lists does each program go into, and > What's the sequence of things being attached/detached, programs > created/destroyed? If you run the WINEDEBUG=+d3d_shader trace, you'll get detailed information about all of the steps involed. Currently, the only time that the list doesn't get de-allocated is when the app doesn't properly clean up after itself. So, that will need to be fixed before this code can be submitted. On a separate topic, we've learned that the reason that some of these pixel shaders fail is because I've hard-coded texture2D() and just assumed that the textures would be 2-dimensional (which is what the ARB programs do now, too). However, in ARB, only the instructions that reference the 3D texture are failing. In GLSL, the entire shader fails if one of the textures is wrong. So, this will have to be thought out some more, since prior to PS 2.0, the app doesn't have to declare if it's a 2D or a 3D texture ahead of time.

June 4, 2006

GetDIBits() with a bitmap that is selected in a device context

by Michael Kaufmann

The application "Fritz 5.32" calls GetDIBits() with a bitmap that is still selected in a device context (see bug 3893). The bitmap has a color table. GetDIBits() creates a memory DC, selects the bitmap into this DC, and calls GetDIBColorTable(). But this fails, because Wine can't select this bitmap in a memory device context again. According to MSDN, calling GetDIBits with a bitmap that is selected in a device context is not allowed. But surprisingly it works on Windows. Does anybody have an idea how to solve this problem? Regards, Michael

June 4, 2006

Re: wined3d: Another GLSL shader status update

by Jason Green

On 6/3/06, Phil Costin <philcostin(a)hotmail.com> wrote: > Hi Jason, > > Can you just clarify for my why you are changing the D3DVS_VERSION() and > D3DPS_VERSION() to 3.0 for SHADER_ARB in the caps section of directx.c? > Sorry, that snuck in. There are some 2.0 shaders that can be handled by ARB already, so I was just telling the app that it supported them as a test. That part shouldn't have been there. :-)

June 4, 2006

Re: Shell integration idea

by Robert Shearman

Mikołaj Zalewski wrote: > >> The number of developers that understand COM aggregation and all the >> baroque rules that make it up is very, very low. A simple ops struct of >> function pointers as used in the wineserver or kernel would be fine here >> ... COM adds an awful lot of complexity that really isn't needed at all >> (eg you must call CoInitialize, which means caring about apartments, >> which >> means possibly instantiating a STA when windows wouldn't, which means >> pain). >> >> > OK, I won't insist on aggregation :). As for apartments I've thought > that something like that: > HRESULT res=CoInitializeEx(NULL, COINIT_MULTITHREADED); > /* working with objects with ThreadingModel Both */ > if (SUCCEEDED(res)) CoUninitialize(); > > won't have any side effects. But if the number of developers that > knows about COM is low then maybe that it's better to use simple ops > structs instead. As long as the lifetime of the objects doesn't outlive the lifetime of the apartment (which dies in the CoUninitialize call) then it is fine, although trying to change the apartment of the current thread will cause builtin ole32 to print an ERR at the console. -- Rob Shearman

June 4, 2006

Re: To K&R or not

by Aneurin Price

EA Durbin wrote: > One could just write a perl script to parse the code upon submission > that would convert it from K & R style to a uniform standard that it > easy to read, and fix things like the amount of spaces in an indent. > > And thus the discussion comes full circle.

June 4, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

Hans Leidekker wrote: > > Don't be sorry. I like your persistence. And I appreciate your kindness, thank you. > I see what you mean now, yes address doesn't have to be initialised, > there's no way it could be used uninitialised in this code. > > -Hans I shall let the dust settle, then probably put in another patch to remove the superfluous initialisation. Thanks, -- Andy.

June 4, 2006

Re: mapi32: Write-strings warnings fix

by Hans Leidekker

On Sunday 04 June 2006 11:45, Andrew Talbot wrote: > I am sorry to make such a meal of this Don't be sorry. I like your persistence. > What I am saying is, because of all the checking code which follows, can we > be confident that every message->lpRecips[i].lpszAddress must have gained a > value, and therefore just write > > const char *address; > > for "address", without the empty-string initial assignment? I see what you mean now, yes address doesn't have to be initialised, there's no way it could be used uninitialised in this code. -Hans

June 4, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

>> >> would it be safe to omit the initialization of "address"? > > Yes, but it shortens the lines below and improves readability of > the code. > > -Hans I am sorry to make such a meal of this, but - in addition to the write-strings issue - I noticed that the original code initialized "address" thus: char *address = ""; (which you correctly then constified). What I am saying is, because of all the checking code which follows, can we be confident that every message->lpRecips[i].lpszAddress must have gained a value, and therefore just write const char *address; for "address", without the empty-string initial assignment? I shall post the patch, in essence, as you kindly stated, to supersede my earlier offerings before Alexandre gets a chance to look at my mess. But it would be nice to know the answer to the above. Again - and without much thinking - if "address" does need to be set to a default value, should it be to empty-string, or to NULL? -- Andy.

June 4, 2006

Re: FW: RE: My 1.0 wish list

by Hans Leidekker

On Sunday 04 June 2006 11:01, EA Durbin wrote: > It shouldnt matter whether its >= or >, they both return the wrong results > in the actual msi installer and the right results in db.c. Does this patch help? -Hans diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y index b32c417..47f858a 100644 --- a/dlls/msi/cond.y +++ b/dlls/msi/cond.y @@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera return a >= b; case COND_LE: case COND_ILE: - return a >= b; + return a <= b; case COND_SS: case COND_ISS: return ( a & b ) ? 1 : 0;

June 4, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

>From: Hans Leidekker <hans(a)it.vu.nl> >To: wine-devel(a)winehq.org >CC: "EA Durbin" <ead1234(a)hotmail.com> >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 4 Jun 2006 09:49:47 +0200 > >On Sunday 04 June 2006 09:08, EA Durbin wrote: > > > I wrote a quick test in wine/dlls/msi/tests/db.c to add a 2nd row to the > >Could you share it? > > > database that was being created, then I inserted the `id` of 8 into it >and > > then I ran the query SELECT * FROM phone where `id` > 6, and it returned > > the correct results with `id` of 8. But in the actual wine installer >code a > >Is the table in db.c comparable? Does it have the same fields and types? >Also, you're using > in your select but the failing select statement has >= >which may make a difference. > > -Hans It shouldnt matter whether its >= or >, they both return the wrong results in the actual msi installer and the right results in db.c. I have enclosed my tests, I tested these against the America's Army database installer and I have double checked the actual contents of the msi file in ORCA. I've packaged up some tests and included them with this email. Here are some queries that have returned the wrong results SELECT * FROM `Media` WHERE `LastSequence` > 15 SELECT * FROM `File` WHERE `Sequence` > 10 SELECT * FROM `Media` WHERE `LastSequence` >= 15 SELECT * FROM `File` WHERE `Sequence` >= 10

June 4, 2006

Re: wined3d: Another GLSL shader status update

by Ivan Gyurdiev

+ /* Declare textures samplers */ + for(i = 0; i < /*This->baseShader.limits.texture */ 4; i++) { +// if (reg_maps->texcoord & (1 << i)) + shader_addline(buffer,"uniform sampler2D mytex%lu;\n", i); + } What's the problem here? + if (wined3d_settings.shader_mode == SHADER_GLSL) + shader_glsl_add_instruction_modifiers(&hw_arg); If you choose to pull modifier handling out of the per-opcode function, this should be done for SHADER_ARB as well, imho. + for (i=0; i<max_constants; ++i) { ... - for (i = 0; i <= WINED3D_VSHADER_MAX_CONSTANTS; ++i) { Is this fixing off-by-one bug in the old code in the process (or introducing one)? + loadConstants(iface, GL_VERTEX_PROGRAM_ARB, constants, NULL, + vshader->baseShader.limits.constant_float, programId, TRUE); What's the purpose of the "skip_type_check" parameter - TRUE here. Doesn't the current code only work for float constants anyway? + /* Update the constants */ + loadConstants(iface, GL_FRAGMENT_PROGRAM_ARB, This->stateBlock->pixelShaderConstantF, + This->stateBlock->pixelShaderConstantT, pshader->baseShader.limits.constant_float, + programId, FALSE); Those limits aren't checked against GL capabilities yet. The current 3.0 limit is 224 float constants - does this work properly? +void shader_glsl_add_instruction_modifiers(SHADER_OPCODE_ARG* arg Doesn't seem to handle multiple modifiers - I think I changed this elsewhere recently. + FIXME("Unrecognized modifier(0x%#lx)\n", mask >> D3DSP_DSTMOD_SHIFT); 0x and # are redundant. + SHADER_PARAM_FCT_T param_fct; Please don't add any more fields that do not need to persist into base shader. Why are two different param functions needed? +extern void shader_glsl_add_cast( + int numSwizzles, + char *hwLine); Where is this defined? +void pshader_glsl_def(SHADER_OPCODE_ARG* arg) { ... + shader->constants[reg & 0xFF] = VS_CONSTANT_CONSTANT; That's not what the ARBfp code does - pixel shaders are different from vertex shader (and I don't see why, conceptually this is all the same thing, only the limit is slightly different). + /* Set constants for the temporary argument */ I'm not sure I like how the mnxn functions use a temporary argument structure and re-invoke the gen. functions. Do they initialize every field necessary in the arg? I might have added new fields and missed the initialization part in there - maybe this arg should be 0-ed first with memcpy. + GLhandleARB objList[4]; /* There should never be more than 2 objects attached + (one pixel shader and one vertex shader), but we'll be safe */ This doesn't make sense to me - either you know that there are 2 objects attached exactly, or you don't. In either case, it's wrong to cover up a potential bug with a 4-element array. + * Note: The downside to this method is that we may end up compiling and linking + * programs that will not be used. Linking is expensive, but it's typically better to + * create more programs than necessary and just bind them when needed than it is + * to create a new program every time you set the shaders + */ 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 :) Maybe a test case would be useful? If I call: X = CreatePixelShader(dev); Y = CreateVertexShader(dev); Z = CreateVertexShader(dev); SetPixelShader(dev, X); SetVertexShader(dev, Y); SetVertexShader(dev, Z); How many programs are being created? What objects are attached to each? Which linked lists does each program go into, and What's the sequence of things being attached/detached, programs created/destroyed?

June 4, 2006

Re: FW: RE: My 1.0 wish list

by Hans Leidekker

On Sunday 04 June 2006 09:08, EA Durbin wrote: > I wrote a quick test in wine/dlls/msi/tests/db.c to add a 2nd row to the Could you share it? > database that was being created, then I inserted the `id` of 8 into it and > then I ran the query SELECT * FROM phone where `id` > 6, and it returned > the correct results with `id` of 8. But in the actual wine installer code a Is the table in db.c comparable? Does it have the same fields and types? Also, you're using > in your select but the failing select statement has >= which may make a difference. -Hans

June 4, 2006

Re: Prospects of an OpenAL audio driver...

by Eric Pouech

> The reason for using OpenAL is for platforms that dont have > alsa/oss/esd/... support > For one it gives a chance to test audio on windows for example -- and > on mac osx (although the winecoreaudio driver is making great progress). planning to use OpenAL for portability reasons is a bad idea IMO: - it won't support the mapping required by dsound (unless we decide to drop the HW support) - OpenAL is overkill (in terms of API) for portability (PortAudio would be better IMO) - OpenAL doesn't support recording AFAICT A+

June 4, 2006

Re: mapi32: Write-strings warnings fix

by Hans Leidekker

On Sunday 04 June 2006 00:27, Andrew Talbot wrote: > address = message->lpRecips[i].lpszAddress; > if (address) > { > > would it be safe to omit the initialization of "address"? Yes, but it shortens the lines below and improves readability of the code. -Hans

June 4, 2006

Re: To K&R or not

by EA Durbin

One could just write a perl script to parse the code upon submission that would convert it from K & R style to a uniform standard that it easy to read, and fix things like the amount of spaces in an indent. >From: Peter Beutner <p.beutner(a)gmx.net> >To: James Hawkins <truiken(a)gmail.com> >CC: Stephen.Clark(a)seclark.us, Aneurin Price ><wine(a)shadovald.dyndns.org>,wine-devel(a)winehq.org >Subject: Re: To K&R or not >Date: Sun, 04 Jun 2006 01:49:55 +0200 > >James Hawkins schrieb: >>On 6/3/06, Stephen Clark <Stephen.Clark(a)seclark.us> wrote: >>> > >>> >"Tabs are not forbidden but discouraged. A tab is defined as 8 >>> >characters and the usual amount of indentation is 4 characters." >>> > >>> > >>> >>>A tab is not defined as 8 spaces - it is defined as go to the next TAB >>>STOP! The tab stop >>>could be every 8 spaces or 4 spaces or 2 spaces or whatever has been >>>defined. The tab >>>comes from the manual typewriter and there were physical stops you >>>placed where >>>you wanted the carriage to stop at. >>> >> >>You misinterpreted the quote. "A tab is defined as 8 characters" >>means that when you're editing Wine code that has tabs in it, you >>should set your editor to display tabs as 8 spaces so that we all see >>the same indention from a tab. >hm but isn't it rather insane to require specific editor settings just to >be >able to *view* the code? > > >

June 4, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

The bug is in file.c under ready_media_for_file() at the query statement. I hacked the actual wine code and ran some queries aganist actual msi installer databases. I tested a couple different queries in the actual wine installer against actual msi databases on a couple different tables to diagnose the problem, then I iterated through the results returned by the queries. Here are my findings: SELECT * FROM `MEDIA` - works fine SELECT * FROM `MEDIA` ORDER BY `LastSequence` - works fine SELECT * FROM `FILES` - works fine SELECT * FROM `FILES` ORDER BY `Sequence` - works fine SELECT * FROM `FILES` WHERE `Sequence` >= 10 - upon viewing results it returns Sequences 1 through 10 - failed SELECT * FROM `Media` WHERE `LastSequence` >= any number you wish - fails and returns LastSequence numbers from the table, less than the number in your comparison. This means that the bug is either in the WHERE clause, or the conditional statement immediately after the WHERE clause. I'm not sure, and I don't feel like spending another 10 hours learning how the underlying SQL code in wine works or learning how Bison parses things as the underlying code is even more confusing than what I've looked at so far, but I've narrowed down where the bug is, and what part of the query fails at in particular. I wrote a quick test in wine/dlls/msi/tests/db.c to add a 2nd row to the database that was being created, then I inserted the `id` of 8 into it and then I ran the query SELECT * FROM phone where `id` > 6, and it returned the correct results with `id` of 8. But in the actual wine installer code a similar query doesn't return the correct results. I don't know if its because the wine installer is taking the query as a character array and it isn't in db.c, or if files.c is doing other things than in db.c, but I couldn't replicate it in db.c and I give up, the query is broken in the actual installer code, and when Iterating through the results it returns the wrong results from tables. >From: Hans Leidekker <hans(a)it.vu.nl> >To: wine-devel(a)winehq.org >CC: "EA Durbin" <ead1234(a)hotmail.com> >Subject: Re: FW: RE: My 1.0 wish list >Date: Sat, 3 Jun 2006 20:30:16 +0200 > >On Saturday 03 June 2006 18:45, EA Durbin wrote: > > > That can't be used for a test case, for a test case I, or most likely > > someone elsewho has the ability and the time has to write code under > > dlls/msi/tests/db.c and make a program in windows to re-illustrate this > > bug. > >Do you know SQL? Could you write a few SQL statements that reproduce >the exact conditions of the bug? I'm thinking of something like this: > > 1) create a table > 2) insert a few rows > 3) select a row from the table > >If you do, I'll have a go at writing a test case for it. > > -Hans

June 4, 2006

Re: FW: RE: My 1.0 wish list

by James Hawkins

On 6/3/06, Tom Booker <speeddymon(a)gmail.com> wrote: > > hopefully nobody flames me but i just tied all these bugs together thru bug > 5350.. they block it now.. maybe i should just make them all dupes instead? > > plz dont flame me im just trying to help > I don't think that was a good idea. It's possible that all of these bugs really are caused by this one msi bug, but until we go in and check each install app, we shouldn't mark them as such. -- James Hawkins

June 3, 2006

Re: FW: RE: My 1.0 wish list

by Tom Booker

hopefully nobody flames me but i just tied all these bugs together thru bug 5350.. they block it now.. maybe i should just make them all dupes instead? plz dont flame me im just trying to help Tom On 6/3/06, EA Durbin <ead1234(a)hotmail.com> wrote: > > I have compiled a list of applications that are affected by the bug in > which > the query in ready_media_for_file() in MSI returns the wrong results, it > returns LastSequence less than the file->Sequence being passed. > > Here is a detailed analysis of the multiple types of errors this bugs > causes. > > Common debug outputs of this bug are: > > Error #1: > > err:msi:ACTION_InstallFiles compressed file wasn't extracted > > This error is usually caused by the results of the query returning a > LastSequence number of Less than that of the working install media and the > installer is trying to extract the file from the wrong install medium. > > Error #2: > > err:msi:extract_cabinet_file FDICopy failed > err:msi:ACTION_InstallFiles Unable to ready media > > There is a zero in LastSequence Value of the Media table and the query in > ready_media_for_file() returns it. For some reason the msi file has a zero > in the LastSequence but its really a dummy cabinet file and doesn't exist. > The file sequence being passed for the first file is most likely 1, and > the > query of >= 1 is returning 0 falsely causing this error. > > > > This problem in MSI spans a multitude of bugs. > > > America's Army - bug #5139 > J2SE - bug # 4280 > Half Life 2 - bug # 5004, 4533 > Dawn of War Demo - bug # 3749 > E-Sword 6.5 - bug # 4251 > Rush for Berlin demo - bug #5187 > ATI demo(Rendering With Natural Light ) - bug # 4712? > > There are probably other bugs resulting from this, but the log doesn't > detail it well enough, alot of them just have the debug dump at the end > and > not the pertainent msi err lines. I only included applications where it > was > obvious from the log, or I tested personally. > > >From: Mike McCormack <mike(a)codeweavers.com> > >To: EA Durbin <ead1234(a)hotmail.com> > >Subject: Re: FW: RE: My 1.0 wish list > >Date: Sun, 04 Jun 2006 00:30:41 +0900 > > > > > >You can send me as many mails as you like, but I'm not doing anything > until > >there's a test case showing the problem. > > > >Mike > > I wrote a test showing the results of the query in the wine installer and > included the source code and resulting logs which clearly displays the > problem. That's the best I can do. I'm not up to snuff on my C > programming, > nor am I familiary with how the official test case for wine is supposed to > be layed out. If someone else wants to work on it then thats fine, but I > layed out the problem, and debugged it, and I've proven this with code and > resulting logs. This problem affects a multitude of applications in wine. > If > your not willing to work on it then either someone else can, or it can > remain broken. > > > > >

June 3, 2006

Re: My 1.0 wish list

by Tom Booker

On 6/3/06, EA Durbin <ead1234(a)hotmail.com> wrote: > > I just tested the latest Kidspiration install. The self extracting .exe > extracts the Trial.exe file into windows/temp, and then complains about > not > having a program associated with Kid's Trial.exe. After traversing into > the > .wine/drive_c/windows/temp folder and typing Wine Kid's Trial.exe the > program installed and ran just fine. That sounds like a loader problem.. might want to ask one of the senior devels *cough*AJ*cough* to look into it and give at least an explanation of what might be causing it.. with that info, maybe someone could unofficially mentor a fix for it outta one of the SoC kids. <g> Tom

June 3, 2006

Re: FW: RE: My 1.0 wish list

by Mike McCormack

EA Durbin wrote: > proven this with code and resulting logs. This problem affects a > multitude of applications in wine. If your not willing to work on it > then either someone else can, or it can remain broken. I told you from the start that I don't have time to work on this now. I've told you already if make it easier for me by condensing your results into a test case and adding it to the Wine test suite I will look into it. I have other real work to do, and fixing this bug would probably take a day of my time, so if it stays broken, that's fine with me, and if somebody else fixes it, that's fantastic! Mike

June 3, 2006

Re: wined3d: Another GLSL shader status update

by Phil Costin

To clarify - It doesn't matter that you're changing the version of the future software pixel shader support capability but the vertex shader change is problematic because apps may see the 3.0 VS capability and supply a 3.0 shader to a 1.4 capable GL implementation. Phil Phil Costin wrote: > Hi Jason, > > Can you just clarify for my why you are changing the D3DVS_VERSION() and > D3DPS_VERSION() to 3.0 for SHADER_ARB in the caps section of directx.c? > > SHADER_ARB refers to ARB_vertex_program and ARB_fragment_program which do > not support features greater than VS 1.1 and PS 1.4 respectively. This > code does not affect SHADER_GLSL at all. > > Thanks, > Phil C

June 3, 2006

Re: DirectX blitter bug

by Alexander Nicolaysen Sørnes

Søndag 04 juni 2006 02:13, skrev Mike Hearn: > Lords of Magic works perfectly EXCEPT that rendering is corrupted when it > is using DirectX "fast blitting"; they provide a software emulated > workaround for some truly ancient cards (Matrox Mystique anyone?) and the > game works well in this mode. But it should work properly in DirectX > accelerated mode too. > > The kind of corruption varies but it appears as, for instance, mouse > trails which to me suggests some kind of co-ordinate system problem. > This is fixed in Stefan's ddraw patchset. Regards, Alexander N. Sørnes

June 3, 2006

Re: wined3d: Another GLSL shader status update

by Phil Costin

Hi Jason, Can you just clarify for my why you are changing the D3DVS_VERSION() and D3DPS_VERSION() to 3.0 for SHADER_ARB in the caps section of directx.c? SHADER_ARB refers to ARB_vertex_program and ARB_fragment_program which do not support features greater than VS 1.1 and PS 1.4 respectively. This code does not affect SHADER_GLSL at all. Thanks, Phil C Jason Green wrote: > Well, I've fixed the speed issues with using GLSL (it's now just as > fast as ARB shaders for the ones that actually work correctly) and > gotten a few other things to work correctly. However, I'm still > having issues with certain pixel/vertex shader combinations. Ohsix > caught on that it may have to do with sampler limits on graphics cards > and how sampling/textures are handled different in GLSL that with ARB. > I'm not sure at the moment and could use some help. > > http://cmhousing.net/wine/glsl_hack6.diff > > is the diff against the most recent git tree. There are still some > ugly hacks lying around in there. Note that I've separated out most > of the GLSL functions into a new file "glsl_shader.c". Once again, to > use GLSL instead of ARB shaders, you'll have to apply this patch, have > a graphics card that's capable of GLSL, and add the following case > senstive registry key: > > HKCU\Software\Wine\Direct3D\UseGLSL = "enabled" (String value)

June 3, 2006

DirectX blitter bug

by Mike Hearn

Lords of Magic works perfectly EXCEPT that rendering is corrupted when it is using DirectX "fast blitting"; they provide a software emulated workaround for some truly ancient cards (Matrox Mystique anyone?) and the game works well in this mode. But it should work properly in DirectX accelerated mode too. The kind of corruption varies but it appears as, for instance, mouse trails which to me suggests some kind of co-ordinate system problem. The demo is here: ftp://ftp.sierra.com/pub/sierra/lordsofmagic/demos/si_lordsofmagic_demo.exe and it installs cleanly on the master branch. If any DirectDraw gurus want to take a look, please do! I bet this problem affects other games too.... thanks -mike

June 3, 2006

Re: To K&R or not

by Peter Beutner

James Hawkins schrieb: > On 6/3/06, Stephen Clark <Stephen.Clark(a)seclark.us> wrote: >> > >> >"Tabs are not forbidden but discouraged. A tab is defined as 8 >> >characters and the usual amount of indentation is 4 characters." >> > >> > >> >> A tab is not defined as 8 spaces - it is defined as go to the next TAB >> STOP! The tab stop >> could be every 8 spaces or 4 spaces or 2 spaces or whatever has been >> defined. The tab >> comes from the manual typewriter and there were physical stops you >> placed where >> you wanted the carriage to stop at. >> > > You misinterpreted the quote. "A tab is defined as 8 characters" > means that when you're editing Wine code that has tabs in it, you > should set your editor to display tabs as 8 spaces so that we all see > the same indention from a tab. hm but isn't it rather insane to require specific editor settings just to be able to *view* the code?

June 3, 2006

Re: Shell integration idea

by Mike Hearn

On 6/3/06, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > OK, I won't insist on aggregation :). As for apartments I've thought > that something like that: > HRESULT res=CoInitializeEx(NULL, COINIT_MULTITHREADED); > /* working with objects with ThreadingModel Both */ > if (SUCCEEDED(res)) CoUninitialize(); > > won't have any side effects. Well, you'd be possibly changing the apartment of the current thread, which is not allowed IIRC. > But if the number of developers that knows > about COM is low then maybe that it's better to use simple ops structs > instead. I'd say so... thanks -mike

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

Hans Leidekker wrote: > [...] How about this patch? > > - char *address = "", *to = NULL, *cc = NULL, *bcc = NULL, *subject, > *body; > + char *to = NULL, *cc = NULL, *bcc = NULL; > + const char *subject, *body, *address = ""; > > -Hans Because of the testing: if (!message) return MAPI_E_FAILURE; and if (!message->lpRecips) { WARN("No recipients found\n"); return MAPI_E_FAILURE; } before address = message->lpRecips[i].lpszAddress; if (address) { would it be safe to omit the initialization of "address"? -- Andy.

June 3, 2006

Re: Shell integration idea

by Mikołaj Zalewski

>The number of developers that understand COM aggregation and all the >baroque rules that make it up is very, very low. A simple ops struct of >function pointers as used in the wineserver or kernel would be fine here >... COM adds an awful lot of complexity that really isn't needed at all >(eg you must call CoInitialize, which means caring about apartments, which >means possibly instantiating a STA when windows wouldn't, which means pain). > > OK, I won't insist on aggregation :). As for apartments I've thought that something like that: HRESULT res=CoInitializeEx(NULL, COINIT_MULTITHREADED); /* working with objects with ThreadingModel Both */ if (SUCCEEDED(res)) CoUninitialize(); won't have any side effects. But if the number of developers that knows about COM is low then maybe that it's better to use simple ops structs instead. Mikolaj Zalewski PS: I will be absent during the next week so I won't be able to reply to e-mails.

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

Hans Leidekker wrote: > > I see no warnings with -Wwrite-strings and -Wcast-qual. > > -Hans Hans, Yes, you are right. Of course, the values are being taken from the SDK elements, not being assigned to them, so the local variable can and should be constified. -- Andy.

June 3, 2006

Re: Prospects of an OpenAL audio driver...

by Nick Burns

On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote: >>Are there any problems with using OpenAL for such a purpose? >Probably not, it depends on the exact level of abstraction OpenAL gives. >But it begs the question - why? >thanks -mike The reason for using OpenAL is for platforms that dont have alsa/oss/esd/... support For one it gives a chance to test audio on windows for example -- and on mac osx (although the winecoreaudio driver is making great progress). - Nick

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Hans Leidekker

On Saturday 03 June 2006 22:06, Andrew Talbot wrote: > The problem is that the SDK defines the strings as non-const, so making > subject and body const char * would cause a qual-cast violation. I see no warnings with -Wwrite-strings and -Wcast-qual. -Hans

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

Actually, sorry, my earlier statement was rubbish. But the point of the Write-strings warning is to flag the discarding of a qualifer. Thus char *s = "string"; /* bad */ discards the effective const factor of the string constant. So I can't assign const char * values to char * variables. -- Andy.

June 3, 2006

Alsa sound vs OSS with wine and riven

by Stephen Clark

Hello, I have been working to get "Riven" the sequel to Myst to work with the latest wine from cvs on the latest FC5. It works and the sound is almost perfect with OSS, but is totally screwed up when I use ALSA, I don't know whether this is a WINE or Linux issue, so I am cross posting to both lists. Regards, 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)

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

Option 2 is the way to go. -- A.

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

Hans Leidekker wrote: > That won't do either because these pointers are dereferenced a few lines > further down. How about this patch? > > - char *address = "", *to = NULL, *cc = NULL, *bcc = NULL, *subject, > *body; > + char *to = NULL, *cc = NULL, *bcc = NULL; > + const char *subject, *body, *address = ""; > > -Hans The problem is that the SDK defines the strings as non-const, so making subject and body const char * would cause a qual-cast violation. I think there are two solutions: 1) I could put casts in the sprintf() line, thus: sprintf( mailto, format, to ? to : "", (char *) subject, cc ? cc : "", bcc ? bcc : "", (char *) body ); or 2) I could define const CHAR empty[] = ""; and reinstate the original ?: construct. I'm not sure which is best, if either. -- Andy.

June 3, 2006

Re: To K&R or not

by James Hawkins

On 6/3/06, Stephen Clark <Stephen.Clark(a)seclark.us> wrote: > > > >"Tabs are not forbidden but discouraged. A tab is defined as 8 > >characters and the usual amount of indentation is 4 characters." > > > > > > A tab is not defined as 8 spaces - it is defined as go to the next TAB > STOP! The tab stop > could be every 8 spaces or 4 spaces or 2 spaces or whatever has been > defined. The tab > comes from the manual typewriter and there were physical stops you > placed where > you wanted the carriage to stop at. > You misinterpreted the quote. "A tab is defined as 8 characters" means that when you're editing Wine code that has tabs in it, you should set your editor to display tabs as 8 spaces so that we all see the same indention from a tab. -- James Hawkins

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Hans Leidekker

On Saturday 03 June 2006 21:26, Andrew Talbot wrote: > subject = message->lpszSubject; > body = message->lpszNoteText; That won't do either because these pointers are dereferenced a few lines further down. How about this patch? - char *address = "", *to = NULL, *cc = NULL, *bcc = NULL, *subject, *body; + char *to = NULL, *cc = NULL, *bcc = NULL; + const char *subject, *body, *address = ""; -Hans

June 3, 2006

Re: To K&R or not

by Stephen Clark

James Hawkins wrote: >On 6/3/06, Peter Beutner <p.beutner(a)gmx.net> wrote: > > >>The question is in how far that really works in reality. Even when leaving >>such (imho) minor things like K&R or not, spaces after if or not,etc aside. >>Just look at the tabs vs. space issue: >>I don't really have a problem with both of them but mixing them is imo the >>worst thing that could happen. >> >>And things like this: >>(tabs = underscore, space = dots) >> >>...if() { >>______int foo; >>______if() { >>______.....do_something(); >>......_____for() >>......_____....do_somethingelse(); >>______} >>....} >>(and yes you really find things like this) >> >>are just UGLY and if you don't have the exact same tabsize settings like the author >>you get complete "garbage". >> >>Granted, I probably haven't even seen the majority of the source code and maybe I just found >>one of the few negative examples, but imho some kind of consensus here would be >>definitly a good thing. >> >>4-space indention and using spaces instead of tabs already seems to be most used >>setting, so why not enforce it for everybody? >> >> >> > >We do have a consensus about tabs vs. spaces. To quote the page I >sent you in the last message: > >"Tabs are not forbidden but discouraged. A tab is defined as 8 >characters and the usual amount of indentation is 4 characters." > >More and more this is being followed, but we won't force it on anyone. > If someone creates a new page with tabs, we're not going to stop that >code from getting in. > > > A tab is not defined as 8 spaces - it is defined as go to the next TAB STOP! The tab stop could be every 8 spaces or 4 spaces or 2 spaces or whatever has been defined. The tab comes from the manual typewriter and there were physical stops you placed where you wanted the carriage to stop at. Cheers, 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)

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Andrew Talbot

Peter Oberndorfer wrote: > On Saturday 03 June 2006 16:33, Andrew Talbot wrote: >> Changelog: >> mapi32: Write-strings warnings fix. >> >> diff -urN a/dlls/mapi32/sendmail.c b/dlls/mapi32/sendmail.c >> --- a/dlls/mapi32/sendmail.c 2006-05-23 17:24:40.000000000 +0100 >> +++ b/dlls/mapi32/sendmail.c 2006-06-03 14:44:21.000000000 +0100 >> @@ -113,8 +113,8 @@ >> } >> if (message->nFileCount) FIXME("Ignoring attachments\n"); >> >> - subject = message->lpszSubject ? message->lpszSubject : ""; >> - body = message->lpszNoteText ? message->lpszNoteText : ""; >> + subject = message->lpszSubject ? message->lpszSubject : NULL; >> + body = message->lpszNoteText ? message->lpszNoteText : NULL; > I think this is wrong, as it makes the whole "? :" construct unnecessary. > (for non NULL it evaluates to "message->lpszNoteText" and for NULL it > becomes NULL; >> > Greetings Peter Hi Peter, I believe you are right! I started by trying to prevent the assignment of an empty string constant to a non-const pointer to char, looked up the MapiMessage struc specification and noted that an unsupplied value of lpszSubject or lpszNoteText could otherwise be represented by NULL, saving me a small amount of work. But I failed to observe that the constructs then simplify to subject = message->lpszSubject; body = message->lpszNoteText; I shall submit an amended version of the patch, accordingly. Well-spotted and thanks! -- Andy.

June 3, 2006

Re: Wine VM86 exception handling bug?

by Mike Hearn

On Fri, 02 Jun 2006 08:01:55 -0700, Dan Kegel wrote: > You can embed a trivial DOS executable as data in the .c file I'd rather we got out of the habit of doing this seeing as I think git can deal with binaries better than cvs can. thanks -mike

June 3, 2006

Re: Added initial version of Wine OleView

by Vitaliy Margolen

Saturday, June 3, 2006, 11:36:45 AM, Piotr Caban wrote: Please change FSF's address to the new one. Vitaliy Margolen

June 3, 2006

Re: FW: RE: My 1.0 wish list

by Hans Leidekker

On Saturday 03 June 2006 18:45, EA Durbin wrote: > That can't be used for a test case, for a test case I, or most likely > someone elsewho has the ability and the time has to write code under > dlls/msi/tests/db.c and make a program in windows to re-illustrate this > bug. Do you know SQL? Could you write a few SQL statements that reproduce the exact conditions of the bug? I'm thinking of something like this: 1) create a table 2) insert a few rows 3) select a row from the table If you do, I'll have a go at writing a test case for it. -Hans

June 3, 2006

wined3d: Another GLSL shader status update

by Jason Green

Well, I've fixed the speed issues with using GLSL (it's now just as fast as ARB shaders for the ones that actually work correctly) and gotten a few other things to work correctly. However, I'm still having issues with certain pixel/vertex shader combinations. Ohsix caught on that it may have to do with sampler limits on graphics cards and how sampling/textures are handled different in GLSL that with ARB. I'm not sure at the moment and could use some help. http://cmhousing.net/wine/glsl_hack6.diff is the diff against the most recent git tree. There are still some ugly hacks lying around in there. Note that I've separated out most of the GLSL functions into a new file "glsl_shader.c". Once again, to use GLSL instead of ARB shaders, you'll have to apply this patch, have a graphics card that's capable of GLSL, and add the following case senstive registry key: HKCU\Software\Wine\Direct3D\UseGLSL = "enabled" (String value)

June 3, 2006

Re: Prospects of an OpenAL audio driver...

by Mike Hearn

On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote: > Are there any problems with using OpenAL for such a purpose? Probably not, it depends on the exact level of abstraction OpenAL gives. But it begs the question - why? thanks -mike

June 3, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Mike Hearn

On Sat, 03 Jun 2006 09:43:04 +0200, Alexandre Julliard wrote: > If it's a solution that can be expanded later on to cover the other > cases, yes, but not if it's a dead-end. When this was discussed before the idea of bringing back the service thread was raised. I still think we should do this, assuming details like suppressing attach notifications are done properly ... thanks -mike

June 3, 2006

Re: MSI query tests

by Mike Hearn

On Thu, 01 Jun 2006 21:51:20 -0500, EA Durbin wrote: > I don't know how I would run this on windows. You don't have to, you just need to run it against a native MSI. As to how to convert your findings into a test case, I guess that may be trickier. There is some fundamental behavior here that is wrong, so creating a database that shows the problem then testing queries on it might work? thanks -mike

June 3, 2006

Re: Shell integration idea

by Mike Hearn

On Fri, 02 Jun 2006 20:16:25 +0200, Mikolaj Zalewski wrote: > Of course when we use COM aggregation instead of a factory pattern we > will have all the interfaces visible under one CLSID so we will be able > to construct a IWineTrash directly with the main object hidden behind > the scene. Argh, this is exactly what Alexandre meant! :) The number of developers that understand COM aggregation and all the baroque rules that make it up is very, very low. A simple ops struct of function pointers as used in the wineserver or kernel would be fine here ... COM adds an awful lot of complexity that really isn't needed at all (eg you must call CoInitialize, which means caring about apartments, which means possibly instantiating a STA when windows wouldn't, which means pain). thanks -mike

June 3, 2006

Re: Added initial version of Wine OleView

by James Hawkins

On 6/3/06, Piotr Caban <piotr.caban(a)gmail.com> wrote: > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA The address has changed, and we recently did a sweep of the code base changing to the new address, so we'd like to keep the old address out. * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA +/* BINRES toolbar.bmp */ +IDB_TOOLBAR BITMAP DISCARDABLE toolbar.bmp +/* { +'42 4d 36 12 00 00 00 00 00 00 36 00 00 00 28 00' +'00 00 60 00 00 00 10 00 00 00 01 00 18 00 00 00' +'00 00 00 12 00 00 12 0b 00 00 12 0b 00 00 00 00' The patch is quite large by Wine's standards. You could reduce the size by taking out the bitmap for now and sending that separately; otherwise, it looks good and keep up the good work! -- James Hawkins

June 3, 2006

Re: How are we doing?

by Mike Hearn

On Sat, 03 Jun 2006 12:03:21 +1000, Jeff Latimer wrote: > We seem to have a policy of not accepting comments in exisiting code. We do? I seem to recall having comment patches accepted before. Albiet a long time ago. > If I add comments to existing code that clear up a mystery I have found > they are nicely deleted. A pity as the comments would help me next time > I am in the area if no one else. Hmm, well that should be changed if so! I can agree that some parts of Wine are painfully obscure. I've learned most of what I know about how Wine works by asking questions here and on IRC. Hopefully the developer guide expansion I worked on a while ago covers a lot of the more exotic topics. thanks -mike

June 3, 2006

Re: How are we doing?

by Mike Hearn

On Fri, 02 Jun 2006 08:03:46 -0500, Jeremy White wrote: > And I think I would agree that the Wine server is commented > about right; it is, imho, a beautiful piece of code. +1 to that. I reckon I didn't really grok in that deep-down-in-your-soul way what "good coding style" is until I took time to study the wineserver. That said, some parts of it could use a tad more explanation. The reader will know that files are opened for clients by the wineserver due to POSIX locking semantics ..... but not any more detail than that. How on earth does the blocking/sync/wait infrastructure in the server work? What is an "in flight" fd? When I started it was black magic. It also has a bunch of comments like this: /* initialize the structure for a newly allocated thread */ inline static void init_thread_structure( struct thread *thread ) ;) That said, I could not have written the wineserver, so my comments should be taken for what they're worth (not much)! thanks -mike

June 3, 2006

Re: How are we doing?

by Mike Hearn

On Fri, 02 Jun 2006 12:33:03 +0100, Robert Shearman wrote: > The lack of comments in your email is more horrifying. Haha :) Maybe we should have a new janitorial task "comment code", or maybe Alexandre should reject patches that don't have enough comments? The problem I think is that because MSDN basically describes what the code is meant to do, developers familiar with that area end up perceiving it all as "obvious". I know this was an issue with the old DCOM code, and it took a long time before I really understood what it was doing. I think the new code is a lot better commented which is nice. Plus we have in depth explanations of DCOM in the developer guide now. The other issue is that Wine is an extremely opaque codebase *unless* you know operating system design inside out, in which case it's often self explanatory. Most people don't, and this surfaces as "I wish it had more comments". Well, yeah .... thanks -mike

June 3, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Robert Shearman

Alexandre Julliard wrote: >"Dan Kegel" <dank(a)kegel.com> writes: > > > >>On 6/2/06, Alexandre Julliard <julliard(a)winehq.org> wrote: >> >> >>>The problem here is that you don't control at what point you interrupt >>>the process, so you can't do anything in it except system calls, and >>>that won't be enough. >>> >>> >>Why isn't a call to mmap enough? >> >> > >You need to build the proper structures on the client side, just like >a normal VirtualAlloc would, otherwise the process won't know about >that memory area. > You could add an entry to a linked list of operations that would defer the building of the proper structures. This list could then be checked on entry to every Nt*VirtualMemory and if it was not empty, these structures could be updated then, so it should appear to the client as though the structures were updated instantly. -- Rob Shearman

June 3, 2006

Re: FW: RE: My 1.0 wish list

by EA Durbin

That can't be used for a test case, for a test case I, or most likely someone elsewho has the ability and the time has to write code under dlls/msi/tests/db.c and make a program in windows to re-illustrate this bug. >From: "Jason Green" <jave27(a)gmail.com> >To: "EA Durbin" <ead1234(a)hotmail.com> >CC: mike(a)codeweavers.com, dank(a)kegel.com, wine-devel(a)winehq.org >Subject: Re: FW: RE: My 1.0 wish list >Date: Sat, 3 Jun 2006 12:02:15 -0400 > >On 6/3/06, EA Durbin <ead1234(a)hotmail.com> wrote: >> >>This problem in MSI spans a multitude of bugs. >> >>ATI demo(Rendering With Natural Light ) - bug # 4712? >> > >I noticed yesterday that just about every ATI Demo had similar >installer problems. Just try a few from here if you need some quick >test cases: > >http://www.ati.com/developer/demos.html > >Thanks, and good luck!

June 3, 2006

Re: To K&R or not

by Peter Beutner

James Hawkins schrieb: > We do have a consensus about tabs vs. spaces. To quote the page I > sent you in the last message: > > "Tabs are not forbidden but discouraged. A tab is defined as 8 > characters and the usual amount of indentation is 4 characters." > > More and more this is being followed, but we won't force it on anyone. > If someone creates a new page with tabs, we're not going to stop that > code from getting in. That is exactly the point. Unless you don't force it for everyone the consensus is more or less worthless. You have nice parts where people follow it and you have "ugly" parts where they don't follow it. In the end you have a horrible mix of everything. And that won't change. Especially for a project as big as wine I think it helps a lot in terms of readability to have some clearly defined coding styles. Plus with the current policy in mind I am not sure it is "allowed" at all to send patches to fix some places with totally broken indendation, because maybe the author just liked that style ;)

June 3, 2006

Re: To K&R or not

by James Hawkins

On 6/3/06, Peter Beutner <p.beutner(a)gmx.net> wrote: > > The question is in how far that really works in reality. Even when leaving > such (imho) minor things like K&R or not, spaces after if or not,etc aside. > Just look at the tabs vs. space issue: > I don't really have a problem with both of them but mixing them is imo the > worst thing that could happen. > > And things like this: > (tabs = underscore, space = dots) > > ...if() { > ______int foo; > ______if() { > ______.....do_something(); > ......_____for() > ......_____....do_somethingelse(); > ______} > ....} > (and yes you really find things like this) > > are just UGLY and if you don't have the exact same tabsize settings like the author > you get complete "garbage". > > Granted, I probably haven't even seen the majority of the source code and maybe I just found > one of the few negative examples, but imho some kind of consensus here would be > definitly a good thing. > > 4-space indention and using spaces instead of tabs already seems to be most used > setting, so why not enforce it for everybody? > We do have a consensus about tabs vs. spaces. To quote the page I sent you in the last message: "Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters." More and more this is being followed, but we won't force it on anyone. If someone creates a new page with tabs, we're not going to stop that code from getting in. -- James Hawkins

June 3, 2006

Re: FW: RE: My 1.0 wish list

by Jason Green

On 6/3/06, EA Durbin <ead1234(a)hotmail.com> wrote: > > This problem in MSI spans a multitude of bugs. > > ATI demo(Rendering With Natural Light ) - bug # 4712? > I noticed yesterday that just about every ATI Demo had similar installer problems. Just try a few from here if you need some quick test cases: http://www.ati.com/developer/demos.html Thanks, and good luck!

June 3, 2006