Re: [PATCH] kernel32: Add a stub for SetProcessDEPPolicy
On Wed, Nov 03, 2010 at 11:54:33PM +0100, Detlef Riekenberg wrote:
---
dlls/kernel32/kernel32.spec |1 +
dlls/kernel32/process.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec
index 8381ae8..f32371e 100644
--- a/dlls/kernel32/kernel32.spec
+++ b/dlls/kernel32/kernel32.spec
@@ -1053,6 +1053,7 @@
@ stdcall SetNamedPipeHandleState(long ptr ptr ptr)
@ stdcall SetPriorityClass(long long)
@ stdcall SetProcessAffinityMask(long long)
+@ stdcall SetProcessDEPPolicy(long)
@ stdcall SetProcessPriorityBoost(long long)
@ stdcall SetProcessShutdownParameters(long long)
@ stdcall SetProcessWorkingSetSize(long long long)
diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c
index fdd19db..86747d9 100644
--- a/dlls/kernel32/process.c
+++ b/dlls/kernel32/process.c
@@ -3394,3 +3394,11 @@ DEP_SYSTEM_POLICY_TYPE WINAPI GetSystemDEPPolicy(void)
FIXME(stub\n);
return OptIn;
}
+/**
+ * SetProcessDEPPolicy (KERNEL32.@)
+ */
+BOOL WINAPI SetProcessDEPPolicy(DWORD newDEP)
+{
+FIXME((%d): stub\n, newDEP);
+return TRUE;
+}
Perhaps return FALSE; and SetLastError(..NOTIMPLEMENTED...) as we did not
actually do it.
(always better not to lie with security related functions.)
Ciao, MArcus
Re: [PATCH 2/5] d3d8/tests: Check for multiple expected messages in test_wndproc().
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6785 Your paranoid android. === WVISTAADM (32 bit device) === device.c:1670: Test failed: Expected foreground window 000201D4, got 000101D2. === W2K8SE (32 bit device) === device.c:1670: Test failed: Expected foreground window 00010126, got 0001011A.
Fwd: msvcrt: Implement _get_tzname.
http://msdn.microsoft.com/en-us/library/4ssfs1ya.aspx _get_tzname should simply copy the contents of _tzname. In my opinion it should be ok. According to this document it's the default value. In my Polish XP it's also PST and PDT, which is of course irracional ( Poland is in Europe ). So I would assume static char tzname_std[64] = ; static char tzname_dst[64] = ; more of a hack. 2010/11/3 Dmitry Timoshkov dmi...@codeweavers.com: Eryk Wieliczko ewde...@gmail.com wrote: This is not an implementation, this is a quick and dirty hack. -- Dmitry.
Re: [PATCH 3/5] d3d9/tests: Check for multiple expected messages in test_wndproc().
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6786 Your paranoid android. === WVISTAADM (32 bit device) === device.c:2650: Test failed: Expected foreground window 000301CA, got 000201C8.
Re: Transparent windows (with alpha channel)
On 03/11/2010 12:36 πμ, Vassilis Virvilis wrote: On 02/11/2010 02:12 πμ, Vincent Povirk wrote: It is probably a layered window, in which case the following functions in user32 are relevant: SetLayeredWindowAttributes, GetLayeredWindowAttributes, UpdateLayeredWindowIndirect, and UpdateLayeredWindow Most of user32 is implemented based on gdi32, wineserver, and winex11.drv. When you see USER_Driver in user32, that indicates a function in winex11.drv. So USER_Driver-pSetLayeredWindowAttributes is really X11DRV_SetLayeredWindowAttributes. Wine requires a compositing window manager to implement layered windows properly. It does not matter whether the window manager provides any 3D effects or uses opengl. Thank you very much for the directions. They certainly put me on the right track. Again thanks for the directions. The UpdateLayeredWindowIndirect implementation of wine only utilizes a global per window alpha value. After a little bit of research it looks like what I want is something called per-pixel alpha or per color alpha or blending with alpha channel. Does wine and/or X-Windows support something like this and if so where? My guess is in bitblit but any insightful comment is welcome. .bill
RFC: Fixing comctl32 toolbar tests for different system font heights
I'm trying to fix these test failures:
http://test.winehq.org/data/d4f64121e83671ac10ed6ead04f1c19eb5586cb0/xp_wtb-wxpprojasp3/comctl32:toolbar.html
These failures occur because the system font metrics are different to
what is assumed for the hard-coded numbers.
Attached is my go at fixing these (in a three part patch set). Is
this approach even close to being the right way to do this?
From 6940f0c65a39b9a9e87c96857dc82c27bae726fa Mon Sep 17 00:00:00 2001
From: Austin Lund austin.l...@gmail.com
Date: Thu, 4 Nov 2010 15:07:18 +1000
Subject: [PATCH 1/4] comctl32/tests: Change toolbar size test data to load dynamically.
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/comctl32/tests/toolbar.c | 227 +++--
1 files changed, 103 insertions(+), 124 deletions(-)
diff --git a/dlls/comctl32/tests/toolbar.c b/dlls/comctl32/tests/toolbar.c
index 87edee1..890d604 100644
--- a/dlls/comctl32/tests/toolbar.c
+++ b/dlls/comctl32/tests/toolbar.c
@@ -680,129 +680,107 @@ typedef struct
RECT rcButtons[100];
} tbsize_result_t;
-static tbsize_result_t tbsize_results[] =
-{
- { {0, 0, 672, 26}, {100, 22}, 5, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 46, 2, 54, 24},
-{ 54, 2, 77, 24}, { 77, 2, 100, 24},
- }, },
- { {0, 0, 672, 26}, {146, 22}, 7, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 46, 2, 54, 24},
-{ 54, 2, 77, 24}, { 77, 2, 100, 24}, {100, 2, 123, 24},
-{ 0, 24, 23, 46},
- }, },
- { {0, 0, 672, 48}, {146, 22}, 7, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 46, 2, 54, 24},
-{ 54, 2, 77, 24}, { 77, 2, 100, 24}, {100, 2, 123, 24},
-{ 0, 24, 23, 46},
- }, },
- { {0, 0, 672, 26}, {146, 22}, 7, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 46, 2, 54, 24},
-{ 54, 2, 77, 24}, { 77, 2, 100, 24}, {100, 2, 123, 24},
-{123, 2, 146, 24},
- }, },
- { {0, 0, 672, 26}, {192, 22}, 9, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 46, 2, 54, 24},
-{ 54, 2, 77, 24}, { 77, 2, 100, 24}, {100, 2, 123, 24},
-{123, 2, 146, 24}, {146, 2, 169, 24}, {169, 2, 192, 24},
- }, },
- { {0, 0, 672, 92}, {882, 22}, 39, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 0, 2, 8, 29},
-{ 0, 29, 23, 51}, { 23, 29, 46, 51}, { 46, 29, 69, 51},
-{ 69, 29, 92, 51}, { 92, 29, 115, 51}, {115, 29, 138, 51},
-{138, 29, 161, 51}, {161, 29, 184, 51}, {184, 29, 207, 51},
-{207, 29, 230, 51}, {230, 29, 253, 51}, {253, 29, 276, 51},
-{276, 29, 299, 51}, {299, 29, 322, 51}, {322, 29, 345, 51},
-{345, 29, 368, 51}, {368, 29, 391, 51}, {391, 29, 414, 51},
-{414, 29, 437, 51}, {437, 29, 460, 51}, {460, 29, 483, 51},
-{483, 29, 506, 51}, {506, 29, 529, 51}, {529, 29, 552, 51},
-{552, 29, 575, 51}, {575, 29, 598, 51}, {598, 29, 621, 51},
-{621, 29, 644, 51}, {644, 29, 667, 51}, { 0, 51, 23, 73},
-{ 23, 51, 46, 73}, { 46, 51, 69, 73}, { 69, 51, 92, 73},
-{ 92, 51, 115, 73}, {115, 51, 138, 73}, {138, 51, 161, 73},
- }, },
- { {0, 0, 48, 226}, {23, 140}, 7, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 46, 2, 94, 24},
-{ 94, 2, 117, 24}, {117, 2, 140, 24}, {140, 2, 163, 24},
-{ 0, 24, 23, 46},
- }, },
- { {0, 0, 92, 226}, {23, 140}, 7, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 0, 24, 92, 32},
-{ 0, 32, 23, 54}, { 23, 32, 46, 54}, { 46, 32, 69, 54},
-{ 69, 32, 92, 54},
- }, },
- { {0, 0, 672, 26}, {194, 30}, 7, {
-{ 0, 2, 31, 32}, { 31, 2, 62, 32}, { 62, 2, 70, 32},
-{ 70, 2, 101, 32}, {101, 2, 132, 32}, {132, 2, 163, 32},
-{ 0, 32, 31, 62},
- }, },
- { {0, 0, 672, 64}, {194, 30}, 7, {
-{ 0, 2, 31, 32}, { 31, 2, 62, 32}, { 62, 2, 70, 32},
-{ 70, 2, 101, 32}, {101, 2, 132, 32}, {132, 2, 163, 32},
-{ 0, 32, 31, 62},
- }, },
- { {0, 0, 672, 64}, {194, 30}, 7, {
-{ 0, 0, 31, 30}, { 31, 0, 62, 30}, { 62, 0, 70, 30},
-{ 70, 0, 101, 30}, {101, 0, 132, 30}, {132, 0, 163, 30},
-{ 0, 30, 31, 60},
- }, },
- { {0, 0, 124, 226}, {31, 188}, 7, {
-{ 0, 0, 31, 30}, { 31, 0, 62, 30}, { 0, 30, 124, 38},
-{ 0, 38, 31, 68}, { 31, 38, 62, 68}, { 62, 38, 93, 68},
-{ 93, 38, 124, 68},
- }, },
- { {0, 0, 672, 26}, {146, 22}, 7, {
-{ 0, 2, 23, 24}, { 23, 2, 46, 24}, { 46, 2, 54, 24},
-{ 54, 2, 77, 24}, { 77, 2, 100, 24}, {100, 2, 123, 24},
-{123, 2, 146, 24},
- }, },
- { {0, 0, 672, 26}, {146, 100}, 7, {
-{ 0, 0, 23, 100}, { 23, 0, 46, 100}, { 46, 0, 54, 100},
-{ 54, 0, 77, 100}, { 77, 0, 100, 100}, {100, 0, 123, 100},
-{123, 0, 146, 100},
- }, },
- { {0, 0, 672, 26}, {215, 100}, 10, {
-{ 0, 0, 23, 100}, { 23, 0, 46, 100}, { 46, 0,
Re: Fwd: msvcrt: Implement _get_tzname.
Eryk Wieliczko ewde...@gmail.com wrote: http://msdn.microsoft.com/en-us/library/4ssfs1ya.aspx _get_tzname should simply copy the contents of _tzname. In my opinion it should be ok. According to this document it's the default value. In my Polish XP it's also PST and PDT, which is of course irracional ( Poland is in Europe ). I'd expect a real implementation return something in line with what GetTimeZoneInformation() returns. Wrting some tests to see what actual behaviour is would help. -- Dmitry.
Re: Transparent windows (with alpha channel)
2010/11/4 Vassilis Virvilis vas...@iit.demokritos.gr: On 03/11/2010 12:36 πμ, Vassilis Virvilis wrote: [...] Aain thanks for the directions. The UpdateLayeredWindowIndirect implementation of wine only utilizes a global per window alpha value. After a little bit of research it looks like what I want is something called per-pixel alpha or per color alpha or blending with alpha channel. Does wine and/or X-Windows support something like this and if so where? My guess is in bitblit but any insightful comment is welcome. .bill As much as I know XRender or Compositing Window Manager can be used for alpha blending. -- Ozan, BSc, BEng
Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (resend try 5)
Charles Davis cda...@mymail.mines.edu writes: If the volume is indeed case insensitive, we skip searching through the whole directory ourselves, and just stat() each portion of the path. You still have extra stat calls. You should stop trying to pass a case_sensitive flag to find_file_in_dir and have it take care of everything internally, if and only if a case insensitive search seems to be required. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/2] slc: Implement SLGetWindowsInformationDWORD
Detlef Riekenberg wine@web.de writes:
+HRESULT WINAPI SLGetWindowsInformationDWORD(LPCWSTR lpszValueName, LPDWORD
pdwValue)
+{
+FIXME((%s, %p): semi-stub\n, debugstr_w(lpszValueName), pdwValue);
+
+if (!lpszValueName || !pdwValue)
+return E_INVALIDARG;
+
+if (!*lpszValueName)
+return SL_E_RIGHT_NOT_GRANTED;
+
+/* We have always a genuine Wine */
+*pdwValue = 1;
+return S_OK;
There's no reason that this dword would represent the genuine flag, it
can be just about anything. Returning value not found would probably be
preferable, or else do a real attempt at determining what value would be
expected for the specified name.
--
Alexandre Julliard
julli...@winehq.org
Re: msvcrt: Implement _asctime_s and _wasctime_s.
Eryk Wieliczko ewde...@gmail.com writes:
+MSVCRT_long CDECL MSVCRT_asctime_s(char *output, MSVCRT_size_t max, const
struct MSVCRT_tm *mstm)
+{
+char *buffer;
+MSVCRT_size_t bufflen;
+
+if (output max 0)
+ output[0] = '\0';
+if (!output)
+{
+*MSVCRT__errno() = MSVCRT_EINVAL;
+return MSVCRT_EINVAL;
+}
You probably want to use the new parameter checking macros. Also the
first check is redundant.
--
Alexandre Julliard
julli...@winehq.org
Where in the code does wine read fonts?
Hi! I am trying to figure out how wine reads fonts on startup but am having a little trouble. I checked out the source and found a lot of good stuff in winex11.drv/xfont.c, but I am not sure this is actually the code, that gets executed when my wine boots. What I experience, is that wine reads the X fonts, using the fontconfig library. Is that correct? Maybe I should say *why* I am digging into the font handling in the code. When I rebuild the system fontcache (using fc-cache), wine suddenly gets painfully slow to boot. When I revert to the old cache I had before rebuild, it gets fast again. Listing the cache content (using fc-list) yields the same amount of fonts before and after rebuild, so I find it strange with the extra boot time. Actually, it would be better for me to NOT have wine read the X fonts (I think). So, I tried digging in to understand it better from the code. Is there a central place in the source code I am missing, that could lead me to the lightsource :-) Regards, Per
banning spammer from the forum
Jeremy, Please ban ebook1210 from the forum. I've had to delete multiple spam posts from him/her over the past couple of days. -- Rosanne DiMesio dime...@earthlink.net
Re: banning spammer from the forum
Done. On 11/04/2010 08:57 AM, Rosanne DiMesio wrote: Jeremy, Please ban ebook1210 from the forum. I've had to delete multiple spam posts from him/her over the past couple of days.
PGP key signing party at WineConf
Hi all, During WineConf we will be holding a key signing party, organized by your truly. The wiki page for WineConf has been updated with details on how to participate, and I have set up a page explaining the process for people who have never participated before. Please email your keys to me, with the subject WineConf key signing (so that my spam filters don't eat it up). The wineconf wiki page, in case you are not up to date, is at http://wiki.winehq.org/WineConf2010 The key signing page is at http://wiki.winehq.org/KeySigningParty Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Transparent windows (with alpha channel)
On Thu, Nov 4, 2010 at 3:08 AM, Vassilis Virvilis vas...@iit.demokritos.gr wrote: On 03/11/2010 12:36 πμ, Vassilis Virvilis wrote: On 02/11/2010 02:12 πμ, Vincent Povirk wrote: It is probably a layered window, in which case the following functions in user32 are relevant: SetLayeredWindowAttributes, GetLayeredWindowAttributes, UpdateLayeredWindowIndirect, and UpdateLayeredWindow Most of user32 is implemented based on gdi32, wineserver, and winex11.drv. When you see USER_Driver in user32, that indicates a function in winex11.drv. So USER_Driver-pSetLayeredWindowAttributes is really X11DRV_SetLayeredWindowAttributes. Wine requires a compositing window manager to implement layered windows properly. It does not matter whether the window manager provides any 3D effects or uses opengl. Thank you very much for the directions. They certainly put me on the right track. Again thanks for the directions. The UpdateLayeredWindowIndirect implementation of wine only utilizes a global per window alpha value. After a little bit of research it looks like what I want is something called per-pixel alpha or per color alpha or blending with alpha channel. Does wine and/or X-Windows support something like this and if so where? My guess is in bitblit but any insightful comment is welcome. .bill You would require ARGB visuals. Various drivers support them these days for desktop composition purposes. When I asked Alexandre about them a long time ago, he said we couldn't use them in Wine. I don't know why that was. Further even if we could use it, we would have to recreate the window upon this call since I don't think we would want to use ARGB by default. Roderick
Re: Voting for bugs (Was: Re: [Bug 20969])
On Thu, 4 Nov 2010 18:03:38 -0500 Tom Spear speeddy...@gmail.com wrote: My point in making the statement is that voting for the bug should confirm the bug once a certain threshold has been reached. It already does. -- Rosanne DiMesio dime...@earthlink.net
Re: Voting for bugs (Was: Re: [Bug 20969])
On 11/4/10 4:03 PM, Tom Spear wrote: On Wed, Nov 3, 2010 at 2:38 AM, Dmitry Timoshkov dmi...@codeweavers.com mailto:dmi...@codeweavers.com wrote: Yaron Shahrabani sh.ya...@gmail.com mailto:sh.ya...@gmail.com wrote: I think that voting for bugs is a great feature, otherwise there would have been many annoying comments like: it happens to me too and what info you can get out of it? Adding such a comment is pefectly acceptable. Confirming a bug and voting for it are two different things. Once a bug is confirmed its state changes from UNCONFORMED to NEW, and usually once sombody else bisides the reporter confirms a bug, a person with appropriate bugzilla rights sets bug state to NEW. But asking people to vote for a bug is a waste of effort, since that doesn't change anything. There are bugs in Wine bugzilla with huge amounts of votes on them, but that doesn't suddenly make a bug more important to developers for various reasons. Voting helps setting priorities for bugs without nonsense comments. That's the bug severity is for. -- Dmitry. My point in making the statement is that voting for the bug should confirm the bug once a certain threshold has been reached. People other than the reporter making a comment that a bug occurs for them too doesn't necessarily make the bug valid, and certainly doesn't change it's status. There are bugzilla installs for other projects, IIRC, that do change the status of bugs from UNCONFIRMED to NEW once there have been several votes, which helps the developers in terms of how much time they spend doing what they like (coding) vs doing maintenance (marking bugs as invalid). Tom: That already exists. I don't know the threshold of when a bug is moved from UNCONFIRMED to NEW, but it already exists. We already have pool voting but you are restricted to the number of votes per bug. My concern is that we get a bunch of 'me too' comments that have no other substance (like this happens when I do X but not if I do Y or see the dump file on Ubuntu Lucid when the bug was reported with a Fedora build) will start to happen. That is why the bug vote system exists. Yes, there are bugs with thousands of votes, but that just shows the scope of effect of a particular bug. It DOES not mean that the bug will be fixed faster or even a developer exists to fix it. Dmitry is correct in that the bug's priority is set by the development team and is not influenced by the number of votes. However, voting does give users input to which bug should be corrected, not that it will ever be. The reason that I pointed out bug 421 as one that has many votes, has a high priority, has been open for years, but still has not been fixed. This is the reality of life. There has been no developer, to date, that can build code that meets the standards of the Wine development team and successfully implements this function. This does not mean this will never happen. So for now, the vote system does what it is supposed to do and the priority system likewise. This is my additional .02 USD on the subject. James McKenzie
Re: Voting for bugs (Was: Re: [Bug 20969])
On Fri, Nov 5, 2010 at 4:02 AM, James McKenzie jjmckenzi...@earthlink.net wrote: Yes, there are bugs with thousands of votes, but that just shows the scope of effect of a particular bug. I'm not sure where you got that idea: http://bugs.winehq.org/buglist.cgi?query_format=advancedvotes=100order=votes%2Cbug_id -- -Austin
