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

Re: Wine Ma os X port

by Lionel Ulmer

On Wed, Aug 28, 2002 at 04:51:29PM -0700, Francois Gouget wrote: > Not necessarily. What you propose to do for Wine can be done for the C > and X11 libraries. Then you get an emulator that lets you run x86 Linux > applications on a PPC machine... including Wine. Well, yes... But if you have a system that creates for you a 'translation' layer for all the libraries used by Wine, why not use it directly on Wine itself ? I do not see why it would so much more difficult for Wine than for libc or X11 libs (the only additionnal problem I see would be endianness problems for ressource loading, but a part from that, I see none). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 29, 2002

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

by Duane Clark

Andreas Mohr wrote: > On Thu, Aug 29, 2002 at 09:37:13AM -0700, Duane Clark wrote: > >>Martin Wilck wrote: >> >>>In any case this is relatively minor and we can live without. If we >>>don't patch, we need to be prepared that other people stumble into the >>>problem I had, though. I am still feeling dumb - my wine development was >>>practically stuck for 2 months because of that "wine" file. >> >>Since I also was stumbled for a long period on a similar problem, due to >>specifying a "unix" filesystem, perhaps it would be appropriate in the >>documentation to put some large warnings on that option. > > Well, uh, where have you been recently ? ;-) > That's exactly what we've been doing in several docu places for two years now. > OK, it may not be specified in every relevant docu, but I'd say that at least > 40% of all docs tell this story. > Obviously I should have actually looked at the docs before posting that. It is clearly spelled out in the important spots. Oh well, now that I think about it, it was more than two years ago that I had created the config file that had caused the problem for me.

Aug. 29, 2002

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

by Andreas Mohr

On Thu, Aug 29, 2002 at 09:37:13AM -0700, Duane Clark wrote: > Martin Wilck wrote: > > > > In any case this is relatively minor and we can live without. If we > > don't patch, we need to be prepared that other people stumble into the > > problem I had, though. I am still feeling dumb - my wine development was > > practically stuck for 2 months because of that "wine" file. > > Since I also was stumbled for a long period on a similar problem, due to > specifying a "unix" filesystem, perhaps it would be appropriate in the > documentation to put some large warnings on that option. Well, uh, where have you been recently ? ;-) That's exactly what we've been doing in several docu places for two years now. OK, it may not be specified in every relevant docu, but I'd say that at least 40% of all docs tell this story. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

Aug. 29, 2002

Re: WineDbg and sources

by Eric Pouech

Fabian Cenedese a écrit : > > Hello > > If WineDbg stops it tries to show the actual source line. With my files it > always says "Unable to open file X" Looking into debugger/source.c I found > that it always bails out after stat (returns -1). This seems like it can't find > the file. But if I use wine wcmd I can go there without a problem. My guess > is that stat is a Unix tool and therefore case sensitive so this could arise > a problem. But still after trying out different cases it could never find my > source files. The code looks good as does the (windows-) path it is looking > for the file. The only reason is the failing return value of stat. > Is it important if the files are Dos/Unix style? (Kate says it's Unix). > Does anybody have any ideas? the point is rather that under windows, file names are case insensitive (even if they are stored with lower/upper cases) since the debugger doesn't open files with the Windows interface but with the unix interface, name lookup likely fails we should rewrite it using windows API (or link winedbg with msvcrt instead of glibc) the DOS/Unix style (if you mean the \r\n vs \n issues) shouldn't matter I'll try to give a try later on A+

Aug. 29, 2002

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

by Duane Clark

Martin Wilck wrote: > > In any case this is relatively minor and we can live without. If we > don't patch, we need to be prepared that other people stumble into the > problem I had, though. I am still feeling dumb - my wine development was > practically stuck for 2 months because of that "wine" file. Since I also was stumbled for a long period on a similar problem, due to specifying a "unix" filesystem, perhaps it would be appropriate in the documentation to put some large warnings on that option.

Aug. 29, 2002

Re: Wine Status

by Shachar Shemesh

