May 2009 - Wine-Devel - list.winehq.org

Re: Wine policy question: What is considered "reverse engineering"/what is acceptable?

by Jerome Leclanche

I thought reverse engineering was only relevant to MS code? As in reverse engineering of windows dlls and so on; another application would be irrelevant. That's what I understood from it anyway. J. On Wed, May 13, 2009 at 10:20 PM, Daniel Santos <javatroubadour(a)yahoo.com> wrote: > I was recently attempting to isolate the cause of a hang in Lord of the > Rings Online and had it in a debugger. I mentioned this on IRC and was told > that I was "reverse engineering" and any patch I came up with would not be > accepted. I find this rather confusing and would like to better understand > the "dos and don'ts" of wine development. Is this documented anywhere? > > If it matters any, the license agreement says that you may not reverse > engineering it including "decompiling or disassembling" but it does not > specifically mention using a debugger (although viewing disassembly from the > debugger would obviously be covered). My aim was only to attempt to > determine which thread(s) were hanging so I could isolate my logging to > those thread(s) and try to figure out what was going wrong. > > Thanks, > Daniel > > > > > -- Adys

May 13, 2009

Wine policy question: What is considered "reverse engineering"/what is acceptable?

by Daniel Santos

I was recently attempting to isolate the cause of a hang in Lord of the Rings Online and had it in a debugger. I mentioned this on IRC and was told that I was "reverse engineering" and any patch I came up with would not be accepted. I find this rather confusing and would like to better understand the "dos and don'ts" of wine development. Is this documented anywhere? If it matters any, the license agreement says that you may not reverse engineering it including "decompiling or disassembling" but it does not specifically mention using a debugger (although viewing disassembly from the debugger would obviously be covered). My aim was only to attempt to determine which thread(s) were hanging so I could isolate my logging to those thread(s) and try to figure out what was going wrong. Thanks, Daniel

May 13, 2009

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)

by Daniel Santos

Steven, sorry for the slow response, I got tied up in some other stuff. But now back to fun. =) And thanks for your response! The application is Lord of the Rings Online. They don't use normal version numbers, so this bug actually started with "Book 14". In Book 14, the problem would manifest as a crash. The current version is "Mines of Moria" and now I will get either a crash (segfault) or a hang, but the result is a hang 6 times out of 7 (or so). However, I've run into a more serious problem that I have yet to resolve, and I'll post it in a new thread. This problem is related to what is considered acceptable behavior and what is not and what is considered "reverse engineering". I mentioned that I had the program in winedbg and was examining the threads when I was informed that I was reverse engineering and any patch I came up with doing this would not be accepted. I found this rather confounding to say the least!! Anyway, the hang or crash may occur immediately (under 50 milliseconds) after switching to the LOTRO window or it may only occur after I start moving around. It will always occur within 10 or 20 seconds of having switched to the window, usually within 4 or 5. So if I start playing after swithcing to the window and I make it 30 seconds, I'm confident that it wont crash that time. If you want to install this app, I have recently written up a pretty install script to do some enviroment setup and posted it on the appdb here: http://appdb.winehq.org/objectManager.php?sClass=version&iId=14566 You can even create a trial account for testing. Unfortunately, it's a 7GB download. One of my shortcomings in troubleshooting this is that I've never done directx or direct3d, so I don't understand all of the implications of these window events from that perspective (or direct input). I'm going to play more with this today as well. Daniel --- On Sat, 5/9/09, Steven Edwards <winehacker(a)gmail.com> wrote: From: Steven Edwards <winehacker(a)gmail.com> Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags) To: daniel.santos(a)pobox.com Date: Saturday, May 9, 2009, 3:16 PM On Sat, May 9, 2009 at 3:44 PM, Daniel Santos <javatroubadour(a)yahoo.com> wrote: > Additionally, as far as I can tell, there is no mechanism to change it for > all channels. This is actually what I need to do since I do not know where > the specific problem is that I'm troubleshooting and I don't even know for > certain that it isn't a bug in the 3rd party software. What I do know is > that it does not occur on windows and I suspect it's a case of the 3rd party > app entering "undefined results" territory and that on windows, this result > is consistent and does not cause a problem. > > When I attempt to run the app with WINEDEBUG=+all, it appears to enter some > type of deadlock state before I can even get to the point where the bug > normally happens. This hang is probably due to poor timing management in > the app and may indeed be another expression of the same core problem. > > Speaking of the wine task manager, where is that? (or which executable is > it)? Its taskmgr in the source tree as wine/programs/taskmgr. You might try doing something like +relay,+seh,+tid for your channels to isolate the problem down. I might be able to help you isolate the problem but I doubt I can fix it for you even if we are able to find it but that's at least a start. What software are you trying to get to work? Can you describe the exact nature of the problem? Sorry I must confess I've not been following the thread very closely. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 13, 2009

Re: SoC 2009 / Application Test Suite Update

by Austin English

On Wed, May 13, 2009 at 1:01 PM, James Hawkins <truiken(a)gmail.com> wrote: > On Wed, May 13, 2009 at 10:27 AM, Austin English > <austinenglish(a)gmail.com> wrote: >> Howdy all, >> >> I've been working on the test suite. I've got a few basic tests set up >> with notepad, and I'm currently working on setting up the framework, >> using AutoHotKey to both run all the tests and parse the logs for >> failures/passing todo's. >> >> For those interested, here's the first 'real' script I've written. It >> sets up a test directory (C:\appinstall), downloads sha1sum.exe (if it >> doesn't exist), verifies its own sha1sum, downloads winscp.exe >> (portable version), sets up winscp.ini with its settings (I was going >> to use keyboard/mouse control, but ftp.winehq.org times out to >> quickly, and adjusting that setting with mouse/keyboard would be a lot >> more trouble), runs winscp, downloads welcome.msg, closes winscp, >> sha1sum's welcome.msg, and finally, deletes welcome.msg and >> winscp.ini. >> > > This should probably be done in a temporary directory instead of > hard-coded to C:\appinstall. Of course. I'm working on changing any temporary stuff to %TEMP%\appinstall. The reason for C:\appinstall (more accurately, %SYSTEMDIR%, so it will work on Windows installs without a C:\ drive) is to cache downloads. That way sha1sum.exe, wget.exe, etc. don't have to be downloaded repeatedly (they are still sha1sum'ed before use). I'm thinking a bit ahead, that way we can test, e.g., Photoshop CS 3, which has a download available, but not one that is scriptable. That way, if someone running the script already has CS 3 in place, the test is run. Else, it will get skipped, saying 'photoshop isn't available, download manually and place in C:\appinstall if you want to test it'. -- -Austin

May 13, 2009

Re: SoC 2009 / Application Test Suite Update

by James Hawkins

On Wed, May 13, 2009 at 10:27 AM, Austin English <austinenglish(a)gmail.com> wrote: > Howdy all, > > I've been working on the test suite. I've got a few basic tests set up > with notepad, and I'm currently working on setting up the framework, > using AutoHotKey to both run all the tests and parse the logs for > failures/passing todo's. > > For those interested, here's the first 'real' script I've written. It > sets up a test directory (C:\appinstall), downloads sha1sum.exe (if it > doesn't exist), verifies its own sha1sum, downloads winscp.exe > (portable version), sets up winscp.ini with its settings (I was going > to use keyboard/mouse control, but ftp.winehq.org times out to > quickly, and adjusting that setting with mouse/keyboard would be a lot > more trouble), runs winscp, downloads welcome.msg, closes winscp, > sha1sum's welcome.msg, and finally, deletes welcome.msg and > winscp.ini. > This should probably be done in a temporary directory instead of hard-coded to C:\appinstall. > It already found one bug :-): > http://bugs.winehq.org/show_bug.cgi?id=18455. On windows, when > selecting the file to download, winscp pops up a dialog to allow you > to put in an alternate path to save the file. On windows, it's already > selected, so one can simply type a different path. On Wine, it's not > selected, breaking the script. It's an easy work around (sending > {HOME}, followed by {SHIFT}{END}), it's interesting that the script > allows us to find such subtle bugs. > Good catch! Hopefully the scripts will find many more bugs like this, as well as keep Wine from regressing. -- James Hawkins

May 13, 2009

Adding broken() information to the test output

by Paul Vriens

Hi, While going over some just committed patches of mine I saw (again) that we now have some tests that do: ok(ret || broken(!ret), "call failed") The good thing is that tests succeed on all Windows versions and will fail if Wine returns !ret. The bad thing is that changes in the Windows implementation won't be catched. If MS decides to change the return value (in current or newer versions) we won't see this. Is adding broken() information to the test output helpful? So, if a test succeeds due to the broken() it will put out a message like: <file.c>:<line> Test marked broken() succeeded: call failed. I'm only proposing to have this in the output, not visible on test.winehq.org (for now?). Thoughts anybody? -- Cheers, Paul.

May 13, 2009

SoC 2009 / Application Test Suite Update

by Austin English

Howdy all, I've been working on the test suite. I've got a few basic tests set up with notepad, and I'm currently working on setting up the framework, using AutoHotKey to both run all the tests and parse the logs for failures/passing todo's. For those interested, here's the first 'real' script I've written. It sets up a test directory (C:\appinstall), downloads sha1sum.exe (if it doesn't exist), verifies its own sha1sum, downloads winscp.exe (portable version), sets up winscp.ini with its settings (I was going to use keyboard/mouse control, but ftp.winehq.org times out to quickly, and adjusting that setting with mouse/keyboard would be a lot more trouble), runs winscp, downloads welcome.msg, closes winscp, sha1sum's welcome.msg, and finally, deletes welcome.msg and winscp.ini. It already found one bug :-): http://bugs.winehq.org/show_bug.cgi?id=18455. On windows, when selecting the file to download, winscp pops up a dialog to allow you to put in an alternate path to save the file. On windows, it's already selected, so one can simply type a different path. On Wine, it's not selected, breaking the script. It's an easy work around (sending {HOME}, followed by {SHIFT}{END}), it's interesting that the script allows us to find such subtle bugs. Back to work... -- -Austin

May 13, 2009

Re: dplayx: Enclose NS_GetOtherMagic() in #if 0 since it's only used from code enclosed in #if 0.

by Ismael Barros²

NS_GetOtherMagic is probably safe to remove. NS_GetNsMagic was only used in some hackish code that tried to reverse engineer dplay protocol. I removed that code that used it, but don't know if it'll be needed in a future. On Wed, May 13, 2009 at 12:10 PM, Kai Blin <kai.blin(a)gmail.com> wrote: > On Wednesday 13 May 2009 10:38:08 Francois Gouget wrote: > > Personally I think we should just kill all that unused code and be done with > it. Currently the only way to get a working dplay implementation is to use > the native dlls anyway. Our version has been bit-rotting for quite some time. > > Cheers, > Kai > >> 1) Remove this dead code altogether... > > >> 2) Replace the #if 0 with an if (0) so that the function is 'used' >> 3) Fix the code so it has neither #if 0 nor if (0) (which might be the >> same as option 1, I have no idea) >> >> >> dlls/dplayx/name_server.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/dplayx/name_server.c b/dlls/dplayx/name_server.c >> index e6a6b62..a503270 100644 >> --- a/dlls/dplayx/name_server.c >> +++ b/dlls/dplayx/name_server.c >> @@ -183,6 +183,7 @@ DWORD NS_GetNsMagic( LPVOID lpNSInfo ) >> return lpHdrInfo[1]; >> } >> >> +#if 0 >> /* Get the magic number associated with the non NS end */ >> DWORD NS_GetOtherMagic( LPVOID lpNSInfo ) >> { >> @@ -190,6 +191,7 @@ DWORD NS_GetOtherMagic( LPVOID lpNSInfo ) >> >> return ((LPDWORD)lpCache->lpLocalAddrHdr)[1]; >> } >> +#endif >> >> void NS_SetLocalAddr( LPVOID lpNSInfo, LPCVOID lpHdr, DWORD dwHdrSize ) >> { > > > > -- > Kai Blin > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin > Samba team member http://www.samba.org/samba/team/ > -- > Will code for cotton. > > > >

