- wine-devel - winehq.org

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

AppDB: great news !
by Andreas Mohr 12 Jul '02

12 Jul '02

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 12 Jul '02

12 Jul '02

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 12 Jul '02

12 Jul '02

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 12 Jul '02

12 Jul '02

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 12 Jul '02

12 Jul '02

> -----Original Message----- > From: Guy L. Albertelli [mailto:galberte@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

Re: Items with size 0
by Dmitry Timoshkov 12 Jul '02

12 Jul '02

"Gregg Mattinson" <gm138242(a)scot.canada.sun.com> wrote: > +#ifndef __SUNPRO_C > THREADINFO ti[0]; > +#endif > } SYSTEM_PROCESS_INFORMATION; At least this one can be replaced by [1] for now, since it currently is not used in Wine and according to the Nebbett's book has very different layout. -- Dmitry.

1 0

Re: Fix nasty little bug in InitializeGenericSF
by Joshua Thielen 12 Jul '02

12 Jul '02

Joshua Thielen wrote: > This patch fixes a little bug that caused heap corruption (ouch!) when > running the Finale 2002 installer. > Urg! I'm sorry, I just noticed that Rein fixed this on Tuesday. I just wasted a lot of time. Josh

2 1

Re: RFC: Re: [ros-kernel] Shell32 and dplax
by Steven Edwards 12 Jul '02

12 Jul '02

--- Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > Steven Edwards a �crit : > > > > > in short, moving to NT architecture is the way > to > > > go, but > > > it'll need some time > > > may be we could also create a metabug on > bugzilla > > > for this > > > and link all known issues to this meta-bug. > > > > I will start a meta bug for this and being to > track > > these issues as I find them. With any luck we will > be > > able to help with these issues in the next few > months. > ok > btw, is this intentional ? (you didn't cc > wine-devel) no it wasnt. but yes I will start a meta-bug for these issues and wait on input from the bugzilla guys as to if they want to group the issues in another way. Steven __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

3 4

Any advice on how to debug this?
by Medland, Bill 12 Jul '02

12 Jul '02

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. However when I try running with native ones I get two debug consoles and the application continues. (Not a problem). Basically the main program starts two other programs as OLE servers and they load and init commctl32.dll. The stack traces in both cases are similar and indicate to me that the processes have ended up executing data. However by the time I get to disassemble the code referred to by the backtrace the code isn't there any longer. What's my best bet for tracking this down? I've tried winedbg with as many BreakOn.. set as possible but the processes seem to disappear from under the winedbg processes Bill

3 2

HEADER order and index issue
by Medland, Bill 11 Jul '02

11 Jul '02

Dear all Before I spend days trying to find out, can someone tell me straight off? There is a problem with the comctl32 header control and I want to know which is the correct solution. The result is that columns af the associated list control are sometimes put in the wrong place. Here's why! It is a known issue that the first column of a listctrl is left-justified. Therefore the Microsoft-accepted way to proceded with the list control is to add a blank left column, add the columns after that with whatever justification is desired and then delete the first column. Assume we aren't doing any clever column reordering. As the columns are added their headers' orders are equal to the indices. But then the first is removed. When we get to HEADER_Refresh it goes to display them in the correct order; good. However there is an implicit assumption in the code that given n columns the orders there will be one column with order 0, one with 1, ... one with n-1. So 1. Is that assumption invalid? If so then I'll change the code to display the columns in the specified order, assuming that the orders may not be sequential. 2. Is that assumption valid? If so then I'll change it so that deleting a column will modify the orders of the remaining ones. Bill

1 0

Re: Notepad - removed help menu items
by Steven Edwards 11 Jul '02

11 Jul '02

I wouldnt recommend this as ReactOS will be adopting some of the wine/programs including help. Now that Eric P has fixed winehlp I'm sure we can find someone sooner or later that will write a help file for this and other applications at some point. Steven --- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > Changelog > Removed help menu items from notepad. I don't > think > anybody will write help for our notepad, so these > menu > items are useless. > > Andriy > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > ATTACHMENT part 2 application/octet-stream name=notepad_help.diff __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

2 1

Bad exe
by admiral coeyman 11 Jul '02

11 Jul '02

Group, While running tests at my end, I found an odd problem that seems to have developed out of the blue. It seems that only 32 bit dos executables will now run on my system. All of the 16-bit executables that I've been using for the past few years generate 'bad exe' errors. I've redownloaded most of the tree and nothing has fixed this problem. Before I look too deep, is this a problem that anybody else has? It's possible that my local tree has been damaged or that my development tools are not right. God Bless, --Robert 'Admiral' Coeyman [I've had vga planets 4.0 running.] -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

4 5

Re: warcraft 3
by Jesse Allen 11 Jul '02

11 Jul '02

