August 2008 - Wine-devel - list.winehq.org

Re: Is Wine portable to ARM arch?
by James Mckenzie 08 Aug '08

08 Aug '08

Tomasz Czapiewski <xeros(a)irc.pl> on Aug 8, 2008 10:05 AM (PNT) wrote about Is Wine portable to ARM arch? > >I wonder if someone has done successfull port of Wine for >mobile/PDA Linux distributions on hardware with ARM processors. No. >Is it possible? Very likely but you run into the following: 1. Windows programs are written for the x86 processor. Is there an x86 emulator for the ARM arch? 2. Windows programs are mostly written for a minimum of a 640 by 480 pixel display. I know of very few devices that run at that, or higher, resolution. 3. Are the ARM processors 'strong' enough to run both a x86 emulator AND Wine AND provide acceptable performance of many Windows programs. >If no then are there any plans for multiplatform code in Wine? NO! Even MacOSX specific code is not allowed >There are many Linux users of such hardware (like Neo FreeRunner etc.) >which would like to use Windows applications on their portable >ARM-based devices. Don't know. Most functions are provided by other systems. I know that Windows CE (aka Portable Windows) does exist for some handheld devices. The key is to get folks to write software for that platform. My point three above shows why Wine is written, mostly, for x86 devices. It would be nice to see Wine ported to other platforms. Technically, this is possible, however would it provide satisfactory performance as well is key to user satisfaction. James McKenzie

8 7

Re: Is Wine portable to ARM arch?
by James Mckenzie 08 Aug '08

08 Aug '08

Lei Zhang <thestig(a)google.com> on Aug 8, 2008 10:58 AM (PNT) wrote about Is Wine portable to ARM arch? > >On Fri, Aug 8, 2008 at 10:39 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> NO! Even MacOSX specific code is not allowed > >grep -rI __APPLE__ wine-git/ | wc -l >returns 68. Correct, there is code that will only be used on when the system is an Apple (Mac). However, Mac specific code, such as ObjC code is not allowed per Alexandre. James McKenzie

4 5

Re: taskmgr [try 3]: Converted some functions and variables to Unicode [1/12]
by Nikolay Sivov 08 Aug '08

08 Aug '08

Vladimir Pankratov wrote: > - GetLastErrorText(strErrorText, 260); > + GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); The same as of try2. You changed argument type in patch 1/12 but function GetLastErrorText will change later in 12/12. So patches in series aren't not independent now cause after applying first you'll get broken GetLastErrorText call till you applied the last (12th). Changing call and a function should be placed in a single path.

1 0

re: Patch checking robot coming
by Dan Kegel 08 Aug '08

08 Aug '08

Ambroz wrote: > To me, a script that builds just > every patch is a serious security flaw; I suppose it wouldn't > be very hard for someone to send a naughty patch > that would take control of your machine. True. > I suggest you make it build patches in a chroot > as a regular user, and copy over the chroot from a > template every time a new patch is being built. Sounds great. Want to implement that and send it my way? It'll take me a while to get the kinks worked out of the script, it'd be nice to have a hand with the chroot. - Dan

5 10

Re: user32: Add tests and fix for the edit control parent notification
by Dmitry Timoshkov 08 Aug '08