May 13, 2009

Fiddling with EnumServicesStatusExW

by Paul Vriens

(I accidentally only sent this message to Rob only) Hi, To get away from the tests stuff I thought I'd resurrect my plans to implement EnumServiceStatusExW (the A-version is needed by SysInternal's Process Explorer amongst others). I have most of the stuff ready: - Added svcctl_EnumServicesStatusExW to /wine/wine-git/include/wine/svcctl.idl - Added svcctl_EnumServicesStatusExW to /wine/wine-git/programs/services/rpc.c - Added a enumeration routine to /wine/wine-git/programs/services/services.c (and .h of course) - Changed EnumServiceStatusExW in /wine/wine-git/dll/advapi32/service.c to call svcctl_EnumServicesStatusExW There is one important thing I can't get my head around. The call to EnumServicesStatusExW passes a pointer to a BYTE * lpServices with a length of cBufSize. lpServices is an array of some ENUM_SERVICE_STATUS_PROCESSW structs. The first two parameters of these structs are pointers to WCHAR strings. The strings for all these structs (on Windows) can be found after all the structs themselves. So imagine that we should have 2 services in our lpServices to be passed back to the initial caller: 0000 [0].lpServiceName -> 0088 0008 [0].lpDisplayName -> 0114 0016 [0].SERVICE_STATUS struct of 7 DWORDS 0044 [1].lpServiceName -> 0140 0052 [1].lpDisplayName -> 0166 0060 [1].SERVICE_STATUS struct of 7 DWORDS 0088 "ServiceName1" 0114 "DisplayName1" 0140 "ServiceName1' 0166 "DisplayName1" (The above is what EnumServicesStatusExW would pass back to the caller) The enumeration I have in services.c fills the lpServiceName pointer to the actual string. Likewise for lpDisplayName. This is all in the RPC world (where the lpServices address is different to the caller passed address). When lpServices is passed back to the caller I can see that the SERVICE_STATUS structs are correct but the pointers to the strings are pointing to the original ones. How can I make sure the pointers to the strings are correctly passed back as well? Should the RPC stuff take care of these pointers and 'translate' them? We could of course teach EnumServicesStatusExW to change the pointers to the appropriate ones. We know exactly where there strings are so it should be fairly trivial to change those pointers. This however seems like a hack. Any idea is welcome. -- Cheers, Paul.

May 13, 2009

Re: dplayx: Enclose NS_GetOtherMagic() in #if 0 since it's only used from code enclosed in #if 0.

by Kai Blin

On Wednesday 13 May 2009 10:38:08 Francois Gouget wrote: Personally I think we should just kill all that unused code and be done with it. Currently the only way to get a working dplay implementation is to use the native dlls anyway. Our version has been bit-rotting for quite some time. Cheers, Kai > 1) Remove this dead code altogether... > 2) Replace the #if 0 with an if (0) so that the function is 'used' > 3) Fix the code so it has neither #if 0 nor if (0) (which might be the > same as option 1, I have no idea) > > > dlls/dplayx/name_server.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/dplayx/name_server.c b/dlls/dplayx/name_server.c > index e6a6b62..a503270 100644 > --- a/dlls/dplayx/name_server.c > +++ b/dlls/dplayx/name_server.c > @@ -183,6 +183,7 @@ DWORD NS_GetNsMagic( LPVOID lpNSInfo ) > return lpHdrInfo[1]; > } > > +#if 0 > /* Get the magic number associated with the non NS end */ > DWORD NS_GetOtherMagic( LPVOID lpNSInfo ) > { > @@ -190,6 +191,7 @@ DWORD NS_GetOtherMagic( LPVOID lpNSInfo ) > > return ((LPDWORD)lpCache->lpLocalAddrHdr)[1]; > } > +#endif > > void NS_SetLocalAddr( LPVOID lpNSInfo, LPCVOID lpHdr, DWORD dwHdrSize ) > { -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

May 13, 2009

Re: [1/2] wininet: Implement GetDiskInfoA.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > + if ((ret = GetDiskFreeSpaceA(path, &cluster_sectors, &sector_bytes, &free_clusters, &total_clusters))) > + { > + if (cluster_size) *cluster_size = 1; > + if (free) *free = free_clusters * cluster_sectors * sector_bytes; > + if (total) *total = total_clusters * cluster_sectors * sector_bytes; > + } You should use GetDiskFreeSpaceExA to avoid trouble on large disks. -- Alexandre Julliard julliard(a)winehq.org

May 13, 2009

Re: C_ASSERT portability fixes and simplification [PATCH 1/2]

by Gerald Pfeifer

On Mon, 11 May 2009, Alexandre Julliard wrote: > I don't have gcc 4.5 to test this, but you could try using a function > instead, something like this: > > diff --git a/include/winnt.h b/include/winnt.h > index abcc502..aaa4112 100644 > --- a/include/winnt.h > +++ b/include/winnt.h > @@ -292,7 +292,7 @@ extern "C" { > #if defined(_MSC_VER) > # define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1] > #elif defined(__GNUC__) > -# define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] __attribute__((unused)) > +# define C_ASSERT(e) extern void __C_ASSERT__(int [(e)?1:-1]) > #else > # define C_ASSERT(e) > #endif You are a clever man, Sir! :-) It took me a bit, since incidently the GCC 4.5 development tree was broken wrt. Wine on Monday (I reported this bug upstream), but a build with your patch went through both with GCC 4.2.1 and GCC 4.5.0 (experimental) tonight. I assume you will commit this now? Thanks, Gerald

May 13, 2009

Re: [1/3] WineD3D: Separate Tx tempregs from Tx varyings in ARB

by Henri Verbeet

2009/5/12 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Am Dienstag, 12. Mai 2009 21:17:10 schrieb Henri Verbeet: >> I'm probably missing something obvious, but with pre-1.4 texcoord >> registers being read-write, what happens when you write to the >> register before using it to sample a texture? > Nothing special. However, you can't use it to sample afterwards, because you > can't use a tex* instruction after a non-tex instruction. Ie: > Ok.

May 13, 2009

Re: [1/3] WineD3D: Separate Tx tempregs from Tx varyings in ARB

by Stefan Dösinger

Am Dienstag, 12. Mai 2009 21:17:10 schrieb Henri Verbeet: > I'm probably missing something obvious, but with pre-1.4 texcoord > registers being read-write, what happens when you write to the > register before using it to sample a texture? Nothing special. However, you can't use it to sample afterwards, because you can't use a tex* instruction after a non-tex instruction. Ie: ps_1_3 tex t0 mov t1, t0 tex t1 mov r0, t0 Z:\dev\shm\shader.txt(4,1): error X5055: Cannot use tex* instruction after non-tex* instruction. With my patch, the mov will write to the temporary register form of t1; fragment.texcoord[1] will never be used in a correct shader. Now we don't enforce the tex-after-non-tex rule, but if we ever get such a shader enforcing this restriction is how to fix problems. You cannot sample a Tx coord twice either: ps_1_3 tex t0 tex t1 texbem t1, t0 mov r0, t1 Z:\dev\shm\shader.txt(4,1): error X5053: Tex register t1 already declared. This even applies to texkill: ps_1_3 tex t0 tex t1 texkill t1 mov r0, t0 Z:\dev\shm\shader.txt(4,1): error X5053: Tex register t1 already declared. or ps_1_3 texkill t0 tex t0 mov r0, t0 Z:\dev\shm\shader.txt(3,1): error X5053: Tex register t0 already declared. If you want dependent reads in ps_1_3 and earlier, you have to use texreg2rgb: ps_1_3 tex t0 texreg2rgb t1, t0 mov r0, t1 texreg2rgb knows that it should take the address from the tempreg form of t0, not fragment.texcoord[0]. You cannot use texreg2rgb to read from the texture coord: ps_1_3 texreg2rgb t1, t0 mov r0, t1 Z:\dev\shm\shader.txt(2,1): error X5036: Read of uninitialized components(*) in t0: *r/0 *g/1 *b/2 *a/3 If you want to do that, you have to use texcrd: ps_1_3 texcoord t0 texreg2rgb t1, t0 mov r0, t1 in which case texcoord to is a MOV_SAT t0, fragment.texcoord[0]; > > I've put it in the backend and not the frontend because a hypothetical > > nvts shader backend would be confused by this. > > Completely off-topic of course, but isn't it somewhat questionable to > anthropomorphize source code? Maybe. I had to make a decision where to put this register separation code, and I decided that this strange t0 register is valuable information on hardware/APIs that works the same way(ie, nvts, but not atifs), so implementing this register separation throws away information that may be important to such a shader implementation.

May 12, 2009

Re: wined3d: Fix ATI dx10 cards max varying quirk

by Stefan Dösinger

Am Dienstag, 12. Mai 2009 07:36:01 schrieb Robert Key: > I fiddled around with the test and I was able to use varying vec4 > var_in[13] as a max in one array. 14 - 16 resulted in a segmentation > fault and 17 resulted in glLinK failure error. > > I was able to create a second array of varying vec4 testa[3] though > and it compiled successfully resulting in 64 varyings. I'll attach what I > did. Good catch! Now it sounds like a genuine bug in the driver to me, one that should probably be fixed in the driver, not worked around by us. Can you file a bug in ATIs (unofficial) Bugzilla at http://ati.cchtml.com/, attaching the test program(and probably one that crashes the driver) and describing the issue? I'll then make Matthew Tippet aware of it if no ATI guy replies on their own. Given the circumstances, I'd say to leave the bug without Wine workaround for now. If we limit the varyings to 54 or 52 it would be incorrect. If Wine keeps crashing, this will put more pressure on ATI to fix the issue. (The best way to get things fixed is to break them)

May 12, 2009

Re: [1/3] WineD3D: Separate Tx tempregs from Tx varyings in ARB

by Henri Verbeet

2009/5/12 Stefan Dösinger <stefan(a)codeweavers.com>: > ps_1_3 uses Tx to pass in texture coordinates, but also as temporary > registers. ps_1_4 and ps_2_0 only use them for texture coordinates. This patch > gets rid of the Tx = fragment.texcoord[x] assign in all shader versions, and > doesn't even declare Tx in ps_1_4 and ps_2_0. > > The <=ps_1_3 instructions know which kind of input they expect from the Tx > register, so the instruction handlers now know if they have to read the > tempreg Tx or the varying fragment.texcoord[x] I'm probably missing something obvious, but with pre-1.4 texcoord registers being read-write, what happens when you write to the register before using it to sample a texture? > I've put it in the backend and not the frontend because a hypothetical nvts > shader backend would be confused by this. > Completely off-topic of course, but isn't it somewhat questionable to anthropomorphize source code?

May 12, 2009

Re: Question on writing a testcase..

by chris ahrendt

Paul Vriens wrote: > chris ahrendt wrote: >> I have two test cases for the file.c test in kernel32 to show two >> problems I have found and reported as bugs that wine should be able >> to handle. >> >> first problem : >> >> I/O warning : failed to load external entity >> "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" >> >> Wine does not seem to be parsing this correctly while the various >> windows platforms do correctly. >> So I would like to put a test for this in the test case. >> >> Second file issue I found that needs a test case : >> >> I/O warning : failed to load external entity "EQ/updatestatus.xml" >> >> It seems wine is expecting a fully qualified path in this case where >> as windows uses the application running directory and then looks >> there... >> I am not even sure where this is looking in wine. I would guess at >> the root level from the z: mapping if I had to venture a guess >> instead of the current running directory. >> >> Would I just write the two subroutines and then submit them to >> wine-patch? >> >> Chris >> >> > What function(s) are the tests for? Did you already write some > testcases and run them on Windows? > > -- Cheers, > > Paul. > > They are for the open file api let me find the exact API.. filehandle = _lopen( filename, OF_READ ); in the dlls/kernel32/tests/file.c I also would write the test for _lcreate and the other couple of API's that return a file handle. And I am using an application on windows already that does the open in this manner... but could hack something out really quick. Chris

May 12, 2009

Re: Question on writing a testcase..

by Paul Vriens

