wine-devel January 2004

129 participants
360 discussions

by Robert Shearman

I apologise in advance if this message is poorly formatted. Blame webmail for that. Alex Pasadyn wrote: > ChangeLog: > - Make a separate process for the Wine desktop window > - In desktop mode, all applications share one desktop window > - Ensure system metrics are accurate for all processes after resolution > changes I suggest you put the system metrics stuff in a separate patch. It is a lot more tested and more likely to get in than the other code, which is quite a big change. [snip] > While several applications work fine, there are > some issues I have not been able to resolve. The problems have to do > with trying to call WIN_FindWndPtr across processes, especially from the > windows/painting.c file. As you rightly say, we need to move a lot of the window code into wineserver. ReactOS probably has a head start on us in this area, although we won't be able to borrow anything more than ideas because of the license. [snip] > I am hoping someone with more knowledge of the painting and region > code could spot some obvious way to get around the issue. Otherwise it > will be tough. I had tried replacing some of the WND* uses with server > calls to get rectangles and style flags, but that does not handle > everything that's being read out of those structures. Unless there's > some shortcut I don't see how to do it without moving more of that data > into the server. The other problem related to this is that some > functions are supposed to fail if the window is in another process, > while others would work better if they got the data from the server, and > it's not always obvious which way a particular function should work. I guess we need test cases for those then. The way I see it the only way around the problem of inter-process graphics operations is for us to have our own DIB engine and move functions calling WIN_FindWndPtr into the server. X doesn't allow inter-process operations right? > @@ -128,7 +129,14 @@ > */ > BOOL WINAPI PaintDesktop(HDC hdc) > { > - HWND hwnd = GetDesktopWindow(); > + HWND hwnd; > + SERVER_START_REQ( set_desktop_window ) > + { > + req->handle = 0; > + wine_server_call( req ); > + hwnd = reply->cur_handle; > + } > + SERVER_END_REQ; > > /* check for an owning thread; otherwise don't paint anything (non-desktop mode) */ > if (GetWindowThreadProcessId( hwnd, NULL )) Is there some reason for replacing GetDesktopWindow with this server call? [snip] > +/*********************************************************************** > + * BecomeDesktop > + * > + * Tell the server to make our window the desktop. > + */ > +static BOOL BecomeDesktop() > +{ > + BOOL res = TRUE; > + SERVER_START_REQ( set_desktop_window ) This is bad. There shouldn't be a direct server call in a normal wine program. We should try and find the right Windows API to do this, or create our own export from user32. Only user32, gdi32, ntdll and x11drv should need to use server calls (and kernel32 out of convenience). [snip] > +/*********************************************************************** > + * WrapperWndProc > + * > + * Window procedure > + */ > +static LRESULT WINAPI WrapperWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) [snip] > +/*********************************************************************** > + * DesktopWndProc > + * > + * Window procedure > + */ > +static LRESULT WINAPI DesktopWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) Why do you need two windows procedures? If you're sure you do need both of them, a comment in the code explaining why would be good. It's not at all obvious to the casual observer (i.e. me) otherwise. It appears you don't launch winedesktop anywhere and you don't remove any options from the config file. It will be a bit confusing for people who do use the wine desktop when it doesn't do anything after applying your patch (until they launch winedesktop). Do you plan to launch winedesktop at startup (possibly just after wineserver is launched) if the desktop setting is enabled? Rob

20 years, 3 months

Re: Fix Unicode support for SetupApi INFs

by Alexandre Julliard

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > A well meaning individual implemented Unicode support for SetupApi. > However, the detection for whether a file was Unicode was slightly > broken because RtlIsTextUnicode only returns true if all the flags input > were output (and NULL means all flags). Since some are contradictory > this will never return TRUE. I only set the signature detection since > heuristics will probably take a while on larger files. Actually that's a bug in RtlIsTextUnicode. Passing NULL as flags is legitimate and means to do all the available tests; it certainly doesn't mean to always return FALSE, so it will have to be fixed to avoid contradictory tests. -- Alexandre Julliard julliard(a)winehq.com

20 years, 3 months

Named pipes

by Peter Riocreux

[reposted because I posted not from the subscribed address - Doh! Sorry if you see it twice in the end] Using the RH9 RPM from the SF downloads area (wine-20040121-1rh9winehq.i686.rpm) This is my first serious attempt at getting a non-working app working, so if I am giving insufficient, or the wrong kind of, info, or am asking on the wrong list, or have not found the blindingly-obvious-to-everyone-but-me FAQ covering something then please point me at the right things. At my company, we have just purchased a spangly new Alcatel telephone exchange, and despite the exchange running Linux apparently (I am going to start work on obtaining the source next week ...), they have only a Windows client for managing this exchange. Thus Wine .... The management software (binary called pm5.exe) installed fairly easily and gets a long way in on execution but then stops making progress. It consumes pretty much all the CPU and when run with debug messages printed I get the following: fixme:ole:CoRegisterMessageFilter stub warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use arena magic for 402576a0 warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{46A9F31C-E868-11D4-8BC9-000102A831DC}, le is 2 [last message repeated indefinitely] There are two earlier instances of the first message, so I don't think that is the fundamental problem, but that is the first and only HEAP message, and the last message gets repeated endlessly. (full logs available on request). It also looks for, and doesn't find, ADVAPI32.dll. I am not a Windows person at all, so have no idea if the above dll is one that I should expect to find somewhere, or likely to be from the app itself. As for the pipe thing, I couldn't tell whether it couldn't connect because it couldn't make a pipe, or because it could but there was nothing at the end of it. (I am assuming the 'broker' is at the other end of the pipe.) Can anyone advance my state here? Cheers, Peter

20 years, 3 months

Re: Fix .. in path names

by Dimitrie O. Paun

On Wed, 28 Jan 2004, Mike McCormack wrote: > This patch fixes the problem with non-existant directories and .. in > pathnames. (and it makes my test case work, Dimi!) > + /* don't mess with unix path names */ > + if( strchrW(name,'/') ) > + return DOSFS_GetFullNameNoDots( name, check_last, full ); I don't think this is a good test for Unix path names. AFAAIK, DOS supports '/' as well as path separator. Maybe we should export a wine_is_unix_path() function... -- Dimi.

20 years, 3 months

WineHQ: Isn't status update news?

by Dimitrie O. Paun

Guys, How about a news item about the status being updated? Tom just finished a big status update, and people that don't follow wine-{cvs,devel,patches}(a)winehq.org have no way of knowing. In general, I think any big site update should make it as news items. -- Dimi.

20 years, 3 months

Re: Test .. in path name for various file functions

by Dimitrie O. Paun

On January 27, 2004 08:30 pm, Mike McCormack wrote: > This doesn't pass in Wine yet, but it works on Win2000. If they don't pass under Wine, shouldn't they be marked as todo_wine {} ? Alexandre stated a number of times (with good reason my thinks) that he's not going to commit tests that fail under Wine... -- Dimi.

20 years, 3 months

Variable in Visual Basic

by Savio Ramos

Hi, I am using wine with fake_windows. A Program don't works and return the message below. Any help? []'s Run time error '458' Variable uses an Automation type not supported in Visual Basic Invoking /usr/bin/wine.bin SISUPFOR.exe ... fixme:ole:CoRegisterMessageFilter stub fixme:ole:OleLoadPictureEx (0x4140292c,47552,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958), partially implemented. fixme:ole:OleLoadPictureEx (0x4140292c,1086,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958), partially implemented. fixme:ole:OleLoadPictureEx (0x4140292c,334,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958), partially implemented. fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf86c): stub fixme:ole:OLEPictureImpl_SaveAsFile (0x403b9d58)->(0x403c4168, 0, (nil)), hacked stub. fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf0a0): stub fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf1dc): stub fixme:ole:VarCat Failed to convert right side from vt 8 to VT_BSTR? fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf214): stub fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf214): stub fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf214): stub fixme:ole:CoRegisterMessageFilter stub Wine exited with a successful status -- Savio Martins Ramos Arquiteto Rio de Janeiro ICQ 174972645 Pirataria não! Use GNU/Linux Debian-br #705 Unstable http://www.debian.org