Ove Kaaven wrote: > On Wed, 10 Jul 2002, Lionel Ulmer wrote: > > On Tue, Jul 09, 2002 at 06:08:07PM +0200, Matthieu Foillard wrote: > > > Using winex using opengl (compiled from cvs), start using wine > > > path/War3.exe -- -opengl : > > > it prints : > > > fixme:opengl:wglSwapLayerBuffers (): stub ! > > > fixme:opengl:wglSwapLayerBuffers (): stub ! > > > fixme:opengl:wglSwapLayerBuffers (): stub ! > > > > This is fixed in the WineHQ CVS tree. You just need to wait for the > > patch to do the WineHQ => ReWind => WineX path (as it's X11 licensed) :-) > It is? I don't think it said so in > http://www.winehq.com/hypermail/wine-patches/2002/06/0041.html, and Jesse > Allen isn't registered as X11-friendly yet... which is among the reasons > why it hasn't taken that route yet. You can submit the patch to ReWind. =)

1 0

Re: warcraft 3
by Jesse Allen 11 Jul '02

11 Jul '02

Matthieu Foillard wrote: >>> Using wine using opengl (compiled from cvs), start using wine path/War3.exe -- -opengl : fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403aad78,00010023,2):stub fixme:win32:CreateIoCompletionPort (ffffffff, 0000, 00000000, 00000000): stub. then it seems to start fullscreen but does not display anything, so that i must kill it. any ideas ? <<< Okay, have you checked other opengl games under wine? You could run a trace on opengl and see if it's actively running wglSwapLayerBuffers, or other things as well (Create/Destroy context). Did you use the no-cd patch? If nothing comes up with the opengl trace, then you might not be getting past the CD check. Does it minimize the game? This might be interesting if its the case. Please look here where I explain a problem about this: http://www.winehq.com/hypermail/wine-bugs/2002/06/0422.html Basically I said, sometimes opengl apps minimizes when other windows (like a messagebox) become active, and after restoring the opengl window, it produces no output. Here is another interesting note: some people have the same trouble with the movies on real windows like we do on wine. I suggested to rename the movies folder to them, and guess what it worked! But what happens after they do this? the game minimizes, so it's possible this is happening. Here are some references to the problem: http://www.battle.net/forums2/opensupport/posts/ia/27048.shtml http://www.battle.net/forums2/opensupport/posts/fa/27045.shtml Other than that I don't know. I sent Andreas Mohr a more detailed howto, but I pretty much covered everything already. Jesse

1 0

RE: Any advice on how to debug this?
by Medland, Bill 10 Jul '02

10 Jul '02

> -----Original Message----- > From: Andreas Mohr [mailto:andi@rhlx01.fht-esslingen.de] > Sent: Wednesday, July 10, 2002 2:03 PM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Any advice on how to debug this? > > > On Wed, Jul 10, 2002 at 01:11:59PM -0700, Medland, Bill wrote: > > > -----Original Message----- > > > From: Alexandre Julliard [mailto:julliard@winehq.com] > > > > > > That's a common problem with Win9x dlls. It cannot be > completely fixed > > > because we don't control the layout of our address space; > there are > > > some hacks that could be done in the loader to make it > less likely to > > > happen, but I'm not convinced it is worth the trouble. Our efforts > > > would probably be better spent making sure the builtin > versions of the > > > offending dlls work properly. > > > > > > -- > > > Alexandre Julliard > > > julliard(a)winehq.com > > > > > Thanks Alexandre. I guess the lesson is to use NT dlls > wherever possible. > No way. Wine still has lots of problems with NT DLLs, since > they are... > NT DLLs ;) > Wine's support for NT API is too damn incomplete, so you'll > have more luck > with Win9x DLLs in most cases. > Or just choose to not use *any* Windows DLLs. Might help. But that means I would have to fix yet more of the bugs in comctl32.dll.so ;-( Actually what I was doing was trying to run the native comctl32 to see if it corrected the visual bugs so that I would know that it was within that dll. I'll see what I can do about fixing them in a bit. Bill

1 0

RE: Any advice on how to debug this?
by Medland, Bill 10 Jul '02

10 Jul '02

> -----Original Message----- > From: Alexandre Julliard [mailto:julliard@winehq.com] > Sent: Wednesday, July 10, 2002 12:51 PM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Any advice on how to debug this? > > > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > > It looks to me like: > > > > comctl32.dll includes a shared data segment. > > One of the entries in that segment, presumably during the > DllEntry, is > > populated with the address of GetSystemMetrics > > > > A second copy of comctl32 then tries to use that address to call > > GetSystemMetrics > > > > Unfortunately the second process has user32 mapped > somewhere else and so the > > call goes somewhere weird and things fall over. > > > > Any ideas as to what we can do about it? > > That's a common problem with Win9x dlls. It cannot be completely fixed > because we don't control the layout of our address space; there are > some hacks that could be done in the loader to make it less likely to > happen, but I'm not convinced it is worth the trouble. Our efforts > would probably be better spent making sure the builtin versions of the > offending dlls work properly. > > -- > Alexandre Julliard > julliard(a)winehq.com > Thanks Alexandre. I guess the lesson is to use NT dlls wherever possible. Bill

2 1

winedbg font selection?
by Carl Sopchak 10 Jul '02

10 Jul '02

Is there a way to set the font used by winedbg? The font that it is using on my machine is too small with the monitor resolution set at 1600x1200 (which I want to keep). I'd like to bump the size up a few points... Thanks for the help, Carl

4 6

Re: DOSEMU team
by Shachar Shemesh 10 Jul '02

10 Jul '02

WOW, if wine is advanced enough to catch and spread outlook bugs, we must be really moving along. Seriously, though. If anyone here knows "friest", and corresponded with him on the subject of "DOSEMU team", and is using Windows, please check your system. You are infected with a variant of the "klez" virus. Shachar

1 0

RFC: Re: [ros-kernel] Shell32 and dplax
by Steven Edwards 10 Jul '02

10 Jul '02

Note: Forwarded to wine-devel I'm more in support of us chaning wine rather then adapting win9x calls to ReactOS. That being said I have enough trouble writing a 3 line patch so my voice doesnt count to much..."You guys are the programmers, I just break shit." IMHO the way WINE handles certain things is really fubar. A good example besides MapSL and ConvertToGlobalHandle is the way WINE implements PSAPI. All wine psapi does it convert the toolhelp functions already implemented in to the needed format with a wineserver call or two thrown in. If we are going to use wine and not fork the crap out of it then we should fix the 9xisms as we find them. Currently wine has all sorts of ways for doing things, you have win16 apis being called in some places, ntdll in others and then 9xisms all over the place. So far we have MapSL ConvertToGlobalHandle PSAPI DriectX HAL interfaces ? idunno I guess it comes to what can we do to better share code. Currently there is not a chance in hell of us sharing PSAPI in its current state. I started two bugs in wines bugzilla a few weeks ago regarding it. Mabey we should have a meta-bug for making WINE more NT like in "certain" areas. I dont expect the wine projects to make all sorts of changes just for us and not as they are trying to get a 1.0 release. Anyone got any feedback? Mabey we will get more support for this once David and Jason are done with the basic Windowing. Steven > MapSL is in wine kernel32 also, Oh yeah, it's part > of windows 9x > kernel32.dll too. > James __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

