Re: How are we doing?
Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote: There is precious little Why in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc. BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice. I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn. Also it would really help look at the patch itself that _does_ explain what the patch is for. And might even link to the bug #. BTW Alexandre, can we preserve references to bug numbers in patch comments? That would be an ultimate explanation to what most questionable code does. Exactly my point. As in the case of wine, you must try to figure out what a block of code does, then that block of code calls existing wine functions that you've never seen before in your life. So then you have to trace that back to find out what the already implemented function does, and look through the code to it, because there is no documentation for it either, then it calls another function, so go ahead and trace back through the code for it too to find out And how that would be different from reading comments to each function? Or do you expect to have description of what each function with variation of the any other function can do? Vitaliy
Re: How are we doing?
Friday, June 2, 2006, 12:20:58 PM, EA Durbin wrote: From: Juan Lang [EMAIL PROTECTED] To: EA Durbin [EMAIL PROTECTED] CC: wine-devel@winehq.org Subject: Re: How are we doing? Date: Fri, 2 Jun 2006 10:56:15 -0700 (PDT) Especially the code that is responded to as , I know it's a mess to look at, but I didn't write it. Can you give us examples? Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll. There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along. For example, SHFileOperation was a complete mess until James fixed it up. Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions. I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep. Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/ --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com I'm just nitpicky I guess. If I use K R style, or not enough white space, or don't align things perfectly at work my boss will kindly print off a copy of the companies acceptable coding standards policy and bring it over. I guess I'm just used to having things that way, and the shifting coding style and lack of comments in places in wine makes the learning curve steeper than it needs to be for beginning wine developers. Just my 2 cents as a beginning wine developer. Oh yeah I see your pain right here... Even hard to respond in the well accepted format, not in a business ignorant style - My comments more important so I'll put then on top. Vitaliy
Re: How are we doing?
On 6/3/06, Vitaliy Margolen [EMAIL PROTECTED] wrote: I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn. Also it would really help look at the patch itself that _does_ explain what the patch is for. And might even link to the bug #. I think it's good to have seperate documentation to msdn. MSDN has a lot of inaccurate information and regularly discards information about older functions. What better place to put this seperate information, provided it is not too wordy, than in the source code? n0dalus.
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
Dan Kegel [EMAIL PROTECTED] writes: Are you willing to accept a patch which makes some common use cases work well, but does not address others? 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
Dan Kegel [EMAIL PROTECTED] writes: How 'bout we also implement remote thread creation, and create a temporary service thread to service a remote memory allocation request? That would give the thread context you say is required. Yes that's a possibility, we need support for creating remote threads in any case. But of course creating a remote thread correctly is a non-trivial problem too... -- Alexandre Julliard [EMAIL PROTECTED]
Re: How are we doing?
Vitaliy Margolen schrieb: Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote: There is precious little Why in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc. BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice. I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn. Only that there is no guarantee that the information in MSDN will stay forever ;) BTW Alexandre, can we preserve references to bug numbers in patch comments? Indeed that would be nice.
Re: How are we doing?
Peter Beutner [EMAIL PROTECTED] writes: BTW Alexandre, can we preserve references to bug numbers in patch comments? Indeed that would be nice. I'm not opposed to having bug number in the comments, but it has to be in addition to a proper explanation; the log must be understandable on its own without making reference to an external database. -- Alexandre Julliard [EMAIL PROTECTED]
Re: To KR or not
James Hawkins schrieb:
On 6/2/06, Aneurin Price [EMAIL PROTECTED] wrote:
How about setting a standard that will be used in the repository, and
providing the indent commands to set it that way, then indenting *every
file* in the repository to that standard. Then every developer can use
indent or whatever equivalent they prefer when they checkout, if they
don't like the chosen style.
Our coding standard is that there shall be no coding standard. As was
stated before, whoever creates the file, their style is the style that
should be used when anyone makes changes to that file.
The question is in how far that really works in reality. Even when leaving
such (imho) minor things like KR 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?
DAZ Studio
After running winecfg and setting winver for DAZStudio.exe to XP, I get the following. [EMAIL PROTECTED]:~/Download/Windows wine /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub fixme:imm:ImmReleaseContext (0xa00a2, 0x403cde30): stub fixme:imm:ImmReleaseContext (0x200aa, 0x403cde30): stub fixme:uniscribe:ScriptItemize LDAZ|Studio can search for directories that\2028may contain content from other programs\2028that DAZ|Studio can read. Please indicate\2028which drives you want DAZ|Studio to search.\2028NOTE: On large drives or network drives\2028this operation can take several minutes.\4291,249,255,(nil),(nil),0x415ae8a4,0x415af0b0: semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptShape (0xac0, 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptPlace (0xac0, 0x4232a600, 0x4232ba40, L'$=_6WXGLR, 10, 0x4232cea8, 0x4232d1ac, 0x4232bd2c): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db84, 1, 1, 0x4232d1d4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba54, L\0003, 1, 0x4232cebc, 0x4232d1d4, 0x4232bd54): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db86, 3, 3, 0x4232d1fc): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba56, LFDQ, 3, 0x4232cebe, 0x4232d1fc, 0x4232bd58): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8c, 1, 1, 0x4232d224): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5c, L\0003, 1, 0x4232cec4, 0x4232d224, 0x4232bd64): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8e, 6, 6, 0x4232d24c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5e, LVHDUFK, 6, 0x4232cec6, 0x4232d24c, 0x4232bd68): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9a, 1, 1, 0x4232d274): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6a, L\0003, 1, 0x4232ced2, 0x4232d274, 0x4232bd80): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9c, 3, 3, 0x4232d29c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6c, LIRU, 3, 0x4232ced4, 0x4232d29c, 0x4232bd84): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba2, 1, 1, 0x4232d2c4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba72, L\0003, 1, 0x4232ceda, 0x4232d2c4, 0x4232bd90): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba4, 11, 11, 0x4232d2ec): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba74, LGLUHFWRULHV, 11, 0x4232cedc, 0x4232d2ec, 0x4232bd94): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbba, 1, 1, 0x4232d314): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8a, L\0003, 1, 0x4232cef2, 0x4232d314, 0x4232bdc0): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbbc, 4, 4, 0x4232d33c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8c, LWKDW, 4, 0x4232cef4, 0x4232d33c, 0x4232bdc4): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbc4, 1, 1, 0x4232d364): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba94, L, 1, 0x4232cefc, 0x4232d364, 0x4232bdd4): semi-stub fixme:win:SetWindowTextA setting text EAX=6078 EBX=42A6810C ECX=415AF1D8 EDX=403DFDE0 ESI=4232BA94\nEDI=403DF9D8 EBP=415AF15C ESP=415AF144 EIP=42A66FF5 FLG=00210246\nCS=0073 DS=007B SS=007B ES=007B FS=1007 GS=0033 of other process window (nil) should not use SendMessage -- Andrew When the dragons grow too mighty To slay with pen or sword I grow weary of the battle And the storm I walk toward Madrigal by Rush (A Farewell to Kings, 1974)
Re: [Darwine] Quartz driver
At 10:48 PM +0200 5/31/06, Emmanuel Maillard wrote: Hi all, Quartz driver is up to date on Darwine CVS. Ah, so you managed to get bitmaps working. I attempted it, but was getting confused with the undocumented setbitmap behavior in WINE (the bitmaps were being loaded correctly, but weren't being copied to the frame buffer). Winemine is playable on both PPC and x86 but it look fine only on PPC, x86 driver suffer strange rendering bugs. I had weird rendering bugs related to endian issues--displaying little endian bitmaps on my PPC mac. I didn't pursue it further because I assumed it would be cleared up when running on x86. See wiki for building the driver : http://wiki.opendarwin.org/index.php/Darwine:quartzdrv I will update wiki soon with issues and todo for Quartz driver. I'll check this out later hopefully. Do the Win32 title bar buttons respond? IIRC there is a callback function which could easily trigger the analogous OS X events (well, at least minimize).
Re: How are we doing?
Matt Finnicum wrote: Also, sometimes it's not obvious why a function is called. A comment like Call funcResetStatusVariables because the above code triggers a redraw which can break them would save a new developer twenty minutes of But why update them THERE?! Does my code have to do that?. We seem to have a policy of not accepting comments in exisiting code. 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. Jeff
Re: Re: Re: Wine 1.0 Tasks
bint3LPh75nyW.bin Description: undefined
Re: Built-in iexplore
Le vendredi 02 juin 2006 à 13:42 -0700, Brandon a écrit : Daniel Skorka wrote: Oleksii Krykun [EMAIL PROTECTED] wrote: $ wine iexplore fixme:shdocvw:IEWinMain 1 fixme:ole:CoResumeClassObjects stub Could not load Mozilla. HTML rendering will be disabled. ^^ Where is aq problem? Guess. I get the same thing even though I have mozilla installed. I'm using wine in 64-bit linux, though, so that probably has something to do with it. You don't need mozilla, but the Mozilla activex control : http://source.winehq.org/mozactivex I don't know why shdocvw doesn't prompt the user to install it in this case though (so I'm CCing wine-devel and Jacek to see if something has to be changed in nsembed.c). Best regards. Jonathan Ernst signature.asc Description: Ceci est une partie de message numériquement signée
Re: DAZ Studio
Andrew, so far the uniscribe part looks like pretty much like I would expect. What is the problem you are experiencing? Jeff Andrew Neil Ramage wrote: After running winecfg and setting winver for DAZStudio.exe to XP, I get the following. [EMAIL PROTECTED]:~/Download/Windows wine /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub fixme:imm:ImmReleaseContext (0xa00a2, 0x403cde30): stub fixme:imm:ImmReleaseContext (0x200aa, 0x403cde30): stub fixme:uniscribe:ScriptItemize LDAZ|Studio can search for directories that\2028may contain content from other programs\2028that DAZ|Studio can read. Please indicate\2028which drives you want DAZ|Studio to search.\2028NOTE: On large drives or network drives\2028this operation can take several minutes.\4291,249,255,(nil),(nil),0x415ae8a4,0x415af0b0: semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptShape (0xac0, 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptPlace (0xac0, 0x4232a600, 0x4232ba40, L'$=_6WXGLR, 10, 0x4232cea8, 0x4232d1ac, 0x4232bd2c): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db84, 1, 1, 0x4232d1d4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba54, L\0003, 1, 0x4232cebc, 0x4232d1d4, 0x4232bd54): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db86, 3, 3, 0x4232d1fc): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba56, LFDQ, 3, 0x4232cebe, 0x4232d1fc, 0x4232bd58): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8c, 1, 1, 0x4232d224): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5c, L\0003, 1, 0x4232cec4, 0x4232d224, 0x4232bd64): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8e, 6, 6, 0x4232d24c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5e, LVHDUFK, 6, 0x4232cec6, 0x4232d24c, 0x4232bd68): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9a, 1, 1, 0x4232d274): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6a, L\0003, 1, 0x4232ced2, 0x4232d274, 0x4232bd80): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9c, 3, 3, 0x4232d29c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6c, LIRU, 3, 0x4232ced4, 0x4232d29c, 0x4232bd84): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba2, 1, 1, 0x4232d2c4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba72, L\0003, 1, 0x4232ceda, 0x4232d2c4, 0x4232bd90): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba4, 11, 11, 0x4232d2ec): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba74, LGLUHFWRULHV, 11, 0x4232cedc, 0x4232d2ec, 0x4232bd94): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbba, 1, 1, 0x4232d314): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8a, L\0003, 1, 0x4232cef2, 0x4232d314, 0x4232bdc0): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbbc, 4, 4, 0x4232d33c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8c, LWKDW, 4, 0x4232cef4, 0x4232d33c, 0x4232bdc4): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbc4, 1, 1, 0x4232d364): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba94, L, 1, 0x4232cefc, 0x4232d364, 0x4232bdd4): semi-stub fixme:win:SetWindowTextA setting text EAX=6078 EBX=42A6810C ECX=415AF1D8 EDX=403DFDE0 ESI=4232BA94\nEDI=403DF9D8 EBP=415AF15C ESP=415AF144 EIP=42A66FF5 FLG=00210246\nCS=0073 DS=007B SS=007B ES=007B FS=1007 GS=0033 of other process window (nil) should not use SendMessage
Re: DAZ Studio
When I run the command, I get a Crash Detected dialog with the following text: DAZStudio.exe caused an EXCEPTION_ACCESS_VIOLATION in module UNKNOWN at 0073:42A66FF5 Andrew When the dragons grow too mighty To slay with pen or sword I grow weary of the battle And the storm I walk toward Madrigal by Rush (A Farewell to Kings, 1974) Jeff Latimer wrote: Andrew, so far the uniscribe part looks like pretty much like I would expect. What is the problem you are experiencing? Jeff Andrew Neil Ramage wrote: After running winecfg and setting winver for DAZStudio.exe to XP, I get the following. [EMAIL PROTECTED]:~/Download/Windows wine /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub fixme:imm:ImmReleaseContext (0xa00a2, 0x403cde30): stub fixme:imm:ImmReleaseContext (0x200aa, 0x403cde30): stub fixme:uniscribe:ScriptItemize LDAZ|Studio can search for directories that\2028may contain content from other programs\2028that DAZ|Studio can read. Please indicate\2028which drives you want DAZ|Studio to search.\2028NOTE: On large drives or network drives\2028this operation can take several minutes.\4291,249,255,(nil),(nil),0x415ae8a4,0x415af0b0: semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptShape (0xac0, 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptPlace (0xac0, 0x4232a600, 0x4232ba40, L'$=_6WXGLR, 10, 0x4232cea8, 0x4232d1ac, 0x4232bd2c): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db84, 1, 1, 0x4232d1d4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba54, L\0003, 1, 0x4232cebc, 0x4232d1d4, 0x4232bd54): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db86, 3, 3, 0x4232d1fc): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba56, LFDQ, 3, 0x4232cebe, 0x4232d1fc, 0x4232bd58): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8c, 1, 1, 0x4232d224): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5c, L\0003, 1, 0x4232cec4, 0x4232d224, 0x4232bd64): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8e, 6, 6, 0x4232d24c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5e, LVHDUFK, 6, 0x4232cec6, 0x4232d24c, 0x4232bd68): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9a, 1, 1, 0x4232d274): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6a, L\0003, 1, 0x4232ced2, 0x4232d274, 0x4232bd80): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9c, 3, 3, 0x4232d29c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6c, LIRU, 3, 0x4232ced4, 0x4232d29c, 0x4232bd84): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba2, 1, 1, 0x4232d2c4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba72, L\0003, 1, 0x4232ceda, 0x4232d2c4, 0x4232bd90): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba4, 11, 11, 0x4232d2ec): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba74, LGLUHFWRULHV, 11, 0x4232cedc, 0x4232d2ec, 0x4232bd94): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbba, 1, 1, 0x4232d314): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8a, L\0003, 1, 0x4232cef2, 0x4232d314, 0x4232bdc0): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbbc, 4, 4, 0x4232d33c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8c, LWKDW, 4, 0x4232cef4, 0x4232d33c, 0x4232bdc4): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbc4, 1, 1, 0x4232d364): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba94, L, 1, 0x4232cefc, 0x4232d364, 0x4232bdd4): semi-stub fixme:win:SetWindowTextA setting text EAX=6078 EBX=42A6810C ECX=415AF1D8 EDX=403DFDE0 ESI=4232BA94\nEDI=403DF9D8 EBP=415AF15C ESP=415AF144 EIP=42A66FF5 FLG=00210246\nCS=0073 DS=007B SS=007B ES=007B FS=1007 GS=0033 of other process window (nil) should not use SendMessage
RE: My 1.0 wish list
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. From: Dan Kegel [EMAIL PROTECTED] To: wine-devel wine-devel@winehq.org Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
Re: mapi32: Write-strings warnings fix
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.0 +0100 +++ b/dlls/mapi32/sendmail.c 2006-06-03 14:44:21.0 +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; TRACE( Subject: %s\n, debugstr_a(subject) ); TRACE( Body: %s\n, debugstr_a(body) ); Greetings Peter
Re: DAZ Studio
Saturday, June 3, 2006, 6:14:14 AM, Andrew Neil Ramage wrote: After running winecfg and setting winver for DAZStudio.exe to XP, I get the following. [EMAIL PROTECTED]:~/Download/Windows wine /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub [skip] Please open a bug in bugzilla and report this problem there. (Attach your terminal output, don't paste). This list is not for such reports. Thank you . Vitaliy
Re: FW: RE: My 1.0 wish list
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 [EMAIL PROTECTED] To: EA Durbin [EMAIL PROTECTED] 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.
Re: FW: RE: My 1.0 wish list
On 6/3/06, EA Durbin [EMAIL PROTECTED] 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!
Re: To KR or not
On 6/3/06, Peter Beutner [EMAIL PROTECTED] wrote:
The question is in how far that really works in reality. Even when leaving
such (imho) minor things like KR 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
Re: To KR or not
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 ;)
Re: FW: RE: My 1.0 wish list
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 [EMAIL PROTECTED]
To: EA Durbin [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], wine-devel@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 [EMAIL PROTECTED] 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!
Index: dlls/msi/files.c
===
RCS file: /home/wine/wine/dlls/msi/files.c,v
retrieving revision 1.37
diff -u -p -r1.37 files.c
--- dlls/msi/files.c 23 May 2006 12:48:16 - 1.37
+++ dlls/msi/files.c 3 Jun 2006 16:34:07 -
@@ -387,7 +387,7 @@ static UINT ready_media_for_file( MSIPAC
'`','L','a','s','t','S','e','q','u','e','n','c','e','`',0};
LPCWSTR cab, volume;
DWORD sz;
-INT seq;
+INT seq, diskId;
LPCWSTR prompt;
MSICOMPONENT *comp = file-Component;
@@ -399,6 +399,9 @@ static UINT ready_media_for_file( MSIPAC
}
mi-count ++;
+
+TRACE(DEBUG OF SELECT * FROM `MEDIA` WHERE `LastSequence` = %i ORDER BY `LastSequence` \n, file-Sequence);
+
row = MSI_QueryGetRecord(package-db, ExecSeqQuery, file-Sequence);
if (!row)
{
@@ -408,10 +411,16 @@ static UINT ready_media_for_file( MSIPAC
seq = MSI_RecordGetInteger(row,2);
mi-last_sequence = seq;
+diskId = MSI_RecordGetInteger(row,1);
volume = MSI_RecordGetString(row, 5);
prompt = MSI_RecordGetString(row, 3);
+cab = MSI_RecordGetString(row,4);
+TRACE( Last Sequence returned is: %i \n, seq );
+TRACE( DiskId returned is: %i \n, diskId );
+TRACE( CAB returned is: %s \n, debugstr_w(cab) );
+
msi_free(mi-last_path);
mi-last_path = NULL;
@@ -432,7 +441,6 @@ static UINT ready_media_for_file( MSIPAC
return rc;
}
-cab = MSI_RecordGetString(row,4);
if (cab)
{
TRACE(Source is CAB %s\n,debugstr_w(cab));
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] writes: On 6/2/06, Alexandre Julliard [EMAIL PROTECTED] 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
Re: How are we doing?
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
Re: How are we doing?
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
Re: How are we doing?
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
Re: Shell integration idea
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
Re: Added initial version of Wine OleView
On 6/3/06, Piotr Caban [EMAIL PROTECTED] 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
Re: MSI query tests
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
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
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
Re: Prospects of an OpenAL audio driver...
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
wined3d: Another GLSL shader status update
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)
Re: FW: RE: My 1.0 wish list
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
Re: Wine VM86 exception handling bug?
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
Re: Added initial version of Wine OleView
Saturday, June 3, 2006, 11:36:45 AM, Piotr Caban wrote: Please change FSF's address to the new one. Vitaliy Margolen
Re: To KR or not
On 6/3/06, Stephen Clark [EMAIL PROTECTED] 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
Re: mapi32: Write-strings warnings fix
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.
Re: mapi32: Write-strings warnings fix
Option 2 is the way to go. -- A.
Re: mapi32: Write-strings warnings fix
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.
Re: mapi32: Write-strings warnings fix
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
Re: Prospects of an OpenAL audio driver...
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
Re: mapi32: Write-strings warnings fix
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.
Re: Shell integration idea
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.
Re: Shell integration idea
On 6/3/06, Mikołaj Zalewski [EMAIL PROTECTED] 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
Re: mapi32: Write-strings warnings fix
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.
Re: To KR or not
James Hawkins schrieb: On 6/3/06, Stephen Clark [EMAIL PROTECTED] 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?
DirectX blitter bug
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
Re: DirectX blitter bug
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
Re: wined3d: Another GLSL shader status update
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)
Re: wined3d: Another GLSL shader status update
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
Re: FW: RE: My 1.0 wish list
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
Re: My 1.0 wish list
On 6/3/06, EA Durbin [EMAIL PROTECTED] wrote: I just tested the latest Kidspiration install. The self extracting .exeextracts 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 theprogram 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
Re: FW: RE: My 1.0 wish list
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 [EMAIL PROTECTED] wrote: I have compiled a list of applications that are affected by the bug in whichthe query in ready_media_for_file() in MSI returns the wrong results, it returns LastSequence less than thefile-Sequence being passed.Here is a detailed analysis of the multiple types of errors this bugscauses.Common debug outputs of this bug are:Error #1: err:msi:ACTION_InstallFiles compressed file wasn't extractedThis error is usually caused by the results of the query returning aLastSequence 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 failederr:msi:ACTION_InstallFiles Unable to ready mediaThere 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 zeroin 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 #5139J2SE - bug # 4280Half Life 2 - bug # 5004, 4533 Dawn of War Demo - bug # 3749E-Sword 6.5 - bug # 4251Rush for Berlin demo - bug #5187ATI 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 andnot the pertainent msi err lines. I only included applications where it wasobvious from the log, or I tested personally.From: Mike McCormack [EMAIL PROTECTED]To: EA Durbin [EMAIL PROTECTED]Subject: Re: FW: RE: My 1.0 wish listDate: Sun, 04 Jun 2006 00:30:41 +0900 You can send me as many mails as you like, but I'm not doing anything untilthere's a test case showing the problem.MikeI wrote a test showing the results of the query in the wine installer and included the source code and resulting logs which clearly displays theproblem. 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 Ilayed out the problem, and debugged it, and I've proven this with code andresulting 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 canremain broken.
