wine-devel

wine-devel@winehq.org

3 participants
84472 discussions

Re: Eliminate bogus error messages
by Guy L. Albertelli 14 Jul '02

14 Jul '02

I hate it when the debugging code sneaks out of the house!! Thanks Michael for catching that. Alexandre, please use this version instead Thanks, Guy ----- Original Message ----- From: "Guy L. Albertelli" <galberte(a)neo.lrun.com> To: "Wine Patches" <wine-patches(a)winehq.com> Sent: Sunday, July 14, 2002 12:19 PM Subject: Eliminate bogus error messages > This eliminate ERR messages for messages greater than 0x7fff which are > application dependent message. > > Note Listview and UpDown are not included because they are currently under > repair in my tree. Those fixes will be coming later. > > License: X11 > > Changelog: > Guy Albertelli <<galberte(a)neo.lrun.com>> > > dlls/comctl32/animate.c,comboex.c,datetime.c, > flatsb.c,header.c,hotkey.c,ipaddress.c,monthcal.c, > progress.c,rebar.c,status.c,tab.c,toolbar.c,tooltips.c, > trackbar.c,treeview.c > - Don't issue error message if message number in application > range. >

1 0

Re: Eliminate bogus error messages
by Michael Stefaniuc 14 Jul '02

14 Jul '02

Hello! On Sun, Jul 14, 2002 at 12:19:13PM -0400, Guy L. Albertelli wrote: > This eliminate ERR messages for messages greater than 0x7fff which are > application dependent message. > > Note Listview and UpDown are not included because they are currently under > repair in my tree. Those fixes will be coming later. > > License: X11 > > Changelog: > Guy Albertelli <<galberte(a)neo.lrun.com>> > > dlls/comctl32/animate.c,comboex.c,datetime.c, > flatsb.c,header.c,hotkey.c,ipaddress.c,monthcal.c, > progress.c,rebar.c,status.c,tab.c,toolbar.c,tooltips.c, > trackbar.c,treeview.c > - Don't issue error message if message number in application > range. Index: dlls/comctl32/tab.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/tab.c,v retrieving revision 1.69 diff -u -r1.69 tab.c --- dlls/comctl32/tab.c 20 Jun 2002 22:45:29 -0000 1.69 +++ dlls/comctl32/tab.c 14 Jul 2002 16:04:57 -0000 @@ -1755,6 +1755,8 @@ */ bkgnd = comctl32_color.clrBtnFace; corner = comctl32_color.clrBtnFace; + bkgnd = 0x00c0c000; /* GLA */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + corner = 0x0000c0c0; /* GLA */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Are you sure that this should go in? Makes the tabs in the Minolta Dimage Image Viefer have the color lightblue/tourquoise. Without this (and also with the native comctrl32 or in Windows) the tabs are lightgray. 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

1 0

Re: Fixing a regression test ...
by Duane Clark 14 Jul '02

14 Jul '02