chris ahrendt wrote: > I have two test cases for the file.c test in kernel32 to show two > problems I have found and reported as bugs that wine should be able to > handle. > > first problem : > > I/O warning : failed to load external entity > "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" > > Wine does not seem to be parsing this correctly while the various > windows platforms do correctly. > So I would like to put a test for this in the test case. > > Second file issue I found that needs a test case : > > I/O warning : failed to load external entity "EQ/updatestatus.xml" > > It seems wine is expecting a fully qualified path in this case where as > windows uses the application running directory and then looks there... > I am not even sure where this is looking in wine. I would guess at the > root level from the z: mapping if I had to venture a guess instead of > the current running directory. > > Would I just write the two subroutines and then submit them to wine-patch? > > Chris > > What function(s) are the tests for? Did you already write some testcases and run them on Windows? -- Cheers, Paul.

May 12, 2009

Question on writing a testcase..

by chris ahrendt

I have two test cases for the file.c test in kernel32 to show two problems I have found and reported as bugs that wine should be able to handle. first problem : I/O warning : failed to load external entity "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" Wine does not seem to be parsing this correctly while the various windows platforms do correctly. So I would like to put a test for this in the test case. Second file issue I found that needs a test case : I/O warning : failed to load external entity "EQ/updatestatus.xml" It seems wine is expecting a fully qualified path in this case where as windows uses the application running directory and then looks there... I am not even sure where this is looking in wine. I would guess at the root level from the z: mapping if I had to venture a guess instead of the current running directory. Would I just write the two subroutines and then submit them to wine-patch? Chris

May 12, 2009

Re: [2/2] kernel32: Fix GetVolumeNameForVolumeMountPointW to match Mountmgr

by Guy Albertelli

On Sat, 2009-05-09 at 09:52 -0600, Vitaliy Margolen wrote: > Few nitpicks about your patch. > > Guy Albertelli wrote: > > > + /* is there space in the return variable ?? */ > > + if ((o1->SymbolicLinkNameLength/sizeof(WCHAR))+2 > size) > > + { > > + SetLastError( ERROR_INVALID_PARAMETER ); > > + goto err_ret; > > + } > This doesn't look right. There are several other error codes that more > appropriate. You should expand your tests to check what native returns here. > Also are you sure that "size" is in chars not bytes? You are right, should be ERROR_FILENAME_EXCED_RANGE - at least on XP. Will cleanup rest and resubmit with additional tests Thanks Guy

May 12, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Reece Dunn

Paul Vriens wrote: > Paul Vriens wrote: >> >> Reece Dunn wrote: >>> >>> According to Windows guidelines, command buttons >>> (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x >>> 14 DLUs (they can be wider than 50 DLUs, but only if the text is >>> bigger than that, which it shouldn't for OK buttons) and have a 4 DLU >>> spacing between other controls. This is so they look good in the >>> presence of themes. >>> >>> - Reece >> >> Maybe, but doing a simple grep shows: >> >> shell32_Bg.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Cs.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Da.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_De.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP >> shell32_En.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Fi.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Fr.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 70, 12, WS_TABSTOP >> shell32_Hu.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_It.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Ja.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Nl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_No.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Pl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Ro.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Ru.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Sk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Sv.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> shell32_Uk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> >> The size of these OK buttons is probably aligned with the other button in >> that window. Sure. There are a lot of places (not just in what you are fixing) that are incorrect. I would like to go through and fix all the layout issues so that the dialogs look nice and are consistent across all the different languages. However, this is a *huge* job. What I would like to do is get an automated (or semi-automated) tool, ideally with a GUI interface to it. That would ultimately put the designer in charge. Hopefully, this would also mean that you have a base resource file that produces the English resources and generate the others using the standard po files - thus making it easier to translate. I'm not sure how far the project should go. And, realistically, at least the core - a command line source+po <==> resource file mapping - should be in Wine as it will need to generate the resource files at runtime (unless a dependency is created on that project).. > I'm not against changing the size of that OK button to 50x14 but was merely > pointing out that this means most of this stuff is not correct. Sure -- see my comments above. > FWIW I was just looking at Outlook 2003 and the OK button on the about > window is the same wide as the other buttons (not 50). The page you > reference doesn't say anything about adjusting sizes of buttons when > multiple (horizontally or vertically) can be found on one page (or at least > I didn't see it). I'm not sure, either. However, I think that consistency is important. - Reece

May 12, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Paul Vriens

Paul Vriens wrote: > Reece Dunn wrote: >> 2009/5/12 Paul Vriens <paul.vriens.wine(a)gmail.com>: >>> Hi, >>> >>> Changed the sizes of the buttons and window to be the same as in >>> English. This make sure the 'Wine license' button can be fully read in >>> Dutch. >>> >>> - DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP >>> + DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP >> >> According to Windows guidelines, command buttons >> (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x >> 14 DLUs (they can be wider than 50 DLUs, but only if the text is >> bigger than that, which it shouldn't for OK buttons) and have a 4 DLU >> spacing between other controls. This is so they look good in the >> presence of themes. >> >> - Reece > Maybe, but doing a simple grep shows: > > shell32_Bg.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Cs.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Da.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_De.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP > shell32_En.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Fi.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Fr.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 70, 12, WS_TABSTOP > shell32_Hu.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_It.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Ja.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Nl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_No.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Pl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Ro.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Ru.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Sk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Sv.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > shell32_Uk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > > The size of these OK buttons is probably aligned with the other button > in that window. > I'm not against changing the size of that OK button to 50x14 but was merely pointing out that this means most of this stuff is not correct. FWIW I was just looking at Outlook 2003 and the OK button on the about window is the same wide as the other buttons (not 50). The page you reference doesn't say anything about adjusting sizes of buttons when multiple (horizontally or vertically) can be found on one page (or at least I didn't see it). -- Cheers, Paul.

May 12, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Paul Vriens

Reece Dunn wrote: > 2009/5/12 Paul Vriens <paul.vriens.wine(a)gmail.com>: >> Hi, >> >> Changed the sizes of the buttons and window to be the same as in >> English. This make sure the 'Wine license' button can be fully read in >> Dutch. >> >> - DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP >> + DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP > > According to Windows guidelines, command buttons > (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x > 14 DLUs (they can be wider than 50 DLUs, but only if the text is > bigger than that, which it shouldn't for OK buttons) and have a 4 DLU > spacing between other controls. This is so they look good in the > presence of themes. > > - Reece Maybe, but doing a simple grep shows: shell32_Bg.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Cs.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Da.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_De.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP shell32_En.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fi.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Fr.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 70, 12, WS_TABSTOP shell32_Hu.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_It.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ja.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Nl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_No.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pl.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Pt.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ro.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Ru.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Sv.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP shell32_Uk.rc: DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP The size of these OK buttons is probably aligned with the other button in that window. -- Cheers, Paul.

May 12, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Reece Dunn

2009/5/12 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Hi, > > Changed the sizes of the buttons and window to be the same as in > English. This make sure the 'Wine license' button can be fully read in > Dutch. > > - DEFPUSHBUTTON "OK", IDOK, 153, 133, 50, 12, WS_TABSTOP > + DEFPUSHBUTTON "OK", IDOK, 153, 133, 60, 12, WS_TABSTOP According to Windows guidelines, command buttons (http://msdn.microsoft.com/en-us/library/aa511453.aspx) should be 50 x 14 DLUs (they can be wider than 50 DLUs, but only if the text is bigger than that, which it shouldn't for OK buttons) and have a 4 DLU spacing between other controls. This is so they look good in the presence of themes. - Reece

May 12, 2009

wined3d: Fix ATI dx10 cards max varying quirk

by Robert Key

I fiddled around with the test and I was able to use varying vec4 var_in[13] as a max in one array. 14 - 16 resulted in a segmentation fault and 17 resulted in glLinK failure error. I was able to create a second array of varying vec4 testa[3] though and it compiled successfully resulting in 64 varyings. I'll attach what I did.

May 12, 2009

Re: DIB Engine : Almost 100% working

by Ben Klein

2009/5/12 Scott Ritchie <scott(a)open-vote.org>: > Ben Klein wrote: >> >> 2009/5/12 Scott Ritchie <scott(a)open-vote.org>: >>> >>> Henri Verbeet wrote: >>>> >>>> 2009/5/11 Scott Ritchie <scott(a)open-vote.org>: >>>>> >>>>> Henri Verbeet wrote: >>>>>> >>>>>> 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >>>>>>> >>>>>>> As I think that Alexandre has stated his preference (and I can >>>>>>> understand >>>>>>> him taking a long term view), I want to ask the packagers for the >>>>>>> distros >>>>>>> out there: Would it be OK for you to add the necessary patch into the >>>>>>> code that you distribute. Personally, that means Marcus and the >>>>>>> openSUSE >>>>>>> wine packages :-) >>>>>>> >>>>>> While distributions are of course free to do that, keep in mind that >>>>>> that would also make them responsible for supporting that code. I'm >>>>>> not sure how feasible that would be for something so close to core >>>>>> Wine functionality. >>>>>> >>>>>> >>>>> Distributions don't really "support" Wine anyway. At best we just make >>>>> a >>>>> new package every now and again. >>>>> >>>> Yes, but the point is that bugs filed against such a package are >>>> potentially invalid. (People should use git for filing bugs, but not >>>> everyone does.) >>>> >>>> >>> We already expect our users to indicate if they've done any manual >>> registry >>> changes when reporting bugs. This seems like just another instance of >>> that. >> >> But they usually don't. >> >> As the Debian package maintainer, I won't bundle the DIB engine until >> it makes it into Wine release sources. I have the same policy for any >> other patch (including my own simple, >> definitely-won't-hurt-anything-but-will-make-things-better patches) to >> assist in keeping bugzilla *and AppDB* "clean". Do we really want the >> users to submit AppDB posts that depend on who packaged the binaries? > > This might not be that bad, since the individual test report indicates their > distribution. Won't work so well for Debian where there are separate, Debian-supported packages (with recent versions if you grab them from experimental). > From my own observations of AppDB reports, when users do > things like winetricks or marking DLLs as native they tend to include that > in the report (or at least say something like "I used the winetricks > workarounds from the howto below") If we're lucky, yes :P However, some users may get confused if there's an option in the registry that works for some but not others. To eliminate confusion, we will need consensus from all packagers, and possibly some distributions that have packages separate from what's on the download page on WineHQ. At least, to *minimise* confusion, the packagers on WineHQ will need consensus. However, I suspect that AJ will object to the DIB engine going in to all packages provided by WineHQ, as this implies official support for a patchset that has been rejected upstream.

May 11, 2009

Re: DIB Engine : Almost 100% working

by Scott Ritchie

Ben Klein wrote: > 2009/5/12 Scott Ritchie <scott(a)open-vote.org>: >> Henri Verbeet wrote: >>> 2009/5/11 Scott Ritchie <scott(a)open-vote.org>: >>>> Henri Verbeet wrote: >>>>> 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >>>>>> As I think that Alexandre has stated his preference (and I can >>>>>> understand >>>>>> him taking a long term view), I want to ask the packagers for the >>>>>> distros >>>>>> out there: Would it be OK for you to add the necessary patch into the >>>>>> code that you distribute. Personally, that means Marcus and the >>>>>> openSUSE >>>>>> wine packages :-) >>>>>> >>>>> While distributions are of course free to do that, keep in mind that >>>>> that would also make them responsible for supporting that code. I'm >>>>> not sure how feasible that would be for something so close to core >>>>> Wine functionality. >>>>> >>>>> >>>> Distributions don't really "support" Wine anyway. At best we just make a >>>> new package every now and again. >>>> >>> Yes, but the point is that bugs filed against such a package are >>> potentially invalid. (People should use git for filing bugs, but not >>> everyone does.) >>> >>> >> We already expect our users to indicate if they've done any manual registry >> changes when reporting bugs. This seems like just another instance of that. > > But they usually don't. > > As the Debian package maintainer, I won't bundle the DIB engine until > it makes it into Wine release sources. I have the same policy for any > other patch (including my own simple, > definitely-won't-hurt-anything-but-will-make-things-better patches) to > assist in keeping bugzilla *and AppDB* "clean". Do we really want the > users to submit AppDB posts that depend on who packaged the binaries? This might not be that bad, since the individual test report indicates their distribution. From my own observations of AppDB reports, when users do things like winetricks or marking DLLs as native they tend to include that in the report (or at least say something like "I used the winetricks workarounds from the howto below") Thanks, Scott Ritchie

May 11, 2009

Re: DIB Engine : Almost 100% working

by Ben Klein

2009/5/12 Scott Ritchie <scott(a)open-vote.org>: > Henri Verbeet wrote: >> >> 2009/5/11 Scott Ritchie <scott(a)open-vote.org>: >>> >>> Henri Verbeet wrote: >>>> >>>> 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >>>>> >>>>> As I think that Alexandre has stated his preference (and I can >>>>> understand >>>>> him taking a long term view), I want to ask the packagers for the >>>>> distros >>>>> out there: Would it be OK for you to add the necessary patch into the >>>>> code that you distribute. Personally, that means Marcus and the >>>>> openSUSE >>>>> wine packages :-) >>>>> >>>> While distributions are of course free to do that, keep in mind that >>>> that would also make them responsible for supporting that code. I'm >>>> not sure how feasible that would be for something so close to core >>>> Wine functionality. >>>> >>>> >>> Distributions don't really "support" Wine anyway. At best we just make a >>> new package every now and again. >>> >> Yes, but the point is that bugs filed against such a package are >> potentially invalid. (People should use git for filing bugs, but not >> everyone does.) >> >> > > We already expect our users to indicate if they've done any manual registry > changes when reporting bugs. This seems like just another instance of that. But they usually don't. As the Debian package maintainer, I won't bundle the DIB engine until it makes it into Wine release sources. I have the same policy for any other patch (including my own simple, definitely-won't-hurt-anything-but-will-make-things-better patches) to assist in keeping bugzilla *and AppDB* "clean". Do we really want the users to submit AppDB posts that depend on who packaged the binaries?

May 11, 2009

Re: DIB Engine : Almost 100% working

by Scott Ritchie

Henri Verbeet wrote: > 2009/5/11 Scott Ritchie <scott(a)open-vote.org>: >> Henri Verbeet wrote: >>> 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >>>> As I think that Alexandre has stated his preference (and I can understand >>>> him taking a long term view), I want to ask the packagers for the distros >>>> out there: Would it be OK for you to add the necessary patch into the >>>> code that you distribute. Personally, that means Marcus and the openSUSE >>>> wine packages :-) >>>> >>> While distributions are of course free to do that, keep in mind that >>> that would also make them responsible for supporting that code. I'm >>> not sure how feasible that would be for something so close to core >>> Wine functionality. >>> >>> >> Distributions don't really "support" Wine anyway. At best we just make a >> new package every now and again. >> > Yes, but the point is that bugs filed against such a package are > potentially invalid. (People should use git for filing bugs, but not > everyone does.) > > We already expect our users to indicate if they've done any manual registry changes when reporting bugs. This seems like just another instance of that. Thanks, Scott Ritchie