4 4

RE: Any advice on how to debug this?
by Medland, Bill 10 Jul '02

10 Jul '02

Thanks Eric > -----Original Message----- > From: Eric Pouech [mailto:eric.pouech@wanadoo.fr] > Sent: Wednesday, July 10, 2002 12:50 PM > To: Medland, Bill > Subject: Re: Any advice on how to debug this? > > > "Medland, Bill" a écrit : > > > > > -----Original Message----- > > So now what do we do. > > > > Having messed about, got a repeatable case and generally > bashed my head > > around I have got to the following unfortunate situation. > > > > It looks to me like: > > > > comctl32.dll includes a shared data segment. > > One of the entries in that segment, presumably during the > DllEntry, is > > populated with the address of GetSystemMetrics > > > > A second copy of comctl32 then tries to use that address to call > > GetSystemMetrics > > > > Unfortunately the second process has user32 mapped > somewhere else and so the > > call goes somewhere weird and things fall over. > > > > Any ideas as to what we can do about it? > hmm bad news... > > did you try to run your app with a NT version (instead of a > Win9x), that > could help (maybe) No, but I have now. (and ignored all the complaints about mixed versions). It works!! I think that this will be the way to go; see Alexandre's reply. > another thought, when your processes disapear under the > debugger, is the > wineserver still up and running (if it crashes, it may explain the > vanishing processes) Yes it was > another solution would be to disable the support for the shared data > segment... but in your case, it could fix this issue but open another > one TOO TRUE!! The app is very dependent upon shared data segments. > > btw, are you sure user32.dll is mapped at another address in > the second > process Yes > another fix would be to force some DLLs to be loaded at fixed > addresses > (user32 could be one of them)... > another question, are you sure the two processes load the > same user32 ? Yes > (could it be that two wine versions coexist and that a > different one is > loaded in each process) ? > > A+ > Thanks for all the help Bill

1 0

RE: Any advice on how to debug this?
by Medland, Bill 10 Jul '02

10 Jul '02

> -----Original Message----- > From: Eric Pouech [mailto:eric.pouech@wanadoo.fr] > Sent: Wednesday, July 10, 2002 4:59 AM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Any advice on how to debug this? > > > > The stack traces in both cases are similar and indicate to > me that the > > processes have ended up executing data. > > However by the time I get to disassemble the code referred to by the > > backtrace the code isn't there any longer. > is most of the cases, it means that the program is no longer > running (it > may > have been killed by the other program) > > > What's my best bet for tracking this down? > as the processes seem to be furtive, using relay traces (and friends) > may be > a better bet to locate the issue, and then perhaps set the bp where > needed > > A+ > Thanks Eric. So now what do we do. Having messed about, got a repeatable case and generally bashed my head around I have got to the following unfortunate situation. It looks to me like: comctl32.dll includes a shared data segment. One of the entries in that segment, presumably during the DllEntry, is populated with the address of GetSystemMetrics A second copy of comctl32 then tries to use that address to call GetSystemMetrics Unfortunately the second process has user32 mapped somewhere else and so the call goes somewhere weird and things fall over. Any ideas as to what we can do about it? Bill

2 1

Meta-bug conversions
by Francois Gouget 10 Jul '02

10 Jul '02

Hi, I propose to use what would hopefully be better concepts to replace the following meta-bugs: * bug 35 - Wine 0.9.0 Meta Bug http://bugs.winehq.com/showdependencytree.cgi?id=35 Instead we could tag all the bug that should be fixed in Wine 0.9.0 with the 0.9.0 target milestone. * bug 395 - Tasklist http://bugs.winehq.com/showdependencytree.cgi?id=395 * bug 455 - FIXMEs http://bugs.winehq.com/showdependencytree.cgi?id=455 * bug 406- Tasklets http://bugs.winehq.com/showdependencytree.cgi?id=406 These three could be replaced by keywords: Tasklist, FIXMEs and Tasklets. Then these bugs can be replaced with a query that returns the bugs that have these keywords. In all cases, the advantages of the alternative methods are: * the above meta-bugs introduce artificial dependencies between bugs * each time a bug changes status, you get an email for the bug, and an email for the corresponding meta-bug * similarly, moving a bug moving from one category to another generates three emails * the new concepts seem a better match Does the above proposal look ok? If so then, once the required keywords are created, I can tag the relevant bugs and retire the meta-bugs (which will create a flurry of emails to wine-bugs in the short term). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

2 1

about XIM support on wine
by rain shaw 10 Jul '02

10 Jul '02

Hi all, I do apply some patches to the wine source according to some tips in bugs library,and I can input chinese in notepad now. But,every time window was created,will the input method popup.For example,if a message box popped up,the xim will popup as well. It seems that we called the XIM related Xlib function every time new window was created. Would u please give me some suggestions about how to disable create and open XIM while create non-text-input related window? in other word,how to determin the x-window that going to be created is a control that need input method ? Thanx!

2 1

Debugger
by Massimo 10 Jul '02

10 Jul '02

Hmmm.... I fiddled a bit with winedbg and found it awful to use.... Maybe I'm too comfortable with visual debuggers :-) There's no plan to make a graphical front-end to it, for example extending DDD or better GVD ? I had a look at GVD sources and docs, and it shouldn't be too difficult to add a supported debugger... It has a quite good support for many external debuggers.... I see only une problem on it, as it seems to me that winedbg opens a new xterm and translates his i/o on it, which can confuse GVD as stated in docs. So, 2 questions : 1) - There's a way to instruct winedbg to not change xterm ? 2) - There's a volunteer with enough skills on winedbg that can help me to write GVD patch ? :-) Regards Max

