Re: winex11drv: Treat CapsLock and NumLock keys as normal keys. They should toggle on button down.
Vitaliy Margolen [EMAIL PROTECTED] writes: Alexandre Julliard wrote: Vitaliy Margolen [EMAIL PROTECTED] writes: On winxp both keys toggle on button down not button up. So no need for any extra treatment. Fixes bug 10446. You still have to handle the case when the state has been toggled outside of Wine, you can't just get rid of the whole thing. And how's the current code handles that? By setting few internal thread unsafe constantly being reset flags? No, it does this by simulating a keypress if the state has been changed outside Wine, nothing to do with the global flags. I certainly agree the global flags can be removed, but that doesn't mean you can remove the rest of the code without understanding what it does. -- Alexandre Julliard [EMAIL PROTECTED]
Re: kernel32: cpu: Detect AMD 64bit CPUs
Alexander Nicolaysen Sørnes [EMAIL PROTECTED] writes: kernel32: cpu: Detect AMD 64bit CPUs Are you really supposed to return a 64bit CPU in 32-bit mode? Do you have a test case? -- Alexandre Julliard [EMAIL PROTECTED]
Re: kernel32: cpu: Detect AMD 64bit CPUs
On Tuesday 11 December 2007 12:08:29 you wrote: Alexander Nicolaysen Sørnes [EMAIL PROTECTED] writes: kernel32: cpu: Detect AMD 64bit CPUs Are you really supposed to return a 64bit CPU in 32-bit mode? Do you have a test case? It only identifies the model as an AMD x86 64bit CPU, so it doesn't imply that the Windows version is 64 bit. I don't have such a CPU myself; it was a fix for bug 10742 (http://bugs.winehq.org/show_bug.cgi?id=10742) Alexander
Re: ntdll: Initialize APC call and result variables to suppress valgrind warnings
Dmitry Timoshkov [EMAIL PROTECTED] writes: Alexandre said that it's OK to use memset for server requests because of backwards compatibility. It's OK for requests, but why do you want to initialize the result structure too? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Work legalities
I was hoping to be able to submit some patches for wine over the christmas holidays. So I'm trying to sort out with work any legalities with regards to my employment contract and working on other projects. Basically the contract states that they own what I do, unless I get permission from the relevant managers internally to write code for work outside of my employment. In general there isn't any issues in work getting permission to work on open source projects, the company is involved in enough of them itself. However I did remember reading some emails over a year ago on this list about getting written permission, and examples of what would be needed. Just have a query on part of the text. On Thu, Mar 08, 2007 at 02:19:21PM -0600, Jeremy White wrote: I asked James Vasile, of the Software Freedom Law Center, to comment on this. (For those who don't recall, the SFLC officially represents the Wine project on legal matters). This is essentially what he had to say (and James, correct me if I get anything wrong :-/): If you are employed to do programming (even at a university), or have made an agreement with your employer, school or anyone else saying it owns software you write, then you and we need a signed document from them disclaiming any rights they may have to the software. The disclaimer should be signed by a vice president, general manager, or anyone else who is authorized to assign software owned by them. Here is a sample wording: As a general rule, get everything in writing. The below will suffice. Email is fine, paper is better. The project needs a copy (or, better yet, the original) of the document. Here's some sample text: ACME Corporation (Company) hereby disclaims all copyright interest in the code written by Jane Doe for the program [insert name of program] (Program), including original Program code and documentation and support files, changes and enhancements to the Program and files, and any future modifications of the Program and files. We do not consider the code as work made for hire for us. Company affirms that it has no other intellectual property interest that would undermine this release, or the use of the Program, and will do nothing to undermine it in the future. [signature of John Smith], 30 March 2006 John Smith, Vice President, ACME Corp. Ideally, you would obtain this in writing and then get this on to James (vasille - at - softwarefreedom - dot - org, or use snail mail/fax from their web site). Cheers, Jeremy These lines specifically may be an issue. files. We do not consider the code as work made for hire for us. Company affirms that it has no other intellectual property interest that would undermine this release, or the use of the Program, and will do nothing to undermine it in the future. My reading of this, is it would cover patents as well. So if the company (it's a big multi-national, really really big, but not microsoft :) ), has any patents covering wine, not just the code I write for wine, this would mean they release all rights to any patents possibly covering wine. Now I just cannot see them being willing to perform a risk assessment on all IP they might have in this case. Just to let one employee I can see the possibility of getting sign off on them not claiming any copyright over any code I write provided it doesn't use any company resources (equipment or time), but not where it covers all IP. So, do I have the correct reading of what the statement means? Any suggestions on how to deal with this, without simply leaving the company. As I mentioned early, they do work on open source code here too, so I plan to discuss this with my manager as well. -- Darragh Nothing is foolproof to a sufficiently talented fool.
Re: kernel32: cpu: Detect AMD 64bit CPUs
Hi, I think GetSystemInfo should return x86 even on x64 when running 32-bit applications just like a 32-bit Windows or WOW64 does. But GetNativeSystemInfo could return the actual 64-bit CPU altough I'm not sure that it makes any sense without WOW64. Kornél - Original Message - From: Alexander Nicolaysen Sørnes [EMAIL PROTECTED] To: Alexandre Julliard [EMAIL PROTECTED]; wine-devel@winehq.org Sent: Tuesday, December 11, 2007 12:14 PM Subject: Re: kernel32: cpu: Detect AMD 64bit CPUs On Tuesday 11 December 2007 12:08:29 you wrote: Alexander Nicolaysen Sørnes [EMAIL PROTECTED] writes: kernel32: cpu: Detect AMD 64bit CPUs Are you really supposed to return a 64bit CPU in 32-bit mode? Do you have a test case? It only identifies the model as an AMD x86 64bit CPU, so it doesn't imply that the Windows version is 64 bit. I don't have such a CPU myself; it was a fix for bug 10742 (http://bugs.winehq.org/show_bug.cgi?id=10742) Alexander
Re: ntdll: Initialize APC call and result variables to suppressvalgrind warnings
Alexandre Julliard [EMAIL PROTECTED] wrote: It's OK for requests, but why do you want to initialize the result structure too? NTDLL_queue_process_apc for a local process calls invoke_apc() which initializes the result to 0 before proceeding. Perhaps memset() should be added for a not local case as well, or memset() should be removed from invoke_apc() and replaced by explicit initialization as done in my patch. What's your opinion? -- Dmitry.
Re: Wine Weekly News
On Mon, 10 Dec 2007, Jonathan Ernst wrote:
[...]
About the new AppDB Application Status Changes, I see that you have a
change column.
I'm not convinced this column is of any use: it only repeats what we see
in the other two columns but in a less obvious way.
The total / global trend however would be more useful. Something like:
Applications whose rating improved: X
Applications whose rating worsened: Y
I'm not sure more detail is pratical because there are lots of possible
transitions: from Garbage to Bronze, Silver, Gold, Platinum; from
Silver to Garbage, ... (10 total).
We could also have a count of new applications for each rating. But
if this also counts newly added applications, then it does not say much
about whether applications improve or not. But it would give an idea of
the level of activity in the application database.
--
Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/
$live{free} || die ;
Re: winspool: implement EnumFormsA/W for form level 1, add a few builtinforms
Marcel Partap [EMAIL PROTECTED] wrote:
+static const struct builtin_form builtin_forms[] = {
+{{'L','e','t','t','e','r',0}, {{216000,279000}, {0,0,216000,279000}, 0,
FORM_BUILTIN}},
+{{'A','3',0}, {{297000,42}, {0,0,297000,42}, 0, FORM_BUILTIN}},
+{{'A','4',0}, {{21,297000}, {0,0,21,297000}, 0, FORM_BUILTIN}},
+{{'A','5',0}, {{148000,21}, {0,0,148000,21}, 0, FORM_BUILTIN}} };
I guess this info should be fetched from the printer, not hard coded.
--
Dmitry.
Re: winspool: implement EnumFormsA/W for form level 1, add a few builtinforms
I guess this info should be fetched from the printer, not hard coded. No no there are indeed builtin forms: (from http://www.unixwiz.net/techtips/winspooler-forms.html) FORM_INFO_1.Flags Each form can be one of three types: FORM_BUILTIN, FORM_PRINTER and FORM_USER. Builtin forms are an inherent part of the print system (TODO: which part?), and they cannot be deleted or changed with the Forms API. Printer forms are stored in the registry, as are User forms. The Microsoft documentation suggests that the Printer forms are associated with individual printers, but we've not found any indication that they are anything other than system wide and available to all printers. We have not found how user forms are implemented. The database of user and print forms (but not builtin forms) is found in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Forms\ first I wanted to put them into the registry somewhere beneath the wine tree but decided against.. There are lots more builtin forms on windows of course (try winspool crosstest).. regards marcel
Re: Monday's valgrind results: no new errors
Alistair Leslie-Hughes wrote: Dan Kegel [EMAIL PROTECTED] wrote: http://kegel.com/wine/valgrind/logs-2007-12-10-summary.txt ... today's git is probably about as Valgrind-clean as Saturday's. From todays list there isn't a memory leak in vg-shlwapi_string.txt from but on the 8th there was. Just a little concerned that something has been missed. I have a patch locally that I haven't submitted yet. I haven't been paying any attention to memory leaks myself. In fact, I only show files that include pointer and uninitialized access errors, so if a module doesn't have any non-memory-leak errors, I don't even show the file. That may be why the file is missing on the 10th. I guess my thinking was let's fix all the serious errors, then start fixing memory leaks. But I guess I should put some effort into making the logs more useful for people looking for memory leaks. Of course, if you can run valgrind locally, that's the best way to investigate things in detail. - Dan
Re: wintrust: implementations for WTHelperGetFileName and WTHelperGetFIleHandle
Hi Aric, Aric Stewart wrote: + else + return (HANDLE)0x; That's what is INVALID_HANDLE_VALUE for. Jacek
wine proccess list
Hello to all. I have something in mind that I would like to ask to Wine developers. Is it possible using a hack/trick or a hidden option to change the name of wine in the proccess lists? I mean, Is it possible to list 'wine' proccess as, for example 'iexplorer' when I use Internet Explorer under Wine? Thanks a lot for your work, hope my question find the answer here.
Re: wine proccess list
Am Dienstag, 11. Dezember 2007 18:02:53 schrieb Gonzalo Martinez - Sanjuan Sanchez: Hello to all. I have something in mind that I would like to ask to Wine developers. Is it possible using a hack/trick or a hidden option to change the name of wine in the proccess lists? I mean, Is it possible to list 'wine' proccess as, for example 'iexplorer' when I use Internet Explorer under Wine? Thanks a lot for your work, hope my question find the answer here. This is done since quite some time. apps are usually called iexplore.exe, or they have the name of the file that was passed to wine, like C:\Program Files\Internet Explorer\iexplore.exe If you still see wine, wineloader or something similar you have a very outdated version of wine. signature.asc Description: This is a digitally signed message part.
Re: wine proccess list
Hi Gonzalo, Stefan Dösinger schreef: Ow, ah, this is a different business. I think we use some Linux-only feature to set the name, and Alexandre told me that at least MacOS doesn't have it. I have no idea if there is a way to change the process name under BSD. If there is, feel free to implement it and send a patch A slightly hacky method is to copy the process to /tmp, rename it and execute it there. It would work for mac and bsd, but I have no idea wether Alexandre would accept it into wine. Cheers, Maarten.
Re: wine proccess list
El Tuesday 11 December 2007 7:34:49 pm escribió: Am Dienstag, 11. Dezember 2007 18:02:53 schrieb Gonzalo Martinez - Sanjuan Sanchez: Hello to all. I have something in mind that I would like to ask to Wine developers. Is it possible using a hack/trick or a hidden option to change the name of wine in the proccess lists? I mean, Is it possible to list 'wine' proccess as, for example 'iexplorer' when I use Internet Explorer under Wine? Thanks a lot for your work, hope my question find the answer here. This is done since quite some time. apps are usually called iexplore.exe, or they have the name of the file that was passed to wine, like C:\Program Files\Internet Explorer\iexplore.exe If you still see wine, wineloader or something similar you have a very outdated version of wine. Well, im talking about Wine 0.9.48 under FreeBSD/PC-BSD OS.
wine proccess list
Gonzalo sent me this thread, and I may be able to get a patch put together here soon. First, I wanted to make sure I'm on the right path: Can somebody confirm for me that this is the right location where I should be trying to fix this? http://source.winehq.org/source/loader/preloader.c#L1006 FreeBSD has a function called setproctitle(), which I'm pretty sure is the right one for this task. http://www.freebsd.org/cgi/man.cgi?query=setproctitleapropos=0sektion=0manpath=FreeBSD+6.2-RELEASEformat=html I'll probably try and see about a patch here in the next day or so. Who do I send it to if I can get it working? -- Kris Moore PC-BSD Software http://www.pcbsd.com Am Dienstag, 11. Dezember 2007 20:25:20 schrieb Gonzalo Martinez - Sanjuan Sanchez: El Tuesday 11 December 2007 7:34:49 pm escribió: Am Dienstag, 11. Dezember 2007 18:02:53 schrieb Gonzalo Martinez - Sanjuan Sanchez: Hello to all. I have something in mind that I would like to ask to Wine developers. Is it possible using a hack/trick or a hidden option to change the name of wine in the proccess lists? I mean, Is it possible to list 'wine' proccess as, for example 'iexplorer' when I use Internet Explorer under Wine? Thanks a lot for your work, hope my question find the answer here. This is done since quite some time. apps are usually called iexplore.exe, or they have the name of the file that was passed to wine, like C:\Program Files\Internet Explorer\iexplore.exe If you still see wine, wineloader or something similar you have a very outdated version of wine. Well, im talking about Wine 0.9.48 under FreeBSD/PC-BSD OS. Ow, ah, this is a different business. I think we use some Linux-only feature to set the name, and Alexandre told me that at least MacOS doesn't have it. I have no idea if there is a way to change the process name under BSD. If there is, feel free to implement it and send a patch
Re: wine proccess list
Am Dienstag, 11. Dezember 2007 22:29:12 schrieb Kris Moore: Gonzalo sent me this thread, and I may be able to get a patch put together here soon. First, I wanted to make sure I'm on the right path: Can somebody confirm for me that this is the right location where I should be trying to fix this? http://source.winehq.org/source/loader/preloader.c#L1006 I am not familiar to this code unfortunately, so I cannot answer that. It might be that wine-preloader isn't used on BSD, it might use wine-kthread or wine-pthread instead signature.asc Description: This is a digitally signed message part.
Re: wine proccess list
Maarten Lankhorst [EMAIL PROTECTED] writes: Hi Gonzalo, Stefan Dösinger schreef: Ow, ah, this is a different business. I think we use some Linux-only feature to set the name, and Alexandre told me that at least MacOS doesn't have it. I have no idea if there is a way to change the process name under BSD. If there is, feel free to implement it and send a patch A slightly hacky method is to copy the process to /tmp, rename it and execute it there. It would work for mac and bsd, but I have no idea wether Alexandre would accept it into wine. I wouldn't, but on FreeBSD you can use setproctitle() for this. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine proccess list
Kris Moore [EMAIL PROTECTED] writes: Gonzalo sent me this thread, and I may be able to get a patch put together here soon. First, I wanted to make sure I'm on the right path: Can somebody confirm for me that this is the right location where I should be trying to fix this? http://source.winehq.org/source/loader/preloader.c#L1006 No, the right place is set_process_name() in dlls/kernel32/process.c. -- Alexandre Julliard [EMAIL PROTECTED]
Re: imagehlp: improve last error handling in ImageGetCertificateData
Humm, I wrote a test program mimicking the calls in the application I
am working on and found this behavior. The app was passing in a NULL
buffer and a pointer for the size set to 0, We where exiting with TRUE
and not setting the last error correctly which was confusing the app.
Testing on windows seems to show that we needed to set the size and set
last error (and return FALSE).
I am not sure how i would set up a regression test since wouldn't we
need an exe with a certificate in it to test with? There must be a
programmatic way to set that up.
-aric
Juan Lang wrote:
Hi Aric,
-if( !Certificate )
+if( *RequiredLength size )
{
*RequiredLength = size;
-return TRUE;
+SetLastError( ERROR_INSUFFICIENT_BUFFER );
+return FALSE;
}
-if( *RequiredLength size )
+if( !Certificate )
{
*RequiredLength = size;
-SetLastError( ERROR_INSUFFICIENT_BUFFER );
-return FALSE;
+return TRUE;
}
Are you sure this is the order that *RequiredLength and Certificate
are checked in? Seems backwards to the normal style to me. I won't
bug you for a proper regression test, as I failed to produce one too
:)
--Juan
Re: imagehlp: improve last error handling in ImageGetCertificateData
Humm, I wrote a test program mimicking the calls in the application I
am working on and found this behavior. The app was passing in a NULL
buffer and a pointer for the size set to 0, We where exiting with TRUE
and not setting the last error correctly which was confusing the app.
In that case, this part of the patch is still suspect:
-if( *RequiredLength size )
+if( !Certificate )
{
*RequiredLength = size;
-SetLastError( ERROR_INSUFFICIENT_BUFFER );
-return FALSE;
+return TRUE;
I'm not sure how Windows behaves in this case, but if it returns FALSE
(ERROR_INSUFFICIENT_BUFFER) when Certificate is NULL and
*RequiredLength is 0, I'd be surprised if it returned TRUE when
Certificate is NULL and *RequiredLength is large enough.
I am not sure how i would set up a regression test since wouldn't we
need an exe with a certificate in it to test with? There must be a
programmatic way to set that up.
Indeed, I thought the same thing, and tried copying in bits from
kernel32/tests/process.c to create an image. I failed to create one
that Windows would accept, so I gave up. You can blame that on my
laziness, though. Feel free to try yourself.
--Juan
Re: imagehlp: improve last error handling in ImageGetCertificateData
Indeed testing with my test app i see that if the Len is sufficient but
the buffer is null i get a return of FALSE and a last error of
ERROR_INVALID_PARAMETER. I will update my patch.
-aric
Juan Lang wrote:
Humm, I wrote a test program mimicking the calls in the application I
am working on and found this behavior. The app was passing in a NULL
buffer and a pointer for the size set to 0, We where exiting with TRUE
and not setting the last error correctly which was confusing the app.
In that case, this part of the patch is still suspect:
-if( *RequiredLength size )
+if( !Certificate )
{
*RequiredLength = size;
-SetLastError( ERROR_INSUFFICIENT_BUFFER );
-return FALSE;
+return TRUE;
I'm not sure how Windows behaves in this case, but if it returns FALSE
(ERROR_INSUFFICIENT_BUFFER) when Certificate is NULL and
*RequiredLength is 0, I'd be surprised if it returned TRUE when
Certificate is NULL and *RequiredLength is large enough.
I am not sure how i would set up a regression test since wouldn't we
need an exe with a certificate in it to test with? There must be a
programmatic way to set that up.
Indeed, I thought the same thing, and tried copying in bits from
kernel32/tests/process.c to create an image. I failed to create one
that Windows would accept, so I gave up. You can blame that on my
laziness, though. Feel free to try yourself.
--Juan
Valgrind results Dec 11: new quartz/filtergraph crash (oh, Lei...)
New results at http://kegel.com/wine/valgrind/logs-2007-12-11-summary.txt The changes from yesterday are probably noise except: The tests crashed and valgrind hung while running the quartz/filtergraph test; see http://kegel.com/wine/valgrind/logs-2007-12-11/vg-quartz_filtergraph-diff.txt +Unhandled exception: page fault on read access to 0x in 32-bit code (0x045e1290). +Backtrace: +=1 0x045e1290 func_filtergraph+0x110() [/home/dank/wine-git/dlls/quartz/tests/filtergraph.c:161] in quartz_test (0x7f22fe58) + 2 0x045e20e8 run_test+0x128(name=0x7f0003f7) [/home/dank/wine-git/dlls/quartz/tests/../../../include/wine/test.h:389] in quartz_test (0x7f22fea8) + 3 0x045e277d main+0x14d(argc=register ECX not in topmost frame, argv=register ECX not in topmost frame) [/home/dank/wine-git/dlls/quartz/tests/../../../include/wine/test.h:437] in quartz_test (0x7f22fed8) + 4 0x045e284b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/dank/wine-git/dlls/winecrt0/exe_entry.c:36] in quartz_test (0x7f22ff08) + 5 0x045198be start_process+0xee(arg=0x0) [/home/dank/wine-git/dlls/kernel32/process.c:839] in kernel32 (0x7f22ffe8) + 6 0x0402c9e7 wine_switch_to_stack+0x17() in libwine.so.1 (0x) +0x045e1290 func_filtergraph+0x110 [/home/dank/wine-git/dlls/quartz/tests/filtergraph.c:161] in quartz_test: movl 0x0(%eax),%edx +161hr = IFilterGraph2_Release(pF); Lei, could you have a look? You were just in here... - Dan
Re: Valgrind results Dec 11: new quartz/filtergraph crash (oh, Lei...)
Dan Kegel [EMAIL PROTECTED] wrote: New results at http://kegel.com/wine/valgrind/logs-2007-12-11-summary.txt The changes from yesterday are probably noise except: I wonder why http://kegel.com/wine/valgrind/logs-2007-12-11/vg-kernel32_virtual.txt still shows NTDLL_queue_process_apc as an offender since Alexandre committed my patch which supposedly should fix that. -- Dmitry.
Re: wine proccess list
Am Dienstag, 11. Dezember 2007 18:02:53 schrieb Gonzalo Martinez - Sanjuan Sanchez: Hello to all. I have something in mind that I would like to ask to Wine developers. Is it possible using a hack/trick or a hidden option to change the name of wine in the proccess lists? I mean, Is it possible to list 'wine' proccess as, for example 'iexplorer' when I use Internet Explorer under Wine? Thanks a lot for your work, hope my question find the answer here. This is done since quite some time. apps are usually called iexplore.exe, or they have the name of the file that was passed to wine, like C:\Program Files\Internet Explorer\iexplore.exe If you still see wine, wineloader or something similar you have a very outdated version of wine. Hi! BTW I don't like this feature and I would prefer at least a commandline switch, or maybe a registry key, to prevent it. Why ? Because wine (and windows apps) sometimes crash and remain running, doing nothing useful but eating CPU/memory, and not being able to be killed easily (even killing the window doesn't close the app reliably). For this case, it's most easy to execute killall -KILL some static name like wine/wine-pthread instead of doing ps axufw, searching for the name of the app and then killing it. I had a single-liner script called kw (kill wine) and doing exactly the above command, and a beutifull bomb icon calling it. Now I can't se it - even killing wineserver sometimes doesn't help. With regards, Pavel Troller
Re: wine proccess list
On Tuesday 11 December 2007 09:07:15 pm Pavel Troller wrote: Because wine (and windows apps) sometimes crash and remain running, doing nothing useful but eating CPU/memory, and not being able to be killed easily (even killing the window doesn't close the app reliably). For this case, it's most easy to execute killall -KILL some static name like wine/wine-pthread instead of doing ps axufw, searching for the name of the app and then killing it. I had a single-liner script called kw (kill wine) and doing exactly the above command, and a beutifull bomb icon calling it. Now I can't se it - even killing wineserver sometimes doesn't help. IIRC, running 'wineserver -k' will kill wineserver and its processes. It's always worked for me, even on apparently stuck programs. Though both methods (killall with a static wine process name and wineserver -k) will kill all wine/windows processes, even ones that are running fine. It's easier to killall a specific .exe named process, than using ps -fel to look for the PID and using regular kill on it.
Re: [5/5] gdi: Test bitmap depths
This is good since 15-bpp DIB is not supported in my DIB engine. As it is right now, the 15-bit DIB stuff in winex11/gdi is not really correct (even if it might work). On Dec 11, 2007 1:31 PM, Stefan Dösinger [EMAIL PROTECTED] wrote:
Re: wine proccess list
On Wednesday December 12 2007 05:07, Pavel Troller wrote: Am Dienstag, 11. Dezember 2007 18:02:53 schrieb Gonzalo Martinez - Sanjuan Sanchez: Hello to all. I have something in mind that I would like to ask to Wine developers. Is it possible using a hack/trick or a hidden option to change the name of wine in the proccess lists? I mean, Is it possible to list 'wine' proccess as, for example 'iexplorer' when I use Internet Explorer under Wine? Thanks a lot for your work, hope my question find the answer here. This is done since quite some time. apps are usually called iexplore.exe, or they have the name of the file that was passed to wine, like C:\Program Files\Internet Explorer\iexplore.exe If you still see wine, wineloader or something similar you have a very outdated version of wine. Hi! BTW I don't like this feature and I would prefer at least a commandline switch, or maybe a registry key, to prevent it. Why ? Because wine (and windows apps) sometimes crash and remain running, doing nothing useful but eating CPU/memory, and not being able to be killed easily (even killing the window doesn't close the app reliably). For this case, it's most easy to execute killall -KILL some static name like wine/wine-pthread instead of doing ps axufw, searching for the name of the app and then killing it. I had a single-liner script called kw (kill wine) and doing exactly the above command, and a beutifull bomb icon calling it. Now I can't se it - even killing wineserver sometimes doesn't help. You can simply run: wineserver -k This kills all processes which belongs to current WINE prefix (as specified in WINEPREFIX environment variable or ~/.wine otherwise). For me this works in 100% of cases so I see no problem here. Personally I really like this feature because I always know what Windows program(s) use my CPU and I can easily send STOP/CONT/KILL signals to Windows program(s) I want. Without this features this would be (almost) impossible.
Re: [5/5] gdi: Test bitmap depths
Am Mittwoch, 12. Dezember 2007 06:52:26 schrieb Jesse Allen: This is good since 15-bpp DIB is not supported in my DIB engine. As it is right now, the 15-bit DIB stuff in winex11/gdi is not really correct (even if it might work). It is the intention of this patch, and coming ones, to clean up the 24/32 bpp mess, also with regard to 15/16 bpp confusion, although I am missing hardware capable of running X at depth 15 for testing, so it will be mainly about the 24/32 bpp differences which break some games. signature.asc Description: This is a digitally signed message part.
Re: Valgrind results Dec 11: new quartz/filtergraph crash (oh, Lei...)
On Dec 11, 2007 8:11 PM, Dan Kegel [EMAIL PROTECTED] wrote:
New results at
http://kegel.com/wine/valgrind/logs-2007-12-11-summary.txt
The changes from yesterday are probably noise except:
The tests crashed and valgrind hung while running the
quartz/filtergraph test; see
http://kegel.com/wine/valgrind/logs-2007-12-11/vg-quartz_filtergraph-diff.txt
+Unhandled exception: page fault on read access to 0x in
32-bit code (0x045e1290).
+Backtrace:
+=1 0x045e1290 func_filtergraph+0x110()
[/home/dank/wine-git/dlls/quartz/tests/filtergraph.c:161] in
quartz_test (0x7f22fe58)
+ 2 0x045e20e8 run_test+0x128(name=0x7f0003f7)
[/home/dank/wine-git/dlls/quartz/tests/../../../include/wine/test.h:389]
in quartz_test (0x7f22fea8)
+ 3 0x045e277d main+0x14d(argc=register ECX not in topmost frame,
argv=register ECX not in topmost frame)
[/home/dank/wine-git/dlls/quartz/tests/../../../include/wine/test.h:437]
in quartz_test (0x7f22fed8)
+ 4 0x045e284b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000)
[/home/dank/wine-git/dlls/winecrt0/exe_entry.c:36] in quartz_test
(0x7f22ff08)
+ 5 0x045198be start_process+0xee(arg=0x0)
[/home/dank/wine-git/dlls/kernel32/process.c:839] in kernel32
(0x7f22ffe8)
+ 6 0x0402c9e7 wine_switch_to_stack+0x17() in libwine.so.1 (0x)
+0x045e1290 func_filtergraph+0x110
[/home/dank/wine-git/dlls/quartz/tests/filtergraph.c:161] in
quartz_test: movl 0x0(%eax),%edx
+161hr = IFilterGraph2_Release(pF);
Lei, could you have a look? You were just in here...
- Dan
It looks as though you're running the current test with an older quartz.dll.so.
http://kegel.com/wine/valgrind/logs-2007-12-11/vg-quartz_filtergraph.txt says:
fixme:quartz:Filtergraph_QueryInterface unknown interface
{36b73882-c2c8-11cf-8b46-00805f6cef60}
the patch that fixed that also added the test that caused your crash.