May 11, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Scott Ritchie ha scritto: > As a packager, as long as Massimo is willing to keep the patches > applying to the latest version and user-optional to enable, I'd be > willing to bundle em. I'm normally averse to keeping deltas with > Alexandre's main branch other than backports, but this one is > specifically written to not do anything unless manually enabled. > Well, the engine should apply to any next git, as long as there are no changes to driver's function tables (unlikely), to gdifont struct (less unlikely, but should not happen soon...) and to dlls/gdi32/driver.c (also unlikely, as it has just code to load drivers). That was one of the 2 reasons of the new approach... to not to have to rebase it manually each week :-) BTW, about the bugs spotted by testsuite, I'm looking at them just now, mostly are just GetPixel() swapped colors, I got rid of more than an half with a single patch and I guess they'll mostly disappear in short time. Ciao Max

May 11, 2009

Re: DIB Engine : Almost 100% working

by Henri Verbeet

2009/5/11 Scott Ritchie <scott(a)open-vote.org>: > Henri Verbeet wrote: >> >> 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >>> >>> As I think that Alexandre has stated his preference (and I can understand >>> him taking a long term view), I want to ask the packagers for the distros >>> out there: Would it be OK for you to add the necessary patch into the >>> code that you distribute. Personally, that means Marcus and the openSUSE >>> wine packages :-) >>> >> While distributions are of course free to do that, keep in mind that >> that would also make them responsible for supporting that code. I'm >> not sure how feasible that would be for something so close to core >> Wine functionality. >> >> > > Distributions don't really "support" Wine anyway. At best we just make a > new package every now and again. > Yes, but the point is that bugs filed against such a package are potentially invalid. (People should use git for filing bugs, but not everyone does.)

May 11, 2009

Re: DIB Engine : Almost 100% working

by Scott Ritchie

Massimo Del Fedele wrote: > Austin English ha scritto: >> >> FWIW, for those interested, I've added the DIB engine to my daily test >> runs. First result is here: >> http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_a… >> >> >> and for comparison, here's a vanilla wine test run: >> http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_a… >> >> (everything passes on my machine, aside from the known spurious test >> results). >> >> Looks like there's some bugs to fix in ddraw:visual, gdi32:bitmap >> (1317!), and gdi32:palette. >> >> So not quite ready yet (architecture designs aside). >> > > Ah, yep.... swapped colors in pixels. I fixed that everywhere but not on > getpixel :-) > I'll fix it later.... and I'll look to other (few) failures. > I've seen some stuffs passed on todo, also..... > 3 cheers for the test suite! This is, right here, a good handful of bugs completely prevented by it. I'm curious how much more common findings like this are getting as Winetest has grown in sophistication. Thanks, Scott Ritchie

May 11, 2009

Re: DIB Engine : Almost 100% working

by Scott Ritchie

Henri Verbeet wrote: > 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >> As I think that Alexandre has stated his preference (and I can understand >> him taking a long term view), I want to ask the packagers for the distros >> out there: Would it be OK for you to add the necessary patch into the >> code that you distribute. Personally, that means Marcus and the openSUSE >> wine packages :-) >> > While distributions are of course free to do that, keep in mind that > that would also make them responsible for supporting that code. I'm > not sure how feasible that would be for something so close to core > Wine functionality. > > Distributions don't really "support" Wine anyway. At best we just make a new package every now and again. As a packager, as long as Massimo is willing to keep the patches applying to the latest version and user-optional to enable, I'd be willing to bundle em. I'm normally averse to keeping deltas with Alexandre's main branch other than backports, but this one is specifically written to not do anything unless manually enabled. Thanks, Scott Ritchie

May 11, 2009

Re: comctl32/listview: WinSCP dogfood fix

by Nikolay Sivov

Stefan Stranz wrote: > Fixes bug #13867 > Original fix by GameZelda A test needed for such changes. Especially for that part: @@ -519,7 +519,7 @@ static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL isW) if (!aw) return bt ? -1 : 0; if (!bt) return aw ? 1 : 0; if (aw == LPSTR_TEXTCALLBACKW) - return bt == LPSTR_TEXTCALLBACKW ? 0 : -1; + return bt == LPSTR_TEXTCALLBACKW ? 1 : -1; if (bt != LPSTR_TEXTCALLBACKW) { LPWSTR bw = textdupTtoW(bt, isW);

May 11, 2009

Re: Impossible to register to Bugzilla

by Alain Aupeix

May 11, 2009

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try5)

by André Hentschel

Nikolay Sivov schrieb: > André Hentschel wrote: >> now PSDK compatible >> --- >> dlls/comctl32/listview.c | 1 - >> dlls/comctl32/tests/listview.c | 8 ++++++++ >> include/commctrl.h | 6 ++++++ >> 3 files changed, 14 insertions(+), 1 deletions(-) > Still wrong: > > +#define ListView_SetCheckState(hwndLV, i, bCheck) \ > + { LVITEMA _LVi; _LVi.state = ((bCheck?2:1) << 12); _LVi.stateMask > = LVIS_STATEIMAGEMASK;\ > + SNDMSG(hwndLV, LVM_SETITEMSTATE, (WPARAM)(UINT)(i), > (LPARAM)(LPLVITEMA)&_LVi);} > > 'A' structure for both SNDMSG[A,W]. Try with neutral LVITEM. my orientation was ListView_SetItemState with: #define ListView_SetItemState(hwnd,i,data,dataMask) \ { LVITEMA _LVi; _LVi.state = data; _LVi.stateMask = dataMask;\ SNDMSG(hwnd, LVM_SETITEMSTATE, (WPARAM)(UINT)i, (LPARAM) (LPLVITEMA)&_LVi);} > > +#define ListView_GetCheckState(hwndLV, i) \ > + ((((BOOL)(SNDMSGW((hwndLV), LVM_GETITEMSTATE, (i), \ > + LVIS_STATEIMAGEMASK))) >> 12) -1) > > Always W version used. Why? > forgotten, sry. i hope i made everything right in try6

May 11, 2009

Re: DIB Engine : Almost 100% working

by Reece Dunn

Jeremy White wrote: > Reece Dunn wrote: >> Also, doesn't CodeWeavers have the ability to pledge for features >> (such as DirectX) as well as specific applications? > > Well, kinda sorta, but not really. It's on our todo list and has > been for a long time. > > I think Roderick summarized the issue from our perspective correctly. > Everyone wishes it will be a magic bullet, so we all get excited about it. >From Massimo's report, his DIB engine looks like it fixes a few issues on some games - like Age of Empires 2 - and has some speedups there. Not sure how much of a benefit this is going to be overall. > But in practice, it helps very few applications. Improving gdiplus > (an easier task), we have found to have far more dramatic benefits. I understand this approach. The DIB engine is not a trivial, or isolated piece of functionality, to develop. There are some things I'd be interested in seeing: 1. how this affects double-buffering performance (which a lot of applications make use of, as well as the common controls), which uses DIBs to draw the data off-screen; 2. how this affects theme performance (the repainting of winecfg with the Gem theme is glacially slow); 3. whether this will support alpha blending (useful for themes that support it - such as is likely to be used to provide better integration look and feel - as well as the Wine icon refresh that was being looked at). I wonder if there are any media players or video editing applications that would benefit? Anyway, I'll hopefully get around to do some testing on the DIB engine at some point to test these out. - Reece

May 11, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Austin English ha scritto: > On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele <max(a)veneto.com> wrote: >> Massimo Del Fedele ha scritto: >>> Well, after some (many) bugfixes and additions, the mighty DIB Engine is >>> almost 100% >>> operational. >>> On one of tested apps (MSN Messenger) it behaves even better than original >>> one :-) >>> >>> For whom wish to test it, bug 421 page. >>> >>> Ciao >>> >>> Max >>> >>> >>> >>> >> fixed also last (hopefully) color format error, now some games, also D3D and >> Opengl >> ones work perfectly. >> >> Ciao >> >> Max >> >> >> >> > > FWIW, for those interested, I've added the DIB engine to my daily test > runs. First result is here: > http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_a… > > and for comparison, here's a vanilla wine test run: > http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_a… > (everything passes on my machine, aside from the known spurious test results). > > Looks like there's some bugs to fix in ddraw:visual, gdi32:bitmap > (1317!), and gdi32:palette. > > So not quite ready yet (architecture designs aside). > Ah, yep.... swapped colors in pixels. I fixed that everywhere but not on getpixel :-) I'll fix it later.... and I'll look to other (few) failures. I've seen some stuffs passed on todo, also..... Max

May 11, 2009

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try5)

by Nikolay Sivov