08 Aug '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > - /* why do we notify to es->hwndParent, and we send this one to GetParent()? */ > - hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > + /* We must send all notifies to es->hwndParent. > + * If es->hwndParent don't response, we call > + * DefWindowProcW of the current parent. > + */ > + > + hbrush = (HBRUSH)SendMessageW(es->hwndParent, msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > if (!hbrush) > hbrush = (HBRUSH)DefWindowProcW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > return hbrush; If you have changed the target in the SendMessage call, shouldn't you do the same for DefWindowProc? > + SendMessage( hwEdit, WM_PAINT, (WPARAM)GetDC( hwEdit ), 0 ); > + syscolor = GetPixel( GetDC( hwEdit ), PIXEL_X, PIXEL_Y ); > + > + SetParent( hwEdit, hwParent2 ); > + DestroyWindow( hwParent1 ); > + > + SendMessage( hwEdit, WM_PAINT, (WPARAM)GetDC( hwEdit ), 0 ); > + editcolor = GetPixel( GetDC( hwEdit ), PIXEL_X, PIXEL_Y ); > + > + ok( editcolor == syscolor, "Child color is wrong, child = %04x\n", editcolor ); > + > + DestroyWindow( hwEdit ); > + DestroyWindow( hwParent2 ); > +} You are leaking a DC in the test. From your fix it looks like you need to test the message sequences instead of the pixel color (which is not reliable). Same applies to your other patch. -- Dmitry.

1 0

Re: user32: DdeClientTransaction should return 0 in the last param forDDE_DATA
by Dmitry Timoshkov 08 Aug '08

08 Aug '08

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > --- a/dlls/user32/dde_client.c > +++ b/dlls/user32/dde_client.c > @@ -520,6 +520,7 @@ static WDML_QUEUE_STATE WDML_HandleRequestReply(WDML_CONV* pConv, MSG* msg, WDML > case WM_DDE_DATA: > UnpackDDElParam(WM_DDE_DATA, msg->lParam, &uiLo, &uiHi); > TRACE("Got the result (%08lx)\n", uiLo); > + if (ack) *ack = ERROR_SUCCESS; > > hsz = WDML_MakeHszFromAtom(pConv->instance, uiHi); > > diff --git a/dlls/user32/tests/dde.c b/dlls/user32/tests/dde.c > index 8ea0525..debbd20 100644 > --- a/dlls/user32/tests/dde.c > +++ b/dlls/user32/tests/dde.c > @@ -292,10 +292,7 @@ static void test_ddeml_client(void) > hdata = DdeClientTransaction(NULL, 0, conversation, item, CF_TEXT, XTYP_REQUEST, default_timeout, &res); > ret = DdeGetLastError(client_pid); > ok(ret == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", ret); > - todo_wine > - { > - ok(res == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %08x\n", res); > - } > + ok(res == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %08x\n", res); DdeClientTransaction is not supposed to return ERROR_SUCCESS in res. DDE_FNOTPROCESSED looks like a more appropriate value. Same for DdeGetLastError, DMLERR_NO_ERROR seems more reasonable in this case. Also IMO a more appropriate place to set ack to DDE_FNOTPROCESSED is WDML_HandleReply, so that all types of replies get covered. -- Dmitry.

2 5

Re: advapi32: Implement GetSecurityInfo. [take 3]
by Juan Lang 08 Aug '08

08 Aug '08

Hi Dan, + if (ppSecurityDescriptor) + *ppSecurityDescriptor = sd; + you leak sd in the (implicit) else block here. --Juan

3 6

Re: [TRY2]user32/tests: add tests for creating subclassed builtinclass windows
by Dmitry Timoshkov 08 Aug '08

08 Aug '08

"Hongbo Ni" <hongbo(a)njstar.com> wrote: > +static void test_builtin_class_subclassed(char *classA, WCHAR *classW); It is possible to avoid forward declarations by a proper function rearranging. Also please add 'const' to classA/W. > + > +static void test_all_builtin_classes_subclassed(void) > +{ > + int i, n, len; > + WCHAR classW[80]; 10 should be enough. > + CHAR *BUILTIN_CLASSES[MAX_BUILTIN_CLASSES] = { 'static const CHAR BUILTIN_CLASSES[][10]' as in the existing test would be better IMO. > + "Edit", > + "Button", > + "Static", > + "ComboBox", > + "ComboLBox", > + "ListBox", > + "#32770", /* dialog */ > + }; You forgot "ScrollBar" and some other builtin classes. > + > + for(i = 0; i < MAX_BUILTIN_CLASSES; i++) > + { > + len = strlen(BUILTIN_CLASSES[i]); > + for(n = 0; n < len; n++) classW[n] = BUILTIN_CLASSES[i][n]; > + classW[n] = 0; MultiByteToWideChar would be more appropriate here. > + test_builtin_class_subclassed(BUILTIN_CLASSES[i], classW); > + } > +} > + > +static void test_builtin_class_subclassed(char *classA, WCHAR *classW) > +{ > + HWND hwnd, hwnd2; > + WNDPROC oldproc; > + > + hwnd = CreateWindowExA(0, classA, NULL, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, > + CW_USEDEFAULT, 680, 260, NULL, NULL, NULL, 0); It would be helpful to actually test whether window has been created, and what type it has (ansi/unicode). Same is true for all similar cases. Otherwise the test looks good, and it passes for me under XP SP3. -- Dmitry.

2 1

Re: [8/11] ole32 : basic inprocess handler implentation
by Alistair Leslie-Hughes 07 Aug '08

07 Aug '08

<f.dorin(a)free.fr> wrote in message news:146439758.2397291218116816278.JavaMail.root(a)spooler1-g27.priv.proxad…...> Modify the stub implementation of GetDestCtx, to "emulate" a local machine instead of a remote machine. This trick is needed to allow handle marshalling > + *pdwDestContext = MSHCTX_NOSHAREDMEM; //MSHCTX_DIFFERENTMACHINE;> c++ style comments are discouraged. Best Regards Alistair Leslie-Huges _________________________________________________________________ Shout your Messenger buddies to the movies http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4590

1 0

Re: Make RegisterDeviceNotificationW behave like RegisterDeviceNotificationA
by Zachary Goldberg 07 Aug '08

07 Aug '08

On 8/6/08, Martin Profittlich <martin.profittlich(a)gmx.de> wrote: > Hello! > > This patch fixes bug 14781 (http://bugs.winehq.org/show_bug.cgi?id=14781) > > Some Native Instruments apps like Kontakt 3 and Kore Player crash on startup, shortly after calling RegisterDeviceNotificationW(). This stub currently returns a 0 for failure. RegisterDeviceNotificationA() otoh returns a fake handle. This patch makes RegisterDeviceNotificationW() do this also. This makes both apps work. > > This is my first submission. Please let me know if the format is wrong or some important information is missing. > > Martin > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser > > > > > Martin, Your patch is more likely to be accepted if it comes with a test which works on windows, didnt pass in wine before but passes now and demonstrates why the new behavior is correct. --Zach

2 1