Re: Extending File Dialog to include unix file paths [4/4]
Hi Michael, --- Michael Lin <[EMAIL PROTECTED]> wrote: > If your target platform is windows, don't define the WINE_UNIX_PATHS > flag when you compile and it will all behave > the same as before. It's only when you define WINE_UNIX_PATHS flag that > GetOpenFileNameW() will be mapped > to UnixFSGetOpenFileNameW() for example. Else it will call the same > function as before and shouldn't break on Windows. > WINE_UNIX_PATHS is currently not defined anywhere in WINE, so no one > should see any difference. To see the change, > you have to define that flag in your winelib application's makefile. But your defining UnixFSGetOpenFileNameW in the spec file so the import library will still have that function listed so if I link a dll to that import library its going to fail on Windows even if I am not calling that function. The Windows Linker/Loader is not forgiving like the Unix loader if the symbol is not found in the import table. It seems like Winebuild will need some magic as well if you don't want these function exported all the time. Thanks Steven Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html
Re: Extending File Dialog to include unix file paths [4/4]
Hi Steve, Steven Edwards wrote: --- Michael Lin <[EMAIL PROTECTED]> wrote: --- dlls/commdlg/comdlg32.spec +@ stdcall UnixFSGetOpenFileNameA(ptr) +@ stdcall UnixFSGetOpenFileN Is there anyway for us to have these functions inlined or something rather than exported all the time is there? The reason I ask is that being able to build applications using Wine on Windows and Mingw helps with testing and if we building on Windows using Wine headers and link to the Wine import libs the application will fail running the application on Windows because the Windows dll wont export these functions. If your target platform is windows, don't define the WINE_UNIX_PATHS flag when you compile and it will all behave the same as before. It's only when you define WINE_UNIX_PATHS flag that GetOpenFileNameW() will be mapped to UnixFSGetOpenFileNameW() for example. Else it will call the same function as before and shouldn't break on Windows. WINE_UNIX_PATHS is currently not defined anywhere in WINE, so no one should see any difference. To see the change, you have to define that flag in your winelib application's makefile. You should not need any of this for a Winelib app. Office97 does this where it creates a 32bit dialog with a Win16 look and its needed for backwards compatiblity only. No new application should depend on this behavior and clearly not one that you have the source code to in Winelib. I already broke this in Wine once. Just return GetFileDialog95W. +return GetFileDialog95W(ofn, SAVE_DIALOG, TRUE); } Yeah, I wasn't worried about Win16 look that's why I leave it as such. Might put in a FIXME later, just want to send in some patchs before it gets too big. Michael
Re: [WINEDOCS] Add French translation for Wine's FAQ
On Thu, 2005-05-12 at 16:49 +0200, Francois Gouget wrote: > This patch adds the framework for translating Wine's documentation and > adds a translation of the FAQ to French as a demonstration. No compressed patches, please. Also, the patch is big, and some things are cleaner than others. Let's break it down a bit. > Here is what the framework does: > > * first it moves most of en/Makefile.in to Make.rules.in so that this > code can be shared across the various translations. Well, the reason I didn't do that is for cases like incomplete translations. We can move to Make.rules.in: -- DB2* defines -- the targets (docs, pdf, etc) -- the tar rules The rest we can keep local, see how things evolve. We can always refactor it up. > * the actual translation is stored in a po file, one per documentation > document. So for French we currently have fr/wine-faq.po and later we > will also have wineusr-guide.po and winelib-guide.po. I'm not too hot about it to be honest. SGML is hard on the eye, this .po stuff seems to be even worse. But maybe it's easier to work with due to the various tools. If it makes it easier for you to maintain the translation, I'm cool with it. However, I'm not sure this will be the preferred way for all translators out there, so we shouldn't force it on everybody. > * Using po files lets us track exactly which translation paragraphs > are up to date and which are not. It also lets us leverage the tools > that have been developed around that format such as KBabel and maybe > even make it possible for contributors to translate the documentation > online using tools like Pootle (http://pootle.wordforge.org/), Kartouche > (http://i18n.kde.org/tools/kartouche/) or Rosetta > (https://launchpad.ubuntu.com/rosetta). This is great, but I doubt such tools can tell you *what* changed when something did change (the *what* here is "how did paragraph change") > * The link between the SGML files and the PO files and back is handled > by PO4A (http://po4a.alioth.debian.org/). I'm a bit worried about this one. It's new, debian specific, etc. There's no .rpm for it, and that makes me nervous. Tools like this must be easily available. Even if we go for it, maybe we'll have to keep the generated .sgml in CVS (just like configure). > * So configure.ac checks for the po4a tools. If they are missing then > the translated documentation cannot be built. I also added a > Makepo.rules.in that should be used by Makefiles building translated > documentation. What it does is just include the main Make.rules.in file > and add a couple of rules for generating SGML using PO files, and > extending the 'clean' target. This last bit cannot be put in the > top-level Make.rules.in because it does '$(RM) $(ALLBOOKS:%=%.sgml)' > which would be unfortunate in the en directory. The $(RM)... can remain local, and the rules can go in Make.rules.in. It would be confusing to have too many rule files. > sed -e 's/^<\(article .*\) lang="en">$/<\1 lang="fr">/' -e > 's/^<\(book .*\) lang="en">$/<\1 lang="fr">/' wine-faq.posgml > >wine-faq.sgml || (rm -f wine-faq.sgml && false) Nasty. BTW, the 'lang="en"' part of the patch can go in separately too. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: Extending File Dialog to include unix file paths [4/4]
Hi Michael,
I really like the idea of trying to tie the apps in better for users of Winelib
applications but I
have a few problems. (I should have spoken up when the first of the Unixfs
stuff was going in to
shell32 because I feel it should have been a shellext outsite of shell32 but
now I am off the
subject)
--- Michael Lin <[EMAIL PROTECTED]> wrote:
--- dlls/commdlg/comdlg32.spec
+@ stdcall UnixFSGetOpenFileNameA(ptr)
+@ stdcall UnixFSGetOpenFileN
Is there anyway for us to have these functions inlined or something rather than
exported all the
time is there? The reason I ask is that being able to build applications using
Wine on Windows and
Mingw helps with testing and if we building on Windows using Wine headers and
link to the Wine
import libs the application will fail running the application on Windows
because the Windows dll
wont export these functions.
+BOOL WINAPI UnixFSGetSaveFileNameW(
+ LPOPENFILENAMEW ofn) /* [in/out] address of init structure */
+{
+BOOL win16look = FALSE;
+
+if (ofn->Flags & (OFN_ALLOWMULTISELECT|OFN_ENABLEHOOK|OFN_ENABLETEMPLATE))
+win16look = (ofn->Flags & OFN_EXPLORER) ? FALSE : TRUE;
+
+if (win16look)
+return GetFileName31W(ofn, SAVE_DIALOG);
+else
You should not need any of this for a Winelib app. Office97 does this where it
creates a 32bit
dialog with a Win16 look and its needed for backwards compatiblity only. No new
application should
depend on this behavior and clearly not one that you have the source code to in
Winelib. I already
broke this in Wine once. Just return GetFileDialog95W.
+return GetFileDialog95W(ofn, SAVE_DIALOG, TRUE);
}
Thanks
Steven
Discover Yahoo!
Stay in touch with email, IM, photo sharing and more. Check it out!
http://discover.yahoo.com/stayintouch.html
Re: ERROR_NOT_READY (21) in ne_module.c
Alexandre Julliard wrote: Error 21 in LoadModule16 means that the file exists but is 32-bit, which seems to be the appropriate error in that case. I dunno about LoadModule16() (no means to test it since it's a Win16 function...) but for LoadLibrary16() (which is just a one-line wrapper around the former in wine) at least WinXP returns 0 and sets the errorcode to 87 (ERROR_INVALID_PARAMETER). -flx
Re: Support for binaries that were abandoned by M$, and maintenance hell?
--- Francois Gouget <[EMAIL PROTECTED]> wrote: > Furthermore a lot of '32bit applications' actually use 16bit code either > directly or indirectly (although that may be getting less common these > days). What this means is that if you remove 16bit support it's quite > likely a lot of 32bit applications will stop working. I do wish we could change it though. We could share more code with ReactOS with less hassle on merges if we could figure out a way to split the Win16 code out better for say the edit control. Thanks Steven Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/
Re: Software patents
Jonathan Wilson wrote: Its highly likely that GCC and WINE are already infringing on some software patent somewhere (since its well nigh impossible not to in the current "patent everything you can" climate inside a number of big companies) What makes this particular borland patent any different? My guess: many projects have a "don't tell us about patents, we don't wanna know"-policy to plead ignorance in case they get sued (would this work anyway?) - this one is known (now). Did people actually try to get the code into gcc (without saying "unfortunatly this patch infrings on patent #XXX") before? -flexo
Re: user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote: > > Current window activation code in Wine is not entirely correct. I believe > > that > > might be a part of WM rewrite Alexandre is finishing which at the moment. > > Not really, I'm not aware of any problem with the window activation > code, and I'm certainly not working on that part of the code now. What > problems do you know about? I'm aware of the one problem so far: the message order in process of a window activation/zoom/minimize is different from the Windows one. But that single problem supposedly translates into a bunch of different small problems with window activation. -- Dmitry.
Re: Software patents
Its highly likely that GCC and WINE are already infringing on some software patent somewhere (since its well nigh impossible not to in the current "patent everything you can" climate inside a number of big companies) What makes this particular borland patent any different?
Re: Support for binaries that were abandoned by M$, and maintenance hell?
On Wed, 11 May 2005, Marcus Meissner wrote: [...] 16bit support is deeply integrated into the WINE core and not easy to extract. Furthermore a lot of '32bit applications' actually use 16bit code either directly or indirectly (although that may be getting less common these days). What this means is that if you remove 16bit support it's quite likely a lot of 32bit applications will stop working. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
Re: Bug 2931 (again)
On Thu, 12 May 2005, Mike Hearn wrote: On Wed, 11 May 2005 21:11:40 -0500, Dustin Navea wrote: I was wondering if there was a better way to post them? Ill keep that in mind from now on. Well, I'm a bit dubious as to the value of posting bugs here anyway, we have wine-bugs for that. If it really does motivate people to work on them though then I guess it'd be OK. I think if the bugs have been well diagnosed, which appears to be the case here, it can be useful to bring them to the attention of the developers: we all know that Wine developers tend to know about enough bugs already that they don't really scrub Bugzila trying to find one :-/. But some more information directly in the email could be useful. I was not necessarily thinking about the last comment or the subject line but more: * a more catchy subject than 'bug 2931' (which is not to say that the bug number should not be mention in the subject) * small description of the bug (so that readers at least know if it's a DirectX issue or an ntdll one, a developer working on the former would probably not be interested in bugs related to the latter) * which application is affected * URL to the bug * changelog of the patch that was identified as causing the regression * quick analysis of the problem (if possible) With that information a developper reading only the email will know whether it's worth digging deeper and actually looking at the bug report and patch. Also I think it's good that someone checks and cleans up Bugzilla. Dustin, keep up the good work. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY
Re: Looking for win9x/ME testers
* On Thu, 12 May 2005, Hans Leidekker wrote: > * On Thursday 12 May 2005 00:14, Kevin Koltzau wrote: > > The ole32_test.exe file is linked to missing export NTDLL.DLL:atoi. > > This patch fixes it. ... > Changelog: > Don't import from ntdll. Can someone explain me, please, where would atoi() function be linked now to? I still have not installed MinGW package, so cannot cross-compile winetest and cannot check this myself. :-/
Re: CVS compilation problem
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes: Alexandre> Do 'rm dlls/*.def' and it should work again. Thanks, that worked -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: info please part 2
juan melgarejo wrote: Is there any document or how-to showing: how to run a backtrace using the wine debugger how set debug parameters for wine tracing of program execution how to submit bugs to bugzilla (how to report, content) How to Know proper settings for bugs (when a bug should be a blocker, which bug depends on which other bug, etc) ? I should mention that the wine documentation is somewhat out of date, so generally if you don't already know how to do the things mentioned above, they will give you a rough idea, but some of the parameters have changed (especially on setting debug flags for tracing). While you can still apply, the users who already know how to do the above will obviously have a greater chance to be recruited. Dustin
Re: CVS compilation problem
Uwe Bonnes <[EMAIL PROTECTED]> writes: > I updated yesterday and today. Compiling with todays CVS gives: > ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole > joystick.o keyboard.o mouse.o testlist.o -o dinput_test.exe.so > -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/dinput > -L../../../dlls/ole32 -L../../../dlls/version -L../../../dlls/user32 > -L../../../dlls/kernel32 -L../../../libs -ldinput -lole32 -lversion -luser32 > -lkernel32 -ldxguid -luuid -ldxerr8 > joystick.o(.text+0x543): In function `EnumJoysticks': > /spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:165: undefined > reference to `c_dfDIJoystick' > joystick.o(.text+0x592):/spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:169: > > undefined reference to `c_dfDIJoystick2' > collect2: ld returned 1 exit status Do 'rm dlls/*.def' and it should work again. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Software patents
gslink wrote: Borland probably doesn't even realize that Wine exists although some of the people in Borland are probably very familiar with it. I think you will find this to be true of all big software companies such as IBM and Microsoft. IRC borland had a delphi for linux named kylix which if I remember correctly used wine. They had 2 sets of widgets, native and qt classes to ease development and porting. Here is the article. It also mentions codeweavers... Really old news. http://open.itworld.com/4907/IW010305tckylix/page_1.html So it's not possible that they have never heard about wine before... .Bill
Re: info please
juan melgarejo wrote: Is there any document or how-to showing: how to run a backtrace using the wine debugger how set debug parameters for wine tracing of program execution how to submit bugs to bugzilla (how to report, content) How to Know proper settings for bugs (when a bug should be a blocker, which bug depends on which other bug, etc) ? Regards, Juan The Wine FAQ at http://winehq.org/site/docs/wine-faq/index The Wine User Guide at http://winehq.org/site/docs/wine-user/index The Wine Developers Guide at http://winehq.org/site/docs/wine-devel/index How to help get applications working in Wine at http://winehq.org/site/helping-applications Getting Started with Wine Development at http://winehq.org/site/developer-cheatsheet Those are the best resources. You can also check the wine wiki (although I don't have the address).. Dustin
CVS compilation problem
Hallo, I updated yesterday and today. Compiling with todays CVS gives: ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole joystick.o keyboard.o mouse.o testlist.o -o dinput_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/dinput -L../../../dlls/ole32 -L../../../dlls/version -L../../../dlls/user32 -L../../../dlls/kernel32 -L../../../libs -ldinput -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 joystick.o(.text+0x543): In function `EnumJoysticks': /spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:165: undefined reference to `c_dfDIJoystick' joystick.o(.text+0x592):/spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:169: undefined reference to `c_dfDIJoystick2' collect2: ld returned 1 exit status Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
winefile
Hi, I want to merge some Robert Dickenson's version of winfile (derived from the old winefile code in 2002) in the next time into winefile. At the same time I want to keep the code it in sync between the ReactOS code base and Wine. What do you think about splitting the source file into several smaller modules? winefile.c is quite large with its 4223 lines. Martin
Re: [wine] Re: Software patents
David Lee Lambert wrote: Would Wine be able to proceed if we got the following statement from them? "Borland hereby grants a worldwide, royalty-free, non-exclusive license to use the methods described in U.S. patent 5,628,016 to the current Wine developers when they use the current LGPL source-code for wine, and to anyone who properly recieves a copy of that source-code or properly creates a derivative work based on it when they use said copy or derivative work." I think this would satisfy the conditions in section 11 of the LGPL. In absence of communication from Borland, we might also infer this based on their future public statements. I'm not a laywer, and I don't really want to start a debate on this, but my opinion is: It would need to be granted to gcc, not Wine, since gcc would be generating the exception handling code. To be properly compatible with the GPL, I'd guess it would have to be granted to any project that wished to use it with GPL licensed software, not just gcc. Mike
Re: [wine] Re: Software patents
On Thu, May 12, 2005 at 08:04:57AM -0400, gslink wrote: > The easiest way to resolve this business with Borland is to contact > Borland. They may also have an interest in Wine. If they have no > objection to what Wine wants to do then there is no one else to > complain. They might even help Wine. Borland probably doesn't even Borland may have some intrest in Wine (it can be used to run code produced by their compilers, which helps their potential market-share a bit). However, it could also view Wine as a competitor (especially to their Kylix product). I doubt they'd sue Wine developers over this, but it's possible that they have a reciprocal license that would require them to defend patent #5,628,016. Would Wine be able to proceed if we got the following statement from them? "Borland hereby grants a worldwide, royalty-free, non-exclusive license to use the methods described in U.S. patent 5,628,016 to the current Wine developers when they use the current LGPL source-code for wine, and to anyone who properly recieves a copy of that source-code or properly creates a derivative work based on it when they use said copy or derivative work." I think this would satisfy the conditions in section 11 of the LGPL. In absence of communication from Borland, we might also infer this based on their future public statements. I just don't want to see this turn into another situation like GIF files or PGP 2.x, where one company's patent put all "compatible" implementations on shaky legal ground. -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey resume at http://www.cse.msu.edu/~lamber45/resume.htm
Re: Installing Acrobat Reader 7 and Acrobat in general
Use the native Linux Reader 7 from the Adobe web site. Running Reader 7 under Wine isn't worth the trouble. Acrobat Professional is a different matter. The latest Acrobat Professional that will work on Wine is 5. Both 6 and 7 require dlls that must be supplied from Windows. Seven has copy protect features that actually discourage use on any machine. With some trouble you can probably get 6 to work. It will currently install and with the addition of the missing dlls almost work. If someone wants to patch Wine so that 6 runs it would probably see considerable use.
Re: Software patents
gslink wrote: The easiest way to resolve this business with Borland is to contact Borland. They may also have an interest in Wine. If they have no objection to what Wine wants to do then there is no one else to complain. They might even help Wine. Borland probably doesn't even realize that Wine exists although some of the people in Borland are probably very familiar with it. Havn't they even used Wine to port Kylix? ...let's hope they don't blame Wine for Kylix' failure. ;) -flx
Re: Bug 2931 (again)
Hello, Andreas Mohr wrote: On Thu, May 12, 2005 at 02:58:11PM +0100, Mike Hearn wrote: On Wed, 11 May 2005 21:11:40 -0500, Dustin Navea wrote: I was wondering if there was a better way to post them? Ill keep that in mind from now on. Well, I'm a bit dubious as to the value of posting bugs here anyway, we have wine-bugs for that. If it really does motivate people to work on them though then I guess it'd be OK. Many people don't subscribe to wine-bugs. If we have a few select bugs posted here (ones that are very interesting/ important/critical/whatever), then this can only be a good thing. (as long as it does remain a moderate number of mails!) Regressions bugs are quite interesting especialy if the culprit patch is already known bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Bug 2931 (again)
Andreas Mohr wrote: Many people don't subscribe to wine-bugs. exactly If we have a few select bugs posted here (ones that are very interesting/ important/critical/whatever), then this can only be a good thing. (as long as it does remain a moderate number of mails!) hehe, I was hoping someone would say that! Thanks Dustin
Now Recruiting
Please do not reply to this email with this same subject line unless you are notifying myself that you would like to have an interview. If you need to discuss this more with me, use a subject of "Discuss - Now Recruiting" Attention all users of wine! Have you ever run into a situation where "it worked before, but now it doesnt"? Have you ever wanted to help out the wine project, but either don't know how to program, or don't know how to get started? Have you reported bugs on bugs.winehq.com and gotten frustrated because of the response time? You are not alone! The Wine Project is proud to announce that we are now recruiting for Maintainer/Janitor positions on the Bugzilla Database! Bugzilla Maintainers should: Have a good working knowledge of Linux Know how to run a backtrace using the wine debugger Know how set debug parameters for wine tracing of program execution Know how to submit bugs to bugzilla Know proper settings for bugs (when a bug should be a blocker, which bug depends on which other bug, etc) Have strong interpersonal communication skills, and outstanding customer service skills Programming knowledge/experience is a BIG Plus, but is not required Being able to set aside a minimum of 7 hours a _week_ to work on bugs is a BIG Plus, but is not required This position is for the most part unsupervised, and strictly voluntary, meaning you will not be compensated/paid in any way. An interview does not create any form of contract either express or implied between you and The Wine Project, nor any of it's developers, contributors, subsidiaries, sister projects, or other users. If you feel that you have what it takes, and would like to apply, please reply to this message, and send it to Dustin Navea (Speeddymon at gmail dot com) Thanks and good luck! Wine Developers
Re: Bug 2931 (again)
Hi, On Thu, May 12, 2005 at 02:58:11PM +0100, Mike Hearn wrote: > On Wed, 11 May 2005 21:11:40 -0500, Dustin Navea wrote: > > I was wondering if there was a better way to post them? Ill keep that > > in mind from now on. > > Well, I'm a bit dubious as to the value of posting bugs here anyway, we > have wine-bugs for that. If it really does motivate people to work on them > though then I guess it'd be OK. Many people don't subscribe to wine-bugs. If we have a few select bugs posted here (ones that are very interesting/ important/critical/whatever), then this can only be a good thing. (as long as it does remain a moderate number of mails!) Andreas Mohr
Re: Bug 2931 (again)
Mike Hearn wrote: Well, I'm a bit dubious as to the value of posting bugs here anyway, we have wine-bugs for that. If it really does motivate people to work on them though then I guess it'd be OK. It seems to not necessarily _motivate_ someone to work on a bug, but it does seem to get them fixed faster.. Mainly the fastest fixes are done on regressions, which is pretty much all I report here, with one exception.. See below. The only time I actually post a bug to wine-devel is after a regression-causing patch (or the problematic code in case its not related to a patch) is found. And even then I take a look at it to see if I could come up with a solution. Believe me, there are many more bugs that are reported that dont make it to the list, simply because the user isn't willing/able to either run a regression test, or provide the necessary logs and backtrace. Since I am a maintainer for bugzilla, I figure the more I probe the users for information, the less you will have to. And if we find the problem code, then I forward to you all, in the hopes that it can be easily fixed.. I should probably go back through the whole db looking for bugs that can be closed due to inactivity, like I started to do 4 years ago, but I havent found the time to yet. Hopefully now that all of the bugs I was working on are reported, I can do that on monday and tuesday next week, but I cant guarantee that it will happen, as something seems to always come up at the last minute. *sigh* Either way though, I am posting a recruitment message to wine-users, because we do need some more bug competent db maintainers, which will help reduce the clutter and get bugs we need to work on priority.. Dustin
Re: Bug 2931 (again)
On Wed, 11 May 2005 21:11:40 -0500, Dustin Navea wrote: > I was wondering if there was a better way to post them? Ill keep that > in mind from now on. Well, I'm a bit dubious as to the value of posting bugs here anyway, we have wine-bugs for that. If it really does motivate people to work on them though then I guess it'd be OK. thanks -mike
Re: comctl32: Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg
On Thu, 12 May 2005 02:59:38 -0500, you wrote: > Hey, > > This is a patch for the WM_LBUTTONUP msg problem, but I've taken the > advice of Dmitry and now all messages are dispatched. > > Changelog > * Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg. Patches like this have been proposed before. They are wrong: Windows *does* eat the WM_LBUTTONUP in the mouse track message loop. There are cases when in Wine this mouse tracking is entered, where they are not under Windows thus causing loss of messages. http://www.winehq.org/hypermail/wine-devel/2004/05/0159.html http://www.winehq.org/hypermail/wine-devel/2004/09/0072.html Rein.
Re: Software patents
The whole business of software patents is very likely to explode at any time. There are several software patents on cds and dvds which are so vague that it is impossible to tell exactly what is going on. The licenses to use these patents allow the company issuing the patent to control cd content and to examine it. The first time one of these companies tries to use the license to access DOD classified information there will be a resolution. The easiest way to resolve this business with Borland is to contact Borland. They may also have an interest in Wine. If they have no objection to what Wine wants to do then there is no one else to complain. They might even help Wine. Borland probably doesn't even realize that Wine exists although some of the people in Borland are probably very familiar with it. I think you will find this to be true of all big software companies such as IBM and Microsoft.
Re: Getting rid of LOCAL_ exports
Dimi Paun <[EMAIL PROTECTED]> writes: > I've taken a stab (prototype level) at the LOCAL_Alloc() function > (patch included below). Would such an approach be acceptable? Yes, that should be OK. -- Alexandre Julliard [EMAIL PROTECTED]
Re: comctl32: Make sure a WM_LBUTTONUP msg is dispatched while after a WM_LBUTTONDOWN msg
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > Why WM_LBUTTONUP should be different from other kinds of messages? > I.e. why all messages could not be passed to DispatchMessage? What > if just move DispatchMessageW call right right after PeekMessageW? Actually the whole function looks very suspicious, especially the busy wait for a mouse message. I think this needs to be redone differently. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Installing Adobes Acrobat Reader 7.0 (Windows XP Version I think)
Hi, On Thu, May 12, 2005 at 10:45:06AM +0200, Peter wrote: > Hello, > I try to install the Adobes Acrobatreader 7.0. Your rather normal request for help sounds to me like you're doing this in order to get Acrobat Reader 7 installed, not in order to further Wine development. This is rather questionable, since there is a native Linux version of Acrobat Reader 7 available... Andreas Mohr
Re: msvcrt: implement signals, take 2
Juan Lang <[EMAIL PROTECTED]> writes:
> +switch (sig)
> +{
> +/* Cases that fall through to signal(2) */
> +case SIGABRT:
> +case SIGFPE:
> +case SIGILL:
> +case SIGSEGV:
> +ret = signal(sig, func);
> +break;
You can't do that, this will cause major trouble. MSVCRT signals
should be generated from Win32 exceptions.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: tools/widl
"Ge van Geldorp" <[EMAIL PROTECTED]> writes: > I'm wondering what happened to the reworked widl patch at > http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't > been applied yet, does that mean there's no interest on the Wine side and I > can drop it from my TODO list? There is interest, it's just that there is some suspicious code in there, and it needs someone to verify that it's really correct and not just a copy/paste bug inherited from original patch. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Re[2]: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > Current window activation code in Wine is not entirely correct. I believe that > might be a part of WM rewrite Alexandre is finishing which at the moment. Not really, I'm not aware of any problem with the window activation code, and I'm certainly not working on that part of the code now. What problems do you know about? -- Alexandre Julliard [EMAIL PROTECTED]
Installing Adobes Acrobat Reader 7.0 (Windows XP Version I think)
Hello,
I try to install the Adobes Acrobatreader 7.0.
Now this didn't work it gave me a quite odd message that an unexpected
error occured with a long number.
I tried to run wine with the debug Variable +all.
I never done this before so can anybody help me?
Is the ntdll missing something or is it an bug?
thx in advance
Peter
winedebug geave me at the same point this:
0009:Ret PE DLL (proc=0x7f51,module=0x7f50
L"imm32.dll",reason=PROCESS_
DETACH,res=0x1) retval=1
0009:Call PE DLL (proc=0x76de7698,module=0x76de
L"gdi32.dll",reason=PROCESS_
DETACH,res=0x1)
0009:Call kernel32.__wine_unregister_dll_16(76e39680) ret=76de7872
0009:Ret kernel32.__wine_unregister_dll_16() retval=0007
ret=76de7872
0009:Call kernel32.__wine_unregister_dll_16(76e39698) ret=76deaa02
0009:Ret kernel32.__wine_unregister_dll_16() retval=0008
ret=76deaa02
0009:Call kernel32.__wine_unregister_dll_16(76e396b0) ret=76deace2
0009:Ret kernel32.__wine_unregister_dll_16() retval=0009
ret=76deace2
0009:Ret PE DLL (proc=0x76de7698,module=0x76de
L"gdi32.dll",reason=PROCESS_
DETACH,res=0x1) retval=1
0009:Call PE DLL (proc=0x7705ebd0,module=0x7705
L"advapi32.dll",reason=PROCE
SS_DETACH,res=0x1)
0009:Ret PE DLL (proc=0x7705ebd0,module=0x7705
L"advapi32.dll",reason=PROCE
SS_DETACH,res=0x1) retval=1
0009:Call PE DLL (proc=0x77b02f00,module=0x77af
L"kernel32.dll",reason=PROCE
SS_DETACH,res=0x1)
0009:Call ntdll.RtlEnterCriticalSection(77bde5c0) ret=77b4e3e5
0009:Ret ntdll.RtlEnterCriticalSection() retval= ret=77b4e3e5
0009:Call ntdll.RtlLeaveCriticalSection(77bde5c0) ret=77b4e3f5
0009:Ret ntdll.RtlLeaveCriticalSection() retval= ret=77b4e3f5
0009:Ret PE DLL (proc=0x77b02f00,module=0x77af
L"kernel32.dll",reason=PROCE
SS_DETACH,res=0x1) retval=1
0009:Call PE DLL (proc=0x77eb535c,module=0x77ea
L"ntdll.dll",reason=PROCESS_
DETACH,res=0x1)
0009:Ret PE DLL (proc=0x77eb535c,module=0x77ea
L"ntdll.dll",reason=PROCESS_
DETACH,res=0x1) retval=1
0009:Ret ntdll.LdrShutdownProcess() retval= ret=77b484a2
0009: terminate_process( handle=0x, exit_code=1150 )
0009: terminate_process() = 0 { self=1 }
0009: *killed* exit_code=1150
RE: tools/widl
I'm wondering what happened to the reworked widl patch at http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't been applied yet, does that mean there's no interest on the Wine side and I can drop it from my TODO list? Best regards, Ge van Geldorp.
Re: Re[2]: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
> >> According to native messages sent to app we should redraw window
> >> inside SetActiveWindow.
> > If you have a test app then it should be converted into a Wine message
> > test, there is no other way to prove that your patch is correct.
> I have sent a test in a separate patch. It does verify this statement. The
> test
> I used is an altered version of tests\win.c dumping all messages. Then I
> compared native and wine outputs.
I meant a msg.c test. That's exactly the kind of the test appropriate
for the behaviour you are trying to fix.
> As far as WM_WINDOWPOSCHANGING/ED go, it does depend on Z-order changes that
> Alexandre indicated are up to wm and not critical anyway. My patch will send
> more of these messages than native. But I would think they are important
> enough
> to be sent, especially WM_WINDOWPOSCHANGED.
As I noted in the previous mail, all window management/message handling related
patches require a test case in order to be accepted.
> >> @@ -152,7 +232,7 @@ static BOOL set_active_window( HWND hwnd
> >>
> >> if (IsWindow(hwnd))
> >> {
> >> -SendMessageW( hwnd, WM_NCACTIVATE, (hwnd ==
> >> GetForegroundWindow()), (LPARAM)previous );
> >> +SendMessageW( hwnd, WM_NCACTIVATE, TRUE, (LPARAM)previous );
>
> > Active and foreground windows in win32 are not necessary the same window.
> As it was it was always sending FALSE. Not sure what the deal is here. I would
> think that active window might need to change it's icon. Considering that here
> we do activate window and it should became foreground, this change is correct.
Active and foreground windows are set per thread. If a window does not belong
to a foreground thread it can't activate a window.
> Also SetForegroundWindow actually calls SetActiveWindow any way. So active
> window _is_ foreground window.
> Because earlier in that function we test for previous != hwnd this code being
> reached only when we change active window.
Current window activation code in Wine is not entirely correct. I believe that
might be a part of WM rewrite Alexandre is finishing which at the moment.
--
Dmitry.
Re: comctl32: Make sure a WM_LBUTTONUP msg is dispatched while after a WM_LBUTTONDOWN msg
"James Hawkins" <[EMAIL PROTECTED]> wrote:
> You were right about having the NM_CLICK msg sent in
> LISTVIEW_LButtonUp, and the problem was that a WM_LBUTTONUP msg was
> never sent. This fixes the problem where you had to double click an
> item in the drives list to select it.
>
> Changelog
> * Make sure a WM_LBUTTONUP msg is dispatched after tracking a WM_LBUTTONDOWN
> msg
> --- dlls/comctl32/listview.c 6 May 2005 15:44:32 - 1.409
> +++ dlls/comctl32/listview.c 12 May 2005 05:04:06 -
> @@ -7948,6 +7948,9 @@ static LRESULT LISTVIEW_TrackMouse(LISTV
> else if (msg.message >= WM_LBUTTONDOWN &&
> msg.message <= WM_RBUTTONDBLCLK)
> {
> +if (msg.message == WM_LBUTTONUP)
> +DispatchMessageW(&msg);
Why WM_LBUTTONUP should be different from other kinds of messages?
I.e. why all messages could not be passed to DispatchMessage? What
if just move DispatchMessageW call right right after PeekMessageW?
--
Dmitry.
Re: Re[2]: user32.dll fix and test ShowOwnedPopups
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote: > > Then each owned window will receive 2 WM_SHOWWINDOW messages. Are you sure > > that Windows does it that way? I'd advise to write a message test to verify > > it. > That's exactly what happens. Window receives two WM_SHOWWINDOW messages. One > with lparam indicating a reason for show/hide. And another one with lparam=0, > which indicates native calls ShowWindow and not SetWindowPos directly. > > As for the tests, I could, but I don't think it's that critical. As you can > see, > I just verified that window has to be shown/hidden and not just to receive a > message. Actually a confirmation with a test case is mandatory for not obvious fixes or for fixes which could have side effects. I'd consider all window management/ message handling related patches to be in that category. -- Dmitry.