20 years, 3 months

Re: current cvs doesn't compile,winearts,undefined reference to `DSDEVID_DefaultPlayback'

by Ivan Leo Murray-Smith

Problem fixed by patch 10892. Ivan.

20 years, 3 months

Re: current cvs doesn't compile,winearts,undefined reference to `DSDEVID_DefaultPlayback'

by Ivan Leo Murray-Smith

I have [ivan@localhost ivan]$ artsd -v artsd 1.1.3 on Mandrake 9.2, current code doesn't build, make exits with the following error make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/winmm/winearts' gcc -shared -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini winearts.drv.spec.o arts.o audio.o winearts.drv.dbg.o -o winearts.drv.so -L../../../dlls -L../../../libs/wine -lwine -L/usr/lib -ldl -lartsc -lpthread -luuid -L../../../libs/port -lwine_port -lm -lc audio.o(.text+0x4112): In function `wodDsGuid': /home/ivan/Development/Wine/CVS/wine/wine/dlls/winmm/winearts/audio.c:2058: undefined reference to `DSDEVID_DefaultPlayback' collect2: ld returned 1 exit status make[2]: *** [winearts.drv.so] Error 1 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/winmm/winearts' make[1]: *** [winmm/winearts] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls' make: *** [dlls] Error 2 [ivan@localhost wine]$ Maybe caused by patch 10871? Ivan.

20 years, 3 months

current cvs doesn't compile, winearts, undefined reference to `DSDEVID_DefaultPlayback'

by hatky

make[2]: Entering directory `/home/hatky/cvs/wine/dlls/winmm/winealsa' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/hatky/cvs/wine/dlls/winmm/winealsa' make[2]: Entering directory `/home/hatky/cvs/wine/dlls/winmm/winearts' gcc -shared -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini winearts.drv.spec.o arts.o audio.o winearts.drv.dbg.o -o winearts.drv.so -L../../../dlls -L../../../libs/wine -lwine -L/usr/lib -ldl -lartsc -lpthread -luuid -L../../../libs/port -lwine_port -lm -lc audio.o(.text+0x4112): In function `wodDsGuid': /home/hatky/cvs/wine/dlls/winmm/winearts/audio.c:2058: undefined reference to `DSDEVID_DefaultPlayback' collect2: ld returned 1 exit status make[2]: *** [winearts.drv.so] Error 1 make[2]: Leaving directory `/home/hatky/cvs/wine/dlls/winmm/winearts' make[1]: *** [winmm/winearts] Error 2 make[1]: Leaving directory `/home/hatky/cvs/wine/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install. Mandrake Linux 9.2 box....... -- Hatky. Hebrew translator of http://www.mandrakelinux.com/he/ Helper of http://www.phpnuke-israel.org Worshiper of http://www.winehq.org

20 years, 3 months

← Newer
1
2
3
4
5
6
7
8
...
36
Older →

Jump to page:

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 2004