- Wine-Devel - list.winehq.org

Re: NetUserEnum
by Vijay Kiran Kamuju Jan. 28, 2006

Jan. 28, 2006

Hi, If you could also post the FIXME message or the winedebug trace it would be helpful. It would help us to locate if its a regression or unimplemented case. Thanks, VJ On 1/28/06, suppandi <suppandi(a)gmail.com> wrote: > Hi, > > I was trying to run notes7 and it was crashing because NetUserEnum() was not > implemented. So i tried writing a simple implementation. Could anybody have > a look at this, and tell me whats wrong. Now notes just crashes without any > doc. unfortunately i amn't a windows programmer to write a simple program > to make the call. > > NetUserEnum(LPCWSTR servername, DWORD level, DWORD filter, LPBYTE* bufptr, > DWORD prefmaxlen, LPDWORD entriesread, LPDWORD totalentries, > LPDWORD resume_handle) > { > struct USER_INFO_20 > { > LPWSTR usri20_name; > LPWSTR usri20_full_name; > LPWSTR usri20_comment; > DWORD usri20_flags; > DWORD usri20_user_id; > }; > > switch(level) > { > case 20: > { > struct USER_INFO_20 *data; > char user[]={'t','e','s','t'}; > NetApiBufferAllocate(sizeof(struct USER_INFO_20), > (LPVOID *) bufptr); > data = (struct USER_INFO_20 *)malloc(sizeof(struct USER_INFO_20)); > data->usri20_name = (LPWSTR)malloc(20); > memcpy((void*)data->usri20_name,user,4); > data->usri20_full_name = (LPWSTR)malloc(20); > memcpy((void*)data->usri20_full_name,user,4); > data->usri20_comment = (LPWSTR)malloc(20); > memcpy((void*)data->usri20_comment,user,4); > data->usri20_flags = UF_NORMAL_ACCOUNT; > data->usri20_user_id = 1000; > *entriesread = *totalentries = 1; > return 0; > } > break; > default: > FIXME("(%s,%ld, 0x%ld,%p,%ld,%p,%p,%p) stub!\n", > debugstr_w(servername), level, > filter, bufptr, prefmaxlen, entriesread, totalentries, > resume_handle); > > return ERROR_ACCESS_DENIED; > break; > } > } > > > > >

1 0

setupapi: unimplemented function setupapi.dll.SetupPromptReboot
by Saulius Krasuckas Jan. 28, 2006

Jan. 28, 2006

I stuck upon this function right now. And I see ReactOS folks already have some implementation [*], but for some reason it is disabled. Is anyone working on this for Wine? Any ideas about the ReactOS code? [*] http://www.reactos.org/generated/doxygen/d4/d55/lib_2setupapi_2stubs_8c-sou…

3 8

