March 2008 - Wine-Devel - list.winehq.org

Control-panel app. Works with mingw, need help with winegcc

by pure_evil＠mail.bg

Okay, this is as far as apparently I can make it on my own. This is the *basic* control panel applet. I used Dev-c++ (it's C though). It compiles with mingw and works flawlessly - you know, exports what it should export etc. etc. etc. The result, copied onto c:\windows\system32 shows up in the control panel and launches Notepad. However, I can't for the life of me get it to compile with winegcc (skip the usual "throw out "inlude windows.h" and insert "cpl.h"..." THEN it gets hairier). Help?

March 31, 2008

translation

by Lorenzo M

do u need an italian translator for your wiki/documentation? i can do it properly. u doin very nice job. thanks from a satisfied user. bye -- ¤ acM ¤ Lorenzo M

March 31, 2008

Re: setupapi: prevent page faults in SetupDiDeleteDeviceInterfaceRegKey

by Christopher

wine-devel-request(a)winehq.org wrote: > Message: 4 Date: Sun, 30 Mar 2008 19:13:46 -0600 From: Vitaliy > Margolen <wine-devel(a)kievinfo.com> Subject: Re: setupapi: prevent page > faults in SetupDiDeleteDeviceInterfaceRegKey To: wine-devel(a)winehq.org > Message-ID: <47F03ACA.5010308(a)kievinfo.com> Content-Type: text/plain; > charset=ISO-8859-1; format=flowed Christopher wrote: >> > Changelog: >> > Check that the handle and pointer passed to >> > SetupDiDeleteDeviceInterfaceRegKey are valid to read from. This patch >> > continues to address bug #12242 >> > >> > - if (!DeviceInterfaceData || >> > + if (!DeviceInterfaceData || IsBadReadPtr(DeviceInterfaceData, sizeof(SP_DEVICE_INTERFACE_DATA)) || >> > > Don't ever use IsBadReadPtr and IsBadWritePtr functions. They are bad and > even MS stopped using them. You have to use TRY-EXCEPT block around an > access to the memory. For example see implementation of lstrcpyA > (kernel32/string.c: 359). > > >> > + ok(!ret && GetLastError() == ERROR_INVALID_HANDLE, "Expected SetupDiDeleteDeviceInterfaceRegKey to return FALSE, got %s, \ >> > +with error code: 6, got %d\n", ret ? "TRUE" : "FALSE", GetLastError()); >> > > This is bad way to split strings in c. Do something like this: > > ok(!ret && GetLastError() == ERROR_INVALID_HANDLE, > "Expected SetupDiDeleteDeviceInterfaceRegKey to return FALSE, got %s, " > "with error code: 6, got %d\n", ret ? "TRUE" : "FALSE", GetLastError()); > > Vitaliy. Thanks for the comments! I found that Alexander Morozov's patches fix the same issue my patch was aimed at. After his are committed, I'll fix and resubmit mine if it's needed. Christopher Berner

March 31, 2008

Re: winex11.drv: Don't add owned windows to the taskbar

by Alex Villacís Lasso

Dmitry Timoshkov escribió: > "Alex Villacís Lasso" <a_villacis(a)palosanto.com> wrote: > > >>> The problem with IDA is that the button you see in the Windows task bar >>> does not belong to the main IDA window, it belongs to a zero sized visible >>> window with the same caption. Since it's zero sized Wine doesn't map it all. >>> So, while formally it's a regression, technically it's not: main IDA window >>> has never been added to the task bar before my patch. This all can be easily >>> discovered with spy++ and a simple test app. >>> >>> >>> >> This also affects many, if not all, VB6 applications (and possibly many >> Delphi applications). Personally, I consider this a rather serious >> regression and propose backing out of commit >> cb3ff54789c652b02d852f40db71cafd9fd67ca9 as a fix. >> >> BTW, this reminds me of bug 1598. If the explanation of the bug for IDA >> above is correct, then the "buggy" behavior of not assigning >> minimize/maximize buttons to the window that appears in the panel is >> sort of consistent with this regression. Maybe the behavior should be >> that visible windows owned by an invisible window should get mapped in >> the panel. >> > > 1598 is closed as fixed, and I have no idea how missing minimize/maximize > buttons are related to owned windows, and why you think that it's somehow > related to the visibility of an owner. > > What you need to be fixed is making a zero sized window with WS_VISIBLE > style set mapped, but X11/WMs doesn't handle that gracefully. > > Bug 1598 (even if closed and fixed) is relevant because it was also triggered by having an invisible owner window, as my own analysis in comment #16 suggested. This bug (1598) also made the window button disappear from the taskbar, with the same application that now exhibited the regression. I was just preparing a patch to fix this very issue over the weekend, but it seems Jacek Caban beat me to it. I am currently recompiling my tree to test the patch. -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

March 31, 2008

Re: Some considerations about the Wine FUSE project for GSoC

by Kai Blin

On Monday 31 March 2008 15:30:17 Marc Andre Tanner wrote: > First, I haven't yet applied for the project mainly because i will > probably not be able to work full time on a GSoC project due to real > life issues (part time job, family related things etc). On the other > hand I doubt that it will require ~3 months to implement, I have done > my prototype over more or less a weekend. That's why there's more than one FUSE file systems on the list ;) > I miss the technical discussion on how the problem should be solved. I > think the idea of keeping the original filename in an extended attribute > and storing everything in lower case is a pretty good one. Andrew > Tridgell also listed it on one of his slides from WineConf05 [1]. The tricky part is convincing Alexandre Julliard, as always when working on Wine. > I > prototyped something and thought this way I would at least get some > feedback (after all "Talk is cheap. Show me the code." is common > practice in the open source world). But this wasn't really the > case, so i am still wondering what should be done differently? Whoops, I didn't see that url. Sorry, but things were a bit busy recently. I'll give that a whirl later today. 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.

March 31, 2008

Re: shell32: implement SHGetFolderPathAndSubDirA/W [2nd resend]

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + if (pszSubPath && (length = MultiByteToWideChar(CP_ACP, 0, pszSubPath, -1, NULL, 0))) { > + pszSubPathW = HeapAlloc(GetProcessHeap(), 0, length * sizeof(WCHAR)); > + if(!pszSubPathW) > + return HRESULT_FROM_WIN32(ERROR_NOT_ENOUGH_MEMORY); You are leaking memory on error. Also I don't think it makes sense to test the return value of MultiByteToWideChar, it shouldn't fail in this case (or if you test it, then you need to handle the error properly, not use an empty path instead). -- Alexandre Julliard julliard(a)winehq.org

March 31, 2008

Re: GdipGraphicsClear function implementation and tests

by Alexandre Julliard

"Gynvael Coldwind" <gynvael(a)vexillium.org> writes: > + /* get width and height > + */ > + width = GetDeviceCaps(graphics->hdc, HORZRES); > + height = GetDeviceCaps(graphics->hdc, VERTRES); This won't do what you want. You should probably use something like GetClipBox() here. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2008

Re: [PATCH 2/2] winex11drv: Distinguish left and right keys for shift, ctrl and alt. (try 5)

by Alexandre Julliard

Vitaliy <vitaliy(a)kievinfo.com> writes: > Resending. > > Try 5: > Split out change to user32 as a separate patch. > > Try 4: > This time with lots of tests that exposed number of other problems that were fixed. > > I could not separate this patch into separate pieces - they all linked together and > fixing one problem meant fixing or breaking something else. The message tests don't work: ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so input.c && touch input.ok input.c:755: Test failed: a2/2: the msg sequence is not complete: expected 0000 - actual 000f make: *** [input.ok] Error 1 You most likely need to ignore all non-key messages. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2008

Re: user32: Implement BroadcastSystemMessage, try 5.1

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > But that's the thing. How can you definitively say that there isn't a > program that affected by this? Of course you can never be certain, but after having debugged a number of apps, and checked the behavior of APIs across Windows versions, there are things that you know do matter, and things that don't; and the last error behavior on success is definitely in the latter category. Yes, I'm sure someone someday can find a case where some specific app depends on some specific function to handle last error in a different way; but there's no reason to believe that BroadcastSystemMessage is more likely to trigger that bug than any other of the 10,000 functions that touch last error. So we either wait until we find an app that depends on this and fix the one offending function, or we spend months adding ugly code to every single API; adding the ugly code to only a handful of randomly chosen functions doesn't make any sense. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2008

Re: Some considerations about the Wine FUSE project for GSoC

by Marc Andre Tanner

Kai Blin wrote: > Hi folks, > > after another chat about Wine's goals in respect to FUSE file systems on IRC, > I just wanted to point the students who applied for this project already > (I've Bcced them) at the goals Wine has for this GSoC project. > > For Wine, the goal is to create prototype FUSE file systems so we can figure > out if this approach is useful to Wine at all. There is no immediate goal to > include the file systems into Wine in the near future, we first want to know > if they're what we need. First, I haven't yet applied for the project mainly because i will probably not be able to work full time on a GSoC project due to real life issues (part time job, family related things etc). On the other hand I doubt that it will require ~3 months to implement, I have done my prototype over more or less a weekend. I miss the technical discussion on how the problem should be solved. I think the idea of keeping the original filename in an extended attribute and storing everything in lower case is a pretty good one. Andrew Tridgell also listed it on one of his slides from WineConf05 [1]. I prototyped something and thought this way I would at least get some feedback (after all "Talk is cheap. Show me the code." is common practice in the open source world). But this wasn't really the case, so i am still wondering what should be done differently? Regards, Marc [1]http://us5.samba.org/samba/ftp/slides/tridge_wineconf05.pdf (page 18) -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0

March 31, 2008