4 8

Problems with VGA PLANETS 4
by Oliver Ob 10 Jul '02

10 Jul '02

My P4_BUG.log 01 _ Installed Wine run with -v gives "Wine release 20000430" and error "fixme: pthread_atfork" 02 _ Edited /etc/wine.conf c:\windows\Profiles\Administrator\user.dat must be c:\windows\user.dat 03 _ Trying wine /wine/mnt/c/Programme/Play/vgap/Planets4/planets4.exe as "user" gives errors: - fixme: pthread_atfork - what does this mean at all? - fixme:reg:_w95_parse_dkv RegSetValueEx returned: 0x0000000e - err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x401 36fb4 04 _ Building the font metrics takes a LOT of time, god is that slow! And then it fails! fixme:debug:FlushInstructionCache (0xffffffff,0x41410000,0x00006000):stub last address with 6000, 6000 and with a000 - a popup window from wine says "Unhandled exception 0xc0000005 at address 0x24748b56. Do you want to debug it?" and clicking YES results in - err:seh:UnhandledExceptionFilter Couln't start debugger (winedbg 136366288 1414155735) 05 _ The Temporary Directory (as specified in your config file) is NOT writeable - how can "user" have write access to c:\temp now? What user group has rw access to /mnt/c ? 06 _ Running using su -c "see above" works better, so the errors which do not tell me nothing seem to mostly have to do with access rights. Can someone explain those errors to me? Errors are yet some others - fixme:file:AreFileApisANSI (void): stub - fixme:win32:PE_LoadImage We need to perform base relocations for c:\Programme\Play\vgap\Planets4\gug32.dll - fixme:win32:PE_CreateModule Security directory ignored - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - err:menu:MENU_GetMenu invalid menu handle=4d0, ptr=0x4043f27c, magic=0 - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - fixme:bitmap:X11DRV_DIB_GetImageBits_4 from 24 bit bitmap with mask R,G,B 0,0,0 to 4 bit DIB 07 _ Will try to make my first turn using wine + P4 now. Unpacking the RST works. It opens. I can edit the turn. Try to make a TRN file. But now this makes me worry!!!! A popup window speaks to me that the Planets4.exe has been DAMAGED?!! and that I must replace it with a good copy!??!?!?!?!? 08 _ I quit and see these error messages: - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,(nil),0): unimplemented flags: 0x00400000 - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,0x4044f048,1): unimplemented flags: 0x00400000 - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,(nil),0): unimplemented flags: 0x00800000 - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,0x4044f048,1): unimplemented flags: 0x00800000 - fixme:dc:GetDCEx new hrgnClip[9722] smashes the previous [96c2] - fixme:dc:GetDCEx new hrgnClip[96be] smashes the previous [9726] And what now? And whenever I minimalize the wine window with the program I cannot get it back to full size (normally ALT SPACE + X) how to do that? -- *º¤., ¸¸,.¤º*¨¨¨*¤ =Oliver@home= *º¤., ¸¸,.¤º*¨¨*¤ I http://www.bmw-roadster.de/Friends/Olli/olli.html I I http://www.bmw-roadster.de/Friends/friends.html I I http://groups.yahoo.com/group/VGAP-93 I I mailto:VGAP-93-subscribe@yahoogroups.com I I http://home.t-online.de/home/spacecraft.portal I >>> Telek0ma iBBMS - now back online +49.4504.TRSi1/TRSi2 <<<

2 1

PSDRV question
by Carl Sopchak 10 Jul '02

10 Jul '02

I've been trying to get Quicken 2000 Deluxe running in wine. After I figured out that it wasn't finding a DLL for the internet connection (and got that fixed), I started testing the second-most important function of Quicken that I need: check printing. All went well until I tried to print a sample check (to verify alignment), at which point Wine crashed into winedbg. I figured out why: When reading the ppd file, it sets up an *InputSlot for ManualFeed (even though it's not really an InputSlot, but most Win programs treat it as one...). The problem was that, in ppd.c, a Name wasn't given to the slot (but a FullName was), so when ps.c tried to output the header for the InputSlot it crashed (since strlen(NULL) causes a crash). I hacked the AddSlot call to name the slot "Manual", and this seems to work OK. The question that I have is, is this the way that it should REALLY get fixed (does the name matter?), or should something else be done? I'd be happy to correct my hack, if necessary. In either case, I can post the patch to sourceforge, once I know "the right way" this should be handled. Thanks for the help, Carl P.S., I added some TRACE() statements to help me debug this. These can be left in the patch that I post, right?

2 2

DOSEMU team
by friest 10 Jul '02

10 Jul '02

1 0

Re: Support for 24bpp when DDBLT_KEYSRC etc are set
by Lionel Ulmer 10 Jul '02

10 Jul '02

> Change log: added support for 24bpp when the flags > DDBLT_KEYSRC/DDBLT_KEYDEST and company are set. Well, I have the following comment : > + case 3: { > + int last_sy = -1; > + for (y = sy = 0; y < dstheight; y++, sy += yinc) { > + sbuf = sbase + (sy >> 16) * sdesc.u1.lPitch; > + if ((sy >> 16) == (last_sy >> 16)) { > + /* this sourcerow is the same as last sourcerow - > + * copy already stretched row > + */ > + memcpy(dbuf, dbuf - ddesc.u1.lPitch, width); Are you sure that this works ? If you have pixels in the destination surface that are NOT overwritten by the source surface (due to color-keying) you should not copy these from one line to the other. > + } else { > + LPBYTE s,d = dbuf; > + for (x = sx = 0; x < dstwidth; x++, sx+= xinc) { > + DWORD pixel; > + > + s = sbuf+3*(sx>>16); > + pixel = (s[0]<<16)|(s[1]<<8)|s[2]; > + if (pixel < keylow || pixel > keyhigh){ > + d[0] = (pixel>>16)&0xff; > + d[1] = (pixel>> 8)&0xff; > + d[2] = (pixel )&0xff; > + d+=3; Why only increase the destination pixel when the color is not keyed off ? > + } > + } > + } > + dbuf += ddesc.u1.lPitch; > + last_sy = sy; > + } > + break;} The rest of the patch looks OK :) By the way, which game uses 24 bpp ? It's *EVIL* :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

