Re: Comments on winefontcfg tool?
Nigel Liang [EMAIL PROTECTED] writes: Hi, I submitted a font configure tool a few days ago that lets the user configure system and menu fonts more easily. The tool is especially helpful to asian and middle-eastern users where the fonts installed may differ greatly from user to user and where the default font size is way too small for some users. I know that ideally we should let wine figure out all this based on fonts used in X or something, but for now, something like this is useful to prevent users from digging into the registry looking for entries to modify (and potentially breaking something.). Any comments on this would be greatly appreciated. It's a nice tool, but it should really be integrated in winecfg. The menu font setting should go with the theming stuff, the dpi setting probably in the graphics tab, and you could add a font tab for the font linking setup. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH] monthcal todo_wine now passes
Marcus Meissner [EMAIL PROTECTED] writes: this test succeeds for me. Not for me... -- Alexandre Julliard [EMAIL PROTECTED]
Re: [3/7] WineD3D: Allocate render target management members in Init3D
Stefan Dösinger [EMAIL PROTECTED] writes:
From 05154939b9123ff44c9e3ec0417c31ccba2a8716 Mon Sep 17 00:00:00 2001
From: Stefan Doesinger [EMAIL PROTECTED]
Date: Mon, 16 Jul 2007 19:49:34 +0200
Subject: [PATCH] WineD3D: Allocate render target management members in Init3D
GL_LIMITS() is not always available in CreateDevice, thus the alloc code
has to be in Init3D. To avoid memory leaks and keep things consistent
the free calls are moved from Release to Uninit3D.
../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so
d3d.c touch d3d.ok
wine: Unhandled page fault on read access to 0x at address 0x61bf2a2c
(thread 0019), starting debugger...
WineDbg starting on pid 0017
Unhandled exception: page fault on read access to 0x in 32-bit code
(0x61bf2a2c).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:61bf2a2c ESP:0033fa10 EBP:0033fa58 EFLAGS:00010246( - 00 -RIZP1)
EAX: EBX:61c8c8d8 ECX:001e8678 EDX:61c8d600
ESI: EDI:001e8678
Stack dump:
0x0033fa10: 001e8678 60917764
0x0033fa20: 0011 0002 61c696e1
0x0033fa30: 1302 00340020
0x0033fa40: 61bf281b 61c8c8d8
0x0033fa50: 001e86a0 001e8678 0033fa88 61c1cbb0
0x0033fa60: 0015f1a0 001e8678 00340020 61c37ff8
Backtrace:
=1 0x61bf2a2c IWineD3DDeviceImpl_ResourceReleased+0x21c(iface=0x15f1a0,
resource=0x1e8678) [/home/julliard/wine/wine/dlls/wined3d/device.c:6456] in
wined3d (0x0033fa58)
2 0x61c1cbb0 IWineD3DResourceImpl_CleanUp+0x100(iface=register EDI not in
topmost frame) [/home/julliard/wine/wine/dlls/wined3d/resource.c:89] in
wined3d (0x0033fa88)
3 0x61c4109f IWineD3DSurfaceImpl_Release+0xbf(iface=0x1e8678)
[/home/julliard/wine/wine/dlls/wined3d/surface.c:414] in wined3d (0x0033fac8)
4 0x6072e685 IDirectDrawSurfaceImpl_Destroy+0xe5(This=register ESI not in
topmost frame) [/home/julliard/wine/wine/dlls/ddraw/surface.c:229] in ddraw
(0x0033faf8)
5 0x6072e953 IDirectDrawSurfaceImpl_Release+0x133(iface=0x1e8580)
[/home/julliard/wine/wine/dlls/ddraw/surface.c:425] in ddraw (0x0033fb48)
6 0x6072e37d
IDirectDrawSurfaceImpl_DeleteAttachedSurface+0xfd(iface=0x19f6f0, Flags=0x0,
Attach=register ESI not in topmost frame)
[/home/julliard/wine/wine/dlls/ddraw/surface.c:991] in ddraw (0x0033fb78)
7 0x6072e664 IDirectDrawSurfaceImpl_Destroy+0xc4(This=register ESI not in
topmost frame) [/home/julliard/wine/wine/dlls/ddraw/surface.c:220] in ddraw
(0x0033fba8)
8 0x6072e953 IDirectDrawSurfaceImpl_Release+0x133(iface=0x19f6f0)
[/home/julliard/wine/wine/dlls/ddraw/surface.c:425] in ddraw (0x0033fbf8)
9 0x606db585 func_d3d+0x1ab5()
[/home/julliard/wine/wine/dlls/ddraw/tests/d3d.c:151] in ddraw_test (0x0033fe58)
10 0x606ed9c8 run_test+0x128(name=0x1103b6)
[/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:389] in
ddraw_test (0x0033fea8)
11 0x606ee05d main+0x14d(argc=register ECX not in topmost frame,
argv=register ECX not in topmost frame)
[/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:437] in
ddraw_test (0x0033fed8)
12 0x606ee12b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000)
[/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test
(0x0033ff08)
13 0x6041059e start_process+0xee(arg=0x0)
[/home/julliard/wine/wine/dlls/kernel32/process.c:820] in kernel32 (0x0033ffe8)
14 0x60027af7 wine_switch_to_stack+0x17() in libwine.so.1 (0x)
0x61bf2a2c IWineD3DDeviceImpl_ResourceReleased+0x21c
[/home/julliard/wine/wine/dlls/wined3d/device.c:6456] in wined3d: cmpl
0x0(%eax,%esi,4),%ecx
6456if (This-fbo_color_attachments[i] == (IWineD3DSurface
*)resource) {
--
Alexandre Julliard
[EMAIL PROTECTED]
Getting CA certificates into the registry
(Apologies if you get this twice - I wasn't subscribed to wine-devel on this account, and apparently it didn't get moderated through.) Folks, I'm hoping for feedback on how to get CA certificates into Wine's registry. We'll need them in order to verify signatures on things. A number of apps depend on this [1]. We have a few choices: 1. Include them in a .inf file and install them with wine. There are two problems with this that I see: Signatures are opaque (asn.1 encoded) and thus hard to verify, and there's a potential maintenance hassle. It's by far the simplest though. 2. We search for certificates installed locally and import them into the registry. The trouble with this is that different distros, and even different versions of the same distro, install them in different locations. There are also usually several potential sources on the same machine, installed by different apps, and it's not clear which certs are meant to be trusted and which are not. (For example, there are several example certs installed on my system, and I can identify them as such, but a tool would not be able to tell the difference.) We could write a script that checks in several likely locations, but that seems dangerous: one of those locations might inadvertently be world-writable, so an attacker could possibly put untrustworthy certificates there. 2.a. We write a tool to import local certs, but make you specify the path. Ugly, but punts the problem to the user. 3. We do what the distros do: get the certificates from Mozilla's CVS, and munge them into the right format. (Google for mkcabundle.pl) This is similar to what we do for the unicode tables, but it does introduce a dependency on CVS (or perhaps wget from a web CVS front end.) I suppose I should mention there's another option: 4. We don't load certs in Wine at all, and don't implement certificate chain verification, but dynamically load openssl or gnutls and ask them to do it for us. I don't think this is simpler than the alternatives, as I've already put a fair amount of work into crypt32, but if none of the other options is acceptable I can look into it. I'd very much appreciate feedback on which option seems the best, or, most likely to get committed ;) Thanks, --Juan [1] Here's a partial list - there are more: Bug 5423, AOL AIM won't install, http://bugs.winehq.org/show_bug.cgi?id=5423 Bug 7892, iTunes startup, http://bugs.winehq.org/show_bug.cgi?id=7892 Bug 8870, Outlook can't open signed messages, http://bugs.winehq.org/show_bug.cgi?id=8870
Re: Getting CA certificates into the registry
On Wednesday 25 July 2007 18:20:36 Juan Lang wrote: 2.a. We write a tool to import local certs, but make you specify the path. Ugly, but punts the problem to the user. 3. We do what the distros do: get the certificates from Mozilla's CVS, and munge them into the right format. (Google for mkcabundle.pl) This is similar to what we do for the unicode tables, but it does introduce a dependency on CVS (or perhaps wget from a web CVS front end.) Isn't that what the distro's add-on value should be? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Should Wine move to LGPL 3?
On 7/24/07, Scott Ritchie [EMAIL PROTECTED] wrote: MS explicitly excluded Wine from that deal anyway. Thanks, Scott Ritchie I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL...
Re: Getting CA certificates into the registry
Isn't that what the distro's add-on value should be? Sorry, I don't understand. You think the distros should put CA certs into Wine's registry? --Juan
Re: Should Wine move to LGPL 3?
On 7/25/07, Scott Ritchie [EMAIL PROTECTED] wrote: On Wed, 2007-07-25 at 21:01 +0200, Marcus Meissner wrote: On Wed, Jul 25, 2007 at 03:28:13PM +0100, Damjan Novak wrote: On 7/25/07, Damjan Novak [EMAIL PROTECTED] wrote: I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL... On second thought, reading further the text and FAQ of the licence, I think Im wrong, sorry. Also, Wine is not on SLED/SLES, just on openSUSE, which is not protected by the patent covenant. And it is explicitly left out. Ciao, Marcus On the other hand, it's quite possible that Parallels would enter into some sort of patent thingy with Microsoft, and they DO distribute Wine. Thanks, Scott Ritchie But it's only wined3d right? And that's based on OpenGL. Why they would even consider a patent convent would boggle me. Of course, the threat for unenumerated patents is enough for some. Jesse
Re: Should Wine move to LGPL 3?
On Wed, 2007-07-25 at 21:01 +0200, Marcus Meissner wrote: On Wed, Jul 25, 2007 at 03:28:13PM +0100, Damjan Novak wrote: On 7/25/07, Damjan Novak [EMAIL PROTECTED] wrote: I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL... On second thought, reading further the text and FAQ of the licence, I think Im wrong, sorry. Also, Wine is not on SLED/SLES, just on openSUSE, which is not protected by the patent covenant. And it is explicitly left out. Ciao, Marcus On the other hand, it's quite possible that Parallels would enter into some sort of patent thingy with Microsoft, and they DO distribute Wine. Thanks, Scott Ritchie
Re: Greek resource files for Comctrl, user32 and oleaut32
Onsdag 25 juli 2007 09:49, skrev Dj Apal [GR]:
Hello. I work on Greek localization for ReactOS and the guys there told me
that I should send you the greek resource files for the modules that they
share with you. SO here there are some first resource files.
If I send something wrong, please let me know.
TIA
You need to send one patch per dll, and only send in patch format. For a new
file you can do
diff -urp /dev/null {path_to_file} {patch.diff}
Where patch.diff already holds the change to add the Greek .rc file.
Alexander N. Sørnes
Re: Italian translation for ui_En.rc
On Mi, 2007-07-25 at 16:55 +0200, Paolo Devoti wrote: /* * English resources for localui Did you forgot to replace English with Italian? * * Copyright 2007 Detlef Riekenberg Your can add your Name here ADDPORT_DIALOG DIALOG LOADONCALL MOVEABLE DISCARDABLE 6, 18, 245, 47 DEFPUSHBUTTON OK, IDOK, 199, 10, 40, 14, WS_VISIBLE PUSHBUTTON Annulla, IDCANCEL, 199, 27, 40, 14, WS_VISIBLE END LPTCONFIG_DIALOG DIALOG LOADONCALL MOVEABLE DISCARDABLE 6, 18, 220, 47 DEFPUSHBUTTON OK, IDOK, 164, 10, 50, 14, WS_VISIBLE PUSHBUTTON Annulla, IDCANCEL, 164, 27, 50, 14, WS_VISIBLE The buttons have the same Text, but a different Layout. I suggest to adjust a Dialog. I did this already for the German resource, but not for English. Thanks -- By by ... Detlef
Re: Italian translation for ui_En.rc (more)
On Mi, 2007-07-25 at 16:55 +0200, Paolo Devoti wrote: Attached is dlls/localui/ui_It.rc Oh, and it would be nice, when you create a Patch from your changes and please include the missing change in localui.rc in the Patchfile. git is prefered, but cvs should also work. Thanks for improving wine. We can help, when needed. -- By by ... Detlef
Re: Getting CA certificates into the registry
On Wednesday 25 July 2007 18:20:36 Juan Lang wrote: 4. We don't load certs in Wine at all, and don't implement certificate chain verification, but dynamically load openssl or gnutls and ask them to do it for us. I don't think this is simpler than the alternatives, as I've already put a fair amount of work into crypt32, but if none of the other options is acceptable I can look into it. Is there perhaps an API to just retrieve the CA bundle from a local openssl or gnutls installation? -Hans
Re: Should Wine move to LGPL 3?
On Wed, Jul 25, 2007 at 03:28:13PM +0100, Damjan Novak wrote: On 7/25/07, Damjan Novak [EMAIL PROTECTED] wrote: I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL... On second thought, reading further the text and FAQ of the licence, I think Im wrong, sorry. Also, Wine is not on SLED/SLES, just on openSUSE, which is not protected by the patent covenant. And it is explicitly left out. Ciao, Marcus
[Fwd: Getting good debugging stack traces from wine apport crash reports]
---BeginMessage--- Hello fans of wine, I already sent this to Scott Ritchie a while ago, but didn't get a reply, so let's try here. When we talked about improving apport to deliver better stack traces to us in Sevilla [1], someone also mentioned that wine upstream currently refuses our gdb stack traces for wine crashes. They want to have some special magic applied to it instead. Who would be an appropriate person and/or ML to discuss this with? I am happy to work with someone to get a good solution for this, but since I have zero knowledge about wine I cannot do this alone. As the spec [1] says in point 6, we can either silence apport for wine completely (easy solution, I can do it myself), or find someone who has a clue about debugging wine and winedb who wants to write a proper apport hook for wine crashes. Did someone get curious now? :-) Thank you! Martin [1] https://wiki.ubuntu.com/ApportBetterRetracing -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- Ubuntu-devel-discuss mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss ---End Message---
