Re: How to install mozilla active in wine
Monday, October 10, 2005, 9:48:18 AM, Dan Kegel wrote: On 10/10/05, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: I would like to install mozilla active in wine, i have downloaded the xpi file. and what should i do make the wine recognize this activex. Searching google for mozilla activex finds http://www.iol.ie/~locka/mozilla/mozilla.htm Does that help? Which brings a question: should we add that address to registry so our Do you want to download and install Mozilla ActiveX? thingy to work? Or should we remove that question all together? Vitaliy This has pretty easy instructions for activex on it, should be in the FAQ http://gentoo-wiki.com/HOWTO_Install_and_update_World_Of_Warcraft_with_wine
Re: [dbghelp] continue dwarf support
On Monday 10 October 2005 21:27, Eric Pouech wrote: BOOL symt_add_udt_element(struct module* module, struct symt_udt* assert(m-symt.tag == SymTagData); if (m-hash_elt.name[0] == name[0] strcmp(m-hash_elt.name, name) == 0) -return TRUE; + return FALSE; } if ((m = pool_alloc(module-pool, sizeof(*m))) == NULL) return FALSE; I don't see the reason of changin the returnd value from TRUE to FALSE usefull because with that i have found a bug ;) (trying to redefine some elements too many times) No problem as all the dbghelp code don't test return code :p Regards, Raphael pgpUYMouLjnUC.pgp Description: PGP signature
Re: Bugzilla administration policies
On Mon, 10 Oct 2005, Tony Lambregts wrote: [...] I'm not sure about 'Window painting in Wine', but we could have one keyword per dll. Then once a bug is disgnosed down to a specific dll, the relevant keyword would be added. This would let developpers with specific knowledge of a given dll look for bugs in their domain. This would also make the keyword list more intuitive and simpler to maintain. Isn't it this what component is for. Currently I know that if it is an MSI bug I set the component to wine-msi and that way Mike McCormack can find them easily. Yes, you're right of course. I had forgotten about 'components'. The big difference between keywords and components is each bug can only have one component but many keywords. Yes, but each bug probably corresponds to only one component so that should be ok. Then there's the granularity issue, i.e. currently there is not a one to one mapping between dlls and components. IIRC the rationale was that having one component per dll was too fine grained and that users would not know what component to put. But I would argue that most of the time users have no idea what component to put anyway. They're prone to take their cue from the first trace in the log and select the component based on that even though the bug is in fact a stack overflow for instance, and thus completely unrelated. So IMHO we have to rely on our Bugzilla maintainers to assign meaningful components to bugs anyway and then they would know exactly which one to use. But then having exactly one component per dll means a RichEdit specialist would have to query for riched32 or richedit20, a network specialist for wsock32, ws2_32 or winsock, etc. So maybe having one component per dll is too fine grained after all. But then in the latter example does the 'wine-net' component include wininet or not? It's the kind of ambiguity that having one component per dll would avoid. Also it would make remembering the component names easier (is it network, wine-net, wine-network?), though I admit that with a list to pick from this point is probably moot. So these are my thoughts and they probably don't help very muchg. One issue with using keywords is that currently it seems one needs special privileges to set them. But this is more a policy issue than a technical one and it can probably be resolved quite easily. You do not need special rights to set existing keywords in a bug. However adding new keywords is a special function (which not everyone has) and so is adding new components. Ok, I was wrong then. That sounds perfect. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
Re: winelib .so change in 20050930?
Michael Ost [EMAIL PROTECTED] writes: OK. That's right. But I'm still flailing trying to build my winelib app with 20050930. Could you tell me what's missing from the steps below? Or point me to some docs? This used to work in 20050419, except that I had to compile the C output from winebuild. A million thanks. ... mo You need to link against libwinecrt0.a. Though using winegcc would probably be easier, it takes care of all that for you. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Bugzilla administration policies
On Tue, 11 Oct 2005, Molle Bestefich wrote: [...] It's mainly a user interface thing. Freetext keywords seem like this really weird feature, which is not clearly represented in the UI, and where the consequences of entering a particular keyword is not especially clear. I think that noone likes to use it (feel free to correct me). I don't share your aversion for keywords. As for them not being clearly represented in the GUI, at least when a bug has a keyword, the keyword is clearly visible in the 'Keywords:' field, whereas when it is associated to a meta-bug all you see is a cryptic dependency on bug 967 or some such. Also the Bugzilla keywords are not freetext. More on this below. Metabugs are much more clear. There's a descriptive text and discussion page for the metabug, where people can discuss which bugs really belong there, or whether this and that bug is related, or which bugs are most critical and needs to be prioritized. There is a page which describes each keyword. To get to it simply click on the 'Keywords:' label in any bug: http://bugs.winehq.org/describekeywords.cgi Note: On this page you can see how many bugs are related to each keyword. Simply click on the bug count and you get all the bugs for that keyword. Keywords are also prone to spelling mistakes. Enter shell23 instead of shell32, noone will find the bug. No. As I said above the Bugzilla keywords are not freetext. Type 'shell23' and all you will get is the following error message: (on a violently red background to be sure you notice itg) shell23 is not a known keyword. The legal keyword names are listed here. Metabugs on the other hand are prone to typos. Say I type '976' instead of '967', Bugzilla won't issue an error message. And if I don't follow the link to make sure I typed right I will not notice the mistake. As you mentioned such a simple typo will prevent people from finding the bug. And since components might be a better match than keywords for some tasks, I will just mention that like keywords they are not freetext, they are clearly displayed in the GUI, and have a page describing them (http://bugs.winehq.org/describecomponents.cgi?product=Wine). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong
Re: Bugzilla administration policies
Francois Gouget wrote: [...] Thanks for the clarifications ;)! There is a page which describes each keyword. To get to it simply click on the 'Keywords:' label in any bug: http://bugs.winehq.org/describekeywords.cgi Well, there I go. That page was well hidden from public view. I see now that it's linked from the keywords anchor on a bug. That's a bit weird, since half of those anchors just link to static informational pages with dumb content. Would've been nice if those had a 'help' icon, to discern them from those that are actually useful. Or perhaps the 'keywords' and 'components' pages should be added to the Bugzilla menu over to the left. My amazement over how unintuitive Bugzilla is will never cease :-).
Re: [TRY3] printer dialog fixes part1 + french
Am Dienstag, den 11.10.2005, 10:36 +0200 schrieb Jonathan Ernst:
-- cut --
+
+EnumPrintersA(PRINTER_ENUM_LOCAL, NULL, 2, NULL, 0, needed, num);
+if(num == 0)
+{
+
-- cut --
Sorry that didn't work.
You receive in num the Number of returned PRINTER_INFO_2 Entries in buffer
Since buffer is NULL, num is always 0.
Working Example from my Patch:
( http://www.winehq.org/pipermail/wine-patches/2005-October/021268.html )
+/* Verify, that we have a Printer installed */
+/* this will fail in wine, when you deleted your printer */
+
+numentries = 0;
+size = 0;
+result = pEnumPrintersA(PRINTER_ENUM_LOCAL,
+NULL, 2, NULL, 0, size, numentries);
+
+if (size == 0)
+{
+result = pEnumPrintersA(PRINTER_ENUM_CONNECTIONS,
+NULL, 2, NULL, 0, size, numentries);
+}
+
-- cut --
size == 0: no Printer installed
size 0: one or more Printers installed
--
By By ...
... Detlef
D:\printer --level 2 --flags 2 -v EnumPrintersA
0002: selected flags: 2
0002:: PRINTER_ENUM_LOCAL
0002: selected level: 2
77d574b1: winspool.drv,pEnumPrintersA
007a: (122) GetLastError() The data area passed to a system call is toosmall.
: EnumPrintersA(0x0002, --NULL--, 2, NULL, 0, 0012ff68, 0012ff60)
0012ff68: (*LPDWORD) pNeeded= 0x01f8 (504)
0012ff60: (*LPDWORD) pReturned= 0x (0)
0001: EnumPrintersA(0x0002, --NULL--, 2, 00142a40, 504, 0012ff68)
0012ff68: (*LPDWORD) pNeeded= 0x01f8 (504)
0012ff60: (*LPDWORD) pReturned= 0x0001 (1)
00142c38: Buffer-Overflow-Check: OK
00142a40: PRINTER_INFO_2 #1
: .pServerName: --NULL--
00142c26: .pPrinterName : Nur_Text
00142c24: .pShareName :
00142c18: .pPortName : FILE:
00142bf0: .pDriverName: Generic / Text Only
00142bb6: .pComment : Generic / Text Only on FILE:
00142bb4: .pLocation :
: .pDevMode :
00142bb2: .pSepFile :
00142ba0: .pPrintProcessor: winprint
00142b98: .pDatatype : RAW
00142b96: .pParameters:
: .pSecurityDescriptor:
0040: .Attributes : 64
0040: : PRINTER_ATTRIBUTE_LOCAL
0001: .Priority : 1
: .DefaultPriority: 0
: .StartTime : 0
: .UntilTime : 0
: .Status : 0
: .cJobs : 0
: .AveragePPM : 0
normal exit
Re: [dbghelp] continue dwarf support
Raphael wrote: On Monday 10 October 2005 21:27, Eric Pouech wrote: BOOL symt_add_udt_element(struct module* module, struct symt_udt* assert(m-symt.tag == SymTagData); if (m-hash_elt.name[0] == name[0] strcmp(m-hash_elt.name, name) == 0) -return TRUE; + return FALSE; } if ((m = pool_alloc(module-pool, sizeof(*m))) == NULL) return FALSE; I don't see the reason of changin the returnd value from TRUE to FALSE usefull because with that i have found a bug ;) (trying to redefine some elements too many times) No problem as all the dbghelp code don't test return code :p Regards, Raphael but it's of no use with the patch you sent, so why clobber the patch with this ? A+ -- Eric Pouech
Re: Bugzilla administration policies
Am Dienstag, den 11.10.2005, 12:48 +0200 schrieb Francois Gouget: And since components might be a better match than keywords for some tasks, I will just mention that like keywords they are not freetext, they are clearly displayed in the GUI, and have a page describing them (http://bugs.winehq.org/describecomponents.cgi?product=Wine). I suggested to add wine-printing in #3302 ( http://bugs.winehq.org/show_bug.cgi?id=3302 ) I think, printing is very important for wine, how many users know, that printing is a part of wine-gdi and the subject is less specific than other keywords (wine-richedit as example). What do you all think about this topic? -- By By ... ... Detlef
Re: [comctl32] Fix SEGV in file dialogs (bug 3366)
Troy Rollo [EMAIL PROTECTED] writes: The following change seems to prevent the SEGV that frequently occurs when you double-click on a folder in the file open/save dialogs. This fix uses IsWindow() to test if the ListView still exists. I have handled all notifications other than those where it seems entirely implausible that the callback could destroy the window. I think it would be a lot cleaner to put the IsWindow test in the notify functions and make them return FALSE (or some appropriate code) when the window is destroyed. Then all you have to do in the callers is check the result instead of duplicating the IsWindow calls all over the place. -- Alexandre Julliard [EMAIL PROTECTED]
Re: D3D7 - WineD3D, 2nd attempt
Hello, I've got the light test running successfully, but I have a problem and need your advice: WineD3D can't create a device without a Window. For DirectDraw and D3D7 running without a Window is valid, at least to a certain extent. The D3D light test does so, and some games use this for some purposes. So I need to do something for the case HWND == 0 or the d3d surface is not a primary surface. * Modifiy WineD3D to work without a window. I don't really like this solution. * Create a hidden window to pass to WineD3D. Such a thing seems to be in DirectDraw allready, at least there's a WNDCLASS member in IDirectDrawImpl, but it's always 0. Does DirectDraw create a internal window somewhere? Is this a useable way to go, or should I try to modify WineD3D for this purpose? Stefan (I CCed this mail to Olivier because WineD3D is heavily involved here.)
Re: [WINEDOC] IDA workarounds;Re: Help translating Japanese error message in installer
James Hawkins wrote: On 10/8/05, Molle Bestefich [EMAIL PROTECTED] wrote: James Hawkins suggested using native comctl32 as a workaround to get IDA running. Here's a patch to mention that in the docs. Using native comctl32 is just a workaround until the bug is fixed. The proper solution is to get this particular bug fixed one way or another. Frank Richter proposed a patch, but it hasn't been committed. We shouldn't document using native dlls though. -- James Hawkins Could you please point me to the URL of the patch that is supposed to fix the IDA installer and has not been committed? I would like to try it with the Japanese RPG installer I asked about earlier. I tried googling for the patch, but there are so many uncommited patches by Frank Richter that I don't know which one(s) to pick, and since the error happens on what looks like a standard edit box, I don't know which file is supposed to be modified. Alex Villacís Lasso
Re: D3D7 - WineD3D, 2nd attempt
On Tue, Oct 11, 2005 at 10:24:58PM +0200, Stefan Dösinger wrote: WineD3D can't create a device without a Window. For DirectDraw and D3D7 running without a Window is valid, at least to a certain extent. The D3D light test does so, and some games use this for some purposes. So I need to do something for the case HWND == 0 or the d3d surface is not a primary surface. Why not use the 'desktop' window to do it ? No idea what window will be used to display when not in Desktop mode (maybe the X root window ?). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Release plans
On 10/1/05, Francois Gouget [EMAIL PROTECTED] wrote: On Sat, 1 Oct 2005, Brian Vincent wrote: On 10/1/05, Molle Bestefich [EMAIL PROTECTED] wrote: Question is, how do I convey updates to the documentation to you guys? Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed WineHQ's CVS page should be updated with instructions on how to get the documentation: http://www.winehq.com/site/cvs I see this is done now. Btw, why not put the Wine documentation in the same CVS as the Wine sources, Website, the AppDB, etc. It seems like this would simplify explaining how to get it a lot (and it would automatically work with cvsup too). When Newman gets a chance it would be a good idea to sync the FAQ currently on WineHQ with the current FAQ on source forge. There is a Q/A in the FAQ that points out how to get the Doc's. -Tom
Re: [comctl32] Fix SEGV in file dialogs (bug 3366)
On Wed, 12 Oct 2005 06:05, Alexandre Julliard wrote: I think it would be a lot cleaner to put the IsWindow test in the notify functions and make them return FALSE (or some appropriate code) when the window is destroyed. Then all you have to do in the callers is check the result instead of duplicating the IsWindow calls all over the place. In most cases this would work, but there are a few cases where a value returned from the callback is used or tested for something else, including one where a return is made if the return value is !FALSE and not if it is FALSE, and one where execution should continue regardless of the return value of the notification. The latter is more problematic since it would require either some magic value that we hope the app does not return or a different notification function that does not interfere with the value returned by the application.
Re: [WINEDOC] IDA workarounds; Re: Help translating Japanese error message in installer
On 10/11/05, Alex Villacís Lasso [EMAIL PROTECTED] wrote: Could you please point me to the URL of the patch that is supposed to fix the IDA installer and has not been committed? I would like to try it with the Japanese RPG installer I asked about earlier. I tried googling for the patch, but there are so many uncommited patches by Frank Richter that I don't know which one(s) to pick, and since the error happens on what looks like a standard edit box, I don't know which file is supposed to be modified. I believe it is this one: http://www.winehq.org/pipermail/wine-patches/2005-September/020456.html -- James Hawkins
Re: Bugzilla administration policies
Detlef Riekenberg wrote: Am Dienstag, den 11.10.2005, 12:48 +0200 schrieb Francois Gouget: And since components might be a better match than keywords for some tasks, I will just mention that like keywords they are not freetext, they are clearly displayed in the GUI, and have a page describing them (http://bugs.winehq.org/describecomponents.cgi?product=Wine). I suggested to add wine-printing in #3302 ( http://bugs.winehq.org/show_bug.cgi?id=3302 ) I think, printing is very important for wine, how many users know, that printing is a part of wine-gdi and the subject is less specific than other keywords (wine-richedit as example). What do you all think about this topic? I changed wine-gdi to read wine-gdi-(printing) This makes it more obvious to everyone. I could change it to something else if anyone has a better idea. -- Tony Lambregts
Re: COMCTL32: fix separators in check groups in toolbars
On 10/11/05, Krzysztof Foltman [EMAIL PROTECTED] wrote: ChangeLog: * Separators with group style set don't separate toolbar radio groups anymore (which broke tool selection in Front Panel Designer) A test case coming soon... I'm not saying this shouldn't be committed, but it might have a better chance if the test case comes first. -- James Hawkins
Re: COMCTL32: fix separators in check groups in toolbars
On 10/11/05, James Hawkins [EMAIL PROTECTED] wrote: On 10/11/05, Krzysztof Foltman [EMAIL PROTECTED] wrote: ChangeLog: * Separators with group style set don't separate toolbar radio groups anymore (which broke tool selection in Front Panel Designer) A test case coming soon... I'm not saying this shouldn't be committed, but it might have a better chance if the test case comes first. Ahh I should've read more of my emails...the test was right after this. Sorry about the noise. -- James Hawkins
Re: Test If Running Under Wine
On Wed, 12 Oct 2005 10:41, cdr wrote: This is naive and far from practical. To me, it's self-evident that an application will want know which run-time OS it's running under for many reasons; it's completely inappropriate for the run-time OS supplier to discourage it from doing so. I wouldn't describe it as completely inappropriate. Aside from the reasons usually given, where possible it is preferable to provide the fix for Wine. Also, if the application is testing for Wine, why not do a Winelib port? It is further my observation that Wine developers are (unfortunately) not particularly interested in supporting application builders who would like to make their applications run well under Wine; There are certainly some who are interested in the Winelib side of things.
Re: Test If Running Under Wine
Troy Rollo wrote: Also, if the application is testing for Wine, why not do a Winelib port? Single sorce to maintain, single binary to distribute. cdr
Re: How to install mozilla active in wine
Le lun 10/10/2005 à 12:12, Dan Kegel a écrit : On 10/10/05, Vitaliy Margolen [EMAIL PROTECTED] wrote: http://www.iol.ie/~locka/mozilla/mozilla.htm Which brings a question: should we add that address to registry so our Do you want to download and install Mozilla ActiveX? thingy to work? Or should we remove that question all together? Good question. One little issue is that that page says the plugin is very finicky about which version of Mozilla it works with. It would probably take a bit of work to make sure that was all working smoothly. One might even consider bundling Firefox and the ActiveX control with binary packages of Wine. But I think that brings up another good point: the decision about what to do about that address probably is best answered by whoever builds the binary packages. IIRC, the maintainer of the Mozilla ActiveX control doesn't have that much bandwidth to spare on Wine users downloading it, so we needed to find another place for that file. The logic place is the sourceforge download servers, but then we need some logic to automatically download from one of the currently active servers. I sent such a patch a couple months ago to wine-patches, but it wasn't applied (screen-scraper, depends on the format of sourceforge pages, etc.). Vincent
Can you reproduce this bug on wine-20050930 like me?
Can you reproduce this bug? Follow these steps: 1. Install Filezilla: http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_16_setup.exe?download 2. FTP into the server of your choice 3. Click and drag files from the server to your local machine (to copy them) 4. Realize now that even though the files have been copied to your machine, you are still dragging the files around If you can replicate this serious bug, can you fix it? Hiji P.S. This is for bug 3148, and I have been able to reproduce it on both Filezilla and AbsoluteFTP __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: Can you reproduce this bug on wine-20050930 like me?
Tuesday, October 11, 2005, 9:00:49 PM, Hiji wrote: Can you reproduce this bug? Follow these steps: 1. Install Filezilla: http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_16_setup.exe?download 2. FTP into the server of your choice 3. Click and drag files from the server to your local machine (to copy them) 4. Realize now that even though the files have been copied to your machine, you are still dragging the files around If you can replicate this serious bug, can you fix it? Hiji P.S. This is for bug 3148, and I have been able to reproduce it on both Filezilla and AbsoluteFTP Yes this is a bug in list view. I've looked into it several days ago. Unfortunately there is no easy fix for it. Wine's DragDetect does not work the same way as it does on windows. When I tried to fix it, it completely broke dragdrop for list view. I didn't want to go to far with fixing it as it surely would of been big changes and not acceptable ATM until after 0.9 release. All I managed to fix was single click dragging that used to start as soon as you clicked on anything. Vitaliy
Tracking bug for serious Wine bugs running must-have K12 apps
I've created metabug http://bugs.winehq.org/show_bug.cgi?id=3554 to track problems in Wine that make K12 classroom applications unusable or untestable. So far I only have two bugs listed there, but I have only looked at one of the apps in the list ( http://kegel.com/wine/qa/#app.k12 ) from the K12OSN folks. My hope is that this becomes a list of the highest impact bugs in K-12 bugs, those that are worth fixing for, say, wine-0.9.2. Less serious bugs can wait for future releases, and don't yet need a tracking bug. Coments, anyone?
