wine-devel August 2007

wine-devel@winehq.org

121 participants
249 discussions

Re: WineD3D: better pixelformat selection code
by H. Verbeet 09 Aug '07

09 Aug '07

On 09/08/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This code lets WineD3D use the pixelformat of the D3D device. The code helps > on Windows where OpenGL offers multiple pixelformats. > The stencil column is probably useful for determining if we need an stencil attachment for FBOs as well. >+int count_bits(int mask) >+{ >+ int i, count=0; >+ for(i=0; i<32; i++) >+ { >+ if(mask & (1<<i)) >+ count++; >+ } >+ return count; >+} The "classical" way to do that would be something like this: unsigned int count_bits(unsigned int mask) { unsigned int count; for (count = 0; mask; ++count) { mask &= mask - 1; } return count; } Ie, simply mask out the set bits one by one until none are set, rather than looping over all of them.

1 0

Re: user32: CallWindowProc[AW] for mismatched built-in winprocs should take into account if the window is Unicode (with testcase, fixes bug #9198)
by Dmitry Timoshkov 09 Aug '07

09 Aug '07

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > --- a/dlls/user32/tests/class.c > +++ b/dlls/user32/tests/class.c > @@ -32,6 +32,7 @@ > #include "winreg.h" > #include "wingdi.h" > #include "winuser.h" > +#include <commctrl.h> /* for WC_EDITW */ Besides using braces instead of quotes to match existing style it's not really nice to include commctrl.h in a user32 (more lower level) test. It shouldn't be too hard to add "Edit" in WCHAR notation. > /*********************************************************************** > */ > static void ClassTest(HINSTANCE hInstance, BOOL global) > @@ -560,7 +566,12 @@ static void test_defwndproc() > { > static const char classA[] = "deftest"; > static const WCHAR classW[] = {'d','e','f','t','e','s','t',0}; > + WCHAR unistring[] = {0x142, 0x40e, 0x3b4, 0}; /* a string that would be destoryed by a W->A->W conversion */ Any other string should work just fine. In the current form the test will fail for some locales. > diff --git a/dlls/user32/winproc.c b/dlls/user32/winproc.c > index 27b31a1..4feb3d5 100644 > --- a/dlls/user32/winproc.c > +++ b/dlls/user32/winproc.c > @@ -2257,7 +2257,17 @@ LRESULT WINAPI CallWindowProcA( > > if (!func) return 0; > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procA || !IsWindowUnicode( hwnd )) > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + else > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + return result; > + } > + > + if (!(proc = handle_to_proc( func ))) > call_window_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procA) > call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > @@ -2281,8 +2291,18 @@ LRESULT WINAPI CallWindowProcW( WNDPROC func, HWND hwnd, UINT msg, > LRESULT result; > > if (!func) return 0; > + > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procW || IsWindowUnicode( hwnd )) > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + else > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + return result; > + } > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + if (!(proc = handle_to_proc( func ))) > call_window_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procW) > call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > @@ -2340,7 +2360,17 @@ INT_PTR WINPROC_CallDlgProcA( DLGPROC func, HWND hwnd, UINT msg, WPARAM wParam, > > if (!func) return 0; > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procA || !IsWindowUnicode( hwnd )) > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + else > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + return result; > + } > + > + if (!(proc = handle_to_proc( func ))) > ret = call_dialog_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procA) > ret = call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > @@ -2368,8 +2398,18 @@ INT_PTR WINPROC_CallDlgProcW( DLGPROC func, HWND hwnd, UINT msg, WPARAM wParam, > INT_PTR ret; > > if (!func) return 0; > + > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procW || IsWindowUnicode( hwnd )) > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + else > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + return result; > + } Please use spaces instead of tabs to match current formatting. -- Dmitry.

2 1

Wine Kernel Handle Support Module
by James Keane 08 Aug '07

08 Aug '07

I have been working on something that might be useful for kernel integration. It is a way for wine to create its own interrupt, so that a wine server/kernel/handle/whatever function could be called from userspace with a simple INT 0xwhatever. Just as linux uses int 0x80. The only problem I could see with this technique is that it directly modifies the IDT, which only exists on i386/amd64 architectures, so that means we would have to find something else. I am not sure if this is the direction that some people want to take, because I am sure this modification of the IDT would be considered improper by kernel types but come on, I mean i386 has something like 200 software interrupts and linux uses only one. As it stands now, I have code that works perfectly with amd64 processors and just need to implement the actual wine system calls for handles or whatever it is. i386 support is a stones throw away, I just need to setup a virtual machine. I know there is some discussion of what should be put in the kernel module, so I am asking for advice on what to implement... ie. just handles, everything wineserver does, etc.

4 3

exporting file associations for linux desktops
by Vincent Povirk 08 Aug '07

08 Aug '07

This was something I thought we wanted for wine for a long time, but I can't find any literature suggesting that's the case. So I'll just explain it here. As it is right now, we have a filetype/association system in Wine's registry, and we have a completely separate one in most Linux desktops. They do not talk to each other. Wine's system relies primarily on extensions because that's what Windows does, but the Linux system works based on MIME Types. I would like to see this gap bridged in one direction by exporting the information in Wine's registry in a simplified format and converting it to something useful for Linux desktops. From what I've seen so far, this looks surprisingly simple. On the Linux end, MIME Types can be registered as described at http://www.freedesktop.org/wiki/Specifications/AddingMIMETutor (only using ~/.local/share instead of /usr/local/share). fd.org doesn't seem to have a standard for registering actions so that would need to be desktop-specific, but I don't expect any major problems from that. The Windows registry does appear to contain some MIME Types, but they're spotty and unreliable. I'm told, though, that most desktops can cope with things like application/x-extension-html even when text/html exists. Generating types like that is probably the way to go. From there, it's a simple matter to get a list of verbs that apply to files with each extension. To register those verbs for Linux desktops, some sort of command-line wrapper around ShellExecute would be needed. I think this is a good idea anyway. Does Windows have anything like that? Is it worth it for me to try writing something like that based on winelib? Also, what's the best way to design this if I want to see it added to Wine? I know how I'd do it as a set of external programs, but I'd rather avoid that. Attached is a simple python script I wrote that prints all of the information I think is necessary to be exported from Wine's registry. I know python is the worst thing I could use if I want something in Wine, but it should be good enough that I can try to import the information on the Linux end before spending too much time on something that may or may not ultimately be useful. -- Vincent Povirk

2 1

Wine components: gdiplus
by Evan Stade 08 Aug '07

08 Aug '07

Hi, Could we add gdiplus to the bugzilla components list? thanks. -- Evan Stade

1 0

Re: Rob Shearman : secur32: Split the NTLM credential and context handles into separate objects.
by Kai Blin 08 Aug '07

08 Aug '07

On Wednesday 08 August 2007 15:59:23 Alexandre Julliard wrote: > > secur32: Split the NTLM credential and context handles into separate > objects. > > This prevents races with two threads using the helper object at the same > time on two different context handles, eliminates the need to free the > credential handle after freeing the context handles and also prevents a Rob, thanks for cleaning up the mess. This looks more sane now. 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.

1 0

Re: user32: CallWindowProc[AW] for mismatched built-in winprocs should take into account if the window is Unicode (with testcase, fixes bug #9198)
by Alexandre Julliard 08 Aug '07

08 Aug '07

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > + hwnd = CreateWindowExW(0, classW, NULL, WS_OVERLAPPEDWINDOW, > + CW_USEDEFAULT, CW_USEDEFAULT, 680, 260, NULL, NULL, GetModuleHandleA(NULL), 0); > + ok(IsWindowUnicode(hwnd), "\n"); > + SetWindowLongPtrW(hwnd, GWLP_WNDPROC, (LONG_PTR)pDefWindowProcA); > + ok(IsWindowUnicode(hwnd), "\n"); > + ok(GetWindowLongPtrW(hwnd, GWLP_WNDPROC) == (LONG_PTR)pDefWindowProcW, "\n"); > + ok(GetWindowLongPtrA(hwnd, GWLP_WNDPROC) == (LONG_PTR)pDefWindowProcA, "\n"); > + SetWindowLongPtrA(hwnd, GWL_WNDPROC, (LONG_PTR)ClassTest_WndProc); > + ok(IsWindowUnicode(hwnd) == FALSE, "\n"); Please use meaningful error messages in the ok() calls. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Wine Kernel Handle Support Module
by Dan Kegel 08 Aug '07

08 Aug '07

keane wrote: > I am not sure if this is the direction that some people want to take, > because I am sure this modification of the IDT would be considered > improper by kernel types but come on, I mean i386 has something like > 200 software interrupts and linux uses only one. Do not anger the kernel gods, for they will not take your patch. You are putting the cart before the horse, If you want to use a kernel module, please figure out why first, and work on solving that problem using standard kernel idioms. Linus has said that he would take a patch to add support for win32 system calls if it solved a real problem. Albert Calahan mentioned a few possible benefits in a thread seven years ago: http://marc.info/?l=linux-kernel&m=96954760832002&w=2 You might dig around in that thread for ideas. - Dan

1 0

Re: programs/wineconsole: Correctly display chars 00..1F and 7F [try 2]
by Kirill K. Smirnov 08 Aug '07

08 Aug '07

Hi, Alexandre, > > > > Is there something wrong with my patch? Did I miss something important? > > I'm not at all convinced that the conversion has to happen at that > point. Do you have a test app that demonstrates this? I've written test application, which writes control chars and performs readback for comparision. It's behaviour heavily depends on console font: 1) True Type (lucida). Control chars are displayed as square boxes, ReadConsoleOutputCharacters[A|W] return codes [0..31]. 2) Raster (fixedsys). Control chars are correctly displayed as glyphs, ReadConsoleOutputCharacterA returns codes [0..31], ReadConsoleOutputCharacterW returns unicode glyphes. It seems I stumbled upon the same strange insane console behaviour I observed while working upon console codepages. (http://www.winehq.org/pipermail/wine-devel/2007-May/056511.html) Since wine renders fonts in his specific way (freetype, AFAIK), I propose the following: 1) Display control characters as glyphes. (like fixedsys). 2) ReadConsoleOutputCharacter[A|W] both should return characters without any corrupting - if I wrote [0..31] I expect [0..31], if I wrote unicode glyphes, I expect unicode glyphes to be returned. (like TrueType) My patch assumes this behaviour. Of course, I wanted to write proper wine test case, but it is impossible due to different default console fonts under Windows - test will fail. -- Kirill

1 0

Re: [kernel32/tests 2/2] Skip all tests if one W-function can't be found
by Paul Vriens 08 Aug '07

08 Aug '07

On 8/7/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > (Should be applied after "[kernel32/tests] Changed skip message"). > > There are to many W-functions called so skip everything if the first function is > not implemented. This makes the test not crash on win95/win98. > > Changelog > Skip all tests if one W-function can't be found > > Cheers, > > Paul > > > Don't use this one. I'll sent an easier fix. The "[kernel32/tests] Changed skip message" can still be applied though. Cheers, Paul.

1 0

← Newer
1
...
16
17
18
19
20
21
22
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel August 2007