André Hentschel wrote: > now PSDK compatible > --- > dlls/comctl32/listview.c | 1 - > dlls/comctl32/tests/listview.c | 8 ++++++++ > include/commctrl.h | 6 ++++++ > 3 files changed, 14 insertions(+), 1 deletions(-) Still wrong: +#define ListView_SetCheckState(hwndLV, i, bCheck) \ + { LVITEMA _LVi; _LVi.state = ((bCheck?2:1) << 12); _LVi.stateMask = LVIS_STATEIMAGEMASK;\ + SNDMSG(hwndLV, LVM_SETITEMSTATE, (WPARAM)(UINT)(i), (LPARAM)(LPLVITEMA)&_LVi);} 'A' structure for both SNDMSG[A,W]. Try with neutral LVITEM. +#define ListView_GetCheckState(hwndLV, i) \ + ((((BOOL)(SNDMSGW((hwndLV), LVM_GETITEMSTATE, (i), \ + LVIS_STATEIMAGEMASK))) >> 12) -1) Always W version used. Why?

May 11, 2009

Re: DIB Engine : Almost 100% working

by Austin English

On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > Massimo Del Fedele ha scritto: >> >> Well, after some (many) bugfixes and additions, the mighty DIB Engine is >> almost 100% >> operational. >> On one of tested apps (MSN Messenger) it behaves even better than original >> one :-) >> >> For whom wish to test it, bug 421 page. >> >> Ciao >> >> Max >> >> >> >> > > fixed also last (hopefully) color format error, now some games, also D3D and > Opengl > ones work perfectly. > > Ciao > > Max > > > > FWIW, for those interested, I've added the DIB engine to my daily test runs. First result is here: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_a… and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_a… (everything passes on my machine, aside from the known spurious test results). Looks like there's some bugs to fix in ddraw:visual, gdi32:bitmap (1317!), and gdi32:palette. So not quite ready yet (architecture designs aside). -- -Austin

May 11, 2009

Re: Severity levels

by Francois Gouget

On Mon, 11 May 2009, Kai Blin wrote: [...] > If you feel the need to insult people for whatever reason, don't do it > on the mailing list. Better yet, they should do it to the mirror<g>. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

May 11, 2009

Re: Severity levels

by Austin English

Guys, please take it off list. -- -Austin

May 11, 2009

Re: Impossible to register to Bugzilla

by Ben Klein

2009/5/11 Alain Aupeix <alain.aupeix(a)wanadoo.fr>: > All is explained in this thread : > "http://forum.winehq.org/viewtopic.php?p=24400#24400" Worked for me just now.

May 11, 2009

RE: Severity levels

by Nicklas Börjesson

>> From almost the first response, the tone was quite condescending > No. Here we go. I'll try again. Yes. >If professionalism means never giving up, even when it has been >*explained* to you why your idea won't work in practice, then you >succeeded. In the end someone did explain, yes. But it took about 10 posts until anyone started to actually read what I had written and stop reading in other things into what it said. Like constantly stating that "photoshop isn't the all only application" and the like, when that had nothing to do with what my point was. I don't give up. Especially when I have time to spare. Which I did. > perhaps your idea isn't as brilliant as you think? I did not think of my idea as brilliant. In fact, I have never even remotely tried to convey that. I just thougt of it as an idea. This is exactly the kind of attitude that leads nowhere. Why even write that sentence? Did we get anywhere? > You have to treat valid critical response with the same respect as > valid positive response. I did, even if it didn't adress what I said. Although I did comment when someone persisted with strawman arguments like "should we let users in control of the project" even though I had never said anything like that. > Ever managed a project as big as Wine? In terms of number of > developers, or sheer lines of code? Have you? Regarding sheer lines of code, the main application (a portfolio/fund management system) I am working have roughly the same amount of code that wine does. Or at least around 90%. The database currently has 327 tables and customer databases range from 1-100 gigabyte in size. With regards to complexity, wine has nothing on it, at least as far as I have seen so far. So I'd say I know a thing or two about large projects. You seem to think that the wine project is some kind of huge beheamoth of a project. In fact, most fairly common business applications are just as large(especially in later years when so much code is auto-generated). One or two million LOCs is not huge. Big, but not huge. Especially, I know that when a project grows, softer values tend to become more important. And that users, handled correctly, can be more of a resource, than a liability. //Nicklas

May 11, 2009

Re: DIB Engine : Almost 100% working

by Marcus Meissner

On Mon, May 11, 2009 at 12:56:28PM +0200, Joerg Mayer wrote: > Hello (mostly wine package maintainers), > > On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: > > James McKenzie ha scritto: > >> Good work. Have you started to think about how to get this into Wine > >> where AJ will approve? > > > > Ah, I'm not very optimistic that it'll ever enter on wine tree :-) > > Nor have I time to adopt the "trial and error" way up to it's > > approved. > > The easiest way I see by now is to add it to wine drivers as an > > "alternative" driver in parallel to X11 one. > > That could be done in less then 5 minutes and with no regressions :-) > > So from the end users point of view Alexandre is refusing this solution which > is much better than what exists now into the official wine tree. > To "solve" this problem from an end users view, I see two approaches: > 1) Alexandre is willing to allow that code into the wine repository, so > it can be maintained in sync with the existing wine code (it is my > understanding that the modifications to existing code are quite small) > and leave it to the user to choose which code to use. > 2) We use the same solution that is used by the linux kernel developers: > Keep the official source clean but add any (dearly wanted/needed) > features as part of the distribution kernel. The distribution these days only accept stuff that has chances to be upstream. Keeping it in a parallel repo forever will not fly. Ciao, Marcus

May 11, 2009

Re: C_ASSERT portability fixes and simplification [PATCH 1/2]

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > The current implementation doesn't work with GCC 4.5 (or ISO C) > and I failed to find any other way. :-( > > Your point on this being autogenerated clearly is strong one -- > either we need to change that generation or find a different way > to implement C_ASSERT. > > Any idea how to best approach this? I don't have gcc 4.5 to test this, but you could try using a function instead, something like this: diff --git a/include/winnt.h b/include/winnt.h index abcc502..aaa4112 100644 --- a/include/winnt.h +++ b/include/winnt.h @@ -292,7 +292,7 @@ extern "C" { #if defined(_MSC_VER) # define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1] #elif defined(__GNUC__) -# define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] __attribute__((unused)) +# define C_ASSERT(e) extern void __C_ASSERT__(int [(e)?1:-1]) #else # define C_ASSERT(e) #endif -- Alexandre Julliard julliard(a)winehq.org

May 11, 2009

Re: Severity levels

by Ben Klein

2009/5/11 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > From almost the first response, the tone was quite condescending No. > and no one even considered if my ideas had any actual merit at > all before slamming them completely. Yes they did. You ignored their just criticism. > Also, because of this, the > conversation was needlessly prolonged, to the obvious annoyance > of all. And the fact that you refuse to acknowledge critical responses. > This also applied to perfectly valid comments i > made in the AppDB. For example ...? > I haven't experienced such behaviour > in an open source project for years. And I have, believe it > or not, both participated in and, yes, managed a few. Ever managed a project as big as Wine? In terms of number of developers, or sheer lines of code? > I would say that no matter how annoying I may have been to this > thread, this is extremely counterproductive. > In communities like this, where most people are involved for > other reasons than money, it is even more important to treat > others with respect. Agreed. However, you have shown little respect for the people on this thread who have been critical of your suggestions. You believe you are right - there's nothing wrong with that - but your suggestion is violently different from what is currently being done - which is a system set up by the Wine developers for the Wine developers, and is attuned to what the Wine developers want and need. > I pride myself with always trying to keep a professional > attitude in my communications. If professionalism means never giving up, even when it has been *explained* to you why your idea won't work in practice, then you succeeded. > Not only with customers or management, but also my peers. > I would like some of the participants of this thread to consider > the damage they do to the wine project when they don't. > Creating technology isn't all about technology. One thread on the mailing list doesn't make the whole project (though I do see your point). However, it cuts both ways. You complain that no one has paid attention to your fantastically brilliant idea (when they have, they just don't like it); perhaps your idea isn't as brilliant as you think? You have to treat valid critical response with the same respect as valid positive response.

May 11, 2009

Re: Winelib - Getting Started guide

by Josef Šimánek

I did this (http://www.winehq.org/docs/winelib-guide/winelib-getting-started) : $ winemaker --lower-uppercase . $ make It throws some error in wrc. So according to GSG I did exactly this: To fix that problem, you will need to edit the list of resource files winemaker thought notepad used, and only keep the master resource file. To do so, open notepad2/Makefile in a text editor and search for an assignment to a variable with RC_SRCS as part of its name. It will likely be named notepad2_exe_RC_SRCS. There will be a list of resource files starting on the same line. Remove them all except rsrc.rc (this is the master one for notepad). Save your work. 2009/5/11 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "Josef Simánek" <retricek(a)gmail.com> wrote: > >> I edit Makefile and type make into console. > > What exactly did you do? notepad is not supposed to work as a console > application for your information. > >> My problem above. In the >> guide is written to report bad compiling behaviour. So I did it. Any >> hints ? >> >> mirindoslav(a)mirindoslav-laptop:~/Plocha/notepad$ make >> winegcc -c -mno-cygwin -I. -o dialog.o dialog.c >> winegcc -c -mno-cygwin -I. -o main.o main.c >> wrc -I. -forsrc.res rsrc.rc >> winegcc -mwindows -mno-cygwin -m32 -o notepad.exe.so dialog.o main.o >> rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid >> dialog.o: In function `DIALOG_StringMsgBox': >> dialog.c:(.text+0x235): undefined reference to `wnsprintfW' >> main.o: In function `HandleCommandLine': >> main.c:(.text+0x25a5): undefined reference to `PathFindFileNameW' > > Looks like you have removed required import libraries, don't do that > if you don't know the consequences. > > -- > Dmitry. >

May 11, 2009

Re: DIB Engine : Almost 100% working

by Austin English

On Mon, May 11, 2009 at 6:39 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > Austin English ha scritto: > >> Perhaps a wine-experimental branch, with applicable warnings? >> >> Getting a bunch of people to test it may give us good data on how much >> it improves things, which is currently lacking. >> > > That one should be maintained too.... not a difficult task but > a time consuming one. > Still I think that the better way should be to include as an > "optional" component in main tree..... I meant for distributions. E.g., there is already, for many: wine-stable wine-devel could add: wine-experimental I'm not suggesting an additional branch for winehq.org. AJ is busy enough as is ;-). Besides, there's already http://repo.or.cz/w/wine/hacks.git for that. -- -Austin

May 11, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Austin English ha scritto: > Perhaps a wine-experimental branch, with applicable warnings? > > Getting a bunch of people to test it may give us good data on how much > it improves things, which is currently lacking. > That one should be maintained too.... not a difficult task but a time consuming one. Still I think that the better way should be to include as an "optional" component in main tree..... Max

May 11, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Henri Verbeet ha scritto: > 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >> As I think that Alexandre has stated his preference (and I can understand >> him taking a long term view), I want to ask the packagers for the distros >> out there: Would it be OK for you to add the necessary patch into the >> code that you distribute. Personally, that means Marcus and the openSUSE >> wine packages :-) >> > While distributions are of course free to do that, keep in mind that > that would also make them responsible for supporting that code. I'm > not sure how feasible that would be for something so close to core > Wine functionality. > > As I told before, the engine almost doesn't touch wine core. It just add an intermediate layer between gdi32 and winex11.drv to handle DIBs. If not enabled, it can't simply harm anything, gdi32 will take the usual way through winex11. And, last but not least, the drivers *needs* to be explicitely enabled by end user.... if not, it's like it wouldn't exist. There's nothing to maintain in wine related do the engine, nor the way around. The engine as it is should be applicable to any future wine version, as lon as it doesn't change hardly the driver's function tables or driver loading in dlls/gdi32/driver.c, which is *very* unlikely to happen. Max

May 11, 2009

RE: Severity levels

by Nicklas Börjesson

> +1, exactly why I muted the conversation. Not implying that I would have "won" the conversation or anything (I obviously didn't), but I did not like the way my arguments were met at all. >From almost the first response, the tone was quite condescending and no one even considered if my ideas had any actual merit at all before slamming them completely. Also, because of this, the conversation was needlessly prolonged, to the obvious annoyance of all. This also applied to perfectly valid comments i made in the AppDB. I haven't experienced such behaviour in an open source project for years. And I have, believe it or not, both participated in and, yes, managed a few. I would say that no matter how annoying I may have been to this thread, this is extremely counterproductive. In communities like this, where most people are involved for other reasons than money, it is even more important to treat others with respect. I pride myself with always trying to keep a professional attitude in my communications. Not only with customers or management, but also my peers. I would like some of the participants of this thread to consider the damage they do to the wine project when they don't. Creating technology isn't all about technology. //Nicklas PS. WOW! Reposting since a fantastic bug in outlook(loves it) totally screwed up the subject in my earlier post. DS.

May 11, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Joerg Mayer ha scritto: > > So from the end users point of view Alexandre is refusing this solution which > is much better than what exists now into the official wine tree. Ah, wait.... it's not "much better", is an alternative. As it is now, it gives speed improvement for some apps, and probably slowdowns for others. The slow downs are because of mixed bitmap blitting, which could be indeed solved. So, if your app does *many* dib drawing and few mixed blits, the speed can improve by high factors; the other way around it can decrease. It has also probably still bugs and for sure some primitives (rarely used) that are still not coded, as circle/ellipse/roundrect, for example. Those are trivial to add, but I still didn't need them.... > To "solve" this problem from an end users view, I see two approaches: > 1) Alexandre is willing to allow that code into the wine repository, so > it can be maintained in sync with the existing wine code (it is my > understanding that the modifications to existing code are quite small) > and leave it to the user to choose which code to use. I'd agree with that one..... adding an optional driver could do no harm, and would be enabled just on user request. The needed core code modifications are really really small, just few lines on a c file that (afaik) is not being modified since long time. It could even be done *without* any modification, but that would be much less comfortable for end-users, as they should fiddle with registry entries. > 2) We use the same solution that is used by the linux kernel developers: > Keep the official source clean but add any (dearly wanted/needed) > features as part of the distribution kernel. That would mean maintain another repo in sync with the main one, not too hard job but I couldn't do it myself.... really no time. > > As I think that Alexandre has stated his preference (and I can understand > him taking a long term view), I want to ask the packagers for the distros > out there: Would it be OK for you to add the necessary patch into the > code that you distribute. Personally, that means Marcus and the openSUSE > wine packages :-) That one could be a nice solution, but I see it quite unlikely to happen. Usually packagers prefer the "official stuffs". ciao Max

May 11, 2009

Re: DIB Engine : Almost 100% working

by Austin English

On Mon, May 11, 2009 at 6:20 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: >> As I think that Alexandre has stated his preference (and I can understand >> him taking a long term view), I want to ask the packagers for the distros >> out there: Would it be OK for you to add the necessary patch into the >> code that you distribute. Personally, that means Marcus and the openSUSE >> wine packages :-) >> > While distributions are of course free to do that, keep in mind that > that would also make them responsible for supporting that code. I'm > not sure how feasible that would be for something so close to core > Wine functionality. Perhaps a wine-experimental branch, with applicable warnings? Getting a bunch of people to test it may give us good data on how much it improves things, which is currently lacking. -- -Austin

