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

Re: SetMenu compatibility issue

by Rob -

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

July 14, 2002

Re: IOPL Error?

by Uwe Bonnes

>>>>> "David" == David A Bartmess <dingodave(a)edingo.net> writes: David> I'm not sure where to post this question... Please be gentle David> <grin> I'm trying to run Office10 winword.exe (a full David> installation on my D: drive) under Mandrake Linux 8.2 from a David> Windows XP Pro installation drive. David> The command I'm using is wine -dll ntdll,msvcrt=builtin David> /mnt/win_d/"Program Files"/Microsoft/Office/Office10/winword.exe David> The window frame opens up, but then I get a small window that David> just says "IOPL not enabled Error". David> I'm a programmer (13 years), so if you need anything like debug David> text, no problem, just tell me. David> Can anyone help? If I can get Office XP working, then I'll be David> set, and WON'T HAVE TO USE WINDOWS! <GRIN> -- David A. Bartmess David> Software Configuration Manager / Sr. Software Developer eDingo David> Enterprises You don't tell whether you did programm on windows. Anyways, do a relay log, search for the call to the messagebox with the said error and look what (miss)happend above. Try also with native msvcrt, because builtin msvcrt still has many week points. And clean out your registry from loading native hardware drivers. On second thought, IOPL smells for direct hardware access, probably requested by some driver trying to load. The relay log might help finding out what registry entry or ini file entry causes this driver to load. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 13, 2002

Re: PATCH: FlushFileBuffers / serial

by Rein Klazes

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

July 13, 2002

Re: SHLWAPI ole32 (delay-load of dlls)

by Alexandre Julliard

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

July 13, 2002

Re: Fixing a regression test ...

by Paul Millar

On Fri, 12 Jul 2002, Duane Clark wrote: > Paul Millar wrote: > > ChangeLog: > > Replace references to D: (which might not exist) with C: (which we > > assume does) [cut: old patch] > 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. Ooops. > The current drive is presumably C:. In my case, the current drive is F: but C: exists so that bit works fine. > But the test should have tested for > the existence of drive D: before using it. Ok, so if I've understood this correctly, some tests check behaviour with whatever the current drive is (assumed to be C:), and some others check behaviour with some other drive (currently D: is assumed to be valid). I'll submit another patch that should remove these assumptions. The patch works for me, but you might like to check I've not negated any of the tests: I'm not sure I follow exactly what's being tested .. Ta, Paul. ---- Paul Millar

July 13, 2002

Re: SHLWAPI ole32 (delay-load of dlls)

by Jürgen Schmied

(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

July 13, 2002

HeapWalk generated FIXME

by Lanny DeVaney

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

July 12, 2002

IOPL Error?

by David A. Bartmess

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.

July 12, 2002

Re: AppDB: great news !

by Francois Gouget

On Fri, 12 Jul 2002, Roland wrote: > At 01:05 PM 7/12/02 +0200, Andreas Mohr wrote: > >Hi all, > > > >I just wanted to let you know that the appliation database > >(http://appdb.codeweavers.com) just managed to reach 1000 entries !! > > > >I think that's a really great thing :-) > > Yes, > unfortunately not all of those 1000 entries really work. I think it would > be nice to have a section of apps that work FLAWLESSLY. If we get that > number to 1000 it will be another thing :)) Look for applications with a rating of 5. For instance in a fake_windows configuration: http://appdb.winehq.com/stdquery.php?fields%5B%5D=appFamily.appId&fields%5B… And remember, preventing rating inflation is the responsibility of everyone. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

July 12, 2002

Re: AppDB: great news !

by Roland

At 01:05 PM 7/12/02 +0200, Andreas Mohr wrote: >Hi all, > >I just wanted to let you know that the appliation database >(http://appdb.codeweavers.com) just managed to reach 1000 entries !! > >I think that's a really great thing :-) Yes, unfortunately not all of those 1000 entries really work. I think it would be nice to have a section of apps that work FLAWLESSLY. If we get that number to 1000 it will be another thing :)) Roland

July 12, 2002