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

Re: Patch to restore iconified window

by Duane Clark

Alexandre Julliard wrote: > Duane Clark <dclark(a)akamail.com> writes: > > >>Unlike most other apps, when iconified fpga_editor triggers >>X11DRV_ShowWindow() with a cmd==SW_HIDE, to hide the window. When >>X11DRV_MapNotify() was subsequently called, it did nothing because >>WS_VISIBLE was not set. This patch fixes that. >> >>I've been using this patch with everything I run for about 5 months now. >> >>Log message: >> Fix restoring of windows that were iconified with SW_HIDE. > > > Well, SW_HIDE is supposed to hide the window, not iconify it, so we > are not supposed to get a MapNotify at this point. What is probably > missing is proper handling for hiding an iconified window. > More particularly, I see that the ShowWindow function in Wine first calls a user function and then sends the message (WM_WINE_SHOWWINDOW, cmd) to the window. Most apps don't seem to have a user function, so I guess the later message iconifies the window. In the case of Xilinx, there is a user function that just does: 0806f758:Call window proc 0x5f401b81 (hwnd=00010021,msg=WM_SHOWWINDOW,wp=00000006,lp=00000000) It is within this call that the X11DRV_ShowWindow() with a cmd==SW_HIDE is called, which in turn calls trace:win:SetWindowPos hwnd 10021, after 0, 0,0 (0x0), flags 00000097 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_NOZORDER SWP_NOACTIVATE SWP_HIDEWINDOW 0806f758:Call x11drv.SetWindowPos(404863c8) ret=4077aa2e Then all this returns and Wine sends the (WM_WINE_SHOWWINDOW, cmd) message, which does another SetWindowPos. So the SetWindowPos command is sent twice, though I haven't figured out whether that is the problem.

Aug. 28, 2002

Re: Need to know some macro values

by Andriy Palamarchuk

Dmitry, one of the ERROR_ constant values you provided to me looks suspicious: ERROR_AUDITING_DISABLED c0090001 All other error codes have much lesser values (the biggest is 14011 - 0x36bb). The value for this error code reminds me values for STATUS_ constants. Could you check if this is correct value? Is it definend in header file with other ERROR_ constants or with STATUS_ constants? Thank you for help, Andriy __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 28, 2002

Re: BreakOnDllLoad crashes Wine

by Eric Pouech

> Has anyone else had this problem? same here. a dirty hacked fix is attached. I'll post later on a decent fix to this pb A+ Index: debugger/winedbg.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/winedbg.c,v retrieving revision 1.64 diff -u -r1.64 winedbg.c --- debugger/winedbg.c 2 Aug 2002 19:00:53 -0000 1.64 +++ debugger/winedbg.c 28 Aug 2002 17:33:20 -0000 @@ -600,7 +600,8 @@ if (!DBG_IVAR(BreakOnAttach)) break; } - DEBUG_context.ContextFlags = CONTEXT_CONTROL + handle_execpt: + DEBUG_context.ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER #ifdef CONTEXT_SEGMENTS | CONTEXT_SEGMENTS @@ -764,6 +765,7 @@ { DEBUG_Printf(DBG_CHN_MESG, "Stopping on DLL %s loading at %08lx\n", buffer, (unsigned long)de->u.LoadDll.lpBaseOfDll); + goto handle_execpt; ret = TRUE; } break;

Aug. 28, 2002

"conformance" tests succeeding in TODO block ...

by Paul Millar

Hi, The test in dlls/kernel/tests/path.c:360 succeeds despite being marked "todo". path.c:360: Test succeeded inside todo block: GetTempPathA should not have modified the buffer Trivial diff not included :) Cheers, Paul. ---- Paul Millar

Aug. 28, 2002

Re: Return value GetStockObject

by Vincent Béron

Le mer 28/08/2002 à 11:10, Fabian Cenedese a écrit : > Hi again > > In my app I try to get a handle to a system font with following call: > HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); > If the call succeeds it should return a handle to the requested object, > otherwise zero. In Windows I get something like 0x018A000E (looks ok), > but in Wine I get 0x0000009E. Even not zero I can't imagine that this is > a valid handle (address). ANSI_FIXED_FONT is never really used in Wine, > only SYSTEM_FONT. > Is this an error or am I barking up the wrong tree? In Wine, handles are not (yet) all void * (see bug #90). Even then, it doesn't mean a handle is a valid heap address; I know there are a couple places in Wine where they are used as an index in an array locating all objects of a kind. It doesn't exactly follow the Windows convention, but I think handles are supposed to be passed back to APIs, not handled (dereferenced) directly by apps. So 0x0000009E doesn't strike me as bad. If you use it in calls to font APIs, does it work correctly? Vincent