No X11 input events in DGA2 mode
by Andy MacLean 10 Jul '02

10 Jul '02

I was trying to run Starcraft under wine in using the X11 DGA2 mode to get a decent frame rate. I tried running it under various versions of wine and got the same result every time. The problem is that when wine runs the game using DGA2 it ignores all input from the keyboard and mouse and so appears to hang. When running the game with DGA2 support disabled (i.e. not running as root) everything works fine but I get a much lower frame rate. I'm new to wine but I had a stab at fixing the problem which as far as I can see is the following: -> wine creates one X11 display connection for each thread and one 'global' display connection to use for various things like DGA2 which it puts in the 'gdi_display' global variable. The thread specific connections get put in x11drv_thread_data structure pointed to by the driver_data pointer in each thread's thread specific structure. -> wine then switches to DGA2 mode if it can and does an 'XSelectInput' to turn on DGA2 input events. It switches to DGA2 mode using the gdi_display connection so all input events will now come through this connection. -> at some point something asks for new X11 events. It goes into the 'X11DRV_MsgWaitForMultipleObjectsEx' function to poll the X11 display connections for each thread. This ends up calling the 'process_events' function in dlls/x11drv/event.c with the 'x11drv_thread_data' structure for each thread. This is the only function that calls 'process_events', which is the only place that calls any X11 event fetching function outside of 'wineclipserv.c' and 'clipping.c' (which seem do something irrelevant to the dga2 problem). -> but process_events can only look at the thread specific X11 display connections since this is the data it gets passed. I cannot find any code which sets up an 'x11drv_thread_data' structure for gdi_display and XNextEvent is only ever called from inside process_events on data->display. Therefore we never poll gdi_display for X11 events at all so I never get any input. I tested this with some debug output code and wine deffinitely never polls gdi_display for events at any time while running the game. X11DRV_MsgWaitForMultipleObjectsEx explicitly does an XFlush on gdi_display as though it is expecting to have to poll it separately, but it never does ... I tried changing 'process_events' in dlls/x11drv/events.c to the following: static int process_events( struct x11drv_thread_data *data ) { XEvent event; int count = 0; wine_tsx11_lock(); while ( XPending( data->display ) ) { XNextEvent( data->display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #ifdef FIX_DGA2_INPUT while ( DGAUsed && gdi_display != NULL && data->display != gdi_display && XPending( gdi_display ) ) { XNextEvent( gdi_display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #endif wine_tsx11_unlock(); return count; } And this fixed the problem. What's bugging me though is that if this is the correct answer then how do any programs work at all in DGA2 mode? Wouldn't any program hang in the same way as soon as wine switched to DGA2 mode? It would be handy if this were fixed in the wine code so I don't have to keep downloading source and patching so can someone who knows more about the code please let me know if they think this is worth submitting as a patch or point me in the right direction if this is on the wrong track? Thanks in advance, A.

2 2

RE: newbie question
by Medland, Bill 10 Jul '02

10 Jul '02

(BTW HTML email is generally sort of frowned on here) Unix doesn't run windows programs. I suggest you actually read some of the documentation at www.winehq.com <http://www.winehq.com> , especially the Winelib stuff. Basically wine is a Unix program that understands the structure of Windows DLLS and exes. Wine itself runs, loads the dlls and exes into memory and executes them. Some DLLS are replaced by plug-compatible unix so's that interface to the lower levels. So CreateBitmap will eventually result in calls into probably X11 code. Bill -----Original Message----- From: Preetham [mailto:preetham@student.utdallas.edu] Sent: Tuesday, July 09, 2002 5:24 PM To: wine-devel(a)winehq.com Subject: newbie question Hi all: I have a very elementary question. How does the Winodws program run in Unix. For example, i write a program where i call the CreateBitmap() method, what happens. How is a dll called in the unix environment. From what i know, unix dlls are .so files. From the wingdi.h file in the wine\include directory, how does the unix OS know how to resolve the WINAPI call. If i am right, windows dll's are implemented in unix, how is this done. I'm kinda flustered at the moment, would appreciate the help Thanks, Preetham.

4 3

newbie question
by Preetham 10 Jul '02

10 Jul '02

Hi all: I have a very elementary question. How does the Winodws program run in Unix. For example, i write a program where i call the CreateBitmap() method, what happens. How is a dll called in the unix environment. From what i know, unix dlls are .so files. From the wingdi.h file in the wine\include directory, how does the unix OS know how to resolve the WINAPI call. If i am right, windows dll's are implemented in unix, how is this done. I'm kinda flustered at the moment, would appreciate the help Thanks, Preetham.

2 1

RE: Debugger
by Medland, Bill 09 Jul '02

09 Jul '02

> -----Original Message----- > From: Max [mailto:max@veneto.com] > Sent: Wednesday, July 10, 2002 3:21 PM > To: wine-devel(a)winehq.com > Subject: Re: Debugger > > > thanx !!! > I'll try it just now... > Btw, two more questions, if you can answer :-) > SNIP > 2 - Starting an app, while loading dll's and symbols, > winedbg starts showing garbage like this : > > No debug information in 32bit DLL > 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40b55000) > Loaded debug information from ELF > '/usr/local/lib/wine/x11drv.dll.so' (0x40b45000) > failure on > type_info:T(3,1)=s8__name:/1(3,2)=*(0,2),0,32;.vf(3,1):(3,3)=* > (0,23),32;type_info::(3,4)=#(3,1),(0,21),(3,5)=*(3,1),(0,1),(0,21);:qq > > _._9type_info;2A*2;(3,1);;operator=::(3,6)=##(3,7)=&(3,1);:__a > s__9type_infoRC9type_info;0A.;type_info::(3,8)=##(3,5);:RC9type_info; > > 0A.(3,9)=##(3,5);:PCc;1A.;before::(3,10)=##(0,12);:RC9type_inf > o;2B.;name::(3,11)=##(3,2);:;2B.; > > operator==::(3,10):__eq__C9type_infoRC9type_info;2B.;operator! > =::(3,10):__ne__C9type_infoRC9type_info;2B.;; > ~%(3,1); at /1(3,2)=*(0,2),0,32;.vf(3,1):(3,3)=*( > ..............<MORE>................. > Loaded debug information from ELF > '/usr/local/lib/wine/x11drv.dll.so' (0x40b45000) > ..............<MUCH MORE>................. > Unknown type '&' > failure on arg:p(0,25)=&(3,1) at (3,1) > Nothing has been defined <> > failure on bl:p(0,26)=*(2,17) at > ..............<MUCH MUCH MORE>................. > > Is it a known bug or... ? Known issue. The debugger doesn't yet know how to handle the extended information available about C++ classes. (If it really cheeses you I have a patch that basically replaces the detailed garbage with "we don't understand") Bill

1 0

Converting resources from A to W and vica versa
by Shachar Shemesh 09 Jul '02

09 Jul '02

Hi list, Returning after a short absence, I have bug 864 to discuss (I have opened it, and will soon be closing it). The problem was that a program I wrote used "ChooseFont" with a resource. I know those are not supported, but when compiled for Unicode (in VC), the program crashed when trying to open the dialog. Investigation revealed that a function called "ChooseFontWtoA" is called, and that, in turn, assumes that lpTemplateName argument is a string. In practice, this argument was actually an int after being handled with "MAKEINTRESOURCE". I will shortly be sending a fix to wine-patches, but I just wanted to draw your attention to the fact that when handling resources, they are not necessarily strings. Failure to recognize this will crash programs. Worst, and this is not the first place I have seen this, this argument is accessed and handled even if the "CF_ENABLETEMPLATE" flag is not set. In other words, an argument that the MSDN promises will not be touched unless a flag is set can crash a program if not set correctly, even if the relevant flag is not set. In short - pay attention, people. Even when implementing stubs, do read through the arguments list and meanings. Shachar

1 0

'Runtime Error 429', and $ offered for a fix
by Sean Russell 09 Jul '02

09 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I originally posted this to c.e.ms-windows.wine, but I wanted to cross post it to the developers list in the hopes of attracting the proper attention. I appologise if it is inappropriate to offer money for solutions, in this list. My wife is an author. For the past eight months, she's been happily working exclusively on Linux with OpenOffice. She just recently accepted a job doing some tech writing; the application she is to document is a Windows application, made (apparently) predominantly of VB. This application fails to run under a recent Wine. I'm considering two options: (a) Buy a copy of Windows and VMWare, and (b) donate the money I'd spend to a Wine Guru or the Wine project instead, to get the application running. I'd MUCH rather give my money to the Wine project, but this is only an option if I can reasonably hope for a quick turn-around. I'm trying desperately from having to give money to Redmond and incidentally having to maintain a Windows install on her computer :-( Windows would cost me $100, $150 with VMWare. I'll happily donate that to the Wine project, or a Wine developer. It isn't a lot, I know, but if anybody is willing to take this on, please let me know. If it looks like a simple fix, then fine. If it looks like a lot of work, then just let me know and I'll grab a copy of VMWare. I don't have the sourcecode for the application. If you're interested in taking a look at this, email me at 'ser at germane dash software dot com', and I'll send you console dumps, Wine versions, etc. The basic error that the Windows dialog gives us is: Runtime Error '429' ActiveX component can't create object Thanks, sincerely. Sean - --- SER -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD4DBQE9KKOyP0KxygnleI8RAhrWAJiTIgHSli8/GDlIdLKlqMMHBTjyAJoCQV2y 0zty1Z52wQ8TVML1Fn/C5g== =NtZe -----END PGP SIGNATURE-----

2 1

MS' hidden API
by Zhang Shu 09 Jul '02

09 Jul '02

Dear wine developers, I have one question on the development of wine. Long(one or two years) ago I've heard that Microsoft got some hidden APIs in their products of various windows, and they use these APIs in their own applications. I wonder if this is still a problem on their recent product like windows XP. If it is, I guess wine will not be able to run such MS applications which uses hidden APIs. Is this right? And, is wine designed(or its goal is) to run all applications(including MS product and non-MS product) that runs on windows? Please forgive me if this problem has appeared in the past. I just joined this list a couple of days ago. Thank you. Regards, -- Zhang Shu

10 10

wine source doubts
by Preetham 09 Jul '02

09 Jul '02

Hi All: I am a newbie to wine. I have a few queries. 1. I downloaded the wine source from cvs, however, is there any document as to where i can start lookin into the code.? 2. Where is the program(wine loader) that loads a .ece file located in the source. Appriciate the help. Regards, Preetham

2 1

One more try at bug 829 (same surface corruption)
by Tony Lambregts 09 Jul '02

09 Jul '02

After talking with Lionel Ulmer offline I came up with the following patch for bug 829. It includes a hopefully more clear comment of when the corruption can occure and a better set of rules. Change log: fix same surface corruption when no flags are set and areas are the same size Tony Lambregts tony_lambregts(a)telusplanet.net Index: dib.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/dsurface/dib.c,v retrieving revision 1.11 diff -u -r1.11 dib.c --- dib.c 28 Jun 2002 17:32:25 -0000 1.11 +++ dib.c 9 Jul 2002 03:57:37 -0000 @@ -351,6 +351,7 @@ int bpp, srcheight, srcwidth, dstheight, dstwidth, width; int x, y; LPBYTE dbuf, sbuf; + BOOL SameSurfaceOK = TRUE; TRACE("(%p)->(%p,%p,%p,%08lx,%p)\n", This,rdst,src,rsrc,dwFlags,lpbltfx); @@ -474,6 +475,18 @@ sbase = (BYTE*)sdesc.lpSurface+(xsrc.top*sdesc.u1.lPitch)+xsrc.left*bpp; xinc = (srcwidth << 16) / dstwidth; yinc = (srcheight << 16) / dstheight; + SameSurfaceOK = ((src != iface)|| + (sbase >= dbuf)|| + (xdst.top > xsrc.bottom)||(xdst.left > xsrc.right)||(xdst.right < xsrc.left)); + + /* + A little explination: Screen coruption can occure if the following set of circumstances is true + + 1.) Both the source and destination are the same surface. -->(src != iface) + 2.) The start of the source is less than the destination . -->(sbase >= dbuf) + 3.) There is overlap. -->(xdst.top < xsrc.bottom)&&(xdst.left < xsrc.right)(xdst.right < xsrc.left) + This is fixed in the case where no flags are set and the areas are the same size. + */ if (!dwFlags) { /* No effects, we can cheat here */ @@ -482,11 +495,29 @@ /* No stretching in either direction. This needs to be as * fast as possible */ sbuf = sbase; - for (y = 0; y < dstheight; y++) { - memcpy(dbuf, sbuf, width); - sbuf += sdesc.u1.lPitch; - dbuf += ddesc.u1.lPitch; - } + if (SameSurfaceOK) { + for (y = 0; y < dstheight; y++) { + memcpy(dbuf, sbuf, width); + sbuf += sdesc.u1.lPitch; + dbuf += ddesc.u1.lPitch; + } + } else { + sbuf += (sdesc.u1.lPitch*dstheight); + dbuf += (ddesc.u1.lPitch*dstheight); + if (xdst.top == xsrc.top) { /* Are the source and destination on the same line? */ + for (y = 0; y < dstheight; y++) { + sbuf -= sdesc.u1.lPitch; + dbuf -= ddesc.u1.lPitch; + memmove(dbuf, sbuf, width); + } + } else { + for (y = 0; y < dstheight; y++) { + sbuf -= sdesc.u1.lPitch; + dbuf -= ddesc.u1.lPitch; + memcpy(dbuf, sbuf, width); + } + } + } } else { /* Stretching in Y direction only */ for (y = sy = 0; y < dstheight; y++, sy += yinc) { @@ -544,6 +575,10 @@ } } else if (dwFlags & (DDBLT_KEYSRC | DDBLT_KEYDEST | DDBLT_KEYSRCOVERRIDE | DDBLT_KEYDESTOVERRIDE)) { DWORD keylow, keyhigh; + + if (!SameSurfaceOK) { + FIXME("\tSoure and destination surfaces are the same and could cause display problems\n"); + } if (dwFlags & DDBLT_KEYSRC) { keylow = sdesc.ddckCKSrcBlt.dwColorSpaceLowValue;

1 0

Re: SHLWAPI wsprintf - with patch this time
by Alexandre Julliard 09 Jul '02

09 Jul '02

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +dlls/shlwapi/wsprintf.c dlls/user/wsprintf.c > Add decimal double (%f) format specifier to *printf functions. These functions are not supposed to handle %f. If you need %f you have to use the real sprintf, not the wsprintf variants. -- Alexandre Julliard julliard(a)winehq.com

1 0

malloc, heapalloc, etc
by John Lightsey 08 Jul '02

08 Jul '02

Hi all, I've been playing around with the wininet dll to get a windows app I developed running, and I've written a patch that fixes the problems with wininet that I've noticed, but it's an ugly fix and I'd like to get a little clarification about how heap memory is being used in Wine. In dlls/wininet/internet.c InternetOpenUrlA() malloc() is used to put together the HTTP host header in hostreq. The pointer is then passed to HttpAddRequestHeadersA() which creates a buffer with HeapAlloc, copies the contents pointed to by hostreq to it then frees the buffer with HeapFree. Control then passes back to InternetOpenUrlA which does not call free() on the hostreq pointer. So, my question is which is the encouraged way of doing things? HeapAlloc and HeapFree or malloc and free? Also, is the fact that free() was not called on hostreq a bug, or am I missing something? Please be gentle....I'm a Perl programmer, not a C programmer.

2 1

about programming books
by Andreas Mohr 08 Jul '02

08 Jul '02

Hi all, I just created http://wine.codeweavers.com/fom-meta/cache/831.html to list all the Windows programming books I own (16 books ! ;-) I'd be happy if some other people could add an entry, too. That way we'd have an amazing information resource whenever needed. Hmm, I just hope you've got editing capabilities on this page. If you're unable to add something, then please tell me. (or just edit an entry in some FOM category where you're able to edit it, I'll move it there then) Of course I will add more details of the books to the page once I feel bored (actually a separate page per book within a sub category per author would probably be better). Thanks ! -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

1 0

Support for 24bpp when DDBLT_KEYSRC etc are set
by Tony Lambregts 08 Jul '02

08 Jul '02

I am working on implementing the flags under DDBLTFX (Bug 841) and in order to do so I needed to understand how the current code worked. While researching this I came up with this patch for the flags DDBLT_KEYSRC/DDBLT_KEYDEST and company. This patch should be faster then the current code since the switch statement is outside the loop. It also adds support for 24bpp colour. The problem that I have with this is that it assumes stretching in both the x and y directions but from what I understand stretching should only be done if the flag DDBLTFX is set and has the operation DDBLTFX_ARITHSTRETCHY in dwDDFX. Is that right or can Marcus Meissner or Lionel Ulmer explain this to me. Change log: added support for 24bpp when the flags DDBLT_KEYSRC/DDBLT_KEYDEST and company are set. Tony Lambregts tony_lambregts(a)telusplanet.net Index: dib.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/dsurface/dib.c,v retrieving revision 1.11 diff -u -r1.11 dib.c --- dib.c 28 Jun 2002 17:32:25 -0000 1.11 +++ dib.c 8 Jul 2002 19:02:35 -0000 @@ -561,28 +561,54 @@ keyhigh = lpbltfx->ddckDestColorkey.dwColorSpaceHighValue; } - for (y = sy = 0; y < dstheight; y++, sy += yinc) { - sbuf = sbase + (sy >> 16) * sdesc.u1.lPitch; #define COPYROW_COLORKEY(type) { \ - type *s = (type *) sbuf, *d = (type *) dbuf, tmp; \ - for (x = sx = 0; x < dstwidth; x++, sx += xinc) { \ - tmp = s[sx >> 16]; \ - if (tmp < keylow || tmp > keyhigh) d[x] = tmp; \ - } \ - break; } + type *s = (type *) sbuf, *d = (type *) dbuf, tmp; \ + for (y = sy = 0; y < dstheight; y++, sy += yinc) { \ + (LPBYTE)s = sbase + (sy >> 16) * sdesc.u1.lPitch; \ + for (x = sx = 0; x < dstwidth; x++, sx += xinc) { \ + tmp = s[sx >> 16]; \ + if (tmp < keylow || tmp > keyhigh) d[x] = tmp; \ + } \ + (LPBYTE)d += ddesc.u1.lPitch; \ + } \ + break; } - switch (bpp) { - case 1: COPYROW_COLORKEY(BYTE) - case 2: COPYROW_COLORKEY(WORD) - case 4: COPYROW_COLORKEY(DWORD) - default: - FIXME("%s color-keyed blit not implemented for bpp %d!\n", - (dwFlags & DDBLT_KEYSRC) ? "Source" : "Destination", bpp*8); - ret = DDERR_UNSUPPORTED; - goto error; - } - dbuf += ddesc.u1.lPitch; + switch (bpp) { + case 1: COPYROW_COLORKEY(BYTE) + case 2: COPYROW_COLORKEY(WORD) + case 4: COPYROW_COLORKEY(DWORD) + case 3: { + int last_sy = -1; + for (y = sy = 0; y < dstheight; y++, sy += yinc) { + sbuf = sbase + (sy >> 16) * sdesc.u1.lPitch; + if ((sy >> 16) == (last_sy >> 16)) { + /* this sourcerow is the same as last sourcerow - + * copy already stretched row + */ + memcpy(dbuf, dbuf - ddesc.u1.lPitch, width); + } else { + LPBYTE s,d = dbuf; + for (x = sx = 0; x < dstwidth; x++, sx+= xinc) { + DWORD pixel; + + s = sbuf+3*(sx>>16); + pixel = (s[0]<<16)|(s[1]<<8)|s[2]; + d[0] = (pixel>>16)&0xff; + d[1] = (pixel>> 8)&0xff; + d[2] = (pixel )&0xff; + d+=3; + } + } + dbuf += ddesc.u1.lPitch; + last_sy = sy; + } + break;} + default: + FIXME("%s color-keyed blit not implemented for bpp %d!\n", + (dwFlags & DDBLT_KEYSRC) ? "Source" : "Destination", bpp*8); + ret = DDERR_UNSUPPORTED; + goto error; } #undef COPYROW_COLORKEY dwFlags &= ~(DDBLT_KEYSRC | DDBLT_KEYDEST | DDBLT_KEYSRCOVERRIDE | DDBLT_KEYDESTOVERRIDE);

1 0

RE: Wine ODBC compatibilty
by Medland, Bill 08 Jul '02

08 Jul '02

> -----Original Message----- > From: James Juran [mailto:jamesjuran@alumni.psu.edu] > Sent: Friday, June 28, 2002 3:43 PM > To: Robert Damen > Cc: 'wine-devel(a)winehq.com' > Subject: Re: Wine ODBC compatibilty > > > Robert Damen wrote: > > > > Wine, > > I found this address on your website, if it is the > wrong address for > > these types of questions - Sorry!. > > > > I was wondering weather you could answer a question I have > about support for > > Microsoft Office applications. > > The question is about weather wine can emulate (or has its > own version of) > > the "ODBC Data Sources (32bit)" application found in > > c:\windows\Control Panel\ODBC Data Sources > > This application is used to set up DSN drivers for ODBC > access on Access and > > Excel. > > An example of one of the drivers that this application > handles is the MyODBC > > 3.51 windows driver. > > The "ODBC Data Sources" application in the control panel merely > manipulates registry entries. If all you need to do is set > them up, you > can do that easily with regedit. > > If you're wondering if they will work after you set them up, someone > else will have to answer that question :-) > > -- > James Juran > jamesjuran(a)alumni.psu.edu > To the best of my knowledge there is no such application, and it would be strange if there were. The WINE ODBC32 module is merely a wrapper around any suitable Linux ODBC module. For example we use unixODBC. Thus the WINE ODBC module has no real need to access the registry since all the work is being done by the Linux ODBC module. The way that the Linux ODBC module is configure depends upon which one you use. The unixODBC module, for example, uses a odbc.ini and odbcinst.ini file to store its configuration information. Although it does have a graphical configuration tool, with plugins for some database drivers, I prefer to edit the files by hand. That being said, it may be necessary to add some information to the registry for some ODBC-based applications. I do know that Crystal Reports directly accesses the registry for ODBC information rather than asking ODBC itself. HTH Bill

1 0

Re: Question about --debugmsg +snoop
by Massimo 08 Jul '02

08 Jul '02

So if I understand well there's no way now to snoop a single DLL, even putting it in ~/.wine/config ?

1 0

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