BiDi - 5% done. me tom wrote: > Hello , > > The Wine Status page located here : > http://www.winehq.com/about/index.php?status > Has gone for about one year now with out updates and I > have volunteer'd to work on bringing this page up to date. > I am new to the Wine Project and I am in need of some assistance to make > sure all changes are corrct and accurate. > Over the next week or so I plan to read over the change log's for the > last year > so I will have a feel of the changes that have been made. > > If current Users/Developers could send me changes that they are aware of > I will start a log of changes against the current page. > > If anyone is willing to help me with this I would be most appreciative . > > Thomas Wickline > > >

Aug. 29, 2002

Re: Wine Status

by Dimitrie O. Paun

I also keep track on individual control status, do you want to integrate that too? -- Dimi.

Aug. 29, 2002

Re: Wine Status

by Andriy Palamarchuk

[skipped] > I am new to the Wine Project and I am in need of some > assistance to make > sure all changes are corrct and accurate. > Over the next week or so I plan to read over the change > log's for the > last year > so I will have a feel of the changes that have been > made. A couple of good sources of information about changes in Wine: 1) Wine Weekly News articles http://www.winehq.com 2) Notes in the release ANNOUNCE file http://cvs.winehq.com/cvsweb/wine/ANNOUNCE Good luck, Andriy Boston, MA, USA __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 29, 2002

WineDbg and sources

by Fabian Cenedese

Hello If WineDbg stops it tries to show the actual source line. With my files it always says "Unable to open file X" Looking into debugger/source.c I found that it always bails out after stat (returns -1). This seems like it can't find the file. But if I use wine wcmd I can go there without a problem. My guess is that stat is a Unix tool and therefore case sensitive so this could arise a problem. But still after trying out different cases it could never find my source files. The code looks good as does the (windows-) path it is looking for the file. The only reason is the failing return value of stat. Is it important if the files are Dos/Unix style? (Kate says it's Unix). Does anybody have any ideas? Thanks Fabi

Aug. 29, 2002

Re: Menu patch breakage

by Andreas Mohr

On Thu, Aug 29, 2002 at 01:03:38PM +0200, Rein Klazes wrote: > Hi, > > Yesterday's destroymenu patch broke a number of applications, among > them Forte Agent. Because I don't quite understand the issues yet, I > have uploaded a +relay,+menu log to > www.xs4all.nl/~rklazes/temp/ag.log.bz2 if anyone wants to have a look. ARGL ! ;) Hah, but I guess I understand it, fortunately ! :-) The program first creates a window: 0806eae8:Call user32.CreateWindowExA(00000000,005c4183 "ForteAgent:Main",417123b 0 "Agent",1acf0000,80000000,00000000,80000000,00000000,00000000,0000008c,0040000 0,00000000) ret=00598ea1 trace:menu:MENU_GetSysMenu loading system menu, hWnd 10025, hPopupMenu 0000 trace:menu:CreateMenu return 00c8 trace:menu:MENU_GetSysMenu hWnd 10025 (hMenu 00c8) then it assigns a menu to this window: trace:menu:SetMenu (10025, 008c); later it does: 0806eae8:Call window proc 0x406fc3dc (hwnd=00010026,msg=WM_MDISETMENU,wp=0000010 4,lp=0000053c) trace:menu:GetMenu for 10025 returning 008c trace:menu:SetMenu (10025, 0104); 0806eae8:Ret window proc 0x406fc3dc (hwnd=00010026,msg=WM_MDISETMENU,wp=0000010 4,lp=0000053c) retval=0000008c And since hmenu 0x008c isn't used any more, it does: 0806eae8:Call user32.DestroyMenu(0000008c) ret=004dd671 trace:menu:DestroyMenu (008c) 0806eae8:Ret user32.DestroyMenu() retval=00000001 ret=004dd671 and thus WIPING OUT the hMenu member of the window, since 0x008c's hWnd member *still* points to the hWnd now owning the 0x0104 hMenu, and thus lets DestroyMenu() wipe out the *old*, wrong hWnd's hMenu member ! So either: a) DestroyMenu should check whether the hMenu's "owner" window still contains the very same menu handle and set it to 0 in this case *only* (i.e.: not eliminate "foreign" hMenu values) or b) a SetMenu should unregister the hWnd member of the hMenu previously assigned to the window (i.e.: set hMenu->hWnd to 0). I'll do some testing to find out which path to take ASAP. For now, I'd assume that b) is the correct answer. Thank you very much for this report ! -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

Aug. 29, 2002