Aug. 28, 2002

DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Martin Wilck

I wrote on 2002-06-27: > > $ make test > > /home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so' > > make: *** [tests/alloc.ok] Fehler 1 > > Am I the only one with this problem? Or is it so trivial that I should > have figured it out? I have finally figured this out. It has to do with some (intentional?) DOSFS_FindUnixName() weirdness. My wine sources are in a directory /home/martin/Software/Wine/CVS/wine. /home/martin is my Windows drive Y: Now in /home/martin/Software, I have subdirectories "Wine" and "wine". DOSFS_FindUnixName() uses "wine" because a) DOSFS_ReadDir returns it first, b) The DOS short names match (the Unix names obviously don't). Since "wine" is the wrong path, the search fails shortly after. This happens even if I set the Filesystem type of drive Y: to "unix". I guess this is the right thing to do on Windows-style file systems, but should it be this way on a "unix" file system, too? The patch below does what I'd consider "sane" behaviour on Unix. Alternatively, on a "unix" filesystem, one could search the whole directory for exact matches, and try short names only if that fails. Martin Index: dos_fs.c =================================================================== RCS file: /home/wine/wine/files/dos_fs.c,v retrieving revision 1.117 diff -u -r1.117 dos_fs.c --- dos_fs.c 27 Aug 2002 01:13:59 -0000 1.117 +++ dos_fs.c 28 Aug 2002 16:27:47 -0000 @@ -760,7 +760,7 @@ if (!strncmpiW( long_name, name, len )) break; } } - if (dos_name[0]) + if (dos_name[0] && ignore_case) { /* Check against hashed DOS name */ if (!short_name) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Aug. 28, 2002

Contact info / Leaving Sun

by Gregg Mattinson

Unfortunatly, this is my last week at Sun. I will no longer be able to submit Sparc / Solaris patches, but I will probably continue working on Wine from home on i386 / RedHat. If anyone needs to contact me, my home email address is grmattin(a)uwaterloo.ca Thanks, Gregg Mattinson Co-op Developer Sun Microsystems of Canada

Aug. 28, 2002

Return value GetStockObject

by Fabian Cenedese

Hi again In my app I try to get a handle to a system font with following call: HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); If the call succeeds it should return a handle to the requested object, otherwise zero. In Windows I get something like 0x018A000E (looks ok), but in Wine I get 0x0000009E. Even not zero I can't imagine that this is a valid handle (address). ANSI_FIXED_FONT is never really used in Wine, only SYSTEM_FONT. Is this an error or am I barking up the wrong tree? Thanks Fabi

Aug. 28, 2002

Re: New win api docs

by Andreas Mohr

On Wed, Aug 28, 2002 at 08:04:41PM +0900, Dmitry Timoshkov wrote: > "Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > > > here is the documentation for the API's that m$ had to disclose after > > the settlement: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/… > > And nothing regarding undocumented comctl32 interfaces... > > Almost all disclosed APIs are already known or useless. Well, did you expect otherwise from a company known to be in bed with government ? William B. Gates should probably do a name change to "Bill of Rights". </sarcasm> Well, but at least they did publish some interfaces, which is actually more than I expected from such a company. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

Aug. 28, 2002

Re: New win api docs

by Michael Stefaniuc

On Wed, Aug 28, 2002 at 08:16:36AM -0400, tom wrote: > Dmitry Timoshkov wrote: > >"Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > >>here is the documentation for the API's that m$ had to disclose after > >>the settlement: > >>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/… > >And nothing regarding undocumented comctl32 interfaces... > > > >Almost all disclosed APIs are already known or useless. > Yea here is a nice link : http://www.theregister.co.uk/content/4/26803.html > > It tell's the real story about the API documentation ;-) Yes, i've seen it too on http://www.heise.de/newsticker/data/ps-28.08.02-000/ (in german only) but sent the email before I've read the lower part of the message (sorry to have spamed the list). bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 28, 2002