May 11, 2009

Bega

by Nicklas Börjesson

> +1, exactly why I muted the conversation. Not implying that I would have "won" the conversation or anything (I obviously didn't), but I did not like the way my arguments were met at all. >From almost the first response, the tone was quite condescending and no one even considered if my ideas had any actual merit at all before slamming them completely. Also, because of this, the conversation was needlessly prolonged, to the obvious annoyance of all. This also applied to perfectly valid comments i made in the AppDB. I haven't experienced such behaviour in an open source project for years. And I have, believe it or not, both participated in and, yes, managed a few. I would say that no matter how annoying I may have been to this thread, this is extremely counterproductive. In communities like this, where most people are involved for other reasons than money, it is even more important to treat others with respect. I pride myself with always trying to keep a professional attitude in my communications. Not only with customers or management, but also my peers. I would like some of the participants of this thread to consider the damage they do to the wine project when they don't. Creating technology isn't all about technology. //Nicklas

May 11, 2009

Re: DIB Engine : Almost 100% working

by Henri Verbeet

2009/5/11 Joerg Mayer <jmayer(a)loplof.de>: > As I think that Alexandre has stated his preference (and I can understand > him taking a long term view), I want to ask the packagers for the distros > out there: Would it be OK for you to add the necessary patch into the > code that you distribute. Personally, that means Marcus and the openSUSE > wine packages :-) > While distributions are of course free to do that, keep in mind that that would also make them responsible for supporting that code. I'm not sure how feasible that would be for something so close to core Wine functionality.

May 11, 2009

Unused functions in fusion.dll

by Francois Gouget

CompareAssemblyIdentity() and GetAssemblyIdentityFromFile() have stubs in fusion.c, but they are not used and not exported in any way. Is there any point in keeping them in their current state? Where/how should they be exported? A look at the fusion.dll export table on my Windows XP turned up nothing... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

May 11, 2009

Re: C_ASSERT portability fixes and simplification [PATCH 1/2]

by Gerald Pfeifer

On Mon, 11 May 2009, Alexandre Julliard wrote: >> 2. More importantly, these were the only occurences of C_ASSERT at >> file level. By moving these at function level use thereof becomes >> consistent which will allow the fix from PATCH 2/2 to work at all. > C_ASSERT is supposed to work at the file level too. The current implementation doesn't work with GCC 4.5 (or ISO C) and I failed to find any other way. :-( Your point on this being autogenerated clearly is strong one -- either we need to change that generation or find a different way to implement C_ASSERT. Any idea how to best approach this? Gerald

May 11, 2009

Re: DIB Engine : Almost 100% working

by Austin English

On Mon, May 11, 2009 at 6:07 AM, Chris Howe <mrmessiah(a)gmail.com> wrote: > 2009/5/11 Joerg Mayer <jmayer(a)loplof.de> >> >> Hello (mostly wine package maintainers), >> On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: >> > James McKenzie ha scritto: >> >> Good work. Have you started to think about how to get this into Wine >> >> where AJ will approve? >> > >> > Ah, I'm not very optimistic that it'll ever enter on wine tree :-) >> > Nor have I time to adopt the "trial and error" way up to it's >> > approved. >> >> So from the end users point of view Alexandre is refusing this solution >> which >> is much better than what exists now into the official wine tree. > > Going to make that request for official (Alexandre-approved) documentation > of "the right way" to go up somewhere, one more time. Its ludicrous that > there's > a solution this good that's wrong, and there's no roadmap for making a > better > one. It would still take a lot of time to write that documentation. Time is money, and AJ/Huw are both busy people. Unless someone sponsors it, it's on the back burner, since it's not for sure that it would even help popular applications. Not the answer most people want, but the truth isn't always comfortable. -- -Austin

May 11, 2009

Re: DIB Engine : Almost 100% working

by Chris Howe

2009/5/11 Joerg Mayer <jmayer(a)loplof.de> > Hello (mostly wine package maintainers), > On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: > > James McKenzie ha scritto: > >> Good work. Have you started to think about how to get this into Wine > >> where AJ will approve? > > > > Ah, I'm not very optimistic that it'll ever enter on wine tree :-) > > Nor have I time to adopt the "trial and error" way up to it's > > approved. > > So from the end users point of view Alexandre is refusing this solution > which > is much better than what exists now into the official wine tree. > Going to make that request for official (Alexandre-approved) documentation of "the right way" to go up somewhere, one more time. Its ludicrous that there's a solution this good that's wrong, and there's no roadmap for making a better one. -- Chris

May 11, 2009

Re: DIB Engine : Almost 100% working

by Joerg Mayer

Hello (mostly wine package maintainers), On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: > James McKenzie ha scritto: >> Good work. Have you started to think about how to get this into Wine >> where AJ will approve? > > Ah, I'm not very optimistic that it'll ever enter on wine tree :-) > Nor have I time to adopt the "trial and error" way up to it's > approved. > The easiest way I see by now is to add it to wine drivers as an > "alternative" driver in parallel to X11 one. > That could be done in less then 5 minutes and with no regressions :-) So from the end users point of view Alexandre is refusing this solution which is much better than what exists now into the official wine tree. To "solve" this problem from an end users view, I see two approaches: 1) Alexandre is willing to allow that code into the wine repository, so it can be maintained in sync with the existing wine code (it is my understanding that the modifications to existing code are quite small) and leave it to the user to choose which code to use. 2) We use the same solution that is used by the linux kernel developers: Keep the official source clean but add any (dearly wanted/needed) features as part of the distribution kernel. As I think that Alexandre has stated his preference (and I can understand him taking a long term view), I want to ask the packagers for the distros out there: Would it be OK for you to add the necessary patch into the code that you distribute. Personally, that means Marcus and the openSUSE wine packages :-) ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

May 11, 2009

Re: Severity levels

by Austin English

On Mon, May 11, 2009 at 5:17 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2009/5/11 Kai Blin <kai.blin(a)gmail.com>: >> I seriously dislike the tone this mailing list keeps taking recently. > In case it means anything to anyone, I agree. +1, exactly why I muted the conversation. -- -Austin

May 11, 2009

Re: C_ASSERT portability fixes and simplification [PATCH 1/2]

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > This patch moves these into main() in main.c, which has several > advantages: > > 1. The asserts are only evaluated once, not for every #inclusion > of request.h, which simplifies/speeds up the compilation. It doesn't make any difference, that stuff is inside a #ifdef. Also it's auto-generated, so moving it manually won't help. > 2. More importantly, these were the only occurences of C_ASSERT at > file level. By moving these at function level use thereof becomes > consistent which will allow the fix from PATCH 2/2 to work at all. C_ASSERT is supposed to work at the file level too. -- Alexandre Julliard julliard(a)winehq.org

May 11, 2009

Re: Severity levels

by Henri Verbeet

2009/5/11 Kai Blin <kai.blin(a)gmail.com>: > I seriously dislike the tone this mailing list keeps taking recently. In case it means anything to anyone, I agree.

May 11, 2009

Re: Severity levels

by Kai Blin

On Sunday 10 May 2009 15:59:30 Ken Sharp wrote: Ken, some food for thought here. > Henri Verbeet wrote: > > When you're not subscribed to the list, your posts have to go through > > moderation. Sometimes that can take a while. > > So the idiot isn't even subscribed to this group, but is spamming it > anyway? > > Don't feed the trolls. How exactly is this post not an ad hominem attack, commonly used by trolls to start flame wars? I seriously dislike the tone this mailing list keeps taking recently. This kind of poisonous behaviour is bad for Wine in general. Please try to be civil. An engineer should be able to voice technical criticism without insulting people. If you feel the need to insult people for whatever reason, don't do it on the mailing list. Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

May 11, 2009

Re: wined3d: Fix ATI dx10 cards max varying quirk

by Stefan Dösinger

Am Montag, 11. Mai 2009 02:51:29 schrieb Robert Key: > Changelog: > * This adds a quirk to change the default max varying value from > 68 to 48 on ATI dx10 cards that use fglrx because a declaration > of 17 varying vec4s causes shaders not to render and using > 48 (12 varyings vec4s) works for HD2000 to HD4000 ATI cards. > > Fixes bug #17437 I'm fine with putting the quirk in until fglrx is fixed. The ATI developers confirmed the bug and recommended this workaround for now. (I somewhere heard that their driver shipping latency is > 3 months for some reason) Looking at the code again I saw a few details I don't like though: +static BOOL match_fglrx_r600_to_700(const WineD3D_GL_Info *gl_info) { + if(gl_info->gl_vendor != VENDOR_ATI) return FALSE; + if(strstr(gl_info->gl_renderer, "DRI")) return FALSE; + if(gl_info->max_glsl_varyings == 68) return TRUE; + return FALSE; +} Maybe its better to compare max_glsl_varyings to > 44. 44 is the amount advertised on dx9 cards(and I think we fix this up somewhere already). The main question is if we want this quirk to disable itself as soon as the driver is fixed, or if we want to disable it manually. The other thing that bothers me is the replacement value 48 or 52: According to an ATI dev[1] the correct value is 64, which would match the dx10 limit of 16 varyings. Assuming we subtract 8 for the builtin primary and secondary color we're still at 56, not 52 or even 48. There's probably the fog color or the gl_ClipVertex "varying", but we're not using the clip vertex position currently. I think we should figure out where the 48 comes from. Can you play a bit with the attached program and see how many varyings you can declare, and if the builtin color varyings, fog coord or gl_ClipPos change anything? 1: http://ati.cchtml.com/show_bug.cgi?id=1462

