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

Re: Lostwages: acknowledgement take two.......

by Tom Wickline

On 8/16/05, Jonathan Ernst <Jonathan(a)ernstfamily.ch> wrote: > I have sent about 310 patches since december 2004, mostly for AppDB, > some for lostwages and bugzilla and quite a few translating resources > files in french and reimplementing the uninstaller, I really don't know > if it makes it worth inclusion and won't be angry if I'm not included. > Of course you should be included, this is the main reason why I ask in my first patch if I forgot someone to please forgive me, and let me know so I can add everyone who should be here. Would you prefer <misc> or <AppDB/Bugzilla> ? Tom

Aug. 16, 2005

Re: DINPUT: Generic FF effect implementation (FF #4)

by Alexandre Julliard

Daniel Remenak <dtremenak(a)gmail.com> writes: > Submitted #5 a couple days ago, along with a short explanation of how > it all worked together. Any comments? If you'd like me to change the > architecture I'm willing to do so, if you can give me some hints about > what direction to go with it. If you want some other changes made, > please drop some clues about what they might be. If you want to see > more, I have more that can be cleaned up for submission. If you need > more clarification on some issue I can give it. I just loathe sitting > around wondering if these are good enough or not when I could be > working more on them if they need revision or the next batch if they > don't ;) It looks a bit overdesigned to me. With this patch you add even more infrastructure, generic interfaces, etc. and it still doesn't do anything. I'd suggest going the other way around: implement one working version of the code without worrying about being generic, without trying to abstract interfaces or anything, just a simple source file implementing the COM interface directly. Then if there's really a need for other implementations to share a lot of code we can look at abstracting parts of it. -- Alexandre Julliard julliard(a)winehq.org

Aug. 16, 2005

Re: Help with debugging needed

by Stefan Dösinger

Hi, > Could you put the +ddraw trace somewhere on the web ? This suspiciously > looks like a reference counting issue either in the application or in the > Wine code. It looks to me that Empire Earth accidentally frees the DirectDraw Interface it's working with. During my look at the ddraw code, I've stubled accross this thing in DDRAW_Create: { ... driver = DDRAW_FindDriver(lpGUID); if (driver == NULL) return DDERR_INVALIDDIRECTDRAWGUID; hr = driver->create(lpGUID, &pDD, pUnkOuter, ex); if (FAILED(hr)) return hr; hr = IDirectDraw7_QueryInterface(pDD, iid, lplpDD); IDirectDraw7_Release(pDD); <-- Is this correct??? return hr; } I haven't found any useable Documentation on MSDN, because it's all archived content. But this Release Call seems odd to me. If I remove this call, Empire Earth continues loading and bails out on some string operation, which I haven't investigated yet. Stefan

Aug. 16, 2005

Re: IStorage* vs. LPSTORAGE vs. winapi_check

by Marcus Meissner

On Tue, Aug 16, 2005 at 04:33:36PM +0200, Francois Gouget wrote: > > I checked the prototypes of OleDoAutoConvert() and GetConvertStg() and > they use LPSTORAGE rather than IStorage* so I think the 16bit versions > should match. This would avoid introducing ISTorage* in win16.api. > > However one could probably also argue that these functions (which are > currently just stubs) should take a SEGPTR anyway... > > This brings me to OleLoad16() and ReadClassStg16() which were causing > winapi_check to complain because they have comments in their prototypes > that look like documentation to it. I think the right way to handle > those is use the regular documentation to document the real type of > these pointers, i.e. do it as follows: The LPSTORAGE layout is definitely not the same. So LPSTORAGE16 would be more fitting I think. Also when not using "SEGPTR" I get conversion warnings and it clarifies a bit what exactly the type of the argument is. I am fine by the patch, but will have to fix it up regarding LPSTORAGE once we get to the point of implementing those funcs. Ciao, Marcus

Aug. 16, 2005

Re: Lostwages: developer-cheatsheet.template.diff

by Andreas Mohr

Hi, On Tue, Aug 16, 2005 at 06:17:27PM +0200, Francois Gouget wrote: > Actually 'dereference' is correct here, although I have no doubt that it > is not in any dictionary. Huh, why? http://dictionary.reference.com/search?q=dereference But OTOH it does mention "well established in jargon", so you might have a point here. Andreas

Aug. 16, 2005

Re: Get shlfolder test running with shell32 4.0

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > Version 4.0 of the shell32 dll does not export StrRetToBufW(). Other shell32 versions don't either, since StrRetToBufW is in shlwapi ;-) -- Alexandre Julliard julliard(a)winehq.org

Aug. 16, 2005

Re: Report swap file total/free sizes to be the same as physical memory

by Andreas Mohr

Hi, On Tue, Aug 16, 2005 at 11:49:34PM +0900, Dmitry Timoshkov wrote: + /* Project2k refuses to start if it sees less than 1Mb of free swap */ + if (lpmemex->ullTotalPageFile < lpmemex->ullTotalPhys) + lpmemex->ullTotalPageFile = lpmemex->ullTotalPhys; + if (lpmemex->ullAvailPageFile < lpmemex->ullAvailPhys) + lpmemex->ullAvailPageFile = lpmemex->ullAvailPhys; 1 mega*bit* sounds a "bit" small... Andreas Mohr

Aug. 16, 2005

Re: Winecfg and port access

by Christian Schmitz

HI: Thanks for you answer but i dont know how program these lines for control ioperm(). Yes my system is Suse Linux 9.3 with kde upgraded 3.4.1 I solve the problem (in old wine) of this way: In the old file config i write [ppdev] "378" = "/dev/parport0" [ports] "read" = "0x779,0x378-0x37f,0x280-0x2a0" "write" = "0x779,0x378-0x37f,0x280-0x2a0" I set the attributes crw-rw-rw- 1 me root 99, 0 2005-03-19 16:36 /dev/parport0 crw-rw-rw- 1 lp lp 6, 0 2005-03-19 16:36 /dev/lp0 and add Myuser to the lp group. With all this i get the right of access. Maybe if you sendme a clue maybe i can make the wrapper. Thanks Christian >> I am using TopMax software (a chip programmer) with old wine version (with >> config file). >> >> I try the new wine but i not find where grant the FULL parallel port >> access to the TopMax program >> >> Where is the new config file for touch manually? or >> How i can make for grant port access (standard 378-37f) >If you're using linux, you will most likely have to use a suid-root wrapper >that calls ioperm() and subsequently drops privileges and invokes wine. >That's about 10 lines of C and should be a good exercise ;] I don't know >offhand how portable ioperm() is, and if there is something in /proc that >would be more portable, etc. > >I don't see anything suid-root that comes with wine, so probably wine itself >doesn't have anything of the sort. And I don't know either how wine managed >to pull it off before w/o using suid root executable, unless it did it via >signal catching and some manual forwarding to /dev/lp#. With right ioperms in >place the program should be able to run at full speed. -- En un mundo sin fronteras.... ¿Quién necesita Puertas y Ventanas? EN INGLES: In a world without frontiers, who needs Gates and Windows

