- Wine-Devel - list.winehq.org

IOPL Error?
by David A. Bartmess July 13, 2002

July 13, 2002

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 July 13, 2002

July 13, 2002

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 July 13, 2002

July 13, 2002

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 July 13, 2002

July 13, 2002

(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 July 12, 2002

July 12, 2002

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

AppDB: great news !
by Andreas Mohr July 12, 2002

July 12, 2002

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 :-) -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

3 2

Re: Crash in SHELL32_ParseNextElement
by Gregg Mattinson July 12, 2002

July 12, 2002

No. I came across this crash a few weeks ago when testing an application. Unfortunatly, I can't even remember what caused it to crash. I just remember adding this small change and that fixed things. Gregg >From: "Jürgen Schmied" <juergenschmied(a)lycos.de> >To: Gregg Mattinson <gm138242(a)opcom-mail.canada.sun.com>, wine-devel(a)winehq.com >Date: Fri, 12 Jul 2002 18:03:17 +0200 >MIME-Version: 1.0 >Subject: Re: Crash in SHELL32_ParseNextElement >CC: wine-devel(a)winehq.com >Content-transfer-encoding: 7BIT >Content-description: Mail message body > >Im about to do a major update to the shellfolder stuff. Are you aware of any other >probkems? > >juergen > >On 12 Jul 2002 at 10:11, Gregg Mattinson wrote: > >> ChangeLog: dlls/shell32/shlfolder.c >> - Initialized the pidlOut variable in SHELL32_ParseNextElement to prevent a >> crash in some cases. >> >> Gregg Mattinson >> Co-op Developer >> Sun Microsystems of Canada >> >> > > >--- >juergen.schmied(a)debitel.net >

1 0

Re: SHLWAPI ole32 (delay-load of dlls)
by Jürgen Schmied July 12, 2002

July 12, 2002

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. juergen On 11 Jul 2002 at 21:05, Jon Griffiths wrote: > Hi, > > SHLWAPI updates continued. > > This patch removes the need for direct linking to ole32, which is > only ever late bound by the real SHLWAPI. > > For fear of patch conflicts with myself, I haven't included a patch > to Makefile.in to remove the import and the FIXME. I'll send this in > a later patch, if need be. > > > ChangeLog: > > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > > +dlls/shlwapi/shlwapi_main.c dlls/shlwapi/string.c > Remove the need to directly link to ole32. > > > ===== > "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!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com --- juergen.schmied(a)debitel.net

2 1

Re: Crash in SHELL32_ParseNextElement
by Jürgen Schmied July 12, 2002

July 12, 2002

Im about to do a major update to the shellfolder stuff. Are you aware of any other probkems? juergen On 12 Jul 2002 at 10:11, Gregg Mattinson wrote: > ChangeLog: dlls/shell32/shlfolder.c > - Initialized the pidlOut variable in SHELL32_ParseNextElement to prevent a > crash in some cases. > > Gregg Mattinson > Co-op Developer > Sun Microsystems of Canada > > --- juergen.schmied(a)debitel.net

1 0

RE: Any advice on how to debug this?
by Medland, Bill July 12, 2002

July 12, 2002

> -----Original Message----- > From: Guy L. Albertelli [mailto:galberte(a)neo.lrun.com] > Sent: Thursday, July 11, 2002 5:13 PM > To: Medland, Bill; Wine devel (E-mail) > Subject: Re: Any advice on how to debug this? > > > > ----- Original Message ----- > From: "Medland, Bill" <Bill.Medland(a)accpac.com> > To: "Wine devel (E-mail)" <wine-devel(a)winehq.com> > Sent: Tuesday, July 09, 2002 5:51 PM > Subject: Any advice on how to debug this? > > > > Any suggestions would be appreciated. > > > > The application runs reasonably with builtin > comctl32/commctrl but there > are > > some alignment issues which I suspect might be corrected by > using the > native > > one. > > > Bill, > > Can you document the alignment issues for me with Bugzilla. > Screen shots are > fine. Traces with "+relay,+message,+tid,+win" are also great > for finding > these type of problems. Is the application available in a > demo version?? > > Guy > > Will comply Also I am in the process of fixing it. (Yesterday's submission was part and yesterday's question about HEADER was the other; I will continue today. Bill

1 0