May 11, 2009

Re: Simplify dlls/comctl32/rebar.c (RESEND)

by Dmitry Timoshkov

"Gerald Pfeifer" <gerald(a)pfeifer.com> wrote: > static LRESULT > -REBAR_GetPalette (const REBAR_INFO *infoPtr, WPARAM wParam, LPARAM lParam) > +REBAR_GetPalette () > { (void) is mandatory, please don't omit it. -- Dmitry.

May 11, 2009

Re: regedit: remember settings state

by Dmitry Timoshkov

"André Hentschel" <nerv(a)dawncrow.de> wrote: > LRESULT CALLBACK ChildWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) > { > +HKEY hKey; > +LPWSTR lpKeyPath; > switch (message) { > case WM_CREATE: Indentation is weird. And an empty line after variables won't hurt. -- Dmitry.

May 11, 2009

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState withtests(try4)

by Dmitry Timoshkov

"André Hentschel" <nerv(a)dawncrow.de> wrote: > now with LVITEMW and SNDMSGW You are still casting to LPLVITEMA in ListView_SetCheckState while using LVITEMW and SNDMSGW. As been said by using SNDMSGW/LVITEMW you are making these macros incompatible with PSDK ones, and breaking compatibility if someone will try to compile a non-unicode application with Wine headers. -- Dmitry.

May 11, 2009

Re: Winelib - Getting Started guide

by Dmitry Timoshkov

"Josef Simánek" <retricek(a)gmail.com> wrote: > I edit Makefile and type make into console. What exactly did you do? notepad is not supposed to work as a console application for your information. > My problem above. In the > guide is written to report bad compiling behaviour. So I did it. Any > hints ? > > mirindoslav(a)mirindoslav-laptop:~/Plocha/notepad$ make > winegcc -c -mno-cygwin -I. -o dialog.o dialog.c > winegcc -c -mno-cygwin -I. -o main.o main.c > wrc -I. -forsrc.res rsrc.rc > winegcc -mwindows -mno-cygwin -m32 -o notepad.exe.so dialog.o main.o > rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid > dialog.o: In function `DIALOG_StringMsgBox': > dialog.c:(.text+0x235): undefined reference to `wnsprintfW' > main.o: In function `HandleCommandLine': > main.c:(.text+0x25a5): undefined reference to `PathFindFileNameW' Looks like you have removed required import libraries, don't do that if you don't know the consequences. -- Dmitry.

May 11, 2009

RFC: Removing the --use-cached-creds parameter from ntlm_auth

by Kai Blin

Hi Rob, I've done some digging about using cached credentials from winbindd, and this currently breaks with how we use this from Wine. Specifically, it's not possible to get the session key from winbindd. This breaks our later attempts to do signing/sealing. It might be possible to change winbindd to include this information, but in order to not leak user password information, winbindd can only do so for NTLMv2 and NTLM2. In any case, --use-cached-creds will make things break in new and interesting ways for users who actually are running winbindd. I propose to stop setting that parameter until we figure out how to make this work. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

May 11, 2009

Re: wined3d: Fix ATI dx10 cards max varying quirk

by Henri Verbeet

2009/5/11 Robert Key <hpestilence(a)gmail.com>: > Changelog: > * This adds a quirk to change the default max varying value from > 68 to 48 on ATI dx10 cards that use fglrx because a declaration > of 17 varying vec4s causes shaders not to render and using > 48 (12 varyings vec4s) works for HD2000 to HD4000 ATI cards. > R600 and r700 are supposed to be actively supported. But you know, I don't actually care anymore.

May 11, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

>Feel free, if you'd like. I did, that's why I knew how quick it was. >But the test suite I'm designing for my project is designed for anyone >to be able to use/run, non-interactively. Requiring sign-ups/logins is >not acceptable for it. Ok.

May 11, 2009

Re: Shuttleworth on Wine

by Austin English

2009/5/11 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >>Is possible, but since it requires a login, the script will eventually >>fail from too many login/downloads. > > No, i mean that one would have to register an account for oneself and manually download the files to a predetermined location. > Using the same account for everyone would likely be some kind of breach of their rules anyway. > I'd say, given instructions, that would take 5-10 minutes for most people. > Don't you think people would consider that acceptable to make a quite important test run(i would)? Feel free, if you'd like. But the test suite I'm designing for my project is designed for anyone to be able to use/run, non-interactively. Requiring sign-ups/logins is not acceptable for it. -- -Austin

May 11, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

>Is possible, but since it requires a login, the script will eventually >fail from too many login/downloads. No, i mean that one would have to register an account for oneself and manually download the files to a predetermined location. Using the same account for everyone would likely be some kind of breach of their rules anyway. I'd say, given instructions, that would take 5-10 minutes for most people. Don't you think people would consider that acceptable to make a quite important test run(i would)? //Nicklas

May 11, 2009

RE: Severity levels

by Nicklas Börjesson

>So the idiot isn't even subscribed to this group, but is spamming it anyway? >Don't feed the trolls. Hi there. I would have a hard time replying to your posts if I weren't, wouldn't you think? //Nicklas

May 11, 2009

Winelib - Getting Started guide

by Josef Šimánek

Hi ! I was reading Winelib GSG and I tried to compile notepad from Wine sources. So I downloaded Wine sources (version 1.1.21) and I installed wine from Wine Ubuntu repository (version 1.1.21). I edit Makefile and type make into console. My problem above. In the guide is written to report bad compiling behaviour. So I did it. Any hints ? mirindoslav(a)mirindoslav-laptop:~/Plocha/notepad$ make winegcc -c -mno-cygwin -I. -o dialog.o dialog.c winegcc -c -mno-cygwin -I. -o main.o main.c wrc -I. -forsrc.res rsrc.rc winegcc -mwindows -mno-cygwin -m32 -o notepad.exe.so dialog.o main.o rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid dialog.o: In function `DIALOG_StringMsgBox': dialog.c:(.text+0x235): undefined reference to `wnsprintfW' main.o: In function `HandleCommandLine': main.c:(.text+0x25a5): undefined reference to `PathFindFileNameW' collect2: ld returned 1 exit status winegcc: i486-linux-gnu-gcc failed make: *** [notepad.exe.so] Error 2

May 10, 2009

Re: Shuttleworth on Wine

by Austin English

On Sun, May 10, 2009 at 9:04 AM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > > > Austin English wrote: > >> It's the registering/download manager that makes it not useful. It's >> much harder to script all of that. >> > > Is CS2 too old? > http://download.adobe.com/pub/adobe/photoshop/win/cs2/Photoshop_CS2.exe No, actually. CS2 is perfect, since it should install relatively well. That way, we can make sure it doesn't break :-). I'll add it to my list. I'm currently working on designing the test framework, so it'll be a bit before any real testing work gets done. -- -Austin

May 10, 2009

Re: Shuttleworth on Wine

by Austin English

2009/5/10 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >> The idea is to make the test as automated as possible. That way anyone >> can run the tests, not just people with certain programs. > > Ok. Well then, either: > 1. someone can mirror those two files somewhere for easier downloading, > 2. or one adds one or two(quite easy) manual step to the installation instructions. > > 1. makes scripting possible, however, Adobe probably would not like that. > However, one *could* simply ask them if it's ok. > I don't see how this quite specific use case would(come on, it's a trial version) > be a problem for them and I would think that getting their application working > under wine would be something they would like happening. It violates their copyright, and I have no interest in doing that. > 2. I think that one should try to be a bit pragmatical. If a couple of simple > manual steps is all that is needed to get an otherwise completely automated process > going, it should not be allowed to be a problem. Is possible, but since it requires a login, the script will eventually fail from too many login/downloads. -- -Austin

May 10, 2009

Impossible to register to Bugzilla

by Alain Aupeix

May 10, 2009

Re: New icons for 1.1.21

by Scott Ritchie

Frank Richter wrote: > On 09.05.2009 04:41, Scott Ritchie wrote: >> Anyway, please feel free to give way too much feedback :) > > The outline of the upper glass part seems to be a shade of gray, but the > outline of the shaft at the bottom is black, looking kind of > "unbalanced". Changing the black to #919191ff looks IMO better. > > -f.r. > > Hmm, I'll take a closer look there. Thanks! Thanks, Scott Ritchie

May 10, 2009

Re: New icons for 1.1.21

by Scott Ritchie

IneedAname wrote: > On Fri, 08 May 2009 19:41:31 -0700 > Scott Ritchie <scott(a)open-vote.org> wrote: > >> Anyway, please feel free to give way too much feedback :) > > I like then but not the one with the folder on. The gray colour just does not work for me. > > I agree. The folder icon should match the system theme - ultimately my goal is to move "Browse C:\ Drive" (which this icon is used for) to a place in the Gnome Places Menu. That means the icon (or its KDE equivalent) will need to match the system theme - in my case that would mean a yellow folder with a Wine emblem. Thanks, Scott Ritchie

May 10, 2009

Re: dlls/ddraw/executebuffer.c: silence compiler warnings

by Stefan Dösinger

> executebuffer.c:230: warning: comparison between 'D3DRENDERSTATETYPE' and > 'enum _D3DTRANSFORMSTATETYPE' executebuffer.c:232: warning: comparison > between 'D3DRENDERSTATETYPE' and 'enum _D3DTRANSFORMSTATETYPE' > executebuffer.c:234: warning: comparison between 'D3DRENDERSTATETYPE' and > 'enum _D3DTRANSFORMSTATETYPE' Does the attached patch fix the warning?

May 10, 2009

Re: New icons for 1.1.21

by Frank Richter

On 09.05.2009 04:41, Scott Ritchie wrote: > Anyway, please feel free to give way too much feedback :) The outline of the upper glass part seems to be a shade of gray, but the outline of the shaft at the bottom is black, looking kind of "unbalanced". Changing the black to #919191ff looks IMO better. -f.r.

May 10, 2009

Re: DIB Engine : Almost 100% working

by Roderick Colenbrander

> Office won't benefit at all, I'm afraid. Photoshop, maybe. > If sponsorship will be based on those apps, I guess we'll wait > forever :-) > > Max > > Photoshop is quite important for Wine (remember for 1.0 getting photoshop working was one of our main goals). There is still no serious Photoshop replacement for most companies which use Linux. Note that there are also others for obtaining the sponsoring and there is one about which I have been taking a lot but clear goals would need to be formulated for it and that would be a Wine fund raiser. We would raise money to get sponsorship for areas like this which else stay unfixed for years but money can also be used for Wineconf, buying hardware for patchwatcher, buying software for use on test machines, ..... Roderick

May 10, 2009

Re: DIB Engine : Almost 100% working

by Roderick Colenbrander

On Sun, May 10, 2009 at 8:03 PM, Massimo Del Fedele <max(a)veneto.com> wrote: > Roderick Colenbrander ha scritto: > >> >> Unfortunately getting this code into Wine is not really possible >> (Alexandre would like to see Huw finishing the design and all the work >> but no time has been assigned to him for this) BUT I think work on >> this DIB engine even if it won't make it in Wine isn't wasted. This >> DIB engine even if not correct shows us what apps can benefit and by >> how much from the dib engine (before we only had guesses). If running >> photoshop on Wine is significantly faster using the DIB engine (it >> might be useful to do tests for that, there are ways to benchmark >> photoshop) Codeweavers might work on it. >> >> Roderick >> > > I'm (and not just me, afaik....) still very, very but really very curious to > know *which* > would be the "correct" design.... > BTW, I made my design because I needed it, and I'm happy if it'll be useful > for some > other people, quite probable stuff having seen the amount of words wasted > about the > subject from year 2002. > Anyways, if instead of having it as an "alternative" solution inside wine > tree > (which would make stuffs easier for people needing it, for example cad > users) we want > to let it hanging on bug 421's page hoping to have the "right" solution in a > bit less > than another 7 years, ok :-) > > Max > Interpreting Alexandre his words Huw his design was the right way to continue (according to Jeremy he had worked on this for 4-5 months) but even for Huw it would take a similar amount of time to finish it. They didn't know well if continuing with the work was worth it for the apps they had to get working and during a discussion at Wineconf they also weren't certain for which apps it would help and more important by how much (e.g. time is also fixing a lot issues as we are getting faster CPUs all the time). With your patches (even if they aren't clean and won't 100% correctly) we see how much a DIB engine (even unoptimized) can already help. Basically a lot of users should test it using different programs. We need benchmark results e.g. photoshop benchmarks and others. If the DIB engine appears to do wonders for lots of apps (e.g. photoshop, office ...) then some company might sponsor Codeweavers to work on this. Roderick

