August 2007 - Wine-Devel - list.winehq.org

Re: Wine Kernel Handle Support Module

by Marcus Meissner

On Wed, Aug 08, 2007 at 01:10:08PM -0400, Kuba Ober wrote: > > > 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. > > > > The first question is: > > Why do you want to do that and what specifically do > > you want to achieve? > > A small step towards less overhead in client <-> server calls? We did other optimizations towards that goal already. Any testcases that show slow down? Ciao, Marcus

Aug. 8, 2007

Re: exporting file associations for linux desktops

by Steven Edwards

On 8/8/07, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > 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. It sounds to me something like winemenubuilder should be extended to register the mimetype when a new extension is registered in Wine. I mean I think it would be safe to assume if a user installs application foo under Wine then they would want application foo to be able to be used from the Linux Desktop via the menutype. Maybe another tab should be added to winecfg to manage mimetypes that are handled by wine. -- 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

Aug. 8, 2007

Wine components: gdiplus

by Evan Stade

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

Aug. 8, 2007

Re: Wine Kernel Handle Support Module

by Kuba Ober

> > 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. > > The first question is: > Why do you want to do that and what specifically do > you want to achieve? A small step towards less overhead in client <-> server calls? Cheers, Kuba

Aug. 8, 2007

Re: Rob Shearman : secur32: Split the NTLM credential and context handles into separate objects.

by Kai Blin

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.

Aug. 8, 2007

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

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

Aug. 8, 2007

[SNMPAPI] How to fix the tests for win98 and NT4?

by Paul Vriens

Hi, There are several functions in the util.c test that are not available on win98 and NT4. That can be dealt with easily. Almost all tests with a NULL parameter crash on win98/NT4. I know that a few weeks back we talked about ignoring win98 if it would mean skipping a lot of tests, but now NT4 is involved as well. I could introduce a variable of course that's set when we are on NT4 or lower (because of the missing functions) and don't run the 'NULL' tests. Any ideas, comments? Cheers, Paul.

Aug. 8, 2007

re: Wine Kernel Handle Support Module

by Dan Kegel

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

Aug. 8, 2007

Re: programs/wineconsole: Correctly display chars 00..1F and 7F [try 2]

by Kirill K. Smirnov

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

Aug. 8, 2007

exporting file associations for linux desktops

by Vincent Povirk

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

Aug. 8, 2007