Re: USER: creating 16bit windows convert null instances to current process (try #3, should work now)
by Joseph Garvin Jan. 28, 2006

Jan. 28, 2006

It's been a about a month since I sent this in and it still hasn't been applied. Is there something wrong with the patch? Joseph Garvin wrote: > Fixed up the patch according to Dmitry's suggestions :) > > Changelog > Fixed instance = 0 not converted to the current process when making a > window. Broke menus in some apps. (Thanks to Mike) > > >------------------------------------------------------------------------ > >--- dlls/user/win.c.1 2005-12-31 03:03:19.000000000 -0700 >+++ dlls/user/win.c 2006-01-01 01:02:43.000000000 -0700 >@@ -1145,6 +1145,18 @@ HWND16 WINAPI CreateWindowEx16( DWORD ex > cs.cx = (width == CW_USEDEFAULT16) ? CW_USEDEFAULT : (INT)width; > cs.cy = (height == CW_USEDEFAULT16) ? CW_USEDEFAULT : (INT)height; > >+ /* Correct if instance is null now, because later we won't >+ be able to tell the difference between a 16-bit NULL and >+ a 32-bit NULL */ >+ >+ if (!instance) >+ { >+ HTASK16 hTask = GetCurrentTask(); >+ TDB *tdb = GlobalLock16(hTask); >+ instance = tdb->hInstance; >+ GlobalUnlock16(hTask); >+ } >+ > /* Create the window */ > > cs.lpCreateParams = data; > > >------------------------------------------------------------------------ > > > >

1 0

Re: tape.c: remove bogus breaks
by Hans Leidekker Jan. 27, 2006

Jan. 27, 2006

On Friday 27 January 2006 22:13, Michael Stefaniuc wrote: > are those breaks realy supposed to be there? Smatch was complaining > about unreachable code. No, those breaks don't belong there, your patch is correct. -Hans

1 0

Re: opengl: Sync a dibsection to its pixmap before drawing to it via opengl
by Alexandre Julliard Jan. 27, 2006

Jan. 27, 2006

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > +void enter_gl(void) > +{ > + GLXContext gl_ctx; > + Wine_GLContext *ctx; > + enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; > + > + wine_tsx11_lock_ptr(); /* unlock in LEAVE_GL */ > + gl_ctx = glXGetCurrentContext(); > + if(!gl_ctx) return; > + ctx = get_context_from_GLXContext(gl_ctx); > + if(!ctx || GetObjectType(ctx->hdc) == OBJ_DC) > + return; > + > + ExtEscape(ctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); You cannot make GDI calls while holding the X11 lock, this will deadlock. -- Alexandre Julliard julliard(a)winehq.org

1 0

Global hooks problems (WH_MOUSE_LL)
by Vitaliy Margolen Jan. 27, 2006

Jan. 27, 2006

Trying to track down the problem with our DInput implementation I found some interesting stuff - our global hooks don't work correctly because hook callbacks are never called if event is generated in the different thread. I don't think this is a revelation to number of people who knew that before. But how do we fix it? Her is what I dug up so far: 1. Installing global hook we setting it as WINEVENT_INCONTEXT while msdn and tests indicate that it qualifies as WINEVENT_OUTOFCONTEXT instead. Unless of course we don't want to call post_win_event in step 5 and go to step 6 instead. 2. All HW mouse messages start here: http://source.winehq.org/source/dlls/x11drv/mouse.c#L191 From looking at it I assume that all the HW mouse hooks should be handled by HOOK_CallHooks function. This is because there are no code related to hooks in send_message server call. 3. First thing that HOOK_CallHooks does is calling HOOK_IsHooked with checks only current thread for installed hooks. So this is first place that is wrong. Let's comment that check out for now. I think we need to move that check farther down, after the call to server. 4. We call start_hook_chain http://source.winehq.org/source/server/hook.c#L468 to start hook callback chain. There we call get_first_valid_hook on local and then global if no local hooks exist. But there again we check for http://source.winehq.org/source/server/hook.c#L211 the hook callback thread being local (which is again not the case for global hooks). This is problem #2. 5. Now we have post_win_event of but right before it we hitting an assert so this is not the right way? 6. Say we returned with success and back to HOOK_CallHooks that now tries to call MSG_SendInternalMessageTimeout. Which for some reason fails to deliver message to our global hook. So my question is to anyone who knows. What is the proper way to deliver these messages to global hooks that are in a different thread/process? Attached is the small program to test part of this. Fixing problems (1) & (2) made it work. But it still not enough for the game (for some reason). Vitaliy

4 7

Progress on TiVo... but no cigar yet.
by Dan Kegel Jan. 27, 2006

Jan. 27, 2006

Last year, I tried installing Tivo Desktop 2.0, and it failed miserably: http://www.winehq.com/hypermail/wine-devel/2005/03/0406.html Prompted by a request in wine-users, I just tried installing both Tivo Desktop 1.3 (their win98-compatible version) and Tivo Desktop 2.2 (for winxp). 2.2 wouldn't install (it really wanted to install a service, and that didn't work) but 1.3 did install (with a bunch of warnings). Starting TivoPublisher.exe even puts up a GUI after warnings like this: fixme:win:EnumDisplayDevicesW ((null),0,0x7fb1f198,0x00000000), stub! fixme:win:LockWindowUpdate (0x10020), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:secur32:GetUserNameExA 3 0x7fb1f51c 0x7fb1f580 fixme:sync:CreateIoCompletionPort (0xf0, (nil), 7ec2b0dc, 00000000): stub. Unfortunately, the GUI is nonfunctional. (And kind of funny.) Starting TivoServer.exe doesn't work at all (it seems to want a service to be started). At least the installer doesn't crash like it did last year! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

LostWages: Status pages update #4
by Tom Wickline Jan. 26, 2006

Jan. 26, 2006

Hello, Tom Change log: fix security.dll documentation link

1 0

LoadImage (4bpp) / CopyImage() crashing
by Cyril Margorin Jan. 26, 2006

Jan. 26, 2006

Hello, During research the crashing application I've found a problem that can be easily reproduced by test. (http://www.winehq.org/pipermail/wine-patches/2005-November/022384.html) By investigation of problem I've found that original DIB bit depth is 4bpp, Physical pixmap bit depth is (equal to screen) 24bpp. In x11drv/bitmap.c X11_GetBitmapBits takes in account just only bit depth of physical pixmap, and copies it to provided buffer as-is. I.e. it tries to fill buffer with size (e.g.) 48x48x4bpp with 48x48x24bpp that causes buffer overrun and late falling in SetBitmapBits function. The current work-around to stop falling is Index: dlls/x11drv/bitmap.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/bitmap.c,v retrieving revision 1.18 diff -u -r1.18 bitmap.c --- dlls/x11drv/bitmap.c 26 Sep 2005 11:04:12 -0000 1.18 +++ dlls/x11drv/bitmap.c 25 Nov 2005 09:29:12 -0000 @@ -186,7 +186,19 @@ /* copy XImage to 16 bit padded image buffer with real bitsperpixel */ startline = buffer; - switch (physBitmap->pixmap_depth) + + /********************************************************************** + * CoMargo: the switching for physBitmap->pixmap_depth is not correct. + * It should take both physBitmap->pixmap_depth and bitmap.bmBitsPixel + * and convert from one bitdepth to another. + * Otherwise we meet buffer overrun. + */ + if(physBitmap->pixmap_depth != bitmap.bmBitsPixel) + { + FIXME("Pixel conversion from %d bitdepth to %d bitdepth MUST be done!\n",physBitmap->pixmap_depth,bitmap.bmBitsPixel); + } +/* switch (physBitmap->pixmap_depth) */ + switch(bitmap.bmBitsPixel) { case 1: for (h=0;h<height;h++) =================================================================== -- Cyril Margorin

6 15

Re: OLEAUT32: add additional condition for creation of interface
by Robert Shearman Jan. 26, 2006

Jan. 26, 2006

Alex Villacís Lasso wrote: >diff -ur wine-0.9.6-cvs/dlls/oleaut32/typelib.c wine-0.9.6-cvs-patch/dlls/oleaut32/typelib.c >--- wine-0.9.6-cvs/dlls/oleaut32/typelib.c 2006-01-16 16:08:20.000000000 -0500 >+++ wine-0.9.6-cvs-patch/dlls/oleaut32/typelib.c 2006-01-24 21:53:48.000000000 -0500 >@@ -5567,10 +5567,31 @@ > ITypeInfo_AddRef(*ppTInfo); > result = S_OK; > } >- else if (hRefType == -1 && >- (((ITypeInfoImpl*) This)->TypeAttr.typekind == TKIND_DISPATCH) && >- (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL)) >+ else if ( >+ ( >+ hRefType == -1 && >+ (This->TypeAttr.typekind == TKIND_DISPATCH) && >+ (This->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL) >+ ) >+ || >+ ( >+ (This->TypeAttr.typekind == TKIND_DISPATCH) && >+ (This->TypeAttr.wTypeFlags & TYPEFLAG_FDISPATCHABLE) >+ ) >+ ) > { >+ /* Report whether we are here because of the DBGRID32.OCX fix */ >+ if (!( >+ hRefType == -1 && >+ (This->TypeAttr.typekind == TKIND_DISPATCH) && >+ (This->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL) >+ )) >+ { >+ FIXME("ignoring hRefType = %d, TYPEFLAG_FDISPATCHABLE is %s\n", >+ hRefType, >+ (This->TypeAttr.wTypeFlags & TYPEFLAG_FDISPATCHABLE) ? "set" : "not set"); >+ } >+ > /* when we meet a DUAL dispinterface, we must create the interface > * version of it. > */ > > This doesn't look right to me. We need tests for this situation that will tell us whether we are adding a dirty hack or whether this behaviour is correct. I can send you a test suite I have already built for typelibs if you want to add to it. >@@ -5598,8 +5619,47 @@ > if(pRefType->reference == hRefType) > break; > } >- if(!pRefType) >- FIXME("Can't find pRefType for ref %lx\n", hRefType); >+ if(!pRefType) { >+ static const char * descTKIND[TKIND_MAX] = { >+ "TKIND_ENUM", >+ "TKIND_RECORD", >+ "TKIND_MODULE", >+ "TKIND_INTERFACE", >+ "TKIND_DISPATCH", >+ "TKIND_COCLASS", >+ "TKIND_ALIAS", >+ "TKIND_UNION", >+ }; >+ static const char * descTypeFlags[15] = { >+ "TYPEFLAG_FAPPOBJECT", >+ "TYPEFLAG_FCANCREATE", >+ "TYPEFLAG_FLICENSED", >+ "TYPEFLAG_FPREDECLID", >+ "TYPEFLAG_FHIDDEN", >+ "TYPEFLAG_FCONTROL", >+ "TYPEFLAG_FDUAL", >+ "TYPEFLAG_FNONEXTENSIBLE", >+ "TYPEFLAG_FOLEAUTOMATION", >+ "TYPEFLAG_FRESTRICTED", >+ "TYPEFLAG_FAGGREGATABLE", >+ "TYPEFLAG_FREPLACEABLE", >+ "TYPEFLAG_FDISPATCHABLE", >+ "TYPEFLAG_FREVERSEBIND", >+ "TYPEFLAG_FPROXY", >+ }; >+ int i; >+ >+ FIXME("Can't find pRefType for ref %lx\n", hRefType); >+ FIXME("\ttypekind is %s\n", descTKIND[This->TypeAttr.typekind]); >+ FIXME("\twTypeFlags are:"); >+ for (i = 0; i < 15; i++) { >+ if (This->TypeAttr.wTypeFlags & (1 << i)) >+ FIXME(" %s", descTypeFlags[i]); >+ } >+ if (This->TypeAttr.wTypeFlags & 0xFFFF8000) >+ FIXME(" %08x", This->TypeAttr.wTypeFlags & 0xFFFF8000); >+ FIXME("\n"); >+ } > if(pRefType && hRefType != -1) { > ITypeLib *pTLib = NULL; > > This clutters the code too much. There are already functions for dumping the typelib that would work here instead, although I think they don't use the FIXME channel. -- Rob Shearman

2 1