May 10, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Roderick Colenbrander ha scritto: > > Unfortunately getting this code into Wine is not really possible > (Alexandre would like to see Huw finishing the design and all the work > but no time has been assigned to him for this) BUT I think work on > this DIB engine even if it won't make it in Wine isn't wasted. This > DIB engine even if not correct shows us what apps can benefit and by > how much from the dib engine (before we only had guesses). If running > photoshop on Wine is significantly faster using the DIB engine (it > might be useful to do tests for that, there are ways to benchmark > photoshop) Codeweavers might work on it. > > Roderick > I'm (and not just me, afaik....) still very, very but really very curious to know *which* would be the "correct" design.... BTW, I made my design because I needed it, and I'm happy if it'll be useful for some other people, quite probable stuff having seen the amount of words wasted about the subject from year 2002. Anyways, if instead of having it as an "alternative" solution inside wine tree (which would make stuffs easier for people needing it, for example cad users) we want to let it hanging on bug 421's page hoping to have the "right" solution in a bit less than another 7 years, ok :-) Max

May 10, 2009

Re: DIB Engine : Almost 100% working

by Roderick Colenbrander

On Sun, May 10, 2009 at 5:07 PM, Massimo Del Fedele <max(a)veneto.com> wrote: > James McKenzie ha scritto: > >> >> Good work. Have you started to think about how to get this into Wine >> where AJ will approve? >> >> James McKenzie >> > > Ah, I'm not very optimistic that it'll ever enter on wine tree :-) > Nor have I time to adopt the "trial and error" way up to it's > approved. > The easiest way I see by now is to add it to wine drivers as an > "alternative" driver in parallel to X11 one. > That could be done in less then 5 minutes and with no regressions :-) > > As I said before, to include it as replacement of actual driver would > mean to make an half rewrite of both gdi32 and winex11. > BTW, my engine has still space for a 3 optimizations that could speed > it up even a lot more : > > 1) Font caching - shouldn't be too difficult > 2) Access DDB directly for blit - not too difficult, and could bring > a speed gain of 100% on mixed DDB/DIB operations > 3) xxxBlt are not very optimized .... I would expect another 50-100% speed > gain on blitting with few codelines more. > > Ciao > > Max > > > > Unfortunately getting this code into Wine is not really possible (Alexandre would like to see Huw finishing the design and all the work but no time has been assigned to him for this) BUT I think work on this DIB engine even if it won't make it in Wine isn't wasted. This DIB engine even if not correct shows us what apps can benefit and by how much from the dib engine (before we only had guesses). If running photoshop on Wine is significantly faster using the DIB engine (it might be useful to do tests for that, there are ways to benchmark photoshop) Codeweavers might work on it. Roderick

May 10, 2009

Re: Shuttleworth on Wine

by nn

Great find added link to AppDB entry http://appdb.winehq.org/objectManager.php?sClass=version&iId=5392 Thanks. Nat --- On Mon, 11/5/09, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > From: Ken Sharp <kennybobs(a)o2.co.uk> > Subject: Re: Shuttleworth on Wine > To: "Austin English" <austinenglish(a)gmail.com> > Cc: wine-devel(a)winehq.org > Received: Monday, 11 May, 2009, 12:04 AM > > > Austin English wrote: > > > It's the registering/download manager that makes it > not useful. It's > > much harder to script all of that. > > > > Is CS2 too old? > http://download.adobe.com/pub/adobe/photoshop/win/cs2/Photoshop_CS2.exe >

May 10, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

James McKenzie ha scritto: > > Good work. Have you started to think about how to get this into Wine > where AJ will approve? > > James McKenzie > Ah, I'm not very optimistic that it'll ever enter on wine tree :-) Nor have I time to adopt the "trial and error" way up to it's approved. The easiest way I see by now is to add it to wine drivers as an "alternative" driver in parallel to X11 one. That could be done in less then 5 minutes and with no regressions :-) As I said before, to include it as replacement of actual driver would mean to make an half rewrite of both gdi32 and winex11. BTW, my engine has still space for a 3 optimizations that could speed it up even a lot more : 1) Font caching - shouldn't be too difficult 2) Access DDB directly for blit - not too difficult, and could bring a speed gain of 100% on mixed DDB/DIB operations 3) xxxBlt are not very optimized .... I would expect another 50-100% speed gain on blitting with few codelines more. Ciao Max

May 10, 2009

Re: DIB Engine : Almost 100% working

by James McKenzie

Massimo Del Fedele wrote: > Warren Dumortier ha scritto: >> 2009/5/10 Massimo Del Fedele <max(a)veneto.com>: >>> Massimo Del Fedele ha scritto: >>>> Well, after some (many) bugfixes and additions, the mighty DIB >>>> Engine is >>>> almost 100% >>>> operational. >>>> On one of tested apps (MSN Messenger) it behaves even better than >>>> original >>>> one :-) >>>> >>>> For whom wish to test it, bug 421 page. >>>> >>>> Ciao >>>> >>>> Max >>>> >>>> >>>> >>>> >>> fixed also last (hopefully) color format error, now some games, also >>> D3D and >>> Opengl >>> ones work perfectly. >>> >>> Ciao >>> >>> Max >>> >>> >>> >>> >> >> Which games are concerned? Also eMule here is slow when the window is >> resized, would this DIB engine fix that or am i wrong? >> >> >> > > Well, I'm not a big game player, so I don't know how many games would > benefit of it. Max: Good work. Have you started to think about how to get this into Wine where AJ will approve? James McKenzie

May 10, 2009

Re: Shuttleworth on Wine

by Ken Sharp

Austin English wrote: > It's the registering/download manager that makes it not useful. It's > much harder to script all of that. > Is CS2 too old? http://download.adobe.com/pub/adobe/photoshop/win/cs2/Photoshop_CS2.exe

May 10, 2009

Re: Shuttleworth on Wine

by Ken Sharp

> If anyone has some simple applications that are easy to test > (preferably, with no installer), shoot me an e-mail and I'll add it to > my my list of applications to look at. > Ha. That's a shame because Installshield is a real PITA. ;-)

May 10, 2009

Re: Severity levels

by Ken Sharp

Henri Verbeet wrote: > When you're not subscribed to the list, your posts have to go through > moderation. Sometimes that can take a while. So the idiot isn't even subscribed to this group, but is spamming it anyway? Don't feed the trolls.

May 10, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Warren Dumortier ha scritto: > 2009/5/10 Massimo Del Fedele <max(a)veneto.com>: >> Massimo Del Fedele ha scritto: >>> Well, after some (many) bugfixes and additions, the mighty DIB Engine is >>> almost 100% >>> operational. >>> On one of tested apps (MSN Messenger) it behaves even better than original >>> one :-) >>> >>> For whom wish to test it, bug 421 page. >>> >>> Ciao >>> >>> Max >>> >>> >>> >>> >> fixed also last (hopefully) color format error, now some games, also D3D and >> Opengl >> ones work perfectly. >> >> Ciao >> >> Max >> >> >> >> > > Which games are concerned? Also eMule here is slow when the window is > resized, would this DIB engine fix that or am i wrong? > > > Well, I'm not a big game player, so I don't know how many games would benefit of it. I tested Age of Empires, menus with many texts are very fast now. Arx Fatalis works, but I didn't make comparaisons. On apps sides: Autocad works like a charm, tested on 2005 and 2008. MS Messenger 7.5 works I didn't test Emule because (IMHO, of course) it's a nonsense to use an app for which there's a perfect counterpart on Linux Ciao Max

May 10, 2009

Re: DIB Engine : Almost 100% working

by Ricardo Filipe

2009/5/10 Warren Dumortier <nwarrenfl(a)gmail.com> > 2009/5/10 Massimo Del Fedele <max(a)veneto.com>: > > Massimo Del Fedele ha scritto: > >> > >> Well, after some (many) bugfixes and additions, the mighty DIB Engine is > >> almost 100% > >> operational. > >> On one of tested apps (MSN Messenger) it behaves even better than > original > >> one :-) > >> > >> For whom wish to test it, bug 421 page. > >> > >> Ciao > >> > >> Max > >> > >> > >> > >> > > > > fixed also last (hopefully) color format error, now some games, also D3D > and > > Opengl > > ones work perfectly. > > > > Ciao > > > > Max > > > > > > > > > > Which games are concerned? Also eMule here is slow when the window is > resized, would this DIB engine fix that or am i wrong? > > > arx fatalis and age of empires 2 among others.

May 10, 2009

Re: DIB Engine : Almost 100% working

by Warren Dumortier

2009/5/10 Massimo Del Fedele <max(a)veneto.com>: > Massimo Del Fedele ha scritto: >> >> Well, after some (many) bugfixes and additions, the mighty DIB Engine is >> almost 100% >> operational. >> On one of tested apps (MSN Messenger) it behaves even better than original >> one :-) >> >> For whom wish to test it, bug 421 page. >> >> Ciao >> >> Max >> >> >> >> > > fixed also last (hopefully) color format error, now some games, also D3D and > Opengl > ones work perfectly. > > Ciao > > Max > > > > Which games are concerned? Also eMule here is slow when the window is resized, would this DIB engine fix that or am i wrong?

May 10, 2009

Re: DIB Engine : Almost 100% working

by Massimo Del Fedele

Massimo Del Fedele ha scritto: > Well, after some (many) bugfixes and additions, the mighty DIB Engine is > almost 100% > operational. > On one of tested apps (MSN Messenger) it behaves even better than > original one :-) > > For whom wish to test it, bug 421 page. > > Ciao > > Max > > > > fixed also last (hopefully) color format error, now some games, also D3D and Opengl ones work perfectly. Ciao Max

May 10, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

> The idea is to make the test as automated as possible. That way anyone > can run the tests, not just people with certain programs. Ok. Well then, either: 1. someone can mirror those two files somewhere for easier downloading, 2. or one adds one or two(quite easy) manual step to the installation instructions. 1. makes scripting possible, however, Adobe probably would not like that. However, one *could* simply ask them if it's ok. I don't see how this quite specific use case would(come on, it's a trial version) be a problem for them and I would think that getting their application working under wine would be something they would like happening. 2. I think that one should try to be a bit pragmatical. If a couple of simple manual steps is all that is needed to get an otherwise completely automated process going, it should not be allowed to be a problem. Anyway, as I said, interesting project, since we(at work) are in the progress of automating some tests that have to use a browser(testing of some ajax-y web applications). I would prefer to run these tests on a Linux system for a number of reasons. //Nicklas

May 10, 2009

Re: New icons for 1.1.21

by Scott Ritchie

Warren Dumortier wrote: > 2009/5/9 Scott Ritchie <scott(a)open-vote.org>: >> Warren Dumortier wrote: >>> Nice, however i have a little suggestion... >>> Would it be possible to assign an icon to WINE when you select a >>> program from the list? This would be nice! ;) >> Huh? It's not clear to me what you're referring to here. Which list? Which >> icon? >> >> Thanks, >> Scott Ritchie >> > > Because i don't know how to explain it in english, i've made a little > screenshot: http://i44.tinypic.com/2rcxriu.png > Kind regards. > > Ahh, I see what you mean now. Thanks! I'll get to work on it. Thanks, Scott Ritchie

May 10, 2009