Paul Millar wrote: > ChangeLog: > Replace references to D: (which might not exist) with C: (which we > assume does) > > Index: dlls/kernel/tests/path.c > =================================================================== > RCS file: /home/wine/wine/dlls/kernel/tests/path.c,v > retrieving revision 1.6 > diff -u -r1.6 path.c > --- dlls/kernel/tests/path.c 5 Jul 2002 01:22:28 -0000 1.6 > +++ dlls/kernel/tests/path.c 12 Jul 2002 18:03:17 -0000 > @@ -673,9 +673,9 @@ > ok(lstrcmpiA(SHORTFILE,strptr)==0, > "GetLongPathNameA returned part '%s' instead of '%s'",strptr,SHORTFILE); > /* Otherwise insert the missing leading slash */ > - sprintf(tmpstr,"D:%s\\%s",SHORTDIR,SHORTFILE); > + sprintf(tmpstr,"C:%s\\%s",SHORTDIR,SHORTFILE); > ok(GetFullPathNameA(tmpstr,MAX_PATH,tmpstr1,&strptr),"GetFullPathNameA failed"); > - sprintf(tmpstr,"D:\\%s\\%s",SHORTDIR,SHORTFILE); > + sprintf(tmpstr,"C:\\%s\\%s",SHORTDIR,SHORTFILE); > ok(lstrcmpiA(tmpstr,tmpstr1)==0, > "GetLongPathNameA returned '%s' instead of '%s'",tmpstr1,tmpstr); > ok(lstrcmpiA(SHORTFILE,strptr)==0, Actually, the purpose of that particular test was to check the behavior when the supplied path is on a different drive from the current drive. The current drive is presumably C:. But the test should have tested for the existence of drive D: before using it.

2 3

Re: winedbg font selection
by Carl Sopchak 14 Jul '02

14 Jul '02

On Saturday, July 13, 2002 01:01 pm, wine-devel-request(a)winehq.com wrote: > "Carl Sopchak" <carl.sopchak(a)cegis123.com> wrote: > > It not only doesn't save the setting between runs, it's not saved between > > popping it up in the same run! In fact, changing the setting DOES NOT > > change the font! (At least on my system: current cvs, red hat 7.3) > > It's OK on mine, Slakware 8.0 with almost up-to-date CVS with freetype > 2.0.6 and X 4.1.0 > > > Version or environment dependent problem ? It turns out that the fonts listed on this panel do not all work on my machine. I'm not sure (nor do I really care) where the font list comes from, but some selections do not seem to be available. I found one that works, and I'm all set. Thanks to those that helped... Carl

1 0

Re: SetMenu compatibility issue
by Rob - 14 Jul '02

14 Jul '02

Sorry, please disregard this patch. It causes problems with programs that specify a menu in the window class definition, because CreateWindow calls SetMenu. I believe the IsWindowVisible condition in SetMenu should be replaced with a "Is this window fully created yet", but I don't know a safe way to do that. Rob McClinton _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

1 0

IOPL Error?
by David A. Bartmess 13 Jul '02

13 Jul '02

I'm not sure where to post this question... Please be gentle <grin> I'm trying to run Office10 winword.exe (a full installation on my D: drive) under Mandrake Linux 8.2 from a Windows XP Pro installation drive. The command I'm using is wine -dll ntdll,msvcrt=builtin /mnt/win_d/"Program Files"/Microsoft/Office/Office10/winword.exe The window frame opens up, but then I get a small window that just says "IOPL not enabled Error". I'm a programmer (13 years), so if you need anything like debug text, no problem, just tell me. Can anyone help? If I can get Office XP working, then I'll be set, and WON'T HAVE TO USE WINDOWS! <GRIN> -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love and amusements but not happiness.

2 1

Re: PATCH: FlushFileBuffers / serial
by Rein Klazes 13 Jul '02

13 Jul '02

On Fri, 12 Jul 2002 23:22:13 +0200, you wrote: > + /* MSDN says: If hFile is a handle to a communications device, > + * the function only flushes the transmit buffer. > + */ > + ret = (tcdrain( serial->obj.fd ) != -1); Hmm, doesn't that mean you should use tcflush() instead? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: SHLWAPI ole32 (delay-load of dlls)
by Alexandre Julliard 13 Jul '02

13 Jul '02

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > I should clarify. Versions 6 and higher (XP+) of SHLWAPI are linked > via delayed import to ole32. This is a change from previous versions > because versions 5xs and below could be installed on installations > that didn't have ole32 installed. SHLWAPI used to come with IE, and > as such it was an add on to v3.1+, where sometimes ole32.dll was not > available. The latest versions require ole32, however if Wine is > running as a previous version it should _not_ be a requirement that > this dll be installed. I don't see any need for being compatible that way. Wine always comes with ole32 so it's perfectly acceptable to depend on it, as long as our builtin ole32 does what we need. We just have to make sure that it works with existing native ole32 dlls too, for instance by avoiding imports of functions that only exist in the latest versions; but making it work with a non-existing ole32 is not necessary. > If we should > directly link with ole32 then we should probably remove the FIXME > from Makefile.in. If we follow this path, we should eventually also > link with the other DLLs that version 6 delay loads instead of being > optional as before: apphelp, mlang, comctl32, mpr, msi, setupapi, > userenv, winmm etc. If both the native and builtin versions of these dlls implement what we need, and if you can import them without creating circular dependencies, then yes they should definitely be imported instead of using explicit function pointers. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: SHLWAPI ole32 (delay-load of dlls)
by Jürgen Schmied 13 Jul '02

13 Jul '02

(deleted) > Ifwe should directly link with ole32 then we should probably remove the FIXME from Makefile.in. > If we follow this path, we should eventually also link with the other DLLs that version 6 delay > loads instead of being optional as before: apphelp, mlang, comctl32, mpr, msi, setupapi, > userenv, winmm etc. These are a bit to much dlls whats not on every system. Delay loading ole32 just needs a >= win95 version of ole32 so it shouldn't any problem. The other dlls are (except comctl32) are a problem because we can't expect them to be here. If there is no ole32 wine loads the built in as a fallback. I think it's safe to do a delay loading there. juergen > Cheers, > Jon > > Alexandre Julliard <julliard(a)winehq.com> wrote: > "Jürgen Schmied" writes: > > > This is not completely right. shlwapi loads ole32 per delay-load what > > means nearly its linking against it. We don't have anything similar at > > the moment. I don't think we should do anyting by function pointers. > > Maybe we could generate stubs during the build process to implement > > delay loading. It don't looks to hard to implement. > > It's already implemented, you just have to list them as DELAYIMPORTS > instead of IMPORTS in the makefile. > > -- > Alexandre Julliard > julliard(a)winehq.com > > > "Don't wait for the seas to part, or messiahs to come; > Don't you sit around and waste this chance..." - Live > > jon_p_griffiths(a)yahoo.com > > > Do You Yahoo!? > New! SBC Yahoo! Dial - 1st Month Free & unlimited access --- juergen.schmied(a)debitel.net

1 0

HeapWalk generated FIXME
by Lanny DeVaney 12 Jul '02

12 Jul '02

Excuse the newby question, but it appears HeapWalk in memory/heap.c calls RtlWalkHeap in dlls/ntdll/heap.c and this in turn is generating fixme messages (lots of them since it appears this is called in a loop.) Can someone enlighten me as to what the problem is, and why one would see the "not fully compatible" fixme messages from RtlWalkHeap. Thanks, Lanny DeVaney

1 0

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