wine-devel January 2003

wine-devel@winehq.org

151 participants
377 discussions

Re: more HEAP_strdupAtoW removals
by Rolf Kalbermatter 23 Jan '03

23 Jan '03

Matthew Davison <m.davison(a)virgin.net> wrote: >On Thu, 2003-01-23 at 01:36, Dmitry Timoshkov wrote: >> > @@ -760,24 +774,26 @@ >> > BOOL WINAPI OpenPrinterA(LPSTR lpPrinterName,HANDLE *phPrinter, >> > LPPRINTER_DEFAULTSA pDefault) >> > { >> > - LPWSTR lpPrinterNameW = HEAP_strdupAtoW(GetProcessHeap(),0,lpPrinterName); >> > + UNICODE_STRING lpPrinterNameW; >> > + UNICODE_STRING usBuffer; >> > + RtlCreateUnicodeStringFromAsciiz(&lpPrinterNameW,lpPrinterName); >> > PRINTER_DEFAULTSW DefaultW, *pDefaultW = NULL; >> > BOOL ret; > >> Are you sure that mixed data declarations/function call will be accepted >> by any C compiler out there? I doubt that even gcc will accept this. >well, im pretty sure gcc takes this, but ill change it anyway. >thanks. And I can tell you that Visual C is happy to compile this if the file has a .cpp ending but will bark for .c files ;-(. Rolf Kalbermatter

1 0

LockFile support
by David D. Hagood 23 Jan '03

23 Jan '03

I have an old, nasty application that uses the Paradox database engine. This app attempts to lock the database files using LockFile. Now, it USED to work under Wine. It no longer does. The program coughs up an error "No access to directory", and stderr shows a bunch of "LockFile not supported in server" errors. Did the behavior of LockFile change in the past couple of months? Are there plans to add LockFile support into Wine?

2 1

Re: more HEAP_strdupAtoW removals.
by Dmitry Timoshkov 23 Jan '03

23 Jan '03

"Matthew Davison" <m.davison(a)virgin.net> wrote: > Changelog > Remove some more calls to HEAP_strdupWtoA First of all, thanks for doing this! > @@ -554,7 +555,11 @@ > lpwstr = NULL; > for(i=0; i<dwNumServiceArgs; i++) > - lpwstr[i]=HEAP_strdupAtoW(GetProcessHeap(), 0, lpServiceArgVectors[i]); > + { > + RtlCreateUnicodeStringFromAsciiz (&usBuffer,lpServiceArgVectors[i]); > + lpwstr[i]=usBuffer.Buffer; > + RtlFreeUnicodeString(&usBuffer); > + } Of course this is a typo and last RtlFreeUnicodeString should be removed. > @@ -760,24 +774,26 @@ > BOOL WINAPI OpenPrinterA(LPSTR lpPrinterName,HANDLE *phPrinter, > LPPRINTER_DEFAULTSA pDefault) > { > - LPWSTR lpPrinterNameW = HEAP_strdupAtoW(GetProcessHeap(),0,lpPrinterName); > + UNICODE_STRING lpPrinterNameW; > + UNICODE_STRING usBuffer; > + RtlCreateUnicodeStringFromAsciiz(&lpPrinterNameW,lpPrinterName); > PRINTER_DEFAULTSW DefaultW, *pDefaultW = NULL; > BOOL ret; Are you sure that mixed data declarations/function call will be accepted by any C compiler out there? I doubt that even gcc will accept this. -- Dmitry.

2 1

Installshield 6 crash: ole trouble
by Dan Kegel 23 Jan '03

23 Jan '03

So, how's that Installshield 6 support coming along? :-) The company I work for uses Installshield to package up its windows stuff. Today I tried running its installer under cvs Wine, and shortly after it started running IKernel.exe, it dropped me into the wine debugger. Copying and pasting from the wine debugger window is beyond me; it seems totally broken. However, it looks like it was complaining of a null pointer read. Here are the last few interesting lines of the wine log: trace:ole:ITypeInfo_fnGetTypeAttr (0x40298e58) trace:ole:ITypeInfo_fnGetRefTypeOfImplType (0x40298e58) index 0 trace:ole:dump_TypeInfo 0x40298e58 ref=2 trace:ole:dump_TypeInfo attr:{91814ec1-b5f0-11d2-80b9-00104b1f6cea} trace:ole:dump_TypeInfo kind:TKIND_INTERFACE trace:ole:dump_TypeInfo fct:13 var:0 impl:1 trace:ole:dump_TypeInfo parent tlb:0x4026c9c8 index in TLB:28 trace:ole:dump_TypeInfo L"ISetupCABFile" (null) trace:ole:ITypeInfo_fnGetRefTypeOfImplType -- 0x00000000 trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded 080761c8:Call ntdll.RtlUnicodeToMultiByteSize(40791ac8,40791ae4 L"stdole32.tlb",0000001a) ret=409e78c8 080761c8:Call kernel32.MultiByteToWideChar(00000000,00000001,40791cf8 "stdole32.tlb",0000000d,00000000,00000000) ret=40b9e285 080761c8:Call kernel32.MultiByteToWideChar(00000000,00000001,40791cf8 "stdole32.tlb",0000000d,4028bfdc,0000000d) ret=40b9e2a8 trace:ole:LoadTypeLib trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x40791f2c) 080761c8:Call kernel32.SearchPathW(00000000,4028bfdc L"stdole32.tlb",00000000,00000105,40791cac,00000000) ret=40b9e41a trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load FAILED ((nil)) trace:ole:LoadTypeLib trace:ole:LoadTypeLibEx (L"C:\\WINNT\\System32\\StdOle32.tlb",0,0x40791f2c) trace:ole:ITypeInfo_fnGetRefTypeInfo (0x40298e58) hreftype 0x0000 loaded FAILURE (0x13) fixme:ole:_get_funcdesc Did not find a typeinfo for reftype 0? fixme:ole:PSFacBuf_CreateProxy GetFuncDesc 80004005 should not fail here. fixme:ole:StdMarshalImpl_UnmarshalInterface Failed to create a proxy for {91814ec1-b5f0-11d2-80b9-00104b1f6cea} fixme:ole:CoUnmarshalInterface Failed to Unmarshal the interface, 80004005? 080761c8:Ret ole32.CoUnmarshalInterface() retval=80004005 ret=40b9a2fd fixme:ole:_unmarshal_interface Marshaling interface {91814ec1-b5f0-11d2-80b9-00104b1f6cea} failed with 80004005 fixme:ole:deserialize_param failed to stuballoc in TKIND_RECORD. trace:ole:ITypeInfo_fnRelease (0x40279798)->(1) fixme:ole:xCall Failed to unmarshall param, hres 80004005 wine: Unhandled exception, starting debugger... Any suggestions? I am a babe in the woods when it comes to the wine debugger, or for that matter, ole. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

10 19

Re: PATCH: Adds my name to the AUTHORS list
by Shachar Shemesh 23 Jan '03

23 Jan '03

Waldeck Schutzer wrote: > Now that my patches were incorporated to the tree, it would make me > feel happier if my name was listed too :-) > > Best, > Waldeck I think it's time Alexander regenerates the entire Authors list. People want the credit, Alexander. There is a script in "tools" that does something, but I think it only alphabetizes the list, it does not actually add names. Shachar

5 4

[Fwd: dead keys treatment using XmbLookupString]
by Mauro Carvalho Chehab 23 Jan '03

23 Jan '03

Rikki, Please try to apply the following patch against the new CVS version (on /dlls/x11drv directory). This patch will allow keyboard.c to use your locale setting by the usage of xkb extension on X11R6. Please notice that this requires that you *don't have* xkbdisable on your XF86Config file (or XF86Config-4). -------- Original Message -------- Subject: dead keys treatment using XmbLookupString Date: Wed, 08 Jan 2003 12:48:06 -0200 From: Mauro Carvalho Chehab <mchehab(a)brturbo.com> To: wine-patches(a)winehq.com *Modifyied files*: keyboard.c window.c desktop.c *CVS Version*: 20021225 *Change Log: *Add dead key support using XmbLookupString on ToUnicode function, if *xkb* is available otherwise It falls back to the old code. The first Window will be used to define the XIC used by the functions. * Author*: Mauro Carvalho Chehab <mchehab(a)brturbo.com> ______________________________________________________________________________________________ --- keyboard.c 8 Jan 2003 11:24:51 -0000 1.1 +++ keyboard.c 8 Jan 2003 14:30:53 -0000 @@ -1389,6 +1389,44 @@ wine_tsx11_unlock(); } +#ifdef HAVE_XKB +static XIM xim = (XIM) NULL; +static XIC xic = (XIC) NULL; +#endif +/******************************************************************* + * KeyboardWindow (X11DRV.@) + * Called from desktop.c and window.c after Window creating + * This routine allows usage of XmbLookupString by ToUnicode. + * Only the first opened window will be used. It means that + * all windows will share the same locale. + * + */ +void X11DRV_KeyboardWindow (Display *display, Window w) +{ +#ifdef HAVE_XKB + char *p; + + if (xic) return; /* Only the first window will be used */ + + if ((p = XSetLocaleModifiers("")) != NULL && *p) + xim = XOpenIM(display, NULL, NULL, NULL); + if (!xim && (p = XSetLocaleModifiers("@im=none")) != NULL && *p) + xim = XOpenIM(display, NULL, NULL, NULL); + if (!xim) ERR_(key)( "Failed to open input method.\n"); + else { + xic = XCreateIC(xim, + XNInputStyle, XIMPreeditNothing | XIMStatusNothing, + XNClientWindow, w, + XNFocusWindow, w, + NULL); + if (!xic) { + ERR_(key)( "Failed to create input context.\n"); + XCloseIM(xim); + xim=NULL; + } + } +#endif +} /*********************************************************************** * X11DRV_MappingNotify @@ -1741,6 +1779,7 @@ * FIXME : should do the above (return 2 for non matching deadchar+char combinations) * */ + INT X11DRV_ToUnicode(UINT virtKey, UINT scanCode, LPBYTE lpKeyState, LPWSTR bufW, int bufW_size, UINT flags) { @@ -1756,6 +1795,9 @@ TRACE("Key UP, doing nothing\n" ); return 0; } + memset (&e,0,sizeof(e)); + + e.type = KeyPress; e.display = display; e.keycode = 0; e.state = 0; @@ -1814,7 +1856,15 @@ } else TRACE("Found keycode %d (0x%2X)\n",e.keycode,e.keycode); - ret = XLookupString(&e, (LPVOID)lpChar, 2, &keysym, NULL); +#ifdef HAVE_XKB + if (xic) { + ret = XmbLookupString(xic,&e, (LPVOID)lpChar, sizeof(lpChar), &keysym, NULL); + } else { + ret = XLookupString(&e, (LPVOID)lpChar, sizeof(lpChar), &keysym, NULL); + } +#else + ret = XLookupString(&e, (LPVOID)lpChar, sizeof(lpChar), &keysym, NULL); +#endif wine_tsx11_unlock(); if (ret == 0) --- window.c 8 Jan 2003 11:24:51 -0000 1.1 +++ window.c 8 Jan 2003 14:30:53 -0000 @@ -43,6 +43,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(x11drv); extern Pixmap X11DRV_BITMAP_Pixmap( HBITMAP ); +extern X11DRV_KeyboardWindow (Display *display, Window w); #define HAS_DLGFRAME(style,exStyle) \ (((exStyle) & WS_EX_DLGMODALFRAME) || \ @@ -199,6 +200,7 @@ CWEventMask | CWBitGravity | CWBackingStore | CWColormap, &attr ); XSaveContext( display, data->icon_window, winContext, (char *)win->hwndSelf ); wine_tsx11_unlock(); + if (data->client_window) X11DRV_KeyboardWindow (display, data->whole_window); TRACE( "created %lx\n", data->icon_window ); SetPropA( win->hwndSelf, icon_window_atom, (HANDLE)data->icon_window ); @@ -686,6 +688,7 @@ wine_tsx11_unlock(); return 0; } + X11DRV_KeyboardWindow (display, data->whole_window); /* non-maximized child must be at bottom of Z order */ if ((win->dwStyle & (WS_CHILD|WS_MAXIMIZE)) == WS_CHILD) @@ -732,6 +735,7 @@ CWEventMask | CWBitGravity | CWBackingStore, &attr ); if (data->client_window && is_client_window_mapped( win )) XMapWindow( display, data->client_window ); + if (data->client_window) X11DRV_KeyboardWindow (display, data->whole_window); wine_tsx11_unlock(); return data->client_window; } --- desktop.c 8 Jan 2003 11:24:51 -0000 1.1 +++ desktop.c 8 Jan 2003 14:30:53 -0000 @@ -30,6 +30,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(x11drv); +extern X11DRV_KeyboardWindow (Display *display, Window w); /* desktop window procedure */ static LRESULT WINAPI desktop_winproc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) @@ -141,6 +142,8 @@ win = XCreateWindow( display, DefaultRootWindow(display), x, y, width, height, 0, screen_depth, InputOutput, visual, CWBackPixel | CWEventMask | CWCursor | CWColormap, &win_attr ); + + if (win) X11DRV_KeyboardWindow (display, win); /* Set window manager properties */ size_hints = XAllocSizeHints();

2 5

dos4gw stub exec failed
by Enrico Horn 23 Jan '03

23 Jan '03

Hi I have some dos games that want to exec dos4gw.exe when starting. but this seems to fail. I hope i read the debug messages correctly and the comment from file:Win32HandleToDosFileHandle is still valid. what happens is dos:int21 wants to open file with the dos handle and then read from it. reading the file calls the function file:ReadFile with the converted win32 file handle which is invalid if the above mentioned comment is correct. Any ideas how to solve this or am I completely off-track here. Ciao Enrico farmboy1(a)subdimension.com log extract: Call DOS int 0x21 ret=00b7:15d0 eax=00003d00 ebx=000009f0 ecx=0000106a edx=00000a76 esi=00000a76 edi=0000ffff ebp=000009ce esp=000009ca ds=0319 es=0319 fs=0000 gs=0000 flags=000b0246 trace:int21:DOSVM_Int21Handler AX=3d00 BX=09f0 CX=106a DX=0a76 SI=0a76 DI=ffff DS=0319 ES=0319 EFL=000b0246 080eef28:Call kernel32.INT_Int21Handler(416d2c54) ret=4149829e trace:int21:INT_Int21Handler OPEN mode 0x00 C:\CCS\dos4gw.exe trace:file:_lopen ('C:\CCS\dos4gw.exe',0000) trace:file:CreateFileW L"C:\\CCS\\dos4gw.exe" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 trace:dosfs:DOSFS_GetFullName L"C:\\CCS\\dos4gw.exe" (last=1) trace:dosfs:DOSFS_FindUnixName /home/windows,L"CCS\\dos4gw.exe" trace:dosfs:DOSFS_ToDosFCBFormat (L"CCS\\dos4gw.exe", 0x416d19bc) trace:dosfs:DOSFS_OpenDir "/home/windows" trace:dosfs:DOSFS_ReadDir Read: long_name: L".", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"..", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"windows", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"Program Files", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"Temp", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"Angel", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"Buffy", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SFV32w.GID", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SFV32w.hlp", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"dcm95cfg.exe", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"dcom98.exe", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"quicksfv.exe", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"quicksfv.ini", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"sfv32w.exe", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"Spiele", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"wingtk-0.2.exe", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"dxdiag.exe", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"CCS", short_name: (null) trace:dosfs:DOSFS_FindUnixName (/home/windows,L"CCS\\dos4gw.exe") -> L"CCS" (L"CCS") trace:dosfs:DOSFS_FindUnixName /home/windows/CCS,L"dos4gw.exe" trace:dosfs:DOSFS_ToDosFCBFormat (L"dos4gw.exe", 0x416d19bc) trace:dosfs:DOSFS_OpenDir "/home/windows/CCS" trace:dosfs:DOSFS_ReadDir Read: long_name: L".", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"..", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SAMPLE.AD", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"OBJECT.DAT", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"CCSSTR.DAT", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"ADRV688.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"JAMMER.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"PROAUDIO.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"RAP10.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SB16.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SBLASTER.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SBPRO.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SNDSCAPE.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"SNDSYS.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"ULTRA.DIG", short_name: (null) trace:dosfs:DOSFS_ReadDir Read: long_name: L"DOS4GW.EXE", short_name: (null) trace:dosfs:DOSFS_FindUnixName (/home/windows/CCS,L"dos4gw.exe") -> L"DOS4GW.EXE" (L"DOS4GW.EXE") trace:dosfs:DOSFS_GetFullName returning /home/windows/CCS/DOS4GW.EXE = L"C:\\CCS\\DOS4GW.EXE" trace:dosfs:GetDriveTypeW (L"C:\\CCS\\DOS4GW.EXE") trace:file:CreateFileW returning 0x68 trace:file:Win32HandleToDosFileHandle Got 5 for h32 0x68 080eef28:Ret kernel32.INT_Int21Handler() retval=00000005 ret=4149829e trace:int21:DOSVM_Int21Handler returning: AX=0005 BX=09f0 CX=106a DX=0a76 SI=0a76 DI=ffff DS=0319 ES=0319 EFL=000b0246 Ret DOS int 0x21 ret=00b7:15d0 eax=00000005 ebx=000009f0 ecx=0000106a edx=00000a76 esi=00000a76 edi=0000ffff ebp=000009ce esp=000009ca ds=0319 es=0319 fs=0000 gs=0000 flags=000b0246 Call DOS int 0x21 ret=00b7:1f9f eax=00004400 ebx=00000005 ecx=00000005 edx=00000005 esi=0000038a edi=00000005 ebp=000009ce esp=000009ba ds=0319 es=0319 fs=0000 gs=0000 flags=000b0202 trace:int21:DOSVM_Int21Handler AX=4400 BX=0005 CX=0005 DX=0005 SI=038a DI=0005 DS=0319 ES=0319 EFL=000b0202 080eef28:Call kernel32.DosFileHandleToWin32Handle(00000005) ret=414965a0 080eef28:Ret kernel32.DosFileHandleToWin32Handle() retval=00000068 ret=414965a0 080eef28:Call kernel32.DOSFS_GetDeviceByHandle(00000068) ret=414965a6 080eef28:Ret kernel32.DOSFS_GetDeviceByHandle() retval=00000000 ret=414965a6 080eef28:Call kernel32.INT_Int21Handler(416d2c54) ret=41496676 trace:int21:ioctlGetDeviceInfo (5) 080eef28:Ret kernel32.INT_Int21Handler() retval=00000942 ret=41496676 trace:int21:DOSVM_Int21Handler returning: AX=4400 BX=0005 CX=0005 DX=0942 SI=038a DI=0005 DS=0319 ES=0319 EFL=000b0202 Ret DOS int 0x21 ret=00b7:1f9f eax=00004400 ebx=00000005 ecx=00000005 edx=00000942 esi=0000038a edi=00000005 ebp=000009ce esp=000009ba ds=0319 es=0319 fs=0000 gs=0000 flags=000b0202 Call DOS int 0x21 ret=00b7:1f9f eax=00004400 ebx=00000005 ecx=00000005 edx=00004000 esi=00000a76 edi=00000005 ebp=000009ce esp=000009c2 ds=0319 es=0319 fs=0000 gs=0000 flags=000b0246 trace:int21:DOSVM_Int21Handler AX=4400 BX=0005 CX=0005 DX=4000 SI=0a76 DI=0005 DS=0319 ES=0319 EFL=000b0246 080eef28:Call kernel32.DosFileHandleToWin32Handle(00000005) ret=414965a0 080eef28:Ret kernel32.DosFileHandleToWin32Handle() retval=00000068 ret=414965a0 080eef28:Call kernel32.DOSFS_GetDeviceByHandle(00000068) ret=414965a6 080eef28:Ret kernel32.DOSFS_GetDeviceByHandle() retval=00000000 ret=414965a6 080eef28:Call kernel32.INT_Int21Handler(416d2c54) ret=41496676 trace:int21:ioctlGetDeviceInfo (5) 080eef28:Ret kernel32.INT_Int21Handler() retval=00000942 ret=41496676 trace:int21:DOSVM_Int21Handler returning: AX=4400 BX=0005 CX=0005 DX=0942 SI=0a76 DI=0005 DS=0319 ES=0319 EFL=000b0246 Ret DOS int 0x21 ret=00b7:1f9f eax=00004400 ebx=00000005 ecx=00000005 edx=00000942 esi=00000a76 edi=00000005 ebp=000009ce esp=000009c2 ds=0319 es=0319 fs=0000 gs=0000 flags=000b0246 Call DOS int 0x21 ret=00b7:17a7 eax=00003f41 ebx=00000005 ecx=0000001c edx=00000ac6 esi=00000005 edi=0000041e ebp=000009e6 esp=000009d8 ds=0319 es=0319 fs=0000 gs=0000 flags=000b0202 trace:int21:DOSVM_Int21Handler AX=3f41 BX=0005 CX=001c DX=0ac6 SI=0005 DI=041e DS=0319 ES=0319 EFL=000b0202 080eef28:Call kernel32.INT_Int21Handler(416d2c54) ret=4149829e trace:int21:INT_Int21Handler READ from 5 to 0319:0AC6 for 28 byte trace:file:ReadFile 0x68 0x3c56 28 0x416d26dc (nil) 080eef28:Ret kernel32.INT_Int21Handler() retval=0000001c ret=4149829e trace:int21:DOSVM_Int21Handler returning: AX=001c BX=0005 CX=001c DX=0ac6 SI=0005 DI=041e DS=0319 ES=0319 EFL=000b0202 Ret DOS int 0x21 ret=00b7:17a7 eax=0000001c ebx=00000005 ecx=0000001c edx=00000ac6 esi=00000005 edi=0000041e ebp=000009e6 esp=000009d8 ds=0319 es=0319 fs=0000 gs=0000 flags=000b0202 Call DOS int 0x21 ret=00b7:1849 eax=00003e05 ebx=00000005 ecx=00000005 edx=00000f20 esi=00000005 edi=00000f0c ebp=00000a6c esp=000009e8 ds=0319 es=0319 fs=0000 gs=0000 flags=000b0206 trace:int21:DOSVM_Int21Handler AX=3e05 BX=0005 CX=0005 DX=0f20 SI=0005 DI=0f0c DS=0319 ES=0319 EFL=000b0206 080eef28:Call kernel32.INT_Int21Handler(416d2c54) ret=4149829e trace:int21:INT_Int21Handler CLOSE handle 5 trace:file:_lclose16 5 (handle32=0x68) 080eef28:Ret kernel32.INT_Int21Handler() retval=00000000 ret=4149829e trace:int21:DOSVM_Int21Handler returning: AX=0000 BX=0005 CX=0005 DX=0f20 SI=0005 DI=0f0c DS=0319 ES=0319 EFL=000b0206 Ret DOS int 0x21 ret=00b7:1849 eax=00000000 ebx=00000005 ecx=00000005 edx=00000f20 esi=00000005 edi=00000f0c ebp=00000a6c esp=000009e8 ds=0319 es=0319 fs=0000 gs=0000 flags=000b0206

3 3

stupidity: a slighlty less horrible wine tree diff gizmo
by Greg Turner 23 Jan '03

23 Jan '03

Still up to the same old stupid bash tricks... but implemented slightly better. This will still have to be manually maintained to remain useful as wine's directory structure evolves, just like the old "version" of this awfulness. Use at your own (very real) risk as these are almost untested. License is bugroff. This version has better provisions for in-source compilation, runs in only one pass, and is cwd/location independant. It should also be a lot easier to maintain than the previous try winetreediff_excl (a text file listing shell-glob patterns to ignore): >> CVS *.o *.a *.s Makefile *.spec.c *.dll.dbg.c *.exe.dbg.c *.drv.dbg.c *.acm.dbg.c *.ocx.dbg.c *.so *.def *.glue.c *.ok *.mc.rc testlist.c aclocal.m4 *.res gmtdir Makeprog.rules Make.rules *.swp config.log config.status lex.yy.c y.tab.c y.tab.h *.so.?.? wineclipsrv doall doconfig wine.man autom4te.cache mydiffs gmt-cfg-vars Makedll.rules Maketest.rules tags delme.diff delme2.diff wine.texinfo <<EOF winetreediff (a script to filter out impossible-to-glob patterns and perform the real processing. Note the hard-coded path to winetreediff_excl. Change it to match where you put it. Needs the x bit, of course.) >> #!/bin/sh noslash=$( echo "$1" | sed s/\\/$// ) noslashquot=$( echo "$noslash" | sed s/\\//\\\\\\//g | sed s/\\./\\\\\\./g ) # echo "noslash=$noslash noslashquot=$noslashquot" rm -f delme.diff delme2.diff touch delme.diff delme2.diff diff -ur --minimal --exclude-from=/home/greg/bin/winetreediff_excl $noslash . | \ grep -v '^Only in.*wine$' | \ grep -v '^Only in .*dlls/rpcrt4/tests\: stringinput_server$' | \ grep -v '^Only in .*include\: config.h$' | \ grep -v '^Only in .*programs/avitools\: aviinfo$' | \ grep -v '^Only in .*programs/avitools\: aviplay$' | \ grep -v '^Only in .*programs/avitools\: icinfo$' | \ grep -v '^Only in .*programs/clock\: clock$' | \ grep -v '^Only in .*programs/cmdlgtst\: cmdlgtst$' | \ grep -v '^Only in .*programs/control\: control$' | \ grep -v '^Only in .*programs/expand\: expand$' | \ grep -v '^Only in .*programs/notepad\: notepad$' | \ grep -v '^Only in .*programs/osversioncheck\: osversioncheck$' | \ grep -v '^Only in .*programs/progman\: progman$' | \ grep -v '^Only in .*programs/regapi\: regapi$' | \ grep -v '^Only in .*programs/regedit\: regedit$' | \ grep -v '^Only in .*programs/regsvr32\: regsvr32$' | \ grep -v '^Only in .*programs/regtest\: regtest$' | \ grep -v '^Only in .*programs/rpcss\: rpcss$' | \ grep -v '^Only in .*programs/rundll32\: rundll32$' | \ grep -v '^Only in .*programs/uninstaller\: uninstaller$' | \ grep -v '^Only in .*programs/view\: view$' | \ grep -v '^Only in .*programs/wcmd\: wcmd$' | \ grep -v '^Only in .*programs\: wineapploader$' | \ grep -v '^Only in .*programs/wineboot\: wineboot$' | \ grep -v '^Only in .*programs/wineconsole\: wineconsole$' | \ grep -v '^Only in .*programs/winedbg\: winedbg$' | \ grep -v '^Only in .*programs/winefile\: winefile$' | \ grep -v '^Only in .*programs\: winelauncher$' | \ grep -v '^Only in .*programs/winemine\: winemine$' | \ grep -v '^Only in .*programs/winepath\: winepath$' | \ grep -v '^Only in .*programs/winhelp\: hlp2sgml$' | \ grep -v '^Only in .*programs/winhelp\: winhelp$' | \ grep -v '^Only in .*programs/winver\: winver$' | \ grep -v '^Only in .*server\: wineserver$' | \ grep -v '^Only in .*stringinput_server\: stringinput_server$' | \ grep -v '^Only in .*tools\: bin2res$' | \ grep -v '^Only in .*tools\: fnt2bdf$' | \ grep -v '^Only in .*tools\: makedep$' | \ grep -v '^Only in .*tools\: mingwrap$' | \ grep -v '^Only in .*tools/widl\: widl$' | \ grep -v '^Only in .*tools/winebuild\: winebuild$' | \ grep -v '^Only in .*tools/winebuild\: winebuild.man$' | \ grep -v '^Only in .*tools/winedump\: winedump$' | \ grep -v '^Only in .*tools\: winegcc$' | \ grep -v '^Only in .*tools\: winewrap$' | \ grep -v '^Only in .*tools/wmc\: wmc$' | \ grep -v '^Only in .*tools/wrc\: wrc$' | \ ( tee delme.diff | grep -v '^Only in .*\:' ) cat delme.diff | \ grep '^Only in .*\:' | \ sed s/^Only\ in\ // | \ sed s/\:\ /\\// | \ ( tee delme2.diff | grep "^\.\/" ) | \ sed "s/^\.\//diff\ -u\ \/dev\/null\ \.\//" | \ sed "s/$/;/" | \ bash -C - cat delme2.diff | \ grep -v "^\.\/" | \ sed "s/^$noslashquot\//diff\ -u\ \.\//" | \ sed "s/$/\ \/dev\/null;/" | \ ( cd $noslash && bash -C - ) rm -f delme.diff delme2.diff <<EOF still hardly a work of art. but ought to generate diffs between trees ready for submission to wine-devel, no cvs needed. For example, I use this as follows to update my horribly out-of-sync wine tree with the latest changes from cvs: .../wine> cd ../wine.test .../wine.test> winetreediff ../wine.vanilla | wc -l 0 .../wine> # great, these trees are identical w.r.t. winetreediff. .../wine> cd ../wine.vanilla .../wine.vanilla> cvs -qz4 up -dPA [cvs does something] .../wine.vanilla> # generate the difference between "../wine.test" and "." .../wine.vanilla> winetreediff ../wine.test > ../wine/mydiffs/cvsupdate.diff .../wine.vanilla> cd ../wine.test .../wine.test> patch -p0 < ../wine/mydiffs/cvsupdate.diff [ goes fine ] .../wine.test> cd ../wine Now I have a nice diff expressing the difference caused by the CVS update. If I am concerned about it, I could run .../wine> patch -p0 --dry-run < mydiffs/cvsupdate.diff To see what the damage will be, otherwise, just .../wine> patch -p0 < mydiffs/cvsupdate.diff would bring me up-to-date. LIMITATIONS: o Dangerous if used incautiously. o Breaks if wine changes. o Probably Buggy. o Only supports "." and "/" characters in directory argument. o Creates and destroys temp files named delme.diff and delme2.diff. (Should at least use something more obscure.) o Prefers (requires?) a matching directory structure between the two trees. -- gmt

1 0

Re: PATCH: kernel / errno testing
by Dan Kegel 22 Jan '03

22 Jan '03

Marcus Meissner wrote: > Hi, > > glibc 2.3.current CVS is throwing a huge stone in our direction, > it no longer allows overload of __errno_location. > > To visualize this problem I have added this testcase. ... > sched_yield(); /* will not change errno */ BTW sched_yield() is allowed to be a no-op; would nanosleep() or something like that be a better choice? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

3 2

InstallShield 6: fixme:ole:_StubReaderThread Failed with hres 80004005
by Dan Kegel 22 Jan '03

22 Jan '03

Whenever I run an InstallShield 6 installer, and it fails early on for any reason (e.g. a file was missing, or the "object reference not set" bug), the error messagebox "Error installing iKernel.exe: (0x1400)" appears. The user clicks 'OK', and the program terminates (after a few seconds). So far so good. But on stderr I see fixme:ole:_xread Read only 0 of 4 bytes from 0x58. fixme:ole:_StubReaderThread Failed with hres 80004005 and I note the presence of one or two stray wine processes and a wineserver: $ ps augxw | grep wine dank 947 14.9 0.3 3172 1236 ? S 11:58 0:10 wineserver dank 949 0.5 7.5 64400 29028 pts/0 S 11:58 0:00 /usr/local/bin/wine C:\PROG~FBU\COMM~CP1\INST~JM1\engine\6\INTE~MEX\I dank 957 0.0 7.5 64400 29028 pts/0 S 11:59 0:00 /usr/local/bin/wine C:\PROG~FBU\COMM~CP1\INST~JM1\engine\6\INTE~MEX\I Subsequent runs of the installer produce the error "error installing iKernel.exe: (0x1400)" probably because iKernel.exe is locked, and can't be overwritten. Killing all wine processes, e.g. killall wine lets the next run get past the 0x1400 error. I'm not stuck or even terribly bothered by this, but I thought I'd document it here in case anyone's interested. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
38
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 January 2003