Re: [website] Added templates/zh-cn/cvs.template translation
-- On Sat, Aug 17, 2013 09:02 BST Frédéric Delanoy wrote: On Sat, Aug 17, 2013 at 5:57 AM, xulixin xulixin1...@gmail.com wrote: Should I change my name's spelling to Lixin Xu, or LiXin Xu, or other format? Not sure, most people (at least non-Chinese) use firstname lastname convention, but I guess you should use the same convention as other Chinese-speaking committers. Here's a list I extracted from AUTHORS file that *look* Chinese to me (don't know if they're really Chinese, or Korean, or from another Asian country): Chae Jong Bin Cheer Xiao Chia-I Wu Hwang YunSong (황윤성) Jau-Horng Chen Jay Yang Qian Hong Qingchuan Wang Qingdoa Daoo Shi Quan He Wei-Lun Chao Weisheng Li Xiang Li XueFeng Chang Yong Chi Yuxi Zhang Zhangrong Huang Zhan Jianyu Hope this helps, Frédéric Delanoy Many had replied but few had touched the _main_ issue: it is a matter of policy that patches of an anonymous origin to Wine are categorically rejected. The Linux kernel also has a similar policy. This policy is due to past threats of copyright/intellectual-property infringements and possible cause of contamination from people who may have privileged access to proprietary technology. So a real name is needed for any patches. As already discussed, xulixin is a real name - as it appears on official documents, passports, etc. Although for the benefit of Western custom, Xu Li-Xin, or Xu Lixin, or Lixin Xu or Li-Xin Xu might make it more obvious, and make some people happier. Ultimately it is Alexandre's call, what is considered a real name. Anyway, the git command to set a default user name for generating patches is, e.g. for mine: git config --global user.name Hin-Tak Leung (this writes to ~/.gitconfig, which is a text files that one can edit by hand as well). See man git-config for details. Without --global, these config's are set per repository. e.g. you may use different names and e-mail addresses for internal (job-wise) work and external (open) work. I also have a few other global configs of my own; the equivalent of these two are probably useful to most people: git config --global ui.color true and git config --global core.editor emacs (the former sets colorization on for git log, git diff, etc; I find it useful of having diff's colorized - that assumes that you do all your development work on a terminal that's color-capable (most recent linux consoles/terminals are); the latter sets the default editor to emacs, when composing commit messages. You may want to set it to your favorite editor, whichever that is.).
Re: [website] Added templates/zh-cn/cvs.template translation
On Fri, 16/8/13, Frédéric Delanoy frederic.dela...@gmail.com wrote: Subject: Re: [website] Added templates/zh-cn/cvs.template translation To: xulixin xulixin1...@gmail.com Cc: Wine Devel wine-devel@winehq.org Date: Friday, 16 August, 2013, 10:59 On Fri, Aug 16, 2013 at 8:13 AM, xulixin xulixin1...@gmail.com wrote: From 860262aed3d58f42012e6dd5264eb29bd29deffb Mon Sep 17 00:00:00 2001 From: xulixin xulixin1...@gmail.com Date: Fri, 16 Aug 2013 13:56:36 +0800 Subject: add templates/zh-cn/cvs.template snipped the real name is required when sending patches. snipped I believe he did give his real name. Xu is a common surname in China (Not sure about Xin, probably also a less common one!). Most Chinese names consist of 3 syllables, a single-syllable surname and a double-syllable first name. Double-syllable surname are less common, but single-syllable first names are also quite popular in recent years; So you expect most Chinese names to be in 3 syllables, fewer in just two, and an even smaller number in 4. Xu Li-Xin (surname Xu, first name Li-Xin) is a conceivable real name. It is probably also conceivable that it should be interpreted as firstname Xu-Li surname Xin. Yes, with a population of 1.3 x 10^11, and using mostly 3 syllables, collisions are extremely common in China, after romantisation from Mandarin pronunciations.
cygwin's fork Re: [wine-devel] Re: Bug 24018 which appears to be a ... for running Cygwin on Wine
--- On Mon, 1/7/13, David Laight da...@l8s.co.uk wrote: On Mon, Jul 01, 2013 at 06:13:26PM +0200, Peter Rosin wrote: I would like to point out that it seems that the current bug does not appear to be *in* setup.exe, but rather occurs when setup.exe runs a bash post-install script, where the bash.exe that interprets the script depends on cygwin1.dll. If my analysis is correct, the bug would occur also when duplicating the actions of setup.exe manually. If you read into what cygwin does when trying to emulate fork() it is surprising it works at all! Putting some effort into getting the shell (be it bash or an ash derivative) and gmake to use posix_spawn() instead of fork() and adding posix_spawn() to cygwin (for which patches are avaiable) would speed up cygwin no end and probably avoid some of these bugs (and the random fork failed errors). One day I'll get annoyed at some issues with cygwin and start fixing them! (Like getting ^C to work for windows console programs in mintty windows.) Yap. It is fork/exec, the whole thing around process ids, and stat, inode emulation, as well. It is just not setup.exe - post-install scripts are per-package items and some packages don't have them. That has been hinted at a few times by the cygwin developers who answered and me. It is easier to see what the problem is (or what the problems are), by manually unpacking the installing packages and running the scripts by hand - as the cygwin developers had already suggested. And it is even easier by-passing it, if one just wants a cygwin installation to play with, by copying from a windows box. Being able to get through installation, or obtaining an installation, does not change the fact that there are fundamental technical reasons that some part of cygwin does not work well in wine. Not without some serial rewrite in cygwin *and* wine. cygwin did run on win98 . I used cygwin on win98 regularly then. posix_spawn() wasn't available on the 95/98/ME family. Since cygwin works well enough on genuine windows (..more or less...), that it can be improved/rewritten does not say the issues are less of a wine problem.
Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Mon, 1/7/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: ... I hope your negative attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows. ... Look. You have been advised a few times, that it is possible and even easy to bypass installation-related problems and been given brief instructions on how to do so; you have also been told, *many times*, and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list. Going personal and accusing others of being biased is not a way of getting help. If you have bothered to look it up as you claim to do, while I have a formal association with mingw, I have made absolutely no contribution to mingw at all, ever; whereas I have made some patches available, etc to cygwin's GNU findutils (merged into coreutils eventually), LaTeX, emacs/xemacs, over a decade ago. My history with cygwin is about twice as old as my association with mingw. That's a matter of public record. If you bother to look further, the main reason is really that cygwin is a commercial entity - part of Redhat now, but was a privately-own company until 13 years ago when Redhat acquired part of it. Formal membership to cygwin has always been different from how formal membership to mingw operates, for that very reason; and that I live locally to where that company was, (and the part of cygwin that Redhat choose not to buy, still is), and probably know or have met some of the cygwin developers in person. I don't have the fortune to meet/know many, but they have my respects. The cygwin people would have told you the exact same thing: running mingw on wine is fair easier and more straight-forward, and there are very simple technical reasons why that is the case; and that cygwin is not mingw, and there are important difference where wine is concerned. You seem to assume the difference between cygwin and mingw is small - they are not, and really a world apart, as far as wine is concerned. Going via exaggeration/sensationalist (showstoppers) or personal attack is not going to win you any help. FWIW, on the latter point, few are interested in reading a 20-line introduction about your life (or lack of it) every time at the bottom of your posts. That's another thing that put people off from helping you.
How not to ask for help Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a ... for running Cygwin on Wine
--- On Tue, 2/7/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Going personal and accusing others of being biased is not a way of getting help. ...In short, I have a prejudice against anyone stating anecdotal evidence concerning issues with _any_ open-source software if they don't back up that anecdotal evidence with a solid bug report. For example, you stated some anecdotal evidence about a bug in Cygwin cat, but when I requested a reference for your associated bug report to Cygwin you were silent. That told me a lot. ... That tells you only one thing: I don't care about Cygwin enough now to bother filing one more bug among those already filed. My time is more valuable than that. 13 years ago I used it daily and I made my own contributions, and that was then. Half of the time I file bugs on various projects because I have patches to attach/send, and this is not the case with cygwin now, and will not be. I don't intend to file a bug because I don't intend spend time fixing it. You wish. I am not the one asking for help - you are. Launching personal attacks on people trying to help you is just not the way to do it. Nor is exaggeration, nor is 20-line of [lack of] life included in every e-mail. If you want help, ask for it, nicely, and keep it short.
Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Fri, 28/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: ... However, because of the Cygwin fork bug, Cygwin on Wine has largely been untested for the last three years so this could be a good opportunity to do such testing for the combination of Cygwin (with the fork fix) and recent Wine in case some Wine regression is discovered by such testing. what You really don't get it. setup.exe is simply *not* a necessity for putting a cygwin installation under wine. There are many other ways of installing cygwin into wine without running cygwin's installer. The easiest is simply to copy the entire installed directory, plus importing a few registry entries, from a genuine windows box which has cygwin on. (There are many people who bundles bits of cygwin with their software for windows, for years; so if you are a full-time windows user, you might even gain some bits of cygwin without knowing it, and without ever having seen the official cygwin installer or even heard of it) . The problem is that even if you manage to put it on, many part of cygwin don't work correctly under wine. Please don't confuse issues with running the official installer, and issues with running the cygwin system (or part of) itself. You have been told *many times*, in that thread, that setup.exe itself does not depend on cygwin, and use no part of it.
Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Sun, 30/6/13, André Hentschel n...@dawncrow.de wrote: On 29.06.2013 23:34, Hin-Tak Leung wrote: --- On Sat, 29/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: ... Also, running cygwin on wine, compared to other windows software which has no unix/linux equivalents, is hardly a priority. That is obviously personally true for you. And for my personal needs Cygwin on Wine is a would be nice software build and test platform. ... No. Just the fact that nobody else bothered to respond to this thread should convince you that getting cygwin is not a priority to most people who is knowledgeable and capable of hacking wine. I've been following this thread. What i would like to point you all to is: http://wiki.winehq.org/CygwinSupport It describes why running cygwin on wine is not that senseless low priority thing. Further it's mentioned at: http://wiki.winehq.org/TodoList and http://wiki.winehq.org/UnitTestSuites Wiki is what it is - anybody with a wish can add an entry. If somebody put their name down and say: *I* will do this! - and have the knowledge incentive to deliver, that's when it gets interesting. Until then, it is not. (Those entries might just have been added by the original poster of this thread - doesn't prove anything). Using words like showstopper is off-putting. Especially considering there are at least two well-known(?) ways of getting around a mere installation problem of a piece of [any] open-source software - (1) unpack manually. It is open-source and all the actions of the installer are known; (2) copy from an existing installation clone the relevant registry entries. and (3) being able to install is not a warranty it will run. In terms of relative importance, consider that mingw (both native and cross) GNU toolchain works well, the toolchain part of cygwin is hardly a priority; further, between mingw and MSVC (note the distinction - I mean mingw, not cygwin), I would rather spend time improving wine's support for MSVC . That is an interesting observation - getting microsoft products to work well is obviously a priority to the wider community to Crossover, but that isn't mentioned much in those wiki pages.
Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Sat, 29/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: ... The Mingw GNU toolchain works wells under wine. The cygwin GNU toolchain don't, the last time I checked. That may be true, but the best way to make that point about the Cygwin GNU toolchain is with official Cygwin bug reports rather than asserting stuff here in an anecdotal way. No. Anytime that a piece of windows software (including Cygwin) works on windows but not on wine, is a wine problem. The fact that the such software developers (cygwin people) are nice enough to respond and adjust their software (cygwin) to fit a *flaw in wine* does not make the problem less a wine one. The various problems of running cygwin in wine are already well-documented - just do a search on wine's bugzilla (there are over a dozen of those). So the mere fact that the installer does not work correctly, is just another such problem. Also, running cygwin on wine, compared to other windows software which has no unix/linux equivalents, is hardly a priority. One bug among many, and on a piece of software which is interesting but not a priority. That's what the issue is.
Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Sat, 29/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: ... Also, running cygwin on wine, compared to other windows software which has no unix/linux equivalents, is hardly a priority. That is obviously personally true for you. And for my personal needs Cygwin on Wine is a would be nice software build and test platform. ... No. Just the fact that nobody else bothered to respond to this thread should convince you that getting cygwin is not a priority to most people who is knowledgeable and capable of hacking wine. As for true for me - well, I have fixed or help fixed a few issue of wine with running microsoft products - embedded IE rendering, and Microsoft's development tool chain (yes, I am talking about Visual C++, and nmake, [Microsoft's make], and microsoft's manifest modification tool whose name I forget - the tool for Microsoft's way of modifying executable binaries post-compilation). Obviously my interests lies elsewhere. Mingw works alright. Cygwin is just not a priority for my time, and I sincerely hope that other people who are capable of improving wine would spend their time on more worthwhile causes. p.s. using words like showstopper actually put people off.
Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Thu, 27/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-06-26 18:14-0700 Alan W. Irwin wrote: Note in retrospect I realized that this period leading up to the release of Wine-1.6.0 has been a lousy time to ask wine developers with Cygwin expertise to take on the additional distraction of getting the debugging process for bug 24018 started with the Cygwin developers. Because of the bad timing from the Wine developer perspective, I asked Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try and get the debugging process started with the Cygwin developers. The response http://cygwin.com/ml/cygwin/2013-06/msg00666.html to his post looks quite promising. It turned out the fork bomb test programme failed after only 500 iterations, and the Cygwin developer, Corinna Vinschen thinks she knows what the issue is with more to come. So stay tuned to that thread if you have an interest in bug 24018. I read that thread with interest. However, I noticed that you have quite a few fundamental misunderstanding or lack of experience with cygwin. Firstly, cygwin's setup.exe doesn't do much more than unpacking tar balls, write a few registry entries, and run some scripts through sh.exe, occasionally. (the last one depends on the package, the middle one is one-off, the first time ever you run setup.exe - there after it just read those entries back; the unpacking obviously happens per package). So it is entirely possible to *install* cygwin into a wine prefix, without using cygwin's setup.exe, if you know how to unpack those files as well as set up the registry entries. It is even easier if you have access to a windows box: you can simply export those registries and import them into wine, copy the entire installed tree across from a windows box to wine. That, in principle, gives identical results as if you manage to run the setup.exe . (you can clone a cygwin installation across windows boxes in exactly the same way i.e. by copying the whole installed directory, plus export/importing a few registry entries.). However, being able to install does not equal to being able to run, or run correctly. I thought I wrote that already. Anyway, *some* people bundle bits of cygwin in their custom software for little things, and I have come across at least one such installer. The installer runs fine with wine, but the installed cygwin bits don't work correctly in wine. cat echo were the two I noticed - the latter is fairly awful, since cmd has a built in echo, and wine cmd's works alright; said custom software installer also put its binaries in the front of the system $PATH (or if you prefer window's style, %PATH%). The added registry entries - or at least the important ones - are, if I remember correctly, the mount table i.e. it tells the installed bits where to find /usr/share, etc. Of course some, e.g. again, cat, echo, etc don't really have extra bits to look up, unlike say, emacs - which have lisp code files to load - and cat, echo, etc are supposed to work without cygwin mount table entires. On windows, they do work, and on wine, they don't (*not* because of the absence). You can try very simple things, like e.g. cat fileA fileB fileC, if you need convincing.
Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Fri, 28/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: ... But I _know_ the MSYS version of cat works fine on recent Wine just like the rest of the GNU toolchain used for building software so if the MSYS and Cygwin GNU toolchain code bases have not diverged too much it should be straightforward (and probably quite fast, ... Again, MSYS (i.e. Mingw) is not cygwin. This is probably an FAQ on mingw's web site. You really need to do some reading. The Mingw GNU toolchain works wells under wine. The cygwin GNU toolchain don't, the last time I checked.
Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Tue, 25/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: snipped I currently have no experience with Cygwin and my only real interest in Cygwin on Wine is it theoretically provides an alternative build platform to my present successful work with the combination of MinGW, MSYS, and Wine as a Windows build platform. But I haven't even been able to get started with Cygwin on Wine because of this showstopping bug. Therefore, I am mentioning the situation here in the hope that some wine developer on this list with some knowledge of Cygwin will take the responsibility of making a proper bug report to the Cygwin mailing list (which according to http://cygwin.com/problems.html is the correct place to report Cygwin bugs) including the evidence that the issue is a Cygwin regression (assuming investigation of older Cygwin versions with Turkin's test supports that conclusion). snipped FWIW, the fact that cygwin's setup has problems working doesn't not stop you from *trying* cygwin - it doesn't do very much more than just unpacking tar.tgz files, which you can do manually. And for many command-line utilities, just have the exe and the dll around is enough. However, I found that cygwin version of a few utlities does not work correctly uner wine (it obvious does for some under genuine windows). While the mingw/gnuwin32 equivalent, do. echo and cat were two I had problems with, when I accidentally let some 3rd party's installer put cygwin's cat/echo in front of gnuwin32's cat/echo in my $PATH under cmd. Also, I believe MSYS and Mingw do not depends on cygwin. cygwin and msys/mingw are rather different. For building windows applications, you really want to stick with mingw if you can. And, I found cross-compiling works well enough that I don't bother with having a mingw-based dev system under wine. And if I need MS VC specifically, that works well under wine so; so there has not been any need for running mingw or cgywin under wine for a while. I can tell you from first hand experience that mingw gcc/g++ works well under wine, but many times slower compared to cross-compiling. I think the speed problem comes from fork/exec being slow in wine.
Re: po: Update Simplified Chinese translation (resend)
--- On Fri, 21/6/13, André Hentschel n...@dawncrow.de wrote: On 21.06.2013 18:44, Qian Hong wrote: Hi Caibin, Welcome to Wine! Thanks for the great work, patch looks perfect to me. It's a bit pity that Julliard just finishing today's patch committing several minutes ago, hopefully this patch would be committed next week, if we have rc4 :) Actually it's committed: http://source.winehq.org/git/wine.git/commitdiff/abfe8a5b9644b862fa8f5dfe58b7740b68fe4786 It came with the announcement. Thanks for the work. A few comments: @@ -9838,19 +9856,19 @@ 句柄 sounds a bit funny. @@ -9870,7 +9888,7 @@ 列表中没有内容。\n - probably should use 条目 for uniformity? @@ -9905,145 +9926,119 @@ 活跃连接 - sounds a bit funny. 接口统计 - 界面 is probably better? 未知协议 主动打开连接数 @@ -10404,20 +10399,20 @@ a few 接口 - I prefer the older 界面, actually... @@ -10839,41 +10834,45 @@ 错误：键名无效\n @@ -11402,7 +11403,7 @@ -msgstr 指定优先权(P) +msgstr 指定优先级(P) - prefer old @@ -11418,7 +11419,7 @@ -msgstr 亲和度指定(A)... +msgstr 关联 CPU(A)... - I think the old version was correct, the new wrong. @@ -11510,13 +11511,13 @@ -msgstr 处理器亲和度 +msgstr 处理器关联 - again -msgstr 处理器亲和度决定了各进程允许运行在哪些 CPU 上。 +msgstr 处理器关联决定了各进程允许运行在哪些 CPU 上。 @@ -11653,7 +11654,7 @@ -msgstr 选择任务管理器中“进程”标签页显示哪些列。 +msgstr 选择任务管理器中进程标签页显示哪些列。 - 列 is row, you want column! @@ -11945,27 +11946,27 @@ -msgstr +msgstr CPU 时间 --- you want something more precise to mean time *period*. @@ -11973,36 +11974,35 @@ -msgstr +msgstr 用户对象 - sounds wrong -msgstr +msgstr 会话 ID - also @@ -11973,36 +11974,35 @@ -msgstr 向下翻页 +msgstr 已分页池 ... paged shouldn't be translated as 分页. @@ -12027,44 +12029,48 @@ -msgstr +msgstr 没有响应 @@ -12081,7 +12087,7 @@ msgid -你想把这项卸载命令从注册表中删除吗？ +您想把这项卸载命令从注册表中删除吗？ - probably should use 条目. @@ -12137,6 +12143,9 @@ ...更高版本。 - later version, not higher version.
Re: Spam again ...
That, if I remember correctly, is a legitimate wine user who is occasionally active in the bugzilla also. I have had other friends who have clicked on the wrong links (quite possible) and had their addressbook used that way, and/or have e-mails pretended to have come from them. On the whole I don't click on urls even from people I know, if the e-mail contains nothing else or nothing meaningful else, for this reason. --- On Sun, 26/5/13, Joerg Schiermeier n...@schiermeier-it.de wrote: Hi maintainer, ---cite--- Message: 1 Date: Sun, 26 May 2013 01:07:06 + (UTC) From: xerox_xerox2...@yahoo.co.uk To: wine-devel@winehq.org, vidar...@yahoo.com, vla...@utchat.com Subject: RE: Message-ID: 823277.37895...@smtp104.mail.ir2.yahoo.com Moussoiddik%20Aboudou588 http://fonio-bio.org/w/87Elsie%20Mills045 Mon, 27 May 2013 5:04:06 ---/cite--- UCE/Spam again in this list ...! Please remove this user. Thanks a lot. -- Kindly regards Joerg Schiermeier Bielefeld/Germany
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
--- On Sun, 5/5/13, Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: On 05/04/2013 05:37 PM, Sam Edwards wrote: On 05/04/2013 12:59 PM, Max TenEyck Woodbury wrote: You are trying to make this about me. It is not. Windows fairly obviously does not do this 'sanity' test. Wine is supposed to imitate windows. To do this absolutely correctly, the whole 'sanity' test should go away. This sounds like an excellent reason to write a conformance test. A test that succeeds on Windows but fails under Wine is a great way to convince everyone that the patch is necessary. It's also gives us a closer look at Windows's behavior under the same circumstances, so we can see whether Windows does this sanity check or not, and if not, how it reacts when aveWidth is wrong. Having wine throw an exception where it did not do so before is another kind of problem indicator. One that hardly needs a special conformance test. I should note, the commit that introduces the sanity check (21589993826cdb1cb2f87ceb94c8a188bd4a3090) also includes a test (dlls/gdi32/tests/font.c:3908 as of this writing) that passes under Windows, which could mean that Windows actually does include this sanity check for the width vs. the height. Hmm. As I suspected, that is a single point pass only test. It does not explore any of the possible fail conditions. Thus, it is also definitely a possibility that Windows makes no such sanity check. I isolated the problem, and came up with a fix. Bug reports are for cases where you can not yourself identify the bad code. That this code is bad is obvious when you know that it can throw an exception. The only investigation absolutely needed is to report the occurrence of the exception. It happens in at least some circumstances. Anything additional is simply an invitation to delay. Are we sure that *this* code is the problem? Almost certainly. Without this patch, the 'make test' suit throws a divide by zero exception and brings up a dialog box. With this patch, it does not. I believe that is sufficient to convict the unpatched code of having something wrong with it. As Dmitry has said, tmHeight should never be 0, so it's probably valid to assume tmHeight!=0. But that assumption can be checked. Currently there is no such check. 'Should' in this context is a very bad word and has no place at the foundation of an argument about what actually happens. The bug may instead be in allowing the font to load with tmHeight=0, and this is merely the first crash that the problem causes for you. But what about apps that divide by tmHeight under the same assumption? We can't change those, so it's better to fix tmHeight. If the APP does the division, that is the APP's problem. Wine, on the other hand should not throw an exception, and it did NOT do so until recently. Whoever wrote the new code (Dmitry?) should have put in the check or made the test work without doing a division. The fact that it fails is the problem being addressed. Are delays necessarily a bad thing? This bug doesn't have any security implications, and we aren't hurrying to catch the Wine 1.6 release window. We can afford to take the extra time to ensure the quality of the patch. :) I have no objection to someone writing an alternative patch and backing this one out when that patch goes in, but until then, this patch, or something like it, needs to be applied. With wine throwing the exception, some Apps are going to fail that would not fail otherwise. That is definitely a 'Bad Thing' and should be fixed ASAP (like right now)! I'd like to mention two things: - there were(are?) overflows/underflows within Freetype itself, up to and including 2.4.11 - the fixes went into trunk, but AFAIK 2.4.12 isn't release yet. That's specifically affect 32-bit platform, and emulated styles (i.e. where the application requires a font style which cannot be provided by any one font, but needed to be synthesized by fontconfig and freetype). - there a few well-known open-source fonts which microsoft's gdiplus does not like and crash on them, but nonetheless, windows users never encounter the problems, because they typically have the proprietary MS equivalent, and therefore do not need those fonts at all. I suggest - (1) check out freetype trunk to see if it helps, or at least, patch your freetype with those fixes from end of January; (2) modify the Avoid division by zero patch to emit the font's typeface name whenever the condition occur, and just run it on the affected system to see which typeface wine doesn't like? Does this sound reasonable?
Re: [AppDB] version: Only display comments section in case version has maintainers
--- On Thu, 2/5/13, Frédéric Delanoy frederic.dela...@gmail.com wrote: From: Frédéric Delanoy frederic.dela...@gmail.com Subject: Re: [AppDB] version: Only display comments section in case version has maintainers To: Rosanne DiMesio dime...@earthlink.net, André Hentschel n...@dawncrow.de Cc: Wine Devel wine-devel@winehq.org Date: Thursday, 2 May, 2013, 18:53 On Thu, May 2, 2013 at 7:23 PM, Rosanne DiMesio dime...@earthlink.net wrote: On Thu, 2 May 2013 17:57:16 +0200 Frédéric Delanoy frederic.dela...@gmail.com wrote: This won't prevent it, but I'm not sure hiding/disabling comments won't do more harm than good. My opinion, based on close to 5 years experience as an active AppDB admin and maintainer, is it will inconvenience a few people, but overall do far more good than harm, for reasons that go beyond simple spam control. The number of unmaintained apps with an active community of commenters is small; in most unmaintained apps, questions posted just sit there unanswered. Users seeking help would be much better off posting on the forum. Of course, but we don't want people to ask the same questions over and over again on the forum. I thought the whole point of the appdb entry was to centralize information on running apps with wine (comments being common to all versions of the software tested)... Since Andre's patch (thank you, Andre) merely disables comments for unmaintained apps, any user who really thinks it's vital that the comments appear in a particular entry can make that happen themselves simply by volunteering to be a maintainer. If it's not important enough to someone to put forth the trivial effort required to do that, then it's not important to them, period. Maintaining/testing app entries may not be so trivial for everyone, and you can't expect everyone wanting to know how to run an app to become a maintainer...Maybe merely disabling *new* (vs all) comments for unmaintained apps would also do the job??? Frédéric -Inline Attachment Follows- I am surprised this thread lasted this long. I have three points to make: - volunteer is what it means: volunteer. To try to make anybody volunteer in any activity any manner which is less than whole-heartedly willingly, sounds wrong. - most people learn to ignore spam one way or any another, whether it comes in e-mails, forums, or through snail posts. Most still scan their spam folder - or at least skim through all the leaflets from snail mails - from time to time, just because the costs of false positive - throwing away something genuinely important, is too high. There is no reason why the AppDB shouldn't work that way. i.e. just deal with the persistent ones, and let the individual readers skip over the occasional rest as they come. - there are other ways wine users might help other than becoming a volunteer, or even be capable of being one: e.g. supplying workarounds, or offer financial incentives for app-specific fixes; there are also many reasons why a capable person might not want to be come a maintainer - e.g. one might not want to _commit_ to such a role, or company-policy disallowing such outside commitments - but nonetheless can offer one-off advices or one-off patches etc occasionally. To ban such exchanges - between people who ask for help and might even offer incentives, and those who can offer help but not willing/possible to commit to a regular role - seem over-zealous. Just my 2 $.
Re: [AppDB] version: Only display comments section in case version has maintainers
-- On Fri, May 3, 2013 00:35 BST Rosanne DiMesio wrote: On Thu, 2 May 2013 23:26:24 +0100 (BST) Hin-Tak Leung ht...@users.sourceforge.net wrote: - volunteer is what it means: volunteer. To try to make anybody volunteer in any activity any manner which is less than whole-heartedly willingly, sounds wrong. Nobody's trying to make anyone volunteer. I doubt anyone will. There is no reason why the AppDB shouldn't work that way. i.e. just deal with the persistent ones, and let the individual readers skip over the occasional rest as they come. And who do you propose should deal with the persistent spammers? people who are bothered by them, or people who are paid to spend such time. I am neither. To be honest, i am more bothered by this thread (in a list which i subscribe to) than spam on appdb (which i don't). To ban such exchanges - between people who ask for help and might even offer incentives, and those who can offer help but not willing/possible to commit to a regular role - seem over-zealous. We have a perfectly good user's forum for such exchanges. -- Rosanne DiMesio dime...@earthlink.net
Re: zlib's gzseek return gabbage and fails intermittently under wine.
--- On Mon, 15/4/13, Nikolay Sivov bungleh...@gmail.com wrote:
On 4/15/2013 02:50, Hin-Tak Leung
wrote:
--- On Sun, 14/4/13, Vincent Povirk madewokh...@gmail.com
wrote:
Well, here's a simple thing you can
check: Does your zlib dll link to
_lseek or _lseeki64? The first one uses a 32-bit
offset.
Wine's
implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090)
expands that to 64-bit and later truncates the file
offset
to 32-bit.
For a file larger than 2 GB, that could account for
the
large negative
value you're seeing.
And since this would only matter in cases where
zlib uses
lseek (the
first time through I guess it wouldn't, as it has
to read
the whole
everything up to the offset you give at least once)
and is
at least 2
GB into the file, that might also explain why it
doesn't
fail
initially.
But without really digging into the zlib code, all
I can do
it speculate.
I should probably also check coapp's build of zlib
sometime.
It is not a dll - as you suggested and I already wrote,
due to past experience of other's packaging of slightly
outdated, it is being built against a private *source* copy
of the latest zlib.
Also the bogus offset is not large negative but large
(larger than 2^32) positive.
Here is an example of the debug output under wine:
---
set_filepos failed at 34307 returning 134127533721091
Re-opening to re-try
Retry successful
set_filepos failed at 96919 returning 146686018157207
Re-opening to re-try
Retry successful
set_filepos failed at 128254 returning 12103217968382
Re-opening to re-try
Retry successful
...
---
This is generated by this code snipplet which is called
inside a loop, all wrapped in the c++ class:
---
off_t offset =
gzseek(gzvcf_in, filepos, SEEK_SET);
if (offset !=
filepos) { //implicitly converted to off_t by template
streamoff()
LOG.printLOG(set_filepos failed at +
LOG.streampos2str(filepos)
+ returning + LOG.off_t2str(offset) + \n);
LOG.printLOG(Re-opening to re-try\n);
close(); open();
off_t offset1 = gzseek(gzvcf_in, filepos, SEEK_SET);
if
(offset1 == filepos)
LOG.printLOG(Retry successful\n);
else
LOG.error(Retry failed\n); // this also aborts
}
---
This code runs silently on linux i.e. the if (offset
!= filepos) condition is not triggered.
For windows build you'll need to define _WIN32, so _lseeki64
is used by
zlib. After this done you could play with
native msvcrt to see if it helps, and after that +relay will
tell you
everything.
$ i686-w64-mingw32-cpp -dM |grep WIN32
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN32 1
I haven't explained what the application does earlier, so I'd try to add this
info now. It gzseek's to a set of previously generated offsets (some -
actually all the relevant ones, I think, are beyond 2G in
real/already-compressed data.), gzgets a few bytes, apply a user-selected
criteria on those bytes, make a records of which of those offsets are
requested, then go back and go over those requested offsets again and gzgets
a much larger chunk. Conceptually it reads the first few columns of a very
large table, use some user defined criteria to select on those, and extract
selected rows.
In the early test (which took most of a full day to run, compared to about 20
minutes on linux), I found that the count of of matched requests was correct,
so the gzgets in the first pass was correct, but the extracted result from the
2nd pass was complete garbage. So my first idea was that the incremental
forward gzseek in the first pass were okay, but the large backward gzseek
between the first pass and the 2nd pass was wrong. Hence my code addition to
check the return value of gzseek, as well as close/re-open to gzseek forward
from the beginning if gzseek return a wrong value - I was only expecting -1 for
failure to rewine.
After the code addition, I found that the return values from even the first
pass are wrong every other time. So it looks like it is two bugs somewhere, and
on 2nd-thought, not necessarily with wine - I think I should try it on window
at some stage.
- I looked at the zlib code itself (it is in a file gzlib.c in 1.2.7 for those
who wants to have a go). It seems that it always converts a seek request into
relative one, do some actual work, then convert back return an absolute offset.
It is possible that there is a bug somewhat in that, so that a fresh gzseek -
having no where to be relative to - is correct, while a 2nd gzseek - after some
flawed conversion to relative values - is wrong. But this first bug is related
just to a flawed return value and not to the content re-positioning. The 'do
some actual work' part
zlib's gzseek return gabbage and fails intermittently under wine.
I am porting an application which uses zlib's gzseek quite extensively to do pseudo- random access of the content of large gz'ed files, in the same manner of some's use of posix's lseek. On small test data, it works correctly on wine. (identical result as linux). On production data - a large 9GB file - it gives gabbage. I thought it is 32-bit file access problem, until I check the return value of gzseek explicitly. It is supposed to return the same value as input on success, -1 on error. On wine, it does neither, *occasionally*! I found that a first gzseek works correctly, then a 2nd fails. It does not fails with a -1, but fails with a large bogus value. Currently I am working around this strange behavior by closing the file and re-opening until it gets a correct offset. The large bogus value increases gradually and wrap around about 8-10 such repeated set of gzseek calls. Anybody has any suggestion why gzseek would behave badly *intermittently* in wine? I assume it works correctly in windows - hardly to think that it doesn't work, considering how old zlib is and the vast number of windows application which uses zlib. On a separate note, the application seems extraordinary slow in wine (again I haven't tried in windows..) - even when it works correctly without the work-around, it is hundreds of times slower in wine than in linux.
Re: zlib's gzseek return gabbage and fails intermittently under wine.
-- On Sun, Apr 14, 2013 22:34 BST Vincent Povirk wrote: considering how old zlib is and the vast number of windows application which uses zlib Given how many people duplicate the effort to package zlib, the fact that they're rarely updated, and the sort of problems gnulib exists to work around, it would not surprise me if your particular zlib binary is broken somehow. got nobody else to blame - because of exactly the issue you outlined encountered in the past, i am building the application with a private copy of the source of zlib 1.2.7.
Re: zlib's gzseek return gabbage and fails intermittently under wine.
--- On Sun, 14/4/13, Vincent Povirk madewokh...@gmail.com wrote:
Well, here's a simple thing you can
check: Does your zlib dll link to
_lseek or _lseeki64? The first one uses a 32-bit offset.
Wine's
implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090)
expands that to 64-bit and later truncates the file offset
to 32-bit.
For a file larger than 2 GB, that could account for the
large negative
value you're seeing.
And since this would only matter in cases where zlib uses
lseek (the
first time through I guess it wouldn't, as it has to read
the whole
everything up to the offset you give at least once) and is
at least 2
GB into the file, that might also explain why it doesn't
fail
initially.
But without really digging into the zlib code, all I can do
it speculate.
I should probably also check coapp's build of zlib
sometime.
It is not a dll - as you suggested and I already wrote, due to past experience
of other's packaging of slightly outdated, it is being built against a private
*source* copy of the latest zlib.
Also the bogus offset is not large negative but large (larger than 2^32)
positive.
Here is an example of the debug output under wine:
---
set_filepos failed at 34307 returning 134127533721091
Re-opening to re-try
Retry successful
set_filepos failed at 96919 returning 146686018157207
Re-opening to re-try
Retry successful
set_filepos failed at 128254 returning 12103217968382
Re-opening to re-try
Retry successful
...
---
This is generated by this code snipplet which is called inside a loop, all
wrapped in the c++ class:
---
off_t offset = gzseek(gzvcf_in, filepos, SEEK_SET);
if (offset != filepos) { //implicitly converted to off_t by
template streamoff()
LOG.printLOG(set_filepos failed at +
LOG.streampos2str(filepos)
+ returning + LOG.off_t2str(offset) + \n);
LOG.printLOG(Re-opening to re-try\n);
close(); open();
off_t offset1 = gzseek(gzvcf_in, filepos, SEEK_SET);
if (offset1 == filepos)
LOG.printLOG(Retry successful\n);
else
LOG.error(Retry failed\n); // this also aborts
}
---
This code runs silently on linux i.e. the if (offset != filepos) condition is
not triggered.
Re: [website] Simplified Chinese translation for release 1.5.27
--- On Sat, 30/3/13, Qian Hong fract...@gmail.com wrote:
Hi Jactry,
2013/3/30 Jactry Zeng jactr...@gmail.com:
+ li一些 C 运行时的改进。/li
I think it is better to translate C runtime to “C
运行时库“ rather than
just ”C 运行时“。
I think both are terrible translations but could not think of a better
alternative off my head, so I went to consult google translate. It defaults to
運行時庫 for runtime library but allow me to choose a few other alternatives,
among which is
執行階段程式庫
Don't you think that's much better!?
I think google translate is quite useful for technical terms like these, as
long as one is vigilant about not accepting 'not quite correct' and go through
the alternatives. One can also help it a bit by giving a more verbose version
of the concept ('runtime library' instead of just 'runtime'), and even
occasionally some context (e.g.a full sentence with '...loading in a
runtime library...').
+
li为内建程序提供更高质量的图标。/li
Large icon means 大图标，not 高质量图标。You can
verify this by the git commits。
大型圖示 or 大型圖標 ?
Thanks for the work.
--
Regards,
Qian Hong
-
http://www.winehq.org
Re: [website] Simplified Chinese translation for release 1.5.27
I was not very happy with 大型 ... for large icon, so I expanded the meaning
a bit and did 'large size icon'. I think it should be
大規格 or 大尺寸 or 大碼 . All of them are more precise about size, whereas 大型 is
less precise and more generic as in 'large format'/'large style'.
So I would opt for 大碼圖標 .
--- On Sat, 30/3/13, Hin-Tak Leung ht...@users.sourceforge.net wrote:
From: Hin-Tak Leung ht...@users.sourceforge.net
Subject: Re: [website] Simplified Chinese translation for release 1.5.27
To: Wine Devel wine-devel@winehq.org, fract...@gmail.com, Jactry Zeng
jactr...@gmail.com
Date: Saturday, 30 March, 2013, 10:02
--- On Sat, 30/3/13, Qian Hong fract...@gmail.com
wrote:
Hi Jactry,
2013/3/30 Jactry Zeng jactr...@gmail.com:
+ li一些 C
运行时的改进。/li
I think it is better to translate C runtime to “C
运行时库“ rather than
just ”C 运行时“。
I think both are terrible translations but could not think
of a better alternative off my head, so I went to consult
google translate. It defaults to 運行時庫 for runtime
library but allow me to choose a few other alternatives,
among which is
執行階段程式庫
Don't you think that's much better!?
I think google translate is quite useful for technical terms
like these, as long as one is vigilant about not accepting
'not quite correct' and go through the alternatives. One can
also help it a bit by giving a more verbose version of the
concept ('runtime library' instead of just 'runtime'), and
even occasionally some context (e.g. a full
sentence with '...loading in a runtime library...').
+
li为内建程序提供更高质量的图标。/li
Large icon means 大图标，not 高质量图标。You
can
verify this by the git commits。
大型圖示 or 大型圖標 ?
Thanks for the work.
--
Regards,
Qian Hong
-
http://www.winehq.org
Re: [website] Simplified Chinese translation for release 1.5.27
This one I do without google translate, high resolution would be 高解像 . --- On Sat, 30/3/13, Jactry Zeng jactr...@gmail.com wrote: From: Jactry Zeng jactr...@gmail.com Subject: Re: [website] Simplified Chinese translation for release 1.5.27 To: Qian Hong fract...@gmail.com Cc: Wine Devel wine-devel@winehq.org Date: Saturday, 30 March, 2013, 10:23 2013/3/30 Qian Hong fract...@gmail.com 2013/3/30 Jactry Zeng jactr...@gmail.com: + li一些 C 运行时的改进。/li I think it is better to translate C runtime to “C 运行时库“ rather than just ”C 运行时“。 + li为内建程序提供更高质量的图标。/li Large icon means 大图标，not 高质量图标。You can verify this by the git commits。In fact, I have verified it before I commit this patch. I translated it as 高质量 meaning a picture have hight resolution. For a example, programs/wordpad/wordpad.ico, had a 48x48 resolution before, and now it is 256x256. Thanks for the work. Thanks for your review. I will commit a newer patch. :-) -- Regards, Jactry Zeng -Inline Attachment Follows-
Re: [website] Simplified Chinese translation for release 1.5.27
--- On Sat, 30/3/13, Jactry Zeng jactr...@gmail.com wrote: From: Jactry Zeng jactr...@gmail.com Subject: Re: [website] Simplified Chinese translation for release 1.5.27 To: ht...@users.sourceforge.net Cc: Wine Devel wine-devel@winehq.org, Qian Hong fract...@gmail.com Date: Saturday, 30 March, 2013, 10:41 2013/3/30 Hin-Tak Leung ht...@users.sourceforge.net I think both are terrible translations but could not think of a better alternative off my head, so I went to consult google translate. It defaults to 運行時庫 for runtime library but allow me to choose a few other alternatives, among which is 執行階段程式庫 Don't you think that's much better!? Hi Hin-Tak, Thanks for your review. I also think both 运行时 or 运行时库 was not best translation. But I have seen a lot of documents in Simplified Chinese translated it in this way. Maybe it was not too accurate... And in my opinion, 运行时 meaning some function, 运行时库 meaning a runtime library. To be honest, I think a lot of Chinese translations of technical topics (or even not-technical topics) are quite poor, and little beyond a word-for-word substitution. run - 运行 (to convey/process, the more common use of run, of 'using your legs faster than walking' is obviously wrong) time - 时 (hour, during) library - 库 (storage container, the more common use of library to mean collection of books obviously wrong). Whereas 執行階段程式庫 meaning the program/routine library of/in the execute stage is quite a lot more fitting to what 'runtime library' actually means. As I was saying, one needs to be vigilant about automated translations being 'not quite correct'. I suspect it is a much abused practice in China, so you see the same (mis-)usage over and over. There are entire web sites devoted to poorly translated public signs in China and making fun of them. It is quite educational - one gets lazy and and accepts the occasional poor translation, but seeing similar but slightly different mistakes collected in a large quantity really makes one think. 2013/3/30 Jactry Zeng jactr...@gmail.com I translated it as 高质量 meaning a picture have hight resolution. Here has a typo, hight - higher -- Regards, Jactry Zeng
Re: [website] Added simplified chinese
--- On Wed, 30/1/13, Jactry jactr...@gmail.com wrote: From: Jactry jactr...@gmail.com Subject: Re: [website] Added simplified chinese To: Jeremy Newman jnew...@codeweavers.com Cc: wine-devel wine-devel@winehq.org Date: Wednesday, 30 January, 2013, 16:28 Hi Jeremy, 2013/1/30 Jeremy Newman jnew...@codeweavers.com:Patch looks good to me. Since I cannot read it, I need someone else here on wine devel to vouch for the translation. Just to make sure it is legit and not a very tricky spam or just a pass through google translate. So happy to hear that. But please ignore this patch first and I will send a newer soon. There was some wrong in the first patch... You will also need to add a string to the $this-languages array in the data class (include/data.php) Thanks for your remind. And I found that was anthor problem: the folder of Simplified Chinese in templates named zh_CN, but the picture in images/lang/ named zh.png. I think zh.png should be renamed as zh_CN.png. ( In general, something about Simplified Chinese was signed as zh_CN and zh_TW was left for Traditional Chinese)In glibc 2.16, the following locales are defined: zh zh-CN zh_HK zh_TW.Big5 zh_CN zh_CN.GB2312 zh_TW Not to forget zh_HK... I also seem to have come across zh_SG (for Singapore) although I cannot remember what context. 2013/1/30 Jeremy Newman jnew...@codeweavers.com Patch looks good to me. Since I cannot read it, I need someone else here on wine devel to vouch for the translation. Just to make sure it is legit and not a very tricky spam or just a pass through google translate. You will also need to add a string to the $this-languages array in the data class (include/data.php) I also noticed we are still using .cvsignore files, oops. Those should get moved to .gitignore, but I can do that later. -N On Tue 29 Jan 2013 08:34:28 AM CST, Jactry wrote: -Inline Attachment Follows-
Re: [website] Added simplified chinese
--- On Wed, 30/1/13, Jeremy Newman jnew...@codeweavers.com wrote: Patch looks good to me. Since I cannot read it, I need someone else here on wine devel to vouch for the translation. Just to make sure it is legit and not a very tricky spam or just a pass through google translate. You will also need to add a string to the $this-languages array in the data class (include/data.php) I also noticed we are still using .cvsignore files, oops. Those should get moved to .gitignore, but I can do that later. The translation of the content is largely okay. I also find it a bit strange with the .cvsignore file, and also the google_analytic.template file - I think that probably should be factored out into a language-neutral template. Just a note that the encoding is zh_CN.utf8, rather than the more-common-in-China zh_CN.GB18030 . (I think you can find me as a distant-past code contributor - got a couple of patches in, in the mshtml area, I think, a long time ago - and active on bugzilla for some years).
Re: Announcing the Mac driver
--- On Wed, 12/12/12, Ken Thomases k...@codeweavers.com wrote: Greetings Wine community, As many of you may be aware, CodeWeavers just released CrossOver 12. We're pleased to announce that CrossOver 12 includes the long-awaited Mac driver. If you're not familiar with it, the Mac driver is an alternative to Wine's X11 driver for use on Mac OS X. It allows Wine to present windows, receive input from the keyboard and mouse, and interact with system facilities like the clipboard using Cocoa and other Mac-native APIs. That allows for superior integration into the Mac UI and eliminates the need for the foreign X11 middleware. The Mac driver is not yet complete but it's pretty far along. In CrossOver 12, it's described as an experimental feature and is disabled by default. We're aware of chunks of functionality, both big and small, that are simply not implemented yet and there are surely many bugs in need of squashing. You can take a look at the source in CodeWeavers' usual Wine source tarball at http://www.codeweavers.com/products/faq/source/. The Mac driver lives in dlls/winemac.drv. Because it was under (somewhat chaotic) development right up until the release of CrossOver 12, we do not yet have a series of clean patches for it to submit to Wine. In the coming days and weeks, I will be reconstructing the Mac driver as just such a patch series and submitting it. Mind you, those patches will face the same demanding scrutiny from Alexandre as everything else, so that process may be slow and painful. I'm SO looking forward to that! :-). Thank you to everyone who contributes to Wine for making this possible. It will be fun to work with you on continuing development of the Mac driver. Cheers, Ken Well-done for the work and cheers. I am somewhat curious about the tar ball - why is the version 12 source (120MB) and so much bigger than the previous (44MB)? I can probably work it out by downloading and unpacking both, but I am feeling lazy... Hin-Tak
Re: Announcing the Mac driver
--- On Wed, 12/12/12, Josh DuBois dubo...@codeweavers.com wrote: wine-mono. On 12/12/12 4:27 PM, Hin-Tak Leung wrote: I am somewhat curious about the tar ball - why is the version 12 source (120MB) and so much bigger than the previous (44MB)? I can probably work it out by downloading and unpacking both, but I am feeling lazy... Hin-Tak Thank you. That makes sense - that's the size of mono thereabouts. I guess my next question is, does it also have codeweaver-specific bits? Sorry this sounds rather lazy, but I am sure more than one person wants to know :-). Hin-Tak
Re: Announcing the Mac driver
--- On Wed, 12/12/12, André Hentschel n...@dawncrow.de wrote: Am 12.12.2012 23:35, schrieb Hin-Tak Leung: --- On Wed, 12/12/12, Josh DuBois dubo...@codeweavers.com wrote: wine-mono. On 12/12/12 4:27 PM, Hin-Tak Leung wrote: I am somewhat curious about the tar ball - why is the version 12 source (120MB) and so much bigger than the previous (44MB)? I can probably work it out by downloading and unpacking both, but I am feeling lazy... Hin-Tak Thank you. That makes sense - that's the size of mono thereabouts. I guess my next question is, does it also have codeweaver-specific bits? Sorry this sounds rather lazy, but I am sure more than one person wants to know :-). I bet it has as things without change like wine-gecko are not included. the problem is without a clean wine-mono checkout it's hard to see what changed, a folder with patches in addition would be great. -- Best Regards, André Hentschel Yes, I guess I'd be happier downloading a diff (against a specific clean upstream version), than downloading a big tar ball, then try to work out which upstream version it forked against, then do the diff myself. Even if the diff is nothing beyond a diff, with a branket description: diff against upstream wine/mono version/tag x.y.z.
Re: Command line parameters
--- On Tue, 12/6/12, John Emmas john...@tiscali.co.uk wrote: snipped Thanks Hin-Tak and Dan but I think we're at crossed purposes now. Remember that my original question had nothing to do with paths. I simply used paths as a convenient example. My question is about command-line parameters and (more specifically) about UTF-8 string conversion. Here's an example Consider a Windows user whose name is Göran. The UTF-8 byte sequence for this is:- 47 C3 B6 72 61 6E -- (6 bytes) whereas Windows would expect something like this (depending on the user's locale):- 47 F6 72 61 6E -- (5 bytes) Let's suppose that a Linux app launches a Windows child process (via Wine). The (Linux) host app needs to pass the string Göran as one of the command-line parameters. Linux uses UTF-8 and will therefore pass the first sequence of bytes to Wine (6 bytes). But Windows doesn't understand UTF-8. A Windows app would expect the second byte sequence (5 bytes - or 10 bytes for a Unicode app). Does Wine carry out the necessary conversion or does it simply pass the original byte string unmodified? That's what I'm trying to find out. Thanks. I have already answered that question - it depends on your application, how it uses win32 API. win32 api's is divided into the older *A routines which expects ascii, and the newer *W routines, which expects WCHAR (UTF16LE).
Re: Command line parameters
--- On Thu, 7/6/12, John Emmas john...@tiscali.co.uk wrote: snipped Is Wine clever enough to realise that the UTF8 string needs to be converted to a locale-specific string, so that the Windows app can understand it? Or does Wine simply pass whatever characters it received, without attempting any translation? Thanks. John Use the source, Luke!... THe relevant code is in dlls/ntdll/file.c and dlls/ntdll/path.c which do the right thing. As a general windows programming note, in windows' land, file path related WIN32 APIs tend to have two variants, those ending with *A, and those ending with *W. The former expects ascii inputs, the latter expects WCHAR (I think it is basically UT16LE). The long answer is that wine leaves the former unchanged (except path separator translation, e.g. from unix / to windows \, adding or removing drive letter prefixes, depending on the direction of translation), but will convert from utf8 to WCHAR for the latter, so that the application itself receives the right thing. It is still up to the application's author to use the right Windows APIs for reading/writing files, and whether the application itself expects ascii file paths or unicode (WCHAR) file paths. The short answer is that wine *does* translate from unix-like to windows-like file paths so that the application receives the right stuff. You have nothing to worry about.
Re: Command line parameters
--- On Thu, 7/6/12, John Emmas john...@tiscali.co.uk wrote: snipped FWIW the Windows app launches perfectly if I use execl() in the Linux app - and in fact, this has all worked perfectly for years. It was only yesterday that I began to wonder if there might be a problem in non-English locales. Up to now, nobody's ever reported a problem (though, as we all know in programming, that doesn't mean there isn't one!) That depends on whether your application uses the *W file operation WIN32 api or the much older *A routines. For example, I have a quick look at bcc32.exe (part of borland's compiler, time stamp july 2000, 12 years old) with 'winedump -j import bcc32.exe' . It loads only 3 *W routines but 25 of the *A ones. Whereas cl.exe from visual c++ express 9 (2008, 4 years old) loads 31 *W routines and only 2*A routines. So MS VC 9 is far happier in non-English locale than the much older borland 5.5 compiler.
Re: Command line parameters
--- On Thu, 7/6/12, Dan Kegel d...@kegel.com wrote: John wrote: from what Hin-Tak said earlier, it sounds like Wine itself will translate any paths that I pass as a command line parameter (or did I misunderstand that?) Example: wine notepad /home/dank/foo.txt This fails because notepad treats / as the beginning of an option (see http://source.winehq.org/source/programs/notepad/main.c#L616 ). So, no, Wine doesn't translate arguments for you. It would probably work in any of these though: z:/home/dank/foo.txt h:/foo.txt \\home\\dank\\foo.txt h:\\foo.txt (the double backslash for its been interpreted by bash, or whatever shell you use) or cd /home/dank wine notepad foo.txt FWIW the Windows app launches perfectly if I use execl() in the Linux app - and in fact, this has all worked perfectly for years. That's great. Do you actually pass filenames? - Dan That probably means it does not use / for options . (- or no options at all?).
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
--- On Mon, 4/6/12, Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: On 06/04/2012 03:05 AM, Frédéric Delanoy wrote: On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegeld...@kegel.com wrote: On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy frederic.dela...@gmail.com wrote: On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegeldaniel.r.ke...@gmail.com wrote: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh now also installs mono. ... Wouldn't it be better (and more acceptable for people disliking/wanting to avoid mono) to - keep install-gecko.sh as is - create install-mono.sh - create wine-install-addons.sh calling the former ? The point of this script is to make life easier for me and for the average user. It's not to make life easier for people who don't like mono, mostly because I doubt there are many of them. My comment was not only meant for mono-haters, but it can also be useful IMHO to split e.g. to limit download size.when one doesn't even need mono, and it maybe clearer as well (addons is pretty generic). Frédéric Actually, it really is the name that matters. 'mono' is a lightning rod for a lot of political history. If you were to integrate the same functions into Wine itself, and hopefully avoid tripping over the stinking Microsoft patents, that set of problems can be avoided, A native MSWindows application that wants .net support would either connect to the installed dll that provides the required services or install such a dll. It would know nothing about 'mono'. It is only non-MSWindows platform programs that will try to link to the non-MSWinows libraries in 'mono'. So an MSWindows executable looking for .net support needs .net support, NOT mono. We can and should provide such executables the services they need. However we should NOT make it easy for programs from other platforms to fall into the stinking Microsoft Patent trap. That gateway to hell is called 'mono' and we should NOT open it. This is irrational bias against mono. The fact is that, since Vista, .Net Framework runtime is shipped as standard in windows. Therefore any windows application has a reasonable expectation of assuming .Net runtime to be around, and not prompt the user to go and download the .net runtime from microsoft. Athough some application does explicitly test for the presence of .net runtime and make the user go and download it from microsoft when it cannot detect such or when the version of net runtime is too low (i.e. if the user tries to install such software on XP). Granted the authentic MS .net runtime can be installed and works well enough under wine; but would you rather the user goes and download genuine MS .net and install it on wine? If you say downloading .net runtime and using that on linux is preferable from your point of view, I have nothing more to say...
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
--- On Tue, 5/6/12, Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: The issue is access from linux native code to the .net framework. snipped Please stop your anti-mono ranting. You have no idea what you are talking about. wine-mono is an modified version of a *win32* build of mono. wine-mono does not interact with linux native code at all. It is a win32 PE build of mono. Got it?
Re: GSoC proposal
--- On Mon, 26/3/12, Aric Stewart a...@codeweavers.com wrote: Hi, Not to argue if it will be useful or not, as I do not know. I think this will be technically very hard. You will have to be able to get the keystrokes for a native linux applications feed them into WINE, have wine do the IME processing and then get the resulting characters and feed them back into the native linux application. This pipeline is not trivial. Getting arbitrary microsoft or 3rd-party input methods to work with Wine (for windows application under wine) would be an interesting project. Getting arbitrary microsoft or 3rd-party windows input methods to be useable by native [unix] applications would be less useful - and as you wrote, rather troublesome for the sake of it. I would have to say, the perceived problem with ibus/fcitx/whatever's pinyin implementation is simply failing to naming the issue correctly: it is not that the pinyin implementation on Linux/X11 is poor, but that an entire generic input mechanism (which applies to both pronounciation/pinyin-based methods, as well as shape-decomposition-based methoids like Cangjie) that of predictive/anticipatory/auto-completion, is missing. If you cannot name and describe the issue correctly, you are simply barking up the wrong tree, as the saying goes. Also, it is not true that such feature is entirely missing. The Japanese had done some very interesting work in anticipatory XIM inputs based on dictionaries (the typical linux installation actually ships several, from time to time), and I believe that the Taiwan people had done similar as well (these are available more under niche localized linux distributions); one problem is that those technical development has so far largely stayed localized - native-speaking linux/X11 people know where to find them, but have very little incentive or patience of pushing those technical developments back and integrating them into the western/English-speaking world. Additionally, you have not explained how this will benefit WINE. I can forsee none of the above pipeline being accepted into or applicable to WINE presently, at lest in theory, i have done work that allows native XIM clients to be able to work in wines IME framework, so if a user really wants to use windows XIM in wine they should work. The setup is tricky but in all my years of working on wine IME i have never heard of a user wanting that. Almost all requests are to make the Linux/Mac Input Methods work better in WINE. I would love to have you work on improving IME and XIM integration in WINE, but i think the main goal of the project is pretty tangential to wine. Yes, I agree make the Linux/Mac Input Methods work better in WINE, or just make the Linux/Mac Input Methods work better are desired. Actually an ibus-google-chinese bridge would be interesting, but that's completely othorgonal and unrelated to wine. (except in the sense that wine itself is one X11 application among many).
Re: GSoC proposal
--- On Mon, 26/3/12, Cheer Xiao xiaqq...@gmail.com wrote: What you are describing is the desirability of predictive and phrasal input methods in general, where the computer can anticipate and guess your intention as you type. We only disagree in the definition of what a decent IME is. By decent I meant a decent phrasal or sentence IME. Because given the large amount of homophones in Chinese a bare pinyin IME is barely usable. The first step of addressing a problem is to name and describe it correctly. Since predictive and phrasal input algorithms (and allowing fuzzy input) is not specific to pinyin - or pronounciation-based input methods, which the Japanese is also mostly based on - but also applies to shape-decomposition-based input methods like Cangjie. The majority of pinyin-based input methods are correct and complete for what they claim to do, namely translating from sound to words, but not useable. For what it is worth, you are forgetting two entire areas of people. Taiwan/Hong Kong had always been far more computer-literate than Mainland, so your 80% won't bother to learn another is a gross mis-statement in both quantity and quality. Due to different dialects and other reasons, Cangjie (rather than Pinyin) had been far more popular with Chinese users. But even with Cangjie (which is shape/writing-based, rather than sound-based, thus getting around the dialect problem), predictive and phrasal input methods are desirable. I declared that I was talking about the situation in mainland China in the beginning - I should have emphasized that along the way. But by declaring Cangjie is far more popular, you are ignoring the mass majority of people in mainland China. Again, I won't be able to convince you that the majority won't bother to learn another IME, even in highly computer-literate places like CS departments in universities. Arguing about facts is plainly meaningless. You have completely ignore the historical context. Cangjie was the first input method which had a majority usage among ethnic Chinese users. That was in the 80's. It is a known fact that at that time, Mainland had just gotten out of the cultural revolution, and not in the best shape in general education, let alone technical areas, or access to computers or the internet. (in fact it is arguable about the last point even now, but I'll let that pass). Since reliable statistics does not exist - and the Chinese government won't allow it - any claims on majority or percentage of usage is null and void, honestly. You only speak for your own preference. Yes, but just works is not the same thing as usable. You have again lost my point: pinyin is not the missing part in Linux/X11's chinese input support. Predictive/anticipative/auto-completion phrasal input algorithm is. And predictive/anticipative/auto-completion phrasal input algorithm can be used in combination with non-pronounciation-based (i.e. non-pinyin-based) mechanism, such as Cangjie, which is shape-decomposition-based.
Re: GSoC proposal
Cheer Xiao wrote: snipped I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods? (I'm talking about Chinese, but the same is true for Japanese.) Because developing a decent pinyin (it's a romanization scheme of Chinese; see my previous mail) IME is very hard. Yes, there are alternative input methods that is easier to implement, but the majority of the population won't bother to learn. Determined by the complexity of Chinese grammar, a decent pinyin IME would require a large corpse of vocabulary, driven by some statistical algorithm. snipped I think you are describing the situation wrongly, in quite a few ways. Implementing pinyin *itself* is trivial - there is a standard-ish pronounciation, etc, and is completely table-driven. That's how most of Linux/X11's Chinese input method, especially pinyin, works. What you are describing is the desirability of predictive and phrasal input methods in general, where the computer can anticipate and guess your intention as you type. For what it is worth, you are forgetting two entire areas of people. Taiwan/Hong Kong had always been far more computer-literate than Mainland, so your 80% won't bother to learn another is a gross mis-statement in both quantity and quality. Due to different dialects and other reasons, Cangjie (rather than Pinyin) had been far more popular with Chinese users. But even with Cangjie (which is shape/writing-based, rather than sound-based, thus getting around the dialect problem), predictive and phrasal input methods are desirable. Over 10 years ago, I had some on-line discussion on emacs-devel, with Mr RMS no less, about my continued interests and compiler problems with emacs 19 (?) despite emacs 21 being around, which had mule [multi-lingual extension] newly added (or some issue of that vintage). The reason was that I could run emacs 19 inside cxterm (a chinese x terminal). Now the curious thing is that emacs actually took *all* the input methods from cxterm! So Pinyin/Cangjie themselves worked 10+ years ago identically under emacs 19 + cxterm, and emacs 21 mule. What emacs did not, and still does not, implement, which cxterm did even almost 20 years ago, was predictive and phrasal inputs and also fuzzy inputs. i.e. you can type a?b, and get the list of a[a-z]b. That was something done almost 20 years ago which is still missing in many of the modern Chinese X11 input mechanisms. (I have a confession to make - cxterm was orphaned for many years, and I and a few others are who kept it going-ish, in recent years, for what little needs to be done).
Re: GSoC proposal
--- On Sun, 25/3/12, Cheer Xiao xiaqq...@gmail.com wrote: snipped So according to you and the thread Jerome mentioned, uxtheme is one of the more tricky and less rewarding areas; so I will set it aside for the moment and work on the IME proposal instead. snipped There is no reason why you cannot submit two proposals, if you are interested in two areas. You do not get penalized for doing that, other than your own time of preparing two proposals, which is twice the preparation work. In fact it is quite common for GSoC students to apply for more than one project under different/same organization. From the organization's point of view, it may be a good decision to give the project to the strongest candidate if there are multiple students applying to the same area; or not to take up any student for lack of interests (from mentors); in which case you might be still be taken up and assigned to your 2nd choice project. (poor applications - showing no understandings of the background technology, etc - are rejected, so in that sense you are penalized if you cannot devote enough time to your proposal(s), if you divide your efforts).
Re: GSoC proposal
--- On Sun, 25/3/12, Cheer Xiao xiaqq...@gmail.com wrote: 2012/3/25 Hin-Tak Leung ht...@users.sourceforge.net: --- On Sun, 25/3/12, Cheer Xiao xiaqq...@gmail.com wrote: snipped So according to you and the thread Jerome mentioned, uxtheme is one of the more tricky and less rewarding areas; so I will set it aside for the moment and work on the IME proposal instead. snipped There is no reason why you cannot submit two proposals, if you are interested in two areas. You do not get penalized for doing that, other than your own time of preparing two proposals, which is twice the preparation work. In fact it is quite common for GSoC students to apply for more than one project under different/same organization. From the organization's point of view, it may be a good decision to give the project to the strongest candidate if there are multiple students applying to the same area; or not to take up any student for lack of interests (from mentors); in which case you might be still be taken up and assigned to your 2nd choice project. (poor applications - showing no understandings of the background technology, etc - are rejected, so in that sense you are penalized if you cannot devote enough time to your proposal(s), if you divide your efforts). Thanks for the clarification. On the multiple proposals idea, in fact it is explicitly in the GSoC application schedule that there is a final decision afternoon or something, at which some organization admins come together to decide which organization would take a student, if a student had submitted multiple strong proposals to multiple organizations, and multiple organizations had decided to accept the same student to work on two different proposals. So submitting multiple proposals are explicitly allowed. Obviously, if you submit two proposals to the *same* organization, one of your applications would certainly be dropped at some intermediate stage before reaching that final stage, because they are reviewed by the same people (and there are some communications/decisions between organizations *before* that final stage, if multiple applications are made) . This is just because a student cannot be actually working on two projects over the same summer period, so all except one proposals must be turned down/withdrawn *eventually*. I am just saying that, if you feel like you could be happy working on more than one area, and is confident you can get a good proposal in for each (for the same organization, or different ones), by all means submit more than one proposals.
Re: Updating GSoC proposal
--- On Tue, 20/3/12, Hin-Tak Leung ht...@users.sourceforge.net wrote: snipped FWIW I was planning on improving cmd as my GSoC project, and I've talked to Dan Kegel about it - there's been no protests (only support) thus far on that front, so it at least seems doable. In terms of being valid... if cmd were improved it would allow firefox and chromium to be built under wine (if reg was also improved a bit, but that might also fall under my project...) There are one of two bugs I filed which has something to do with cmd (or cmd built-in's). One of them is an append-file issue - I think copy file1+file2 file3 does not do what it does in windows. (joining file1 and file2 and put into file3) - but instead, file2 is ignored, or something. Just thought if you are doing cmd things, you might take an interest. That's the sort of things which are do-able in less than a few months for a student. Oh, I forgot to add that the bug shows up running ghostscript (or ghostpdl?)'s build under wine - with M$ VC++, the usual way it is built for windows. So it might be an issue which also affect other software builds, which would naturally fall within what you are planning to do. (are firefox/chromium preferably built with MS VC++ or mingw?)
Re: Updating GSoC proposal
--- On Tue, 20/3/12, HolyCause holy.ca...@gmail.com wrote: On 3/20/12 07:22, Maarten Lankhorst wrote: Agreed, would like to add cmd parser to that list too. ~Maarten Why is this? Does cmd sound like a bad project? FWIW I was planning on improving cmd as my GSoC project, and I've talked to Dan Kegel about it - there's been no protests (only support) thus far on that front, so it at least seems doable. In terms of being valid... if cmd were improved it would allow firefox and chromium to be built under wine (if reg was also improved a bit, but that might also fall under my project...) There are one of two bugs I filed which has something to do with cmd (or cmd built-in's). One of them is an append-file issue - I think copy file1+file2 file3 does not do what it does in windows. (joining file1 and file2 and put into file3) - but instead, file2 is ignored, or something. Just thought if you are doing cmd things, you might take an interest. That's the sort of things which are do-able in less than a few months for a student.
Fw: Re: po: zh_TW translation updates
Strange bounces... --- On Mon, 27/2/12, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote: --- On Mon, 27/2/12, Francois Gouget fgou...@free.fr wrote: Patches are posted to wine-patc...@winehq.org: http://www.winehq.org/pipermail/wine-patches/2012-February/111804.html A quick look at it (it is a few hundred k) - says a few of the problems I saw and suspected: - some of the changes are not improvements/corrections but just opinionated changes - some changes are wrong (i.e. the older version is more correct/natural and the change makes it worse, not better). - some of the changes are over-eager: i.e. it improves on windows and tried to be more user-friendly, but not exactly how windows does it. I think there should be a notes on the translation FAQ: one is not looking to be better than windows, but bug-for-bug-compatible. Therefore translation is preferably what regional/localized windows (whatever version) does. 20% of the world's population is Chinese, I am sure it is easy enough to do a few screenshots of localized windows (be in traditional or simplied) and show how those behave. There is a definitive answer (or definition answers) to most of these translation strings: what localized windows (some version) does. It is not up to individual or group opinions, really. I mean, public libraries, etc have windows in the far east, there is no excuse to be wrong, or on the opposite extreme, try to improve on windows, even if one does not want to get one's hand dirty and own a windows box.
Re: Translators wanted!
--- On Mon, 27/2/12, Cheer Xiao xiaqq...@gmail.com wrote: 2012/2/17 Qian Hong fract...@gmail.com: Hello, On Fri, Feb 17, 2012 at 2:13 AM, Francois Gouget fgou...@free.fr wrote: I feel that we should put out a call for translators to the wider community. In preparation for that I updated the Wiki's Translating page and added a winepo script to help translators who don't want to check out the whole Wine source: http://wiki.winehq.org/Translating snipped I had maintained zh_CN translation for quite some time, but haven't touched it for about a year (since Wine switched to po files). I might get down to cleaning up zh_CN.po in the near future, but I'll contact you before that. In another thread, I wrote that some of the recent patch 'tries to improves on windows'. IMHO, this is really not a translation job, but just the rather tedious task of looking at what localized windows does in equivalent situations. One should *not* be creative and does one's own thing - the localized message files should be (some version of) what localized windows shows. Anything else is wrong. There are plenty of people running localized windows everywhere these days... shoud not be difficlt to find.
Re: po: zh_TW translation updates
--- On Mon, 27/2/12, 盧瑞元 rueiyuan...@gmail.com wrote: snipped msgid Finished searching the document. -msgstr 檔案搜尋結束。 +msgstr 檔案查找結束. 查找 is used in zh_CN, not zh_TW. The older version is preferred. (may be it is just my opinion). msgid Failed to load the RichEdit library. -msgstr RichEdit 載入失敗。 +msgstr RichEdit 裝載失敗. Same as above. ditto here. The older version is preferred. That's two of us, saying those two changes are questionable. I think quite a few other changes in that patch is of this opinion. Here is the patch, BTW, http://www.winehq.org/pipermail/wine-patches/attachments/20120225/a9133e28/attachment-0001.bin for those of us who can read chinese.
Re: Translators wanted!
--- On Mon, 27/2/12, Francois Gouget fgou...@free.fr wrote: On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] One should *not* be creative and does one's own thing - the localized message files should be (some version of) what localized windows shows. Anything else is wrong. Do not do that. That would be copyright infrigement. That's not what we want. This would get your contributions removed from Wine. claiming copyright on short phrases like 'loading dlls failed' (in whatever language) seems very far-fetched.
Re: po: zh_TW translation updates
--- On Mon, 27/2/12, Francois Gouget fgou...@free.fr wrote: On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] - some of the changes are over-eager: i.e. it improves on windows and tried to be more user-friendly, but not exactly how windows does it. I think there should be a notes on the translation FAQ: one is not looking to be better than windows, but bug-for-bug-compatible. Therefore translation is preferably what regional/localized windows (whatever version) does. 20% of the world's population is Chinese, I am sure it is easy enough to do a few screenshots of localized windows (be in traditional or simplied) and show how those behave. There is a definitive answer (or definition answers) to most of these translation strings: what localized windows (some version) does. It is not up to individual or group opinions, really. I mean, public libraries, etc have windows in the far east, there is no excuse to be wrong, or on the opposite extreme, try to improve on windows, even if one does not want to get one's hand dirty and own a windows box. The dialog labels and error messages are an area where we don't need to and don't want to be word for word identical to Windows. We should definitely follow the Windows User Experience Interaction Guidelines: http://msdn.microsoft.com/en-us/library/aa511258.aspx The Windows GUI is certainly be a valuable resource to determine which terms the users are going to be familiar with (e.g. will they more readily understand 'directory' or 'folder'). That said Wine runs on Linux and Mac OS X so Wine's users will likely be somewhat accustomed to the terms used by these platforms too. But in any case blindly copying all the strings from the Windows GUI would be a very bad idea. but wine is supposed to be bug-for-bug compatible with windows, (just as a joke, or not), surely that includes poor user experience? :-). that aside, I think you are quite wrong in trying to improve user experience. That's a matter of opinion - and unfortunately, I have already pointed out, some of the changes are just opinions, and therefore subject to churns - i.e. some will disagree and want the older version of a translation of a particular phrase back, etc.
Re: po: zh_TW translation updates
--- On Sun, 26/2/12, Francois Gouget fgou...@free.fr wrote: +#, fuzzy msgid Connection unavailable.\n -msgstr +msgstr 不可用; 。\n meaning just 'useless/unavailable' - could be improved. msgid This program is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. msgstr 這個程式是自由軟體﹐您可以遵照\n 自由軟體基金會出版的 GNU LGPL 2.1\n 版或新版的許可條款來修改和重新\n 散佈這個程式。 基金會 seems wrong. Are you sure that's FSF's chinese name? msgid Finished searching the document. -msgstr 檔案搜尋結束。 +msgstr 檔案查找結束. The older version is preferred. (may be it is just my opinion). msgid Failed to load the RichEdit library. -msgstr RichEdit 載入失敗。 +msgstr RichEdit 裝載失敗. ditto here. The older version is preferred. msgid Overwrite %1? (Yes|No|All)\n -msgstr +msgstr 是否覆蓋 %1？ （是｜否｜全部皆是）\n This translation also looks dubious. BTW, where was the patch posted? I don't seem to have the very original patch submission (if it were posted to wine-devel).
Re: po: Update Chinese (Taiwan) translation.
--- On Fri, 24/2/12, Francois Gouget fgou...@free.fr wrote: #, fuzzy msgid Write fault.\n -msgstr 默認。\n +msgstr 預設。\n #, fuzzy msgid Read fault.\n -msgstr 默認。\n +msgstr 預設。\n These two are wrong, as far as I see - (I need to know the context to be sure). From one placeholder to another placeholder. msgid New override for library: -msgstr 新增函式庫頂替(N)： +msgstr 新增函式庫覆載(N): msgid Existing overrides: -msgstr 已有的函式庫頂替(o)： +msgstr 已有的函式庫覆載(O)： These two also look wrong (or unnatural).
winedevice taking up 100% after wine cmd
I just had a rather odd incident earlier today when I just launched wine cmd, and saw that my process monitor max-out to 100% - and it continued, until I finished what I intended to do and exited cmd, minutes later. I wasn't doing anything else and no typing anything in the cmd console either, so that was curious. It was winedevice taking up 100%. I tried wine cmd later but couldn't get that odd behavior any more. But is there any reason why winedevice should go into a spin? This is fedora 15 x86_64 running 32-bit wine I built myself.
Re: Regression testing breakthrough
I have two suggestions - - git clone has a --depth option which does a shallow clone (i.e. with some history removed). - you can use git-archive to export arbitrary commits out as a tar ball dynamically; there is no need to have store a tar ball permanently. That said, I am doubtful about the usefulness of this in a linux environment, because the system libraries (in the general sense - libjpeg, etc) varies between different linux distros. --- On Wed, 19/10/11, Joel Holdsworth j...@airwebreathe.org.uk wrote: Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? Then one could write a simple wine regression bisect tool that implements similar semantics to git bisect, but would essentially wrap wget. Then in your server you could have an index file which is a list of the sha commit ids. This would save the user having to clone a 26Gb repository when most of the commits will be irrelevant. Extra bonus points for doing a better job of compressing the small deltas between binaries*, rather than compressing full wine builds. Joel * Are binaries deterministic like this? or do they tend to be completely scrambled? On 18 October 2011 at 09:45 Damjan Jovanovic damjan@gmail.com wrote: Hi Since the beginning, I've had issues with regression testing. Despite the fact it's very useful, it takes forever, it's easy to make a mistake (especially during reverse regression testing), users find it too long and technical, and only a small minority of regressions are ever bisected. And several patches need backporting to allow older versions of Wine to compile and run on today's make, gcc, and libraries - this is the case even for the 1.0.x releases from less than 3 years ago! The problem is of course compilation. configure takes at least 40 seconds, without any way to speed it up on multi-core CPUs. make takes 5 minutes, and it's only taking longer as Wine gets bigger. Compilation is fundamentally complex and technical to users. But what if we had precompiled binaries, and regression testing consisted of just running different versions of Wine? Wine binaries take up about 122 MB and take over 5 minutes to compile. There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff (Release 1.0) and origin. That's about 4.4 terrabytes of storage and over 4 months of compilation, if each of those versions had to be compiled and installed into its own prefix, way beyond what most users are willing or able to store or do. Most patches however end up affecting only a few binary files in the end, and compiling successive versions allows make to be very quick. So I've written a tool that compiles Wine and adds each commit's binaries into a Git repository. It knows how to compile old versions of Wine (currently as far back as 1.0). It knows that commits affecting only ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such don't need to go through the endlessly slow configure, only make. It is stateless: if interrupted, it can resume from the last successful commit. It works around bugs in GNU make (you won't believe how many there are...). This tool compiled all 35000 or so commits from Wine 1.0 to around 4th October 2011 in only 7 days, generating a Git repository of Wine binaries that's only 26 gigabytes in size. Regression testing with binaries is a pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 step regression in just 20 minutes, and most of that time was spent running the application and dealing with 2 X-server crashes. I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? Any other ideas? Would you like to see this tool? Can I send an attachment with it? Thank you Damjan Jovanovic
Re: [patch] Fake display interface
--- On Fri, 2/9/11, Jari Vetoniemi mailro...@gmail.com wrote: Hello, I personally hate when applications decide to change my screen resolution without asking me, or some applications just won't run inside window. So I did fake display interface for the winex11.drv. It allows you to send any display resolution and frequency to the application, but it does not change resolution. It's small and simple patch, and won't probably ever be included into the mainline wine. However I'll post it here as it might be useful for some. To enable, create string key UseFakeDisp with value Y in H_C_U/Software/Wine/X11 Driver Default fake resolution is 800x600 60HZ, you can change default with registry keys FakeDispHeight, FakeDispWidth, FakeDispFreq You can also use env variable WINE_FAKEDISP=WIDTHxHEIGHT_FREQ (eg. WINE_FAKEDISP=1024x768_60) Might improve it later to use the same syntax for default resolution and allow multiple fake resolutions to be defined with ; separator. This is also useful for dual head setups where you may want to run game or application fullscreen on other monitor while still keeping the other alive. There is also interesting side effect: While some applications throw error or won't run on resolutions they don't support, some applications that don't support them still run with the resolution specified. Eg. I can run Ys games with 1440x900 resolution where they normally would not run, and they look great. In winecfg there is a way of configuring wine to run under its own desktop window (and having any window application's windows running inside that), instead of having the unix host's window manager managing the window application's window. Have you tried using that? Granted it is a bit awkward for what you want to do (having to go into winecfg to change the desktop's resolution and resetting it afterwards, instead of passing the resolution in per application), but may be improving on that functionality in winecfg could get your code included eventually somehow.
Re: gecko and native msvcrt
--- On Fri, 29/4/11, Eric Pouech eric.pou...@orange.fr wrote: Le 29/04/2011 23:07, Dan Kegel a écrit : While testing a game with current gecko, I saw the error wine: Call from 0x7bc4ad90 to unimplemented function msvcrt.dll._snwprintf_s, aborting The game needed a native msvcrt, so I had installed one with winetricks, and it didn't export that function. So it seems that new gecko is incompatible with old msvcrt, and using native msvcrt as a workaround for bugs in wine's version is going to be harder than it used to be. Time to fix more of them msvcrt bugs, I guess... And/or find a more up to date msvcrt.dll for winetricks. or link gecko against msvcr80 or msvcr90 instead of msvcrt A+ This may be asking for trouble - I assume gecko is (preferably) built with mingw gcc, rather than msvc. Recently I tried to go this route - wanted to have 64-bit file access from msvc80. Turned out that binaries generated this way gets very confused by the side-by-side assembly system with msvc80 and you need to add/insert a manifest to the PE if you want to go this route, and doing manifest insertion with mingw gcc or open-source tools (rather than microsoft's manifest tool) aren't easy. Ended up just switching to use mingw-specific unix-like 64-bit file access functions instead, to stay with msvcrt (v7). (i.e. the code wouldn't then build with MSVC because it uses mingw-specific things); but I would rather have it built easy with mingw gcc - it is a small sacrifice and easy to make to drop compatibility with msvc compiler..
Re: Idea
(Please keep the wine-devel CC:)
Sanket Patel wrote:
User File Location
On Tue, Mar 22, 2011 at 8:25 AM, Hin-Tak Leung hintak_le...@yahoo.co.uk
mailto:hintak_le...@yahoo.co.uk wrote:
Sanket Patel wrote:
hi there,
I talk about to make wine portable.
How I am Gonna Do That is ,
There is a files that are related to system and integrated in to
system while install.
We gonna change that system files places .
How ? that is still question but we can do By community Support.
If you talk about takiinng 1/2 of system files into package , i
think there is not really a case to happen
Hmm, I think you are confusing 'relocatable' vs 'portable' - in any
case, wine is already both portable (runs on many x86/x86_64-based
unix systems, include linux, *bsd, solaris, Mac OS X), and wine is
also relocatable to a good extent -
you can either run wine without installing, from within the
source(build) directory with the script provided, or you can choose
an install location with ./configure --prefix=...
Or may be you mean the user file location (${HOME}/.wine
(WINEPREFIX)) vs the wine binary locations (the ./configure
--prefix=where)? You need to clarify what you propose.
Perhaps you did not notice, I already wrote that user file location, while
defaults to ${HOME}/.wine, is controllable by setting the WINEPREFIX environment
variable before launching wine. This machanism of allowing for parallel and
separate user files are quite actively used and maintained. WineInBottle (or
something of a similar name?) and possibly a few other wine add-ons does that,
actually.
GSoC questions (Re: Question)
Sanket Patel wrote: How Teams Are Formed in Google Summer Of Code For Any Project. Is It Formed By Organization Or Google ? First, it would be good etiquette to post to mailing lists with sensible and specific subject fields, rather than generic like your past few posts. Many people only read posts from mailing lists of subjects which interest them; so a generic subject fields like yours is almost a guarantee to be ignored. You might have the naive idea that people read *all* e-mails with ambiguous subjects so to get attention it is best to make the subject as ambiguous as possible - that's quite misguided. Again, your questions are ambiguous. There is no teams at the student's level, and there is no teams at the mentor level, nor there is teams in the organization (either wine or google) level. *A* student needs to file *a* proposal, against an organization (e.g. wine) under the GSoC web site. *A* mentor needs to take official responsibility of *a* student, and *a* organization admin (often self-appointed, but usually a well-known person in a community) needs to approve of the mentor taking on the student, against all the other student+mentor combinations. Then the sets of student+mentor combination per organization is ranked and approved by Google on a quota system against all the other organizations'. Any suggestion of a team only generally happens AFAIK in the mentor level: i.e. while *a* mentor is officially responsible to check up on the progress of *a* student, the community as a whole, or some individuals in particular, can take on informal responsibility for guiding the student's progress. It is relatively rare for two students to work on the same project (but different aspect of it) although not unheard of; Google asks towards the end of the selection process for *a* student which has been accepted by more than one organizations, for one of the organizations to drop one of the applications so the other application can proceed.
bluetooth cpl support (Re: USB Device Support - Nokia PC Suite)
--- On Fri, 18/2/11, Mike Yates e...@fonehelp.co.uk wrote: After rebooting, I did get a full list of fixme lines:- mike@myvmubuntu:~$ wine .wine/drive_c/Program\ Files/Nokia/Nokia\ PC\ Suite\ 7/PCSuite.exe snipped err:module:import_dll Library irprops.cpl (which is needed by LC:\\Program Files\\PC Connectivity Solution\\Transports\\NclMSBTSrv.exe) not found err:module:LdrInitializeThunk Main exe initialization for LC:\\Program Files\\PC Connectivity Solution\\Transports\\NclMSBTSrv.exe failed, status c135 snipped (0x14c0d00)-(0x33bcc8) I/O warning : failed to load external entity ConfServer.dtd err:msxml:domdoc_validateNode Could not load the external subset ConfServer.dtd There are really only two important error messages here - I am not sure about the latter, but the first one is simply that part of the Nokia PC suite tries to load irprops.cpl, which AFAIK is the bluetooth control panel applet. It is not surprising that it fails - that hasn't been written in wine yet. I think both sides are 'barking up the wrong tree' - the initial poster thought PC suite failure is due to lack of sufficient USB support in wine; and some of the wine devs can possibly take a quick look before shouting the poster down. The lack of bluetooth implementation is a valid development discussion? It appears that since Nokia PC suite supports bluetooth connectivity to mobile phones (as well as serial cable, infrared, AFAIK, I own nokia phones for about 10 years), it tries to load some windows OS bluetooth bits and fails. If the poster doesn't actually need bluetooth connectivity, adding a stub minimal implementation of irprops.cpl which does nothing can probably get the software to run? OTOH, I already mentioned both on and off list a few times: xnokii/gnokii does what I need with nokia phones and I have never been drawn to look at running the windows nokia software in wine.
Re: USB Device Support
--- On Thu, 17/2/11, Mike Yates m...@fonehelp.co.uk wrote: Hi I (and a lot of contributors to the Nokia forums) would like to use the Nokia PC Suite in Wine. The current status in the AppDB of Nokia PC Suite http://appdb.winehq.org/objectManager.php?sClass=applicationiId=1026 v7.x.x.x is Garbage because, although installation and all the other functions now (wine v1.2.2) work just fine, it is totally useless without its Connect a Phone function. I have written in AppDB:- I know it is a bit off topic - but what functionality of Nokia PC Suite that you need which isn't provided by gnokii/xnokii ? I have nokia phones for nearly 10 years (actually I have never owned a different brand), and gnokii/xnokii has been sufficient for my needs all these days. Connectivity via infrared/bluetooth are okay. by Dave http://appdb.winehq.org/contact.php?iRecipientId=208842 on Sunday September 12th 2010, 3:34 Running Wine 1.2 (latest version on ubuntu repository), trying to install nokia pc suite 7.1.51.0. I get past the license agreement (all icons are black though, but it's not hard to guess which one is NEXT) and choosing which directory to install to (accept the default). But then it quits and I get a window that says, ERROR_INSTALL_FAILURE. According to your website this has been tested and should install, so what's wrong? Using latest Ubuntu-10.10 wine the installation is all visible. No connectivity, but there IS kernel support. Still investigating - will report more later... The kernel connects to my Nokia 6300 by USB as /dev/ttyACM0 I have used this with with wvdial (and other apps) to use the 6300 as an Edge modem and also with kmobile-tools to sync contacts. Surely there is a way of linking /dev/ttyACM0 into wine as a raw USB or serial port? Anyone know how? Well? -- Mike Yates Cowley Middlesex England * *
Re: 64-bit Notepad2 crashes
Susan Cragin wrote: Does this 'path' exist in LD_LIBRARY_PATH or equivilent? Otherwise ld might not be able to 'find' it when starting the program. James McKenzie James... You've just exhausted my technical knowledge. How do I do / find that? Susan: For the BASH shell: Type in set and look for the LD_LIBRARY_PATH line. for the CSH/KSH shell: Type in env Look for the LD_LIBRARY_PATH line. Hopefully, /usr/local/lib is there. BTW, to make Wine work on a Mac, I have to add this line James McKenzie Typed set Did word search on library. Nothing. for BASH, it should be export | grep LD_LIBRARY_PATH not set.
Re: The Windows version of the octave --version command exposes an uncommon X network transparency issue for wine
Alan W. Irwin wrote: snipped wineconsole --backend=curses MinGW/msys/1.0/bin/bash.exe Under that bash if I set the PATH to include the bin directory where octave.exe resides and run octave --version directly (i.e., not from an X-terminal) I get a good result which consists of the usual GNU octave version message. If I do the same thing from my X-terminal (where all X applications like the xterm where the wineconsole command is executed are running on a remote machine over the office LAN and a local X server on the X-terminal box transparently handles the X display, keyboard, and mouse), then I get the following errors (subject to rewrapping) bash.exe-3.1$ octave --version X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 208 Current serial number in output stream: 210 snipped I am still not quite sure about the two different execution environments you have, but if it is DRI-related, you could try also running Xvfb and setting DISPLAY to the Xvfb virtual display to see if either of your execution environments continue to work. AFAIK Xvfb is totally software-based and since octave --version doesn't use X display at all, using Xvfb should be no effect what so ever.
Re: AUTHORS list and the C locale on Mac OS X
--- On Wed, 10/11/10, Ken Thomases k...@codeweavers.com wrote:
From: Ken Thomases k...@codeweavers.com
Subject: Re: AUTHORS list and the C locale on Mac OS X
To: Reece Dunn mscl...@googlemail.com
Cc: wine-devel wine-devel@winehq.org
Date: Wednesday, 10 November, 2010, 20:08
On Nov 9, 2010, at 4:29 PM, Reece
Dunn wrote:
You could use autoconf to detect:
1/ broken handling of UTF-8 characters by
sed;
2/ name of LC_ALL flag that handles UTF-8
In theory, you only need to set LC_CTYPE, not any other
aspect of the locale. And for that, you don't need the
language or country. On Mac OS X, the encoding can be
bare, such as LC_CTYPE=UTF-8.
The Makefile used to set LANG, then commit
492ac292b918a3369900532e4edfadaeeba32064 changed it to
LC_ALL. That wasn't explained. I assume it was
because LANG could be superseded by LC_* variables in the
user's environment, and that is undesirable.
Perhaps another approach would be to explicitly unset
LC_ALL and export LC_CTYPE=UTF-8.
On Nov 9, 2010, at 4:13 PM, Charles Davis wrote:
Unfortunately, I just remembered that the name of the
UTF-8 encoding is
different on Mac OS ('UTF-8') and Linux ('utf8').
Are you sure about that? Checking on a couple of
Linux systems here, the locale command reports:
$ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
...
Hmm. However, using a bare encoding for LC_CTYPE
doesn't seem to fly on Linux. Darn, so close to a
simple fix. :(
mine (fedora x86_64) does the utf8 thing:
# locale
LANG=en_GB.utf8
LC_CTYPE=en_GB.utf8
...
so there is some truth in the reporter's assertion - what it means is that it
varies between different linux'es!!!
Re: AUTHORS list and the C locale on Mac OS X
--- On Wed, 10/11/10, Ken Thomases k...@codeweavers.com wrote: I should have been clearer. The output just reflects your environment. So, you have LANG set to en_GB.utf8. I had LANG set to en_US.UTF-8. My only point was to say that the UTF-8 form is acceptable. It was not to suggest that utf8 is not, nor that one or the other is a standard. The real question is: does the Linux C library accept 'UTF-8' in the environment variables? I believe it does, which is useful because that's what Mac OS X requires. (It doesn't accept utf8.) For example, the following reports just fine on some Linux systems here: LC_ALL=en_GB.UTF-8 locale As does your case: LC_ALL=en_GB.utf8 locale But the following both produce some diagnostics indicating that the C library is choking on the value: LC_ALL=en_GB.bogus locale LC_ALL=en_GB.UTF-9 locale I take this to mean it's a legitimate test of whether a value is valid. Further, it indicates that (at least some) Linuxes take either form. On my system (fedora 14 x86_64), the valid locales are stored in: /usr/share/X11/locale/ and part of libX11-common together with /usr/share/X11/locale/locale.alias which defines aliases (like the lowercase/uppercase with without - above). I had an impression that these things used to be glibc-common or glibc-locale, but it seems that they have moved.
Re: Problems with Test
--- On Mon, 1/11/10, James Mckenzie jjmckenzi...@earthlink.net wrote: From: James Mckenzie jjmckenzi...@earthlink.net Subject: Re: Problems with Test To: Charles Davis cda...@mymail.mines.edu Cc: wine-devel@winehq.org wine-devel@winehq.org Date: Monday, 1 November, 2010, 14:26 Charles Davis cda...@mymail.mines.edu wrote: On 10/31/10 9:23 PM, James McKenzie wrote: All: I'm trying to convert one integer number using a float number factor. Here is the code: int ry = 125; double ryf; ryf = ry/1440; snipped Got it. I tried to cast ry to double, but that did not work. Guess my version of gcc has a problem or I did it wrong. snipped - ryf = ((double) ry)/1440; - should work# - ryf = (double) ry/1440; - does not work, because it is equivalent to (double) (ry/1440) (still integer division). So it depends on how you did cast, really.
Re: Chinese translation of key pages on wiki.winehq.org?
Frédéric Delanoy wrote: On Tue, Aug 31, 2010 at 02:40, Dan Kegel d...@kegel.com wrote: Are there any Chinese speakers on the list? Any interest in starting a Chinese translation of wiki.winehq.org? I bring this up because a Chinese user/developer is asking for help getting started with submitting translations to Wine. I think he would find Chinese versions of http://wiki.winehq.org/SubmittingPatches and perhaps even http://wiki.winehq.org/Translating helpful. It seems strange for a translator to need help reading English documents, but perhaps it would help them come up the curve faster. Well maybe it's because (some of) these pages are not clear enough for non-techies. Maybe he could tell what parts he didn't understand so the wiki pages can be improved (it would help for other languages, too). Wel, I suppose I can help proof-read if it comes to that. But http://wiki.winehq.org/Translating is really not a good starting point as it assumes a great deal of development and windows knowledge - at least the first few paragraphs scare me :-). I think as a start he/she should try to translate some of the documentation (e.g. say, the user guide, or even the weekly news) rather than windows resources rc files!
Re: Inviting Mono and pulseaudio to wineconf?
--- On Thu, 26/8/10, Vincent Povirk madewokh...@gmail.com wrote: Also, half of the cross-compiling dependencies are available (and more up to date) on fedora under the ming32-* packages. I don't use fedora, but you're welcome to add that information for the benefit of fedora users. (Or even a reference for yourself; that's pretty much what I use the wiki for.) Maybe I'll fix the svn references sometime, if I remember. I have added the github info - wasn't too sure about editing/removing old stuff, so I just added an extra paragraph at the end of the svn checkout part. I'll make another section later about building on fedora and fedora-specific info.
Re: winetrick mono dot net 3.5 emmulation.
apologies - for laziness, I picked one message with Dan Kegel and did a reply and emptied subject/body. I guess that messes up e-mail software that actually uses the invisible headers for threads. Original Message Subject: Re: winetrick mono dot net 3.5 emmulation. Date: Wed, 25 Aug 2010 21:01:09 -0700 From: James McKenzie jjmckenzi...@earthlink.net To: Hin-Tak Leung hintak_le...@yahoo.co.uk Hin-Tak Leung wrote: The installer of one application I have requires Net 3.5 and refuses to install if it is not detected. Yet it runs adequately well with mono 2.6.x (when installed to Vista then copied over). So I am wondering if there should be a winetrick lie about having .net 3.5 registry setting, and go about seeing what needs to be done - e.g. how is that installer detecting dot net 3.5 ? Can you open a separate thread for this? I'm going ahead and deleting all of the messages from the hijacked thread on my system and you have a very good point to make. James McKenzie
Re: Inviting Mono and pulseaudio to wineconf?
Vincent Povirk wrote: snipped http://wiki.winehq.org/Mono is looking good. (Think there's a Summer of Code 2011 project or two in there?) Judging by bugzilla, there don't seem to be any large projects that would help compatibility enough to be worthwhile. All the mscoree bugs only affect one app. Sorry for going off-track in this thread again... I just noticed a couple of outdated-ness on http://wiki.winehq.org/Mono - the Ximian people have switched to git on github for hosting the development about a month ago. It is on git://github.com/mono/mono.git or thereabouts. Also, half of the cross-compiling dependencies are available (and more up to date) on fedora under the ming32-* packages.
winetrick mono dot net 3.5 emmulation.
The installer of one application I have requires Net 3.5 and refuses to install if it is not detected. Yet it runs adequately well with mono 2.6.x (when installed to Vista then copied over). So I am wondering if there should be a winetrick lie about having .net 3.5 registry setting, and go about seeing what needs to be done - e.g. how is that installer detecting dot net 3.5 ?
Re: wine.inf: added .NET InstallRoot key
--- On Tue, 24/8/10, Vincent Povirk madewokh...@gmail.com wrote: And eventually mono will be installed automatically like gecko is? If I ever get the damn thing to build fully on a Linux box, yes. Is there a problem with that? Mono comes with a script called build-mingw32.sh for cross-compiling on linux. I use that for every mono release since about 2.2 as I need a little customization, changing the heap setting, before they get the new garbage collector code scheduled for 2.8(?) ready. I only rebuild the runtime - not the class libraries, so I stop the build in the middle. There are some dependency differences (depending on different versions of dependent dll's) against MSVC builds, file naming differences (the mono dll is called libmono.dll in one but just mono.dll in the other - I filed a bug for it and it is still open), and dependencies on gcc_s*.dll from exception unwinding, but it is basically inter-operable - as I swap one part of the stock msvc build with a custom mingw cross-compiled part for every release for much of the last two years now.
Re: Sending patches for bug #22918
Misha Koshelev wrote: Dear All: Congrats on 1.2! I have begun sending my patches from my repository: http://github.com/misha680/wine/commits/master Specifically, I have sent the first 10 patches (of approx 70 currently). I look forward to your comments/commits ;) Also, if anyone knows how to make git format-patch only output the 10 _bottom-most_ patches, please let me know. I tried: git format-patch -n --stdout origin --branches --not --remotes=upstream -10 | git imap-send (note the -10 in the command above) but that sends the 10 topmost patches, sadly :( Bottom of git-format-patch man-page, example: Extract commits between revisions R1 and R2, and apply them on top of the current branch using git am to cherry-pick them: $ git format-patch -k --stdout R1..R2 | git am -3 -k also read 'man git-rev-parse' about how to do address revision . You want ^10 or ~10 .
Re: The __WINE__ macro does not identify the Wine platform
You seems to have made one mistake - it is winegcc, (without space) not wine gcc. winegcc does define __WINE__ . --- On Thu, 17/6/10, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: According to some old discussion (http://www.mail-archive.com/wine-de...@winehq.com/msg15669.html) on wine-devel it appears that __WINE__ was going to be the macro used to identify the Wine platform, However, that doesn't appear to work for Windows native MinGW on wine. To show this, I attach results from running wine gcc -E -dM foo.c | /tmp/wine_gcc_dM.out where foo.c is an empty file, and gcc is the MinGW 4.5.0-1 version. The equivalent command under Linux gcc shows several macros, (e.g., __linux__) are defined to identify that platform, but I cannot find anything in the attached file that similarly identifies the Wine platform. Furthermore, I have compiled and run a simple test code under Wine that shows that __WINE__ is not available (see previous post on wine-users for details). An excellent general motivation for such an identifying macro for wine is given in the above older wine-devel discussion, and I understand the CMake developers have an immediate use for such a macro within the CMake code itself. Is the lack of a macro to identify the wine platform a bug I should report or am I missing something? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: The __WINE__ macro does not identify the Wine platform
Alan W. Irwin wrote: Thus, is there not some standard means that could be used for wine to tell the various MinGW compilers built on Microsoft Windows but run under wine to always #define __WINE__? I am quite sure AJ will object to any such things - as far as the various compilers (and windows applications in general) are concerned, they should just believe they are running under windows. If a compiler (or a windows application) behaves differently under Microsoft Windows vs under wine, it is a bug for wine. AFAIK, the only recommended/supported way for an application to tell that it is running under wine vs under windows is by querying the presence of one of wine-specific registry entries. It is quite evil for a compiler to query the registry. Microsoft compilers probably try to probe the host about which versions of windows it is running in to work around silently various bugs in different/older versions of OSes which are fixed later, but I doubt any mingw people or GNU people for that matter, want to go down that path. In other words, don't even think about it.
snoop,relay,trace
I am thinking of going barbaric and doing WINEDEBUG=+relay,+snoop,+trace to see how mt.exe get the wrong image size in http://bugs.winehq.org/show_bug.cgi?id=22812 and just grep for the wrong/right sizes (0x 2b000, 176128, 0x 2b200, 176640 ) to see where mt gets it from but none turn up. Since it is a relatively simple command line I thought that would work. or is there any other WINEDEBUG= is worth trying? Also I am thinking since the image size is normally padded to 0x1000, (and it says so), so a PE with an image size that looks like N200 is automatically wrong, is that correct?
Re: Rome total war
Regression tests are not really that hard. I'll give you an example. I have been working on the EM_FORMATRANGE function and let it go for about six months due to other things going on in my life (something called El Tour de Tucson, you can Google it.) When I picked up the code, the Print Preview function did not work. I had a lot of code to bisect. I finished this in less than six hours at about 20 minutes a build Everything is in the git bisect man page. (type man git-bisect in a console and read). There is nothing much to it - it just does a binary search through revision but do the search under your guidance: you answer yes or no whenever a build finishes and tests if that build work (as in for a specific problem) or not. On modern linux systems, ccache caches compilation results and git by default when switches versions update all files which changes to have the latest file stamps, so either way one does actually do a full build (but either read from the compiler cache or rely on make - and the makefile - being correct to have the right dependencies and only rebuild files changed).
Re: software built and worked under wine but not in vista?
Matijn Woudt wrote: There are a few differences I spotted between the two executables: 1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to 0x2b000 makes the executable working under win7. 2) setupgs-wine.exe has wrong resource size, probably related to 1), because the size of both executables are the same. 3) The assembly in setupgs-wine.exe has only LF line endings, vista has CRLF. This explains 2). I don't know the reason for 3), I assume it's a bug somewhere in wine. I have started looking into pedump and dumpbin, and the PE/COFF format, but it is new territory to me... can you explain either in a private e-mail, or if the info is more relevant to the wider audience, how can one tell the image size and resource size is 'wrong'? Presumably it is a consistency check of some sort - i.e. one part needs to agree with another, and the wine loader is not doing the check at the moment. If I can do that life on linux or elsewhere life would be easier - not booting into windows; because then I can see what the 2nd bug is about - tried using native imagehlp and there is no improvement, so I probably need to try each of mt.exe's dependencies to see which of them breaks the executable. (but I need to be able to tell an executable being broken first).
Re: software built and worked under wine but not in vista?
Thanks for everybody who advised. I have filed the two bugs under: [Bug 22813] wine's loader does not check invalid image size [Bug 22812] mt creates corrupted executables In a nutshell, just before running mt, wine and vista generates very similiar executables (differing by 4 bytes, two about time stamps and two seems to be some padding at the end of the import table?). Then the mt makes the executables invalid (at least under vista and also according to one of you, from win7). And wine certainly doesn't behave like vista in rejecting the executables and happily loading them...
Re: software built and worked under wine but not in vista?
--- On Thu, 20/5/10, Saulius Krasuckas sauli...@ar.fi.lt wrote: http://www.ghostscript.com/~hintak/setupgs-vista.exe http://www.ghostscript.com/~hintak/setupgs-wine.exe There are a few differences I spotted between the two executables: 1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to 0x2b000 makes the executable working under win7. 2) setupgs-wine.exe has wrong resource size, probably related to 1), because the size of both executables are the same. 3) The assembly in setupgs-wine.exe has only LF line endings, vista has CRLF. This explains 2). I don't know the reason for 3), I assume it's a bug somewhere in wine. Thus it could be a fault in Wine's msvcrt.dll (or the like: msvcr?0.dll). To check this, it would be nice to run winetricks vcrun6, recomple the app in Wine and see if the resulting exe run OK on Vista. Tried that - the binary differs by 6 bytes - just timestamp and checksum. So using native msvcrt in vcrun6 has no effect.
Re: software built and worked under wine but not in vista?
--- On Thu, 20/5/10, Matijn Woudt tijn...@gmail.com wrote: * On Tue, 18 May 2010, Hin-Tak Leung wrote: So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but just happened to also work under wine. Any idea how it might happen? I have gone ahead and done exactly that - the correct behavior should be a msg box saying filelist.txt is missing, rather than setupgs.exe not a valid win32 application. http://www.ghostscript.com/~hintak/setupgs-vista.exe http://www.ghostscript.com/~hintak/setupgs-wine.exe I haven't tried the uninstaller yet, so I don't know if the wine-built uninstaller work: http://www.ghostscript.com/~hintak/uninstgs-vista.exe http://www.ghostscript.com/~hintak/uninstgs-wine.exe To analyse the executables are a bit beyond me, but I hope somebody can do that. under either system, if I compile the file twice quickly, the result differs only by the datestamp and checksum (and in two wine-compiled executable built a bit of time between , also a few bytes in the .text section after what looks like an import table in a hex editor? There are a few differences I spotted between the two executables: 1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to 0x2b000 makes the executable working under win7. 2) setupgs-wine.exe has wrong resource size, probably related to 1), because the size of both executables are the same. 3) The assembly in setupgs-wine.exe has only LF line endings, vista has CRLF. This explains 2). I don't know the reason for 3), I assume it's a bug somewhere in wine. I tried uninstgs-wine.exe and it is also broken. What's more, the executable is of a different size. I am thinking 2 and 3 are probably red herrings, although it is curious how it happens. (I git-archive under unix and use winzip to extract them, so the manifests are the same, and have unix line endings.) The ghostscript distribution has other executables besides setupgs.exe and uninstgs.exe (for install and uninstall), but only those two seem to be broken. Those two are also different in having been manipulated through mt. Could the running of mt be buggy? mt -nologo -manifest $(PSSRC)dwsetup_x64.manifest -outputresource:$(SETUP_XE);#1 I have tried re-running mt on either a built executable or vista-compiled ones, but there are no modification. perhaps I don't understand what it does and how it does its work.
Re: software built and worked under wine but not in vista?
--- On Fri, 21/5/10, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote: Krasuckas sauli...@ar.fi.lt wrote: http://www.ghostscript.com/~hintak/setupgs-vista.exe http://www.ghostscript.com/~hintak/setupgs-wine.exe There are a few differences I spotted between the two executables: 1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to 0x2b000 makes the executable working under win7. But that has to be a bug in wine - that it doesn't check the image size and loads PE with an invalid image size? (how that end up being invalid is a different issue).
Re: software built and worked under wine but not in vista?
--- On Fri, 21/5/10, André Hentschel n...@dawncrow.de wrote: compile your setupgs in wine but without the mt-step and try running it on vista. if mt breaks the PE file then submit a bug report describing wrong behavior of mt. This is what I am doing next. I have also made a change to ghostscript trunk (r11296) so that the installer/uninstaller executables can be built ahead or independent of the rest. (they are normally built last so there were some hidden assumptions about some files being already generated). I'll upload a source tarball to http://ghostscript.com/~hintak/ as *winedebug.tar.gz soon with a small workaround (there is a bug about cmd/cp I filed and a work around in wine's bugzilla). To build the binaries do: nmake -f psi/msvc32.mak bin\setupgs.exe bin\uninstgs.exe I'll put all these in two bug reports - it is looking like two bugs; - one where binaries are miscompiled - wine's loader does not complain about the mis-compiled executables, but windows vista or win7 do.
Re: software built and worked under wine but not in vista?
Saulius Krasuckas wrote: I sorry for stepping into Alexandre's or Dmitry's shoes, but.. * On Tue, 18 May 2010, Hin-Tak Leung wrote: So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but just happened to also work under wine. Any idea how it might happen? ... there could be a pair of bugs: one in PE image manipulation functions plus another in Wine PE loading mechanism(s). I could imagine the first easily inside a IMAGEHLP, eg. functions ImageAddCertificate() or CheckSumMappedFile(). If you find the first one, then it should be possible to write a test to reveal the second one. I have checked things like end-of-line, but it is curious why the setupgs program works under wine but not in vista, the reverse situation compared to most. Could you build the same project under real Windows? Then I would run winedump dump -f or even -x on both files to compare the outputs (probably line by line) and to find the essential difference. I have gone ahead and done exactly that - the correct behavior should be a msg box saying filelist.txt is missing, rather than setupgs.exe not a valid win32 application. http://www.ghostscript.com/~hintak/setupgs-vista.exe http://www.ghostscript.com/~hintak/setupgs-wine.exe I haven't tried the uninstaller yet, so I don't know if the wine-built uninstaller work: http://www.ghostscript.com/~hintak/uninstgs-vista.exe http://www.ghostscript.com/~hintak/uninstgs-wine.exe To analyse the executables are a bit beyond me, but I hope somebody can do that. under either system, if I compile the file twice quickly, the result differs only by the datestamp and checksum (and in two wine-compiled executable built a bit of time between , also a few bytes in the .text section after what looks like an import table in a hex editor?
Re: software built and worked under wine but not in vista?
--- On Wed, 19/5/10, Saulius Krasuckas sauli...@ar.fi.lt wrote: I sorry for stepping into Alexandre's or Dmitry's shoes, but.. * On Tue, 18 May 2010, Hin-Tak Leung wrote: So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but just happened to also work under wine. Any idea how it might happen? ... there could be a pair of bugs: one in PE image manipulation functions plus another in Wine PE loading mechanism(s). I could imagine the first easily inside a IMAGEHLP, eg. functions ImageAddCertificate() or CheckSumMappedFile(). If you find the first one, then it should be possible to write a test to reveal the second one. I have checked things like end-of-line, but it is curious why the setupgs program works under wine but not in vista, the reverse situation compared to most. Could you build the same project under real Windows? Then I would run winedump dump -f or even -x on both files to compare the outputs (probably line by line) and to find the essential difference. I am thinking of doing it under real windows. I built it twice under wine and the binaries are identical except for 6 bytes (probably date stamps), so if I build the same snapshot with the same compiler under Vista and the same build procedure, I would expect the the result would be similiarly differ by 6 bytes only, if the compiler/wine works the same way as compiler/vista. I'll try it now and see how it goes.
software built and worked under wine but not in vista?
I have encountered a slightly strange issue with building the windows self-extracting installer release of ghostscript (http://www.ghostscript.com/) - the self-extracting installer is created with the winzip self-extractor package, which can be manually unzipped. The curious thing is that I can build the self-extracting installer under 32-bit wine with the win 7 SDK (on 64-bit linux). but when I tried to run the self-installer under Vista, it says %1 is not a valid win32 application. Manually unpacking the selft-extracting installer and run 'setupgs.exe' (the setup program) also gives 'setupgs.ese is not a valid win32 application' message. But the main ghostcript executable seems operational. (the setup program mostly only just copy the extracted files to Program Files and set up a few registry entries, but ghostscript doesn't not require those to work). So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but just happened to also work under wine. Any idea how it might happen? I have checked things like end-of-line, but it is curious why the setupgs program works under wine but not in vista, the reverse situation compared to most.
Re: Release plans
Alexandre Julliard wrote: Ben Klein shackl...@gmail.com writes: I'm more interested to know in the status of WoW64 in Wine. Can 64bit and 32bit Wine be installed sensibly and concurrently? Yes, everything should work as expected now. Please test it. The last time I checked it was possible to re-use an old wineprefix (created by 32-bit wine under x86_64 platform) with 64-bit wine - is it still the case? My .wine is a bit big and I'd hate to have to re-create it... :-(. Hin-Tak
Re: Release plans
--- On Mon, 10/5/10, Alexandre Julliard julli...@winehq.org wrote:
The last time I checked it was possible to re-use an
old wineprefix
(created by 32-bit wine under x86_64 platform) with
64-bit wine - is
it still the case? My .wine is a bit big and I'd hate
to have to
re-create it... :-(.
I meant to write wasn't possible . Sorry about that.
You can use a 32-bit prefix with 64-bit Wine, but of course
only in
32-bit mode, you won't be able to run 64-bit apps with it.
It is all a bit confusing - see
(https://bugzilla.redhat.com/show_bug.cgi?id=533806) I think the last time I
tried both, I did encounter the problem with
'/home/myuzer/.wine' is a 32-bit prefix, it cannot be used with 64-bit
Wine.
I think a wiki/FAQ could be useful - there is an FAQ somewhere which says one
should use a different prefix for 32-bit wine vs 64-bit wine on platforms which
can do both. My concern is that I have a fairly big ${HOME}/.wine and I'd
prefer to continue to use it, or at least it doesn't get messed up if I switch
to 64-bit wine.
Re: winegcc: Fix compiling of 32-bit Winelib Apps on shared 32/64-bit setups
--- On Fri, 16/4/10, Marcus Meissner mar...@jet.franken.de wrote:
On Fri, Apr 16, 2010 at 10:51:29PM
+0200, André Hentschel wrote:
---
tools/winegcc/winegcc.c |8
1 files changed, 8 insertions(+), 0
deletions(-)
diff --git a/tools/winegcc/winegcc.c
b/tools/winegcc/winegcc.c
index 7023ff4..f780a69 100644
--- a/tools/winegcc/winegcc.c
+++ b/tools/winegcc/winegcc.c
@@ -1252,6 +1252,14 @@ int main(int argc, char
**argv)
opts.unicode_app = 1;
else if (strcmp(-m32, argv[i]) == 0)
{
+
if (opts.target_cpu ==
CPU_x86_64)
+
{
+
const char
*stdlib32path[] = { /usr/lib32/wine,
/usr/local/lib32/wine, /lib32/wine };
lib32 is almost never used in the Linux distros though
I think I read it somewhere that it is a debian-ism. on x86_64 debian, 64-bits
libraries are in /lib, and 32-bits are in /lib32 .
e.g. for SUSE:
/usr/lib is the 32bit path on x86, ppc, s390
/usr/lib64 the 64bit path on x86_64, ppc64, s390x
Just ia64 is an exception and has /usr/lib (and the compat
libs somewhere weird).
Ciao, Marcus
Re: richedit: Documented paragraph border widths are in points not pixels.
--- On Sun, 28/2/10, Andrew Eikum and...@brightnightgames.com wrote: I'd be very surprised if git is modifying your patches without telling you. It's probably Gmail trying to be clever. Telling git-imap-send to send as an attachment (--attach) might fix the issue. Or, if you're already doing that, maybe turning it off would fix it ;) I don't know how others use gmail - but I have had problems using patches coming out of 'Save as' from gmail's web front end with that sort of problem (and the same patch e-mail arriving at my other imap/pop3 account doing okay), until I found the 'show original' tab under gmail's menu selections. Also, there is an -l option for GNU patch to cope with extra white spaces.
Re: winedbg: output of the bt command misses sometimes a frame
--- On Sat, 6/2/10, Bernhard Übelacker bernha...@vr-web.de wrote: Hello, as I was debugging in wine I wondered if following behaviour is intended or could be considered a bug (and should be filed in bugtracker?). When the debugger's current position is on the opening curly bracket of a function a bt command writes a different stack as if the current position is on the next instruction in this function. I think you mis-understand how compiler and debugger works. Curly brackets delimit blocks of code but do not correspond to any machine instructions themselves, and is hence removed during compilation and execution. So debuggers are supposed to skip over them and behaves as if they don't exist during code inspection. What me makes wonder is the frame 0 is always correct but the calling function is not in the stack at all in the first bt: Wine-dbgbt Backtrace: =0 0x7ebe3622 IsWindow(hwnd=0x20060) [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2503] in user32 (0x0033b500) 1 0x7e25429d create_window16+0x5c(cs=0x33b53c, className=QWidget, instance=0x40, unicode=1) [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670] in user.exe16 (0x0033b520) 2 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024, className=QWidget, windowName=pica, style=114032640, x=-2147483648, y=-2147483648, width=-2147483648, height=-2147483648, parent=(nil), menu=(nil), instance=0x40, data=0x0(nil)) [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500] in user32 (0x0033b570) 3 0x650778f3 in qtgui4 (+0x778f3) (0x8000) Wine-dbgnext 2507if (!(ptr = WIN_GetPtr( hwnd ))) return FALSE; Wine-dbgbt Backtrace: =0 0x7ebe3637 IsWindow+0x15(hwnd=0x20060) [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2507] in user32 (0x0033b2b0) 1 0x7ebe0bda WIN_CreateWindowEx+0x1201(cs=0x33b53c, className=QWidget, module=0x40, unicode=1) [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1406] in user32 (0x0033b500) 2 0x7e25429d create_window16+0x5c(cs=0x33b53c, className=QWidget, instance=0x40, unicode=1) [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670] in user.exe16 (0x0033b520) 3 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024, className=QWidget, windowName=pica, style=114032640, x=-2147483648, y=-2147483648, width=-2147483648, height=-2147483648, parent=(nil), menu=(nil), instance=0x40, data=0x0(nil)) [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500] in user32 (0x0033b570) 4 0x650778f3 in qtgui4 (+0x778f3) (0x8000) Wine-dbg Kind regards Bernhard
Re: CJK default fonts for packagers to set
--- On Fri, 5/2/10, Aric Stewart a...@codeweavers.com wrote: Scott Ritchie wrote: My notes from Wineconf remind me that I need to create some manual links in the registry to whatever default CJK fonts are on the system. Can someone tell me what these are supposed to look like? Thanks, Scott Ritchie Sure! (sorry for the delay) The important keys are the following: HKLM,Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink,Tahoma HKLM,Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink,Microsoft Sans Serif and HKLM,Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink,Lucida Sans Unicode They are REG_SZ_MULTI type of either font file ttc:font name or Font file ttf You meant ',' instead of ':' here, right, judging from your example below? (and my impression) so for example windows sets (in inf format for Japanese Windows): HKLM,Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink,Tahoma,0x00010002,MSGOTHIC.TTC,MS UI Gothic,gulim.ttc,gulim,SimSun.TTC,SimSun,mingliu.ttc,PMingLiU The glyphs will be found in order. So if a glyph is missing from Tahoma, then it tries MSGOTHIC.TTC next, if still missing gulim.ttc and so on. I do not have chinese windows to investigate but it may be that the order of the fonts is different. This may not be an issue on linux. Any other questions just ask. thanks! -aric
Re: WINEDLLPATH and /usr/lib/wine
--- On Wed, 27/1/10, Alexandre Julliard julli...@winehq.org wrote: The first step would probably be to explain why you need to have an app with the same name as an existing builtin. ddiwrapper provides its own gdi32.dll.so winspool.drv.so , so that bitmap generated by the host's ghostscript is fed into the printer vendor's driver dlll via gdi32 and the result retrieved back to fed to the printer port. This allows some printers for which native driver is not available to work...
Re: WINEDLLPATH and /usr/lib/wine
--- On Mon, 25/1/10, Michael Ost m...@museresearch.com wrote: Alexandre Julliard wrote: Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install. Two easy options would be: 1. put /usr/lib/wine at the end of the list automatically. This is Hin-Tak Leung's approach. 2. require users to add /usr/lib/wine themselves. I could make a patch for that. #1 is easier for me :) but #2 is a little more standard, acting like LD_LIBRARY_PATH or PATH do. Which would you prefer? ... mo If I understand that bit of code correctly, the current behavior is such that built-ins comes before WINEDLLPATH *and* after, so there is no way a user per-application built-ins can override (even temporarily on a per application basis) the system-wide built-ins. As ddiwrapper - the application I was interested in - tried to provide a gdl32.dll.so which does different things - it stopped working when the system-wide built-ins is both prepended and appended to library search. I think it should work like LD_LIBRARY_PATH, really as they are platform shared libraries. There is, of course a rather absurd way of working around the current situation - cross-compilating the override desired as win32 PE's (then WINEDLLOVERRIDES does work) - but this doesn't quite work, for things like ddiwrapper again, as it actually wants to do host-native (linux-) things, rather than win32-only things.
Re: WINEDLLPATH and /usr/lib/wine
--- On Tue, 26/1/10, Ben Klein shackl...@gmail.com wrote: For DLLs at least, you should be able to rename the .dll.so to a .dll and stick it in the application's directory. I don't recall the last time I tried this, but it certainly worked (I was using a hacked ddraw.dll.so to get Diablo and Worms Armageddon playing nicely). I assume you could do something similar for EXEs. Thanks for the tips - that sounds a bit wrong though, so's are not PE dll's :-). It is a nice hack and probably should/could be documented somewhere. Is there some specific reason why you *need* WINEDLLPATH to override standard built-ins? Is your APP.exe.so being called by some other process that does not specify the full path, or something along those lines? ddiwrapper (doing printing using vendor dll) uses a hacked-up gdi32 to receive bitmaps from the host's ghostscript to feed to the vendor printing dll. I didn't write the code - this is my understanding of how it works.
Re: WINEDLLPATH and /usr/lib/wine
--- On Tue, 26/1/10, Alexandre Julliard julli...@winehq.org wrote: Michael Ost m...@museresearch.com writes: I agree. And that's what your patch does, right? Would you like to submit it to the wine-patches list? I think the case for it is strong, especially since (1) you found that it fixes a behavior change in WINEDLLPATH from November 2006 --- arguably a regression; and (2) it works in the same way that LD_LIBRARY_PATH works, which is what Linux programmers would expect. Actually the current way is precisely what LD_LIBRARY_PATH does for relocatable installs. The loader first looks in the rpath $ORIGIN path, then in LD_LIBRARY_PATH, then in system directories. Wine does exactly the same thing. I suppose that's the intention of specifying rpath (and that change back in feb 2006?) - some are security-conscious and wish built-in bits not to be overridable. I agree most uses of LD_LIBRARY_PATH are fairly ugly hacks, and if it is needed somebody is probably doing something wrong. (on the issue with ddiwrapper - supposedly its use of WINEDLLPATH shouldn't be needed if wine's gdi32 and friends have a more complete implementations of DIB, the *Eng* routines, I think... so it is band-aiding over an issue, but it is a band-aid useful to some people, alright).
Re: WINEDLLPATH and /usr/lib/wine
I asked about the same problem a while ago without any response, but I have a patch for it: https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_Vendor_win32_printer_driver_in_Linux.22.29 I reckon it is because the wine devs don't want people to override certain things. WINEDLLPATH used to work until Feb/March 2006 . --- On Mon, 25/1/10, Michael Ost m...@museresearch.com wrote: Hi, I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe. Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target. So, if these files exist: /usr/lib/wine/APP.exe.so /MY_DIR/APP.exe.so Then this command... WINEDLLPATH=MY_DIR wine APP.exe ... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so. Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve? Thanks for tips or background, Michael Ost Muse Research, Inc.
Re: WINEDLLPATH and /usr/lib/wine
--- On Mon, 25/1/10, Michael Ost m...@museresearch.com wrote: Hin-Tak Leung wrote: I asked about the same problem a while ago without any response, but I have a patch for it: https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_Vendor_win32_printer_driver_in_Linux.22.29 I can see how that patch would work. Though I can also see why it wouldn't be accepted! :) I'll let you know if I come up with something else that doesn't need a patch - though I am not hopeful. Well, the patch wasn't intended to be submitted as is - all it does is partially reverting this particularly commit, which I asked about witout hearing an answer. Posting the patch is more as a way of showing where the location of discussion is. -- commit 1269f43c5a68e03b526098fb18dd0edd42858ceb Author: Alexandre Julliard julli...@winehq.org Date: Fri Feb 17 17:39:44 2006 +0100 libwine: Add the runtime library path to the front of the dll paths list. Obviously, if you come up with something better and more acceptable for inclusion to wine I'd love to see it.
Re: example code appending files with w32api broken?
--- On Wed, 20/1/10, Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de wrote: Dear Hin-Tak, try to write test for the test suite. And for trying genuine windows, use the winetsetbot. No need to reboot. Test in the test suite fingerpoint at errors and help to not introduce regressions. I finally got round to reboot to Vista - and found indeed the example works in Vista but not in wine so I filed a 2nd bug (http://bugs.winehq.org/show_bug.cgi?id=21434 ) and make the first one (bug 21394, cmd copy + syntax for joining files) depends on it. ATM it isn't a regression - it is simply unimplemented/incompletely-implemented functionality in wine...
Re: example code appending files with w32api broken?
--- On Wed, 20/1/10, Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de wrote: Dear Hin-Tak, try to write test for the test suite. And for trying genuine windows, use the winetsetbot. No need to reboot. Test in the test suite fingerpoint at errors and help to not introduce regressions. Hmm, I can see how winetsetbot might be useful - I have two questions: - how does one work with binaries which needs specific input fies? one of the wine bugs is about not being able to append to a file with some specific sequence of API, which works on windows; I guess one way to do it is to create such files within the test binary, before the actual test, but that introduces a lot more variable... - the other bug is cmd's built-in - does winetestbot support running *.bat ? Thanks for the good work (although I haven't made use of it yet; just started reading up on it). Hin-Tak
Re: example code appending files with w32api broken?
--- On Tue, 19/1/10, Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de wrote: Register with the winetestbot, upload your test exe and compare the test output Thanks for the pointer. I'll bear that in mind. ATM I have a patch for one bug which does not work, possibly because it uncovers another bug in wine - I can verify the latter by trying out the stand-alone version of the patch on a genuine windows. So I'll possibly try a genuine windows, and if it works out, file a 2nd bug, make the first one depending on the 2nd and attach my patch to the first. I'll just need to find a time to reboot to windows...
example code appending files with w32api broken?
I needed a WIN32 API based file-appending solution to fix a bug (http://bugs.winehq.org/show_bug.cgi?id=21394) and using the example code http://msdn.microsoft.com/en-us/library/aa363778%28VS.85%29.aspx as reference, I have got a somewhat working solution, except if I follow the code, the WriteFile part for appending fails. Then I have cross-gcc compiling that example source code standard-alone, and the resulting executable won't append under wine cmd either. So it looks like either the example code is wrong, or wine's implementation of WriteFile() is a bit broken sometimes. I have determined the ReadFile succceeds and the SetFilePointer() also work) So I have two questions - (1) can somebody tell if there is something obviously wrong with the example, (2) can somebody say if it is because wine is not working e.g. SetPointer doesn't work? On a general question: what's the policy of patches based on MSDN example code like this? I mean, assuming the example does the job, it is quite difficult to write file-appending code which isn't quite similiar to that.
Re: Fedora users, please test mci patch about time-out/hanging machine
pulseaudio occasionally gets into a confusion by itself. I found I need to do pulseaudio --cleanup-shm from time to time. --- On Thu, 19/11/09, joerg-cyril.hoe...@t-systems.com joerg-cyril.hoe...@t-systems.com wrote: Hi, Testhq.org results from 17th of November about winmm:mci were striking: All machines producing a timeout had f11 in their name. (Another day, some f11 machines passed the tests). http://test.winehq.org/data/4990ca0ea342bd115a9a46047b3b2de599cb916e/index_Wine.html Please test whether the following patch correlates with hanging machines. Not checking waveoutwrite's return code for sure has the potential to hang the play loop, waiting for a buffer to come back that was never sent out in case of error. But then, why did waveOutWrite fail? That's what I'd like you to investigate. Why Fedora 11? Below patch only adds error reporting to the mciplay loop. Feel free to add the same to the mcirecord loop. diff --git a/dlls/mciwave/mciwave.c b/dlls/mciwave/mciwave.c index cdf9146..fdb6b18 100644 --- a/dlls/mciwave/mciwave.c +++ b/dlls/mciwave/mciwave.c @@ -882,6 +882,7 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, waveHdr[whidx], waveHdr[whidx].dwBufferLength, waveHdr[whidx].dwBytesRecorded); dwRet = waveOutWrite(wmw-hWave, waveHdr[whidx], sizeof(WAVEHDR)); +if (dwRet) ERR(Write %d\n, dwRet); left -= count; wmw-dwPosition += count; TRACE(after WODM_WRITE dwPosition=%u\n, wmw-dwPosition); @@ -893,7 +894,8 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */ /* just to get rid of some race conditions between play, stop and pause */ -waveOutReset(wmw-hWave); +dwRet = waveOutReset(wmw-hWave); +if (dwRet) ERR(Reset %d\n, dwRet); waveOutUnprepareHeader(wmw-hWave, waveHdr[0], sizeof(WAVEHDR)); waveOutUnprepareHeader(wmw-hWave, waveHdr[1], sizeof(WAVEHDR)); A future patch will abort the loop in case of error. However so far, when creating situations that hung on my (non-Fedora) machine (cf. bug #20664), the above ERR message was never triggered. So the cause of random mci time-out on test.winehq may as well lay elsewhere. Thanks for your help, Jörg Höhle