Aug. 16, 2005

Re: MSHMTL: Added QueryStatus implementation

by Jacek Caban

Saulius Krasuckas wrote: >* On Mon, 15 Aug 2005, Jacek Caban wrote: > > >>I've tried to get other tests working on win 98, >>without success. It's possible that it won't work this >>way on 9x, >> >> > >It seems I've found one bug in test/htmldoc.c: > >| if(activeobj) { >| - IOleInPlaceActiveObject_GetWindow(activeobj, &hwnd); >| + hres = IOleInPlaceActiveObject_GetWindow(activeobj, &hwnd); >| ok(hres == S_OK, "GetWindow failed: %08lx\n", hres); > > Right, it's a bug. >And we have a failure in an old version of test on winME: > >| htmldoc.c:502: Test failed: GetWindow failed: 80004005 > >* [1] writes: >| >| IOleInPlaceActiveObject::GetWindow >| >| Always fails and returns E_FAIL for a windowless >| control. Since this is documented in the current >| OLE2 specification, there should not be any problem >| with existing containers and frames. > >So something might be missing here, I thought. > >OTOH, winME always returns E_FAIL {80004005} in this test [2], while win98 >seems to return HRESULT_FROM_WIN32(ERROR_ALREADY_EXISTS) {800700b7} [3]. > > And I'd expect E_FAIL here as GetWindow fails if HTMLDocument is not active in-place (and it's not here because UIActivate failed). Other tests show that it's correct. >Maybe you give it a test-try on win98 as there is no way to do it by WT >now. :-( > > We shouldn't care too much about it as it happens only in scenario when UIActivate fails that won't happen in Wine (and in nt). I've tested different ways UIActivate can fail on xp and Wine fails the same way. Jacek

Aug. 16, 2005

X11: Problems with ConfigureNotify events that are received/processed too late

by Michael Kaufmann

Hi all, I'm trying to get the dialog boxes of Word 95 working. They often appear with the minimal window size (about 70x50 pixels), so they're unusable. With KDE's window manager (KWin) this happens very often. With Enlightenment and GNOME's window manager (Metacity), it only happens from time to time. I've looked for the reason, and I think it's very closely related to WINE bug 1265 which Duane Clark has tried to fix here: http://www.winehq.com/hypermail/wine-patches/2003/02/0095.html That's what's going on (CVS version of WINE, managed window mode): 1. Word creates a dialog with an initial position of (0,0) and size 0x0 (using CreateWindowEx) 2. Word calls SetWindowPos to set the correct dialog position and size 3. Word calls SetWindowPos to show the dialog (SWP_SHOWWINDOW) 4. The dialog gets the focus, the main window is being deactivated 5. In the WM_NCACTIVATE procedure of the main window, Word calls GetQueueStatus. WINE will process X events. 6. WINE receives a ConfigureEvent for the initial dialog position and size (0x0) and saves this to data->whole_rect in X11DRV_sync_window_position (7. If you're lucky, WINE also receives a ConfigureEvent for the correct dialog position) 8. Wine shows the dialog and maps it. It calls X11DRV_set_wm_hints, which calls set_size_hints. This procedure uses data->whole_rect as the dialog's rectangle. But this stored rectangle is completely wrong because WINE has not yet received all ConfigureEvents. 9. The window manager has to resize the dialog to the wrong size. The best solution would be to process all X events before setting the window position in SetWindowPos, but I don't know if that's possible. I've tried another approach: WINE should not set the window size hints when mapping a window (step 8.). I've attached a patch, but it's not 100% correct, because the style of a window (e.g. the WS_THICKFRAME style) may be changed by an application using SetWindowLong and SetWindowPos (with the SWP_FRAMECHANGED flag). WINE doesn't look for the SWP_FRAMECHANGED flag and updates the X11 window every time if it's visible or gets visible. So if an application calls SetWindowPos with the SWP_SHOWWINDOW flag, WINE needs to set the size hints because the window has been hidden and its style may have been changed. What would be the correct fix for this problem? Any ideas? Thanks, Michael Index: window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.115 diff -u -r1.115 window.c --- window.c 27 Jul 2005 15:22:58 -0000 1.115 +++ window.c 15 Aug 2005 21:32:54 -0000 @@ -353,9 +353,9 @@ /*********************************************************************** * X11DRV_set_wm_hints * - * Set the window manager hints for a newly-created window + * Set the window manager hints for a window */ -void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ) +void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ) { Window group_leader; XClassHint *class_hints; @@ -400,7 +400,7 @@ } /* size hints */ - set_size_hints( display, data, style ); + if (update_size_hints) set_size_hints( display, data, style ); /* systray properties (KDE only for now) */ if (ex_style & WS_EX_TRAYWINDOW) @@ -692,7 +692,7 @@ xim = x11drv_thread_data()->xim; if (xim) data->xic = X11DRV_CreateIC( xim, display, data->whole_window ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, TRUE ); SetPropA( data->hwnd, whole_window_prop, (HANDLE)data->whole_window ); return data->whole_window; Index: winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.136 diff -u -r1.136 winpos.c --- winpos.c 15 Aug 2005 09:33:39 -0000 1.136 +++ winpos.c 15 Aug 2005 21:32:56 -0000 @@ -489,7 +489,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); @@ -650,7 +650,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); Index: x11drv.h =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v retrieving revision 1.76 diff -u -r1.76 x11drv.h --- x11drv.h 29 Jun 2005 19:28:06 -0000 1.76 +++ x11drv.h 15 Aug 2005 21:32:58 -0000 @@ -686,7 +686,7 @@ const RECT *new_whole_rect ); extern BOOL X11DRV_set_window_pos( HWND hwnd, HWND insert_after, const RECT *rectWindow, const RECT *rectClient, UINT swp_flags, const RECT *validRects ); -extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ); +extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ); extern void X11DRV_handle_desktop_resize(unsigned int width, unsigned int height); extern void X11DRV_Settings_AddDepthModes(void);

Aug. 16, 2005