Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.
Hello, On Thu, Oct 10, 2013 at 3:24 AM, Ken Thomases k...@codeweavers.com wrote: On Oct 9, 2013, at 4:49 PM, Phil Krylov wrote: Do you consider adding an option to stop interpreting Command as Alt? I have not considered it. What would be gained? Do you want the Command key interpreted as the Windows key? Do you want something else to happen when Command is pressed? Every time I press Cmd-Space to switch keyboard layouts, Wine activates menu as if I would have pressed Alt, so I have to press Command once again to exit it. It does not happen in Windows, though, when I use Alt-Shift to switch layouts, so the real problem is not related to Alt interpretation of Cmd, but to incorrect emulation of Windows behaviour when a keyboard layout switch hotkey is pressed. On the other hand, Option is labeled as Alt, and works this way with the X11 driver, so it seems logical to process Cmd as Win key. And it would hack around my actual problem ;) -- Ph.
Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.
Thanks! Do you consider adding an option to stop interpreting Command as Alt? On Thu, Oct 10, 2013 at 1:30 AM, Ken Thomases k...@codeweavers.com wrote: --- dlls/winemac.drv/cocoa_window.m | 22 -- dlls/winemac.drv/macdrv_cocoa.h |2 ++ dlls/winemac.drv/macdrv_main.c |7 +++ 3 files changed, 29 insertions(+), 2 deletions(-) -- С уважением, Филипп Крылов.
Re: winemac: Don't return characters for Ctrl-(non-letter symbol) keypresses from ToUnicodeEx() as X11 driver already does (try 2)
Hi, On Tue, Sep 10, 2013 at 6:05 AM, Ken Thomases k...@codeweavers.com wrote: Is there a specific problem that you're trying to fix? Yes. I didn't file a bug report yet, but an application I am using (IBM Translation Manager) has some functionality bound to Ctrl-[0-9/] keypresses. Now with the Mac driver when I press Ctrl-1, for example, the function bound to Ctrl-1 is executed, but also '1' gets inserted into the active Richedit control which is wrong. The Mac driver's ToUnicodeEx() implementation started out very similar to the X11 driver's. It was basically a copy that I hacked on. It originally had this same restriction. However, some testing revealed that this is not an absolute restriction on Windows. For example, in the Khmer keyboard layout, Control-digit produces characters for some digits. Given that some Windows keyboard layouts produce characters for Control-digit, I figured it was best left up to the Mac keyboard layout. Similarly for Control-punctuation. For example, the Windows Chinese keyboard layouts produce characters for some of those keystrokes. So does the Czech layout. Yes I investigated the Mac keyboard layout files and found out that the real problem is there - Ctrl-1 is really bound to produce '1' etc. But when I press Ctrl-1 e.g. in TextEdit nothing gets inserted and a beep is heard, but there is no simple way to understand what's happening due to TextEdit's closed-sourcedness. Thanks for the Khmer and Czech Windows layouts info. It might still be possible to re-introduce this restriction if it can be justified based on broad breakage of apps. Although even then, I'd want to make it possible to override the restriction with a registry setting or something. You never know if the ability to enter characters using these key combinations might be crucial for certain Mac users because of the nature of their native keyboard layout. I understand that this is rather a dirty hack, but after I found similar code in winex11.drv, I thought it might get through. If a modification like this were justified, it should go earlier in macdrv_ToUnicodeEx(). There's a section at the top where I moved the checks for combinations that don't produce characters. Also, the check should test that Alt is _not_ pressed, since Control-Alt-digit or punct and Control-Alt-Shfit-digit or punct very commonly produce characters. Control-Alt is a synonym for the AltGr key on some keyboards (e.g. Swiss). Finally, if we're going to pursue this, there are some minor style issues I'd prefer be changed. So, check with me before resubmitting. Ok, I'll retry, although after this answer of yours I have rather little hope left as I don't know any other apps affected by this behaviour, so it can't be called a 'broad' breakage. -- Ph.
Re: [PATCH 1/3] riched20: Use codepage in ME_ToUnicode.
Hello, -ME_EndToUnicode(unicode, wszText); +unicode ? ME_EndToUnicode(1200, wszText) : ME_EndToUnicode(CP_ACP, wszText); Personally I dislike this stuff in C code. Especially when you could make it shorter: ME_EndToUnicode(unicode ? 1200 : CP_ACP, wszText) -- Ph.
Re: Aric Stewart : usp10: Update diacritical script handling for non OpenType Itemization.
Hello, On Fri, Mar 15, 2013 at 12:52 AM, Aric Stewart a...@codeweavers.com wrote: I am just getting back from a vacation so I will review this and your other patch early next week when I am fully back. Thanks for doing work here! Thanks for replying, wasn't sure you saw my posts. And of course thanks for your work too. -- Ph.
Re: Aric Stewart : usp10: Update diacritical script handling for non OpenType Itemization.
Hello Aric,
On Tue, Feb 5, 2013 at 11:25 PM, Alexandre Julliard julli...@winehq.org wrote:
Module: wine
Branch: master
Commit: ef4b7c5948e43d4ceeed98ba4ddbf6c59d36
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=ef4b7c5948e43d4ceeed98ba4ddbf6c59d36
Author: Aric Stewart a...@codeweavers.com
Date: Tue Feb 5 08:57:44 2013 -0600
usp10: Update diacritical script handling for non OpenType Itemization.
(snip)
+for (j = i-1; j = 0 scripts[j] == first_script
pwcInChars[j] != Numeric_space; j--)
+{
+WORD original = scripts[j];
+if (original == Script_Ideograph || original ==
Script_Kana || original == Script_Yi || original == Script_CJK_Han ||
original == Script_Bopomofo)
+{
+asian = TRUE;
+break;
+}
+if (original != Script_MathAlpha
scriptInformation[scripts[j]].props.fComplex)
+break;
+scripts[j] = scripts[i];
+if (original == Script_Punctuation2)
+break;
+}
+if (scriptInformation[scripts[j]].props.fComplex ||
asian)
+scripts[i] = scripts[j];
I am not sure about the logic of this, so I can't commit a good patch,
but in the last statement you definitely access scripts[-1] when j
reaches the value of 0. Which may cause a crash here or (in my case)
later.
-- Ph.
Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value
On 03/07/2008, Dylan Smith [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 2:01 PM, Juan Lang [EMAIL PROTECTED] wrote: Hi Dylan, - if (!editor-bEmulateVersion10 || (editor-nEventMask ENM_UPDATE)) + if (!editor-dwEmulatedVersion || (editor-nEventMask ENM_UPDATE)) This change is incorrect, as dwEmulatedVersion is never set to 0. I believe you mean if (editor-dwEmulatedVersion 0x100 || ... You're right, that was a mistake. Thanks for catching it. I have to ask, though: what bug does this fix? This doesn't fix a bug, but it allows me to add functionality for msftedit.dll without changing the way riched20.dll works when loaded directly. Without storing more than a boolean value it will be hard to support the multiple versions of richedit controls. I would like to properly implement tables for richedit controls, which greatly differs in how it is implemented between riched20.dll and msftedit.dll. Should I only worry about how it is done in the newer richedit controls? I am worried that this will cause problems considering that amy program that loads msftedit.dll assumes that they are getting a specific implementation. IMHO no real applications depend on poverty of table functionality of versions 2 and 3. If somebody finds one, we could think about it then... To my knowledge, there is just one thing better in table support of 2.0 than in 3.0 and IIRC 4.1: better breaking of long tables on page boundaries when printing. But I consider it a bug in versions 2.0 which we should not replicate (when EM_FORMATRANGE will be supported). -- Ph.
Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.
On 29/06/2008, Dylan Smith [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 4:20 AM, Phil Krylov [EMAIL PROTECTED] wrote: Of course this looks most sane. But I'm asking if you're going to make use of the dwEmulatedVersion other than 0x200? That is, under what circumstances we should emulate version 2 or 3 when we have support for version 5? It's interesting to me, because it seemed to me that the native versions (starting with 2.0) are very compatible to each other. -- Ph. I know that versions 2 and 3 are very compatible with, since they register the same class and dll name. Richedit 4.1 however uses msftedit.dll instead, which means that programs would need to explicitlydecide which version they are using depending on which dll they load and which class they specify. Certainly there are differences between richedit 3 and 4.1, but I don't know if programs would depend on these differences. OK I see your point, and after hitting a very interesting blog on RichEdit, I even agree that the exact version number may be needed. http://blogs.msdn.com/murrays/archive/2006/10/14/richedit-versions.aspx http://blogs.msdn.com/murrays/archive/2006/10/20/some-richedit-history.aspx BTW they say that the DLL name for versions 5.0, 5.1, and 6.0 is riched20.dll again. -- Ph.
Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.
2008/6/27 Dylan Smith [EMAIL PROTECTED]: Currently msftedit.dll is implemented by loading riched20.dll and then riched20.dll registers the classes that msftedit.dll normally register. Native msftedit.dll appears to be a full implementation of the richedit controls, rather than a wrapper. Here are the options that I can think of: 1. We could continue to implement msftedit.dll as a wrapper around riched20.dll. This patch would be a step in that direction. Of course this looks most sane. But I'm asking if you're going to make use of the dwEmulatedVersion other than 0x200? That is, under what circumstances we should emulate version 2 or 3 when we have support for version 5? It's interesting to me, because it seemed to me that the native versions (starting with 2.0) are very compatible to each other. -- Ph.
Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.
Hi, 2008/6/27 Dylan Smith [EMAIL PROTECTED]: riched20.dll is implementing all the versions of richedit controls (1.0, 2.0, 3.0, and 4.1), so it is better to store the version that is being emulated. The bEmulateVersion10 value is replaced with dwEmulatedVersion. I thought it implements 1.0 emulation for riched32.dll usage and latest possible version for other usages - just like native. Or are you planning to add some functionality depending on the actual emulated version, not on (dwEmulatedVersion 0x200) boolean flag? -- Ph.
Re: Wine code freeze in seven weeks; volunteers needed to fix 1.0 bugs
Hi, That patch is old and crusty and doesn't apply anymore. James should have an updated version. One thing I can add from looking at that patch is that the comments about the deficiency of MS richedit tables handling are true only for versions =2.0. Later versions, including msftedit, improved tables handling with each new version. -- Ph
Re: Do we need a forum?
Hi, On 19/02/2008, Dan Kegel [EMAIL PROTECTED] wrote: Steven Edwards wrote: My thoughts, as well as Tom's was that by creating a blessed location, all third parties as well as vendors that develop Wine related products could say if you want to discuss using a vendor provided Wine product in a non-supported manner all are advised to go here and share information Yes, of course, it would be nice if there were One True Place to go, but the closest we're ever going to get is essentially the status quo, where the wine-users mailing list is the place of record for user support, the appdb is the place of record for looking for tips for a particular app, and all the other areas are secondary. We can improve slightly on this by linking to other popular wine forums as they pop up, emphasizing all the while that they are secondary. I think that any existing place will eventually grow really popular if it will be called http://forum.winehq.org;. -- Ph.
Re: wine and msys rxvt.exe
On 26/02/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Wesley Parish [EMAIL PROTECTED] wrote: failed to load libX11.dll Looks like rxvt.exe is linked to an MSys provided X11 libraries that require a Windows X11 sever to be present and running. That's a sort of layer on layer and I don't think that there is someone who wants to make this configuration work. AFAIR MSys's rxvt.exe uses libW11.dll, which implements Xlib API on top of Win32 USER/GDI (no extra X server). However, it could be still difficult (probably because of API name clashes?) Not sure why the message is about libX11.dll - probably it sees $DISPLAY and tries to use real X? -- Ph.
Re: WineD3D: Fix my name
Hi Dmitry, On 11/01/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: At least one free resource compiler that claims to support UTF-8: http://www.jorgon.freeserve.co.uk/#rc Unfortunately it's not Microsoft's rc.exe, i.e. not something I'm interested to compare wrc output/compatibility with. Agreed. Also, there are not much editors in the Windows world that support UTF-8, since it's a multibyte encoding and in general is very cumbersome encoding to work with. Please don't do that. At least Notepad on Windows XP does support UTF-8. If that was supposed to be a joke I didn't buy it. No it was not a joke. I only tried to say that there is a UTF-8 enabled editor included in standard Windows distribution. If you don't like Notepad (yes, it's very limited) you can always find another editor (I use Vim in Windows as well as in Unices). In other words, your second reason to not switch to UTF-8 does not look like a good reason to me. But the first one does. -- Ph.
Re: WineD3D: Fix my name
Hi Dmitry, On 11/01/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: I'd say that since converting resources to UTF-8 makes them not compatible with any other resource compiler except wrc, IMO that's a bad idea At least one free resource compiler that claims to support UTF-8: http://www.jorgon.freeserve.co.uk/#rc Also, there are not much editors in the Windows world that support UTF-8, since it's a multibyte encoding and in general is very cumbersome encoding to work with. Please don't do that. At least Notepad on Windows XP does support UTF-8. -- Ph.
Re: CRichEditCtrl: Performance issue
Hello, On 16/11/06, Renu Rajput [EMAIL PROTECTED] wrote: I am facing a performance issue in CRichEditCtrl under Wine. My application reads data from a *.dat file and displays it in the CRichEdit editor. When I try to open large data files, it takes a lot of time(around 4-5 minutes) to open the file. I checked the code and found that, in Wine, the richedit editor streams-in the data in a block of 4096 bytes. On Linux, the read request to the file is routed via Wine. For every block of 4096 bytes that are read, the system makes a back and forth call between the callback function in the application and Wine code(ME_StreamInFill() in dlls\riched20\editor.c), which causes the delay. 4096 bytes is the same that MS uses. In fact, we have other problem, it's the speed of insertion of large text chunks (especially without any formatting) to the editor storage from the RTF/plaintext reader. It should be optimized. And also, MS RichEdit, starting from version 3, displays the first page of large loaded text very quick, and you can work with it and see how vertical scrollbar thumb gets smaller and smaller and smaller while the text is read into editor storage in the background. We should add that, too. The size of the buffer does not really matter here... If anyone stumbled upon the similar issue, what should be the solution to this. Optimize internal text storage (many small mallocs and reallocs ;( ). Optimize text insertion code. Do formatting/layout tasks in the background. -- Ph.
Re: CRichEditCtrl: Performance issue
Hello, On 16/11/06, Renu Rajput [EMAIL PROTECTED] wrote: I am facing a performance issue in CRichEditCtrl under Wine. My application reads data from a *.dat file and displays it in the CRichEdit editor. When I try to open large data files, it takes a lot of time(around 4-5 minutes) to open the file. I checked the code and found that, in Wine, the richedit editor streams-in the data in a block of 4096 bytes. On Linux, the read request to the file is routed via Wine. For every block of 4096 bytes that are read, the system makes a back and forth call between the callback function in the application and Wine code(ME_StreamInFill() in dlls\riched20\editor.c), which causes the delay. 4096 bytes is the same that MS uses. In fact, we have other problem, it's the speed of insertion of large text chunks (especially without any formatting) to the editor storage from the RTF/plaintext reader. It should be optimized. And also, MS RichEdit, starting from version 3, displays the first page of large loaded text very quick, and you can work with it and see how vertical scrollbar thumb gets smaller and smaller and smaller while the text is read into editor storage in the background. We should add that, too. The size of the buffer does not really matter here... If anyone stumbled upon the similar issue, what should be the solution to this. Optimize internal text storage (many small mallocs and reallocs ;( ). Optimize text insertion code. Do formatting/layout tasks in the background. -- Ph.
explorer: Build on Darwin versions prior to 8.0
Hello, In Darwin versions prior to 8.0, the DiskArbitration framework was a private framework, that is, the headers were not included in SDK and the API was changing in every version. This patch fixes the build in these OS versions. -- Ph. diskarb.patch Description: Binary data
Re: explorer: Build on Darwin versions prior to 8.0
Sorry guys, wrong list ;-) -- Ph.
Re: msi/iTunes and questions
Hi, On 20/09/06, Paul Vriens [EMAIL PROTECTED] wrote: The single-quotes should be needed as the SQL statement in the trace showed: trace:msi:MSI_DatabaseOpenViewW LSELECT `Message` FROM `Error` WHERE `Error` = The installlation of QuickTime did not complete successfully. iTunes requires QuickTime. 0x6669a498 and a bit further: err:msidb:WHERE_VerifyCondition Couldn't find column LThe This is just one of many issues with this installation. Does the fix look OK? Looks good but it will probably fail when %s contains an apostrophe. -- Ph.
Re: segfaults with last selection repaint patch in riched20
Hi Krzysztof, On 11/08/06, Krzysztof Foltman [EMAIL PROTECTED] wrote: What are the circumstances? Is it after some delete/insert operation, or just after document load? Well I have not traced the whole sequence of calls to richedit, but from the display I can suppose the following. I am doing a search operation on some files. When the app finds a match, it fills the richedit with some text including the match, and changes the match's color (supposedly selects the match and calls setcharformat). It works OK. After that I push Find next button. After finding another match the app updates richedit text with the new context of the match and (not changed the match's color yet) segfaults. I'd do an assert(pLastSelStartPara-member.para.nCharOfs = pLastSelEndPara-member.para.nCharOfs) or something. That could possibly shed some light on the issue. When it crashes and falls out to GDB, nCharOfs of the first para is 10, and nCharOfs of the last para is 3. This git thing is a piece of unreliable unintuitive crap. For sure CVS was simpler, but GIT also has some advantages... I haven't had any problems requiring to git-clone yet, but I still have to hold the GitWine wiki page open in my browser ;) -- Ph.
segfaults with last selection repaint patch in riched20
Hi Krzysztof,
I was getting a segfault in ME_MarkForPainting() after that patch (BTW
great work), and started looking through the code. One thing I found
was obviously a typo which can be easily fixed (BTW I don't know for
sure but I'd also update pLastSelStartPara and pLastSelEndPara here):
--- a/dlls/riched20/paint.c
+++ b/dlls/riched20/paint.c
@@ -529,7 +529,7 @@ ME_InvalidateSelection(ME_TextEditor *ed
/* last selection markers aren't always updated, which means
they can point past the end of the document */
if (editor-nLastSelStart len)
-editor-nLastSelEnd = len;
+editor-nLastSelStart = len;
if (editor-nLastSelEnd len)
editor-nLastSelEnd = len;
But it did not resolve my problem. I did not have time to find the
real reason for the segfault, but here is a quick hack which made the
segfault go away and can probably help you in finding the real reason.
Sorry, but I can't officially provide you with the failing application
(IBM Translation Manager 6.0.9) which is proprietary and only for IBM
internal usage.
--- a/dlls/riched20/para.c
+++ b/dlls/riched20/para.c
@@ -94,7 +94,7 @@ void ME_MarkForWrapping(ME_TextEditor *e
void ME_MarkForPainting(ME_TextEditor *editor, ME_DisplayItem *first,
ME_DisplayItem *last)
{
- while(first != last)
+ while(first first != last)
{
first-member.para.nFlags |= MEPF_REPAINT;
first = first-member.para.next_para;
The backtrace of the segfault was:
1 0x7d948cc0 ME_MarkForPainting+0x10(editor=0x11700f8,
first=0x11741d8, last=0x1173ac8)
[/home/phil/build/wine-git/dlls/riched20/para.c:99] in riched20
(0x7d948cc0)
2 0x7d948816 ME_InvalidateSelection+0x186(editor=0x11700f8)
[/home/phil/build/wine-git/dlls/riched20/paint.c:542] in riched20
(0x7d948816)
3 0x7d9442e9 RichEditANSIWndProc+0x22d9(hWnd=0x100b4, msg=0xb1,
wParam=0xe, lParam=0x117)
[/home/phil/build/wine-git/dlls/riched20/editor.c:1579] in riched20
(0x7d9442e9)
4 0x7d9466aa RichEdit10ANSIWndProc+0x3a(hWnd=0x100b4, msg=0xb1,
wParam=0xe, lParam=0x117)
[/home/phil/build/wine-git/dlls/riched20/editor.c:2598] in riched20
(0x7d9466aa)
...
-- Ph.
Re: riched20: new selection invalidation logic
Have you even tried your code on purposely broken rtf? How does it handle it? Broken rtf can only possibly break the RTF reader code, although it has not been happening for quite a long time. And the asserts are there to report Wine riched20 developer's errors, not the app developers'. -- Ph.
Re: riched20: modify ME_CharFromPoint to work properly with password controls
Hi Matt, On 07/08/06, Matt Finnicum [EMAIL PROTECTED] wrote: This patch modifies ME_CharFromPoint to work properly with password controls (the patch i sent in / got committed a couple days ago). Should not the temp string be freed afterwards? -- Ph.
Re: [Bug 5769] Regression of wine 0.9.6 in riched20 causes program to fail
I was using fresh GIT from 2006-07-26.
Re: RESEND: enhmetafile: Read and write support for little-endian EMFs on big-endian machines
Hi, Doctor, why everybody ignores me? - Next, please. -- Ph. On 03/07/06, Phil Krylov [EMAIL PROTECTED] wrote: Hi, Is anything wrong with that patch? On 25/06/06, Phil Krylov [EMAIL PROTECTED] wrote: Hi, This version has no ugly macros and adds read support. Diffed against current CVS. ChangeLog: enhmetafile: Read and write support for little-endian EMFs on big-endian machines. -- Ph.
Re: forgotten patch
On 22/06/06, Krzysztof Foltman [EMAIL PROTECTED] wrote: This patch apparently has been lost, and there's at least one bug inBugzilla that the patch seems to fix (bug# 4452, checked here). http://www.winehq.org/pipermail/wine-patches/2006-January/023875.htmlI don't see anything wrong with the patch, did Phil just send it in awrong moment, or is there anything to fix?AlexandresaidthatitshouldcheckforotherinvalidhWnd values as well. I had no time to improve it since that day ;(( -- Ph.
Re: enhmetafile: Create little-endian EMF files on big-endian machines (fixed)
Hi, On Tue, 11 Apr 2006 20:03:22 +0400 Phil Krylov [EMAIL PROTECTED] wrote: This patch fixes the generation of EMF files (which are little-endian by nature) on big-endian machines. It is by no means complete - some record types are still unsupported, and reading of little-endian EMFs on big-endian machines still does not work - but it works for my app and can be used as a base for future improvements. Anything wrong with this patch? Should I try to improve it in the direction of supporting more metafile record types and supporting reading little-endian EMFs from disk? Or change everything at all? The subject was recently discussed in this thread: http://www.winehq.org/pipermail/wine-devel/2006-April/046606.html -- Ph.
Re: enhmetafile: Create little-endian EMF files on big-endian machines (fixed)
On Wed, 19 Apr 2006 12:52:35 +0200 Alexandre Julliard [EMAIL PROTECTED] wrote: Phil Krylov [EMAIL PROTECTED] writes: Anything wrong with this patch? Should I try to improve it in the direction of supporting more metafile record types and supporting reading little-endian EMFs from disk? Or change everything at all? I think the direction is OK, but the macros are fairly ugly, and non-portable. I'd suggest doing the conversion with inline functions instead. Posted an updated version to wine-patches. -- Ph.
Re: x11drv: question about byte-swapping for DIBs
On Wed, 19 Apr 2006 16:50:47 -0400 Eric Frias [EMAIL PROTECTED] wrote: I'm trying to debug a problem in which 24-bit .bmps don't display correctly from a winelib application on a big-endian sparc host when displaying on a little-endian intel PC. In this case, the image is garbled, with most of the colors being wrong and a pattern of vertical stripes over the image. The code passes through convert_888_to_0888_reverse_dst_byteswap which is what mangles the image data. Just my 2 cents: the same bug appears in a winelib app on a big-endian PowerPC host when displaying on the same big-endian PowerPC host, so it's probably independent of display host. -- Ph.
Re: x11drv: question about byte-swapping for DIBs
On Thu, 20 Apr 2006 00:10:42 +0200 Willie Sippel [EMAIL PROTECTED] wrote: Am Mittwoch, 19. April 2006 22:50 schrieb Eric Frias: I'm trying to debug a problem in which 24-bit .bmps don't display correctly from a winelib application on a big-endian sparc host when displaying on a little-endian intel PC. In this case, the image is garbled, with most of the colors being wrong and a pattern of vertical stripes over the image. The code passes through convert_888_to_0888_reverse_dst_byteswap which is what mangles the image data. Messed colors and vertical stripes? Similar to http://www.froq.net/mirage/mirage1.png ? No, I get rather like this: http://newstar.rinet.ru/~phil/Screenshot-StarLing-for-Macintosh.png (the yellow-greenish square buttons should be light grey and clear) -- Ph.
Re: [gdi] bug reading/writing metafiles on sparc
On Thu, 13 Apr 2006 11:58:02 -0400 Eric Frias [EMAIL PROTECTED] wrote: Due to little-endian/big-endian differences, winelib on Sparc can't read windows metafiles generated on a PC (or on Wine on x86), and conversely PCs can't read metafiles created on a Sparc. It looks like there are a few ways this could be fixed, and I wanted to make sure we don't go about it the wrong way (and that nobody else is working on it). I think the right thing to do is make the on-disk and in-memory formats always be little-endian. We would only convert the data to big-endian format when it is generated or used. GetMetaFileBitsEx and SetMetaFileBitsEx would return take the raw data in little-endian format. I have submitted a patch that fixes creation of on-disk _enhanced_ metafiles a few days ago: http://article.gmane.org/gmane.comp.emulators.wine.patches/23393 It byteswaps EMF records just for writing to disk. Adding byteswapping for reading from disk seems very easy - just feed the file content to the same byteswapper functions. I think it is a bit more clean than your approach. -- Ph.
Re: [gdi] bug reading/writing metafiles on sparc
On Thu, 13 Apr 2006 22:39:57 +0400 Phil Krylov [EMAIL PROTECTED] wrote: It byteswaps EMF records just for writing to disk. Adding byteswapping for reading from disk seems very easy - just feed the file content to the same byteswapper functions. I think it is a bit more clean should be: to the same byteswapper function. than your approach. -- Ph.
Re: [gdi] bug reading/writing metafiles on sparc
On Thu, 13 Apr 2006 16:39:02 -0400 Eric Frias [EMAIL PROTECTED] wrote: Phil Krylov wrote: I have submitted a patch that fixes creation of on-disk _enhanced_ metafiles a few days ago: http://article.gmane.org/gmane.comp.emulators.wine.patches/23393 Thanks for the pointer, I hadn't seen that patch. It byteswaps EMF records just for writing to disk. Adding byteswapping for reading from disk seems very easy - just feed the file content to the same byteswapper functions. I think it is a bit more clean than your approach. I like how yours works -- one function call converts both directions. My only hesitation was that all of the operations -- read, copy, get bits set bits -- change from simple writes of a block of memory to looping through the records one-by-one to convert them. That's not a bad price to pay for cleaner code... We have to do this conversion one place or another, and I supposed that reading/writing metafile from disk is used less frequently than other metafile operations (mostly record addition and playback). Here's a question that I guess is worth asking: what kind of data do you expect to get when you call GetMetaFileBitsEx()? Do you get bits in the in-memory format, where METARECORD structures have values in the native format? Or do you get data in the on-disk format? My first reaction was that you'd want the on-disk (platform-independent) format, because you would probably be writing the data to a file or to the clipboard, and you'd want that to be as platform-independent as the .wmf files are. But I was looking over the API and there are also functions like EnumMetaFile() and PlayMetaFileRecord() that give or take one METARECORD, and that suggests that there are programs out there that try to make sense of the data in the individual records and that you'd expect to see native byte order used. Like you, my immediate problem is just getting wine to write out metafiles that the rest of the world can read. But as soon as I change the file writing, I feel like I should change the reading function to be consistent, and then it starts to get a bit confusing. Yes it really does... However, I don't think there are a lot of programs using these APIs... I mean, let's implement it one or another way and wait till some such programs break (when ported to big-endian machines;) and see how exactly they will break and fix it then. Also, when we're dealing with WineLib, we can just document the endianness-behaviour of these functions and developers can do byteswapping in their apps where needed or use other APIs (e.g. CopyEnhMetaFile instead of GetEnhMetaFileBits followed by a disk write). -- Ph.
Re: README: Updated to not point users at wineinstall and to mention fontforge
On Mon, 10 Apr 2006 08:18:51 +0200 Kai Blin [EMAIL PROTECTED] wrote: Also added fontforge to the build requirements list, with a note to Gentoo users to update their version of fontforge, as the version currently used in Gentoo doesn't work. Too late: today's Gentoo Portage has fontforge-20060406 (although as a ~x86 unstable package). -- Ph.
Re: README: Updated to not point users at wineinstall and to mention fontforge
On Mon, 10 Apr 2006 10:05:33 +0200 Kai Blin [EMAIL PROTECTED] wrote: * Phil Krylov [EMAIL PROTECTED] [10/04/06, 11:52:01]: On Mon, 10 Apr 2006 08:18:51 +0200 Kai Blin [EMAIL PROTECTED] wrote: Also added fontforge to the build requirements list, with a note to Gentoo users to update their version of fontforge, as the version currently used in Gentoo doesn't work. Too late: today's Gentoo Portage has fontforge-20060406 (although as a ~x86 unstable package). That's what my patch mentions. + In order to create your fonts, you will need a recent version of fontforge. + fontforge 20050803 works. NOTE TO GENTOO USERS: fontforge 20050624 does not + work. Use fontforge 20060406 from the ~ARCH repository. OK sorry, didn't read the patch... -- Ph.
Re: README: Updated to not point users at wineinstall and to mention fontforge
On Mon, 10 Apr 2006 04:43:59 -0400 Segin [EMAIL PROTECTED] wrote: Add these lines for those people that ask us how to use ~ARCH fontforge instead of RTFMing: To enable ~ARCH fontforge without setting your whole system ~ARCH, do this (as root): echo =media-gfx/fontforge-20060406 /etc/portage/package.keywords Is this really preferable to the following? echo media-gfx/fontforge ~x86 /etc/portage/package.keywords -- Ph.
Re: richedit20: Implement EM_FORMATRANGE
On Tue, 4 Apr 2006 11:46:18 +1000 Troy Rollo [EMAIL PROTECTED] wrote: + * *** Notes on tables *** + * + * The CHARRANGE structure passed in the FORMATRANGE structure is not + * sufficient to deal with tables, where we would need information on the + * start position for text in each column of the table. + * + * Testing on Windows NT shows that the Microsoft Rich Edit control gives + * pathological results when there are tables in the document - both in edit + * mode and for EM_FORMATRANGE. The Microsoft Rich Edit control uses the + * table solely as a hint to where the paragraph should start. The table + * does not expand to fit its text. Long paragraphs wrap when you hit the + * right page margin and continue at the left page margin. This is only true for RichEdit 2.0 - later versions have better table support, while our current implementation is approximately at 2.0 level. -- Ph.
Re: Debugging X errors?
On Tue, 28 Mar 2006 15:25:26 -0500 Segin [EMAIL PROTECTED] wrote: (Try this: select some text in Wine, and middle click in a Xterm, nothing happens! Go back to the Windows app, tell it to copy the text, and try to paste it into the xterm, nothing again! I think it's a bug IMHO) You need to set the Wine registry entry X11 Driver/UsePrimarySelection to 'Y'. I submitted a patch for Winecfg to do it, but it wasn't accepted and it was a long time ago... -- Ph.
Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462
On Thu, 16 Mar 2006 22:31:40 -0800 (PST) Brian Chang [EMAIL PROTECTED] wrote: +/* get the current selection and text length */ +RichEditANSIWndProc(hWnd, EM_GETSEL, (WPARAM) start, (LPARAM) end); +textlen = RichEditANSIWndProc(hWnd, WM_GETTEXTLENGTH, 0, 0); This looks strange... Why not use ME_GetSelection() and ME_GetTextLength()? -- Ph.
Re: riched20: Implements FR_WHOLEWORD for EM_FINDTEXT
On Sun, 05 Mar 2006 14:20:47 -0800 Lei Zhang [EMAIL PROTECTED] wrote: +if ((flags FR_WHOLEWORD) iswalnum(wLastChar)) Probably a test checking if native richedit does not use user's word breaking procedure (set via EM_SETWORDBREAKPROC) for FR_WHOLEWORD searches would be cool. -- Ph.
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Tue, 21 Feb 2006 14:08:38 -0800 Lei Zhang [EMAIL PROTECTED] wrote: On Tuesday 21 February 2006 12:42 pm, you wrote: On Tue, 21 Feb 2006 10:19:01 -0800 Lei Zhang [EMAIL PROTECTED] wrote: - while (pCurItem pCurItem-member.run.strText-szData[nCurEnd - nMatched - 1] == text[nLen - nMatched - 1]) + while (ME_CharCompare(pCurItem-member.run.strText-szData[nCurEnd - nMatched - 1], text[nLen - nMatched - 1], (flags FR_MATCHCASE))) You've dropped pCurItem NULL check here. Probably just a typo... -- Ph. Hi Phil, Ya, it's a typo. Thanks for catching it. Could you kindly fix it then? As this patch was accepted unfixed. -- Ph.
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Fri, 24 Feb 2006 12:24:45 +0100 Alexandre Julliard [EMAIL PROTECTED] wrote: Phil Krylov [EMAIL PROTECTED] writes: On Tue, 21 Feb 2006 14:08:38 -0800 Lei Zhang [EMAIL PROTECTED] wrote: Hi Phil, Ya, it's a typo. Thanks for catching it. Could you kindly fix it then? As this patch was accepted unfixed. I accepted the patch because I don't see how pCurItem could be NULL in that loop (or rather, it could be NULL, but in that case we'll crash before coming back to the loop test). Am I missing something? Yes, you're right. It can't be NULL because of an earlier test: para-member.para.nCharOfs + item-member.run.nCharOfs + nEnd - nLen = nMin But this is very inevident. -- Ph.
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Fri, 24 Feb 2006 10:48:47 -0800 Lei Zhang [EMAIL PROTECTED] wrote: On Friday 24 February 2006 04:39 am, Phil Krylov wrote: On Fri, 24 Feb 2006 12:24:45 +0100 Alexandre Julliard [EMAIL PROTECTED] wrote: Phil Krylov [EMAIL PROTECTED] writes: On Tue, 21 Feb 2006 14:08:38 -0800 Lei Zhang [EMAIL PROTECTED] wrote: Hi Phil, Ya, it's a typo. Thanks for catching it. Could you kindly fix it then? As this patch was accepted unfixed. I accepted the patch because I don't see how pCurItem could be NULL in that loop (or rather, it could be NULL, but in that case we'll crash before coming back to the loop test). Am I missing something? Yes, you're right. It can't be NULL because of an earlier test: para-member.para.nCharOfs + item-member.run.nCharOfs + nEnd - nLen = nMin But this is very inevident. -- Ph. Hi Phil, Alex Yes, it can become NULL, here's how: Inside while (ME_CharCompare(pCurItem- ) the last if() block assigns a new value to pCurItem, which may be NULL. It may but it won't... ME_FindItemBack(pCurItem) will return NULL only if pCurItem is the first text run in the document. But the if() condition (nCurEnd - nMatched == 0) is TRUE only if the search string is longer than nCurEnd. This does not happen for the first document run because of the condition of the exterior loop which checks if we have enough characters for comparison. --Ph.
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Tue, 21 Feb 2006 10:19:01 -0800 Lei Zhang [EMAIL PROTECTED] wrote: - while (pCurItem pCurItem-member.run.strText-szData[nCurEnd - nMatched - 1] == text[nLen - nMatched - 1]) + while (ME_CharCompare(pCurItem-member.run.strText-szData[nCurEnd - nMatched - 1], text[nLen - nMatched - 1], (flags FR_MATCHCASE))) You've dropped pCurItem NULL check here. Probably just a typo... -- Ph.
Re: msftedit.dll
On Sat, 4 Feb 2006 00:07:24 +0100 Stefan Leichter [EMAIL PROTECTED] wrote: +2 stub IID_IRichEditOle +3 stub IID_IRichEditOleCallback +4 stub CreateTextServices +5 stub IID_ITextServices +6 stub IID_ITextHost +7 stub IID_ITextHost2 +8 stub REExtendedRegisterClass +9 stub RichEditANSIWndProc +10 stub RichEdit10ANSIWndProc +11 stub SetCustomTextOutHandlerEx +12 stub DllGetVersion +13 stub RichEditWndProc +14 stub RichListBoxWndProc +15 stub RichComboBoxWndProc Could this be done another way? E.g., symlink msftedit.dll.so to riched20.dll.so? Or copy riched20.dll.so as msftedit.dll.so, which would resemble MS approach more. -- Ph.
Re: Text Object Model and Richedit?
On Mon, 30 Jan 2006 08:31:59 -0800 Dan Kegel [EMAIL PROTECTED] wrote: I stumbled across the doc for the Text Object Model, which looks like the COM interface to Richedit and anything like it: http://windowssdk.msdn.microsoft.com/library/en-us/shellcc/platform/commctls/richedit/textobjectmodel.asp Is anyone poking around at adding this interface to our Richedit? Not me, at least in the nearest future... It has rather poor documentation on MSDN, and most apps don't use it (probably due to the same poor documentation). -- Ph.
Re: [patch] updated riched20 conformance test
On Tue, 24 Jan 2006 12:23:09 -0800 Thomas Kho [EMAIL PROTECTED] wrote: Attached is a small patch to add a riched20 conformance test. I think it's a good test, but I'd add flags %08x,...flags to the failing test messages, because all these failures are due to unimplemented flags. And probably the message names should be printed as well... -- Ph.
Re: Mac OS X/Intel port
On Sun, 22 Jan 2006 01:12:09 -0600 Chris Campbell [EMAIL PROTECTED] wrote: I just recently downloaded the CVS of WINE and tried to build it on an Apple Intel machine. I ran into some problems during the build and fixed them. I then got to the server and the build quit on context_i386.c. There is nothing in that file that handles darwin/ Mac OS X. It looks like the ptrace functionality (GETREGS, etc) that is used on Linux and FreeBSD is not present in the xnu kernel... I would like to get WINE working on x86 OS X. Can anyone tell me who is working on this? I would like to help with this effort. Please also have a look at http://darwine.opendarwin.org and subscribe to the darwine-devel mailing list there. -- Ph.
Re: translation of wine/programs/wcmd/Ru.rc
On Mon, 16 Jan 2006 18:00:04 +0300 Roman [EMAIL PROTECTED] wrote: I've translaten most of the messages There are some typos: +из другого bat-файла. При по завершении вывываемого командного файла, управление возвращается\n\ should be: +из другого bat-файла. По завершении вызываемого командного файла управление возвращается\n\ And this: +ECHO ON все последующие команды будут выведены на экран\n\ Should be: +ECHO ON включает вывод всех последующих команд на экран\n\ And this: +ECHO OFF отменяет режим ECHO ON (по-умолчанию ECHO is OFF).\n\ Should be: +ECHO OFF отменяет режим ECHO ON (по умолчанию используется режим ECHO OFF).\n\ And this is not translated at all: +The ECHO OFF command can be prevented from displaying by\n\ preceding it with an @ sign.\n And this: +Команда FOR дисползуется для выполнения команд для нескольких файлов.\n\ Should be: +Команда FOR используется для выполнения команд для нескольких файлов.\n\ And this: +Синтаксис: FOR %переменная IN (set) DO команда\n\ Should be: +Синтаксис: FOR %переменная IN (набор) DO команда\n\ And this is partially untranslated: +но не может содержать пробелов (this is different from other operating\n\ +systems). And lots more. Please check your patch for typos and resend. -- Ph.
Re: RESEND: winecfg: Added Use PRIMARY selection option
On Tue, 10 Jan 2006 20:23:20 +0100 Alexandre Julliard [EMAIL PROTECTED] wrote: Phil Krylov [EMAIL PROTECTED] writes: ChangeLog: Added support for Use PRIMARY selection clipboard option. I don't think we want a new property sheet page for that, it should go with the other X11 options. Initially I did it that way, but: 1) The X11 option page is named Graphics, and clipboard is not graphics ;) 2) There's no free space on the Graphics page. Should I make it (and the whole winecfg window) larger? -- Ph.
Re: user: Fix dropdown combo creation when there is no space for an edit control
Hi, Sorry, I meant: ChangeLog: Fixed dropdown combo creation when there is NO space for an edit control. -- Ph.
Re: winecfg: Added Use PRIMARY selection option
Hi, On Fri, 30 Dec 2005 12:43:56 +0100 Stefan Dösinger [EMAIL PROTECTED] wrote: Added support for Use PRIMARY selection clipboard option. One question: Why not make this the default? This would be the unix way to use the clipboard. It would be OK for me, but probably there was some reason why it has not been made the default. Does someone know it? Or use the primary selection on a middle mouse button click, and the other clipboard value on paste / CTRL-V? This is the behavior I'm used to from native apps. Is this possible? But Windows apps may be using the middle button for other actions, and besides that we'd need to add a Wine-specific window message which would be posted on a middle-click instead of WM_PASTE, and some other infrastructure. I don't think it would go well with the design concepts of Wine. -- Ph.
Re: build errors
On Mon, 26 Sep 2005 22:53:18 -0300 Marcelo Duarte [EMAIL PROTECTED] wrote: To fix the problem for me, instead of clean, I__d do the folowing command in wine tree: rm */*/*.spec.* Thanks, it works. But isn't make clean supposed to do this job? -- Ph.
CopyEnhMetaFile() on big endian arch
Hi, My problem is: CopyEnhMetaFile() creates a .wmf file from a HENHMETAFILE by simple dumping of data to the file. On big-endian platforms (in my case - PowerPC) the resulting file is not a valid WMF. To make it valid, we need to convert all binary data to little-endian. I'd like to make it work. Can someone suggest where the byte order should be reversed? Should it be done in the HENHMETAFILE stored in memory, or should rather CopyEnhMetaFile parse the whole metafile and byte-reverse all data that should be dumped to disk? In any case, it seems to be a huge task. If someone is also interested, probably we should cooperate with each other? -- Ph.
build errors
Hi, I can't build current CVS version of Wine: ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./kernel32.spec comm.drv.spec.o krnl386.exe.spec.o stress.spec.o system.drv.spec.o toolhelp.spec.o win87em.spec.o windebug.spec.o atom16.o error16.o kernel16.o registry16.o toolhelp16.o win87em.o actctx.o atom.o change.o comm.o computername.o console.o cpu.o debugger.o dosmem.o editline.o environ.o except.o fiber.o file.o file16.o format_msg.o global16.o heap.o instr.o kernel_main.o lcformat.o local16.o locale.o lzexpand.o module.o ne_module.o ne_segment.o oldconfig.o path.o powermgnt.o process.o profile.o pthread.o relay16.o resource.o resource16.o selector.o snoop16.o stress.o string.o sync.o syslevel.o system.o tape.o task.o thread.o thunk.o time.o toolhelp.o utthunk.o version.o virtual.o volume.o vxd.o windebug.o wowthunk.o relay16asm.o kernel32.dll.dbg.o kernel.res -Wl,--image-base,0x7b80 -o kernel32.dll.so -L../../dlls -L../../dlls/ntdll -lntdll -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port comm.drv.spec.o(.data.rel.ro+0x1f6): In function `__wine_stub_GETDCB': /home/phil/build/wine/dlls/kernel/comm.drv.spec.c:38: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x1d0): In function `__wine_spec_stress_dll_fini': /home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x1e8):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x200):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x218):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x230):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: more undefined references to `__wine_call_from_16_long' follow system.drv.spec.o(.data.rel.ro+0x1d0): In function `__wine_spec_system_drv_fini': /home/phil/build/wine/dlls/kernel/system.drv.spec.c:303: undefined reference to `__wine_call_from_16_word' system.drv.spec.o(.data.rel.ro+0x1e8):/home/phil/build/wine/dlls/kernel/system.drv.spec.c:303: undefined reference to `__wine_call_from_16_word' system.drv.spec.o(.data.rel.ro+0x200):/home/phil/build/wine/dlls/kernel/system.drv.spec.c:303: undefined reference to `__wine_call_from_16_word' Am I the only one? Can you suggest something? -- Ph.
Re: listview: infoPtr might be invalid after WM_NOTIFY
On Tue, 20 Sep 2005 16:20:50 -0500 Robert Shearman [EMAIL PROTECTED] wrote: Since this was a behaviour in our file open dialog, did we even verify that this was a listview bug or is it that destroying the listview in the middle of a notification is something that you shouldn't do? The native file dialog acts the same way. -- Ph.
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
On Fri, 9 Sep 2005 15:09:24 -0400
Dimi Paun [EMAIL PROTECTED] wrote:
From: Phil Krylov [EMAIL PROTECTED]
OK, should we then make a patch which adds an IsWindow() check after every
notification in every control? This one fixes a really annoying bug, while
the other places are not proved to crash.
Well, if it's a entire class of bugs, we should fix them all.
I think that we should check if it's a class of bugs or a single bug first.
I guess we need a bit of experimentation on windows to see
if we need to protect all notifications or only a few ones.
I guess we can protect all of them, in which case we have
to look to see how we can do it centrally, in the notification
function itself.
I don't see a way to do it clean enough.
So, here's a new version of the patch (enhanced comment, WARN changed to a
TRACE).
ChangeLog:
Protect against wrong memory access if a listview is destroyed during
processing of its NM_DBLCLK notification (a.k.a. file dialog GPF).
-- Ph.Index: dlls/comctl32/listview.c
===
RCS file: /home/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.429
diff -p -u -r1.429 listview.c
--- dlls/comctl32/listview.c 30 Aug 2005 10:07:17 - 1.429
+++ dlls/comctl32/listview.c 12 Sep 2005 22:10:51 -
@@ -8083,6 +8083,7 @@ static LRESULT LISTVIEW_KillFocus(LISTVI
static LRESULT LISTVIEW_LButtonDblClk(LISTVIEW_INFO *infoPtr, WORD wKey, INT x, INT y)
{
LVHITTESTINFO htInfo;
+HWND hwnd = infoPtr-hwndSelf;
TRACE((key=%hu, X=%hu, Y=%hu)\n, wKey, x, y);
@@ -8095,7 +8096,17 @@ static LRESULT LISTVIEW_LButtonDblClk(LI
/* send NM_DBLCLK notification */
LISTVIEW_HitTest(infoPtr, htInfo, TRUE, FALSE);
notify_click(infoPtr, NM_DBLCLK, htInfo);
-
+
+/* If during NM_DBLCLK processing the listview was destroyed (e.g. in a
+ * shell browser control, native as well), don't try to continue execution,
+ * it's unsafe.
+ * TODO: Check if it is a whole class of bugs. */
+if (!IsWindow(hwnd))
+{
+TRACE(destroyed during NM_DBLCLK processing\n);
+return 0;
+}
+
/* To send the LVN_ITEMACTIVATE, it must be on an Item */
if(htInfo.iItem != -1) notify_itemactivate(infoPtr,htInfo);
Re: LTSpice/SwitcherCad III Regression with Rich text patch ID=19048
On Sat, 10 Sep 2005 13:49:23 -0400 paul [EMAIL PROTECTED] wrote: I did regression testing and found patch Id=19048 triggers this error wine-pthread: run.c:142: ME_RunOfsFromCharOfs: Assertion `nCharOfs = nParaOfs' failed. filed http://bugs.winehq.org/show_bug.cgi?id=3239 The application is a free download and the bug has steps to generate the failure. It is still a problem with cvs from 20050909. Thanks, I'll look... -- Ph.
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
On Fri, 9 Sep 2005 13:59:05 -0400 Dimi Paun [EMAIL PROTECTED] wrote: From: Phil Krylov [EMAIL PROTECTED] Here is a patch which adds checking if the window has been destroyed at that point. I don't know if it is acceptable but it fixes the problem. But this could potentially happen on any notification, what makes this particular one special (sorry, I was away on vacation and I missed this thread). OK, should we then make a patch which adds an IsWindow() check after every notification in every control? This one fixes a really annoying bug, while the other places are not proved to crash. -- Ph.
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
On Fri, 26 Aug 2005 23:03:33 +0200
Michael Jung [EMAIL PROTECTED] wrote:
Every time you double click a folder, the current ShellView object is
destroyed and a new one is created. Given that I have to browse into like 30
different folders before it crashes on me, I can't pin down the relevant
infoPtr.
In hunt for this bug, I discovered the following:
* It appears both with unixfs and normal Wine fs.
* Every double click on a folder in the listview destroys this listview
object (effectively destroying all underlying structures), creates a new
one, and returns control to the place where double click notification was
sent by the old listview (notify_hdr() function in listview.c). This time
the old listview and its structures are already destroyed, but we
continue to access them, exception!
Here is a patch which adds checking if the window has been destroyed at
that point. I don't know if it is acceptable but it fixes the problem.
ChangeLog:
Protect against wrong memory access if a listview is destroyed in a handler
for its NM_DBLCLK notification.
-- Ph.Index: dlls/comctl32/listview.c
===
RCS file: /home/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.429
diff -p -u -r1.429 listview.c
--- dlls/comctl32/listview.c 30 Aug 2005 10:07:17 - 1.429
+++ dlls/comctl32/listview.c 8 Sep 2005 16:58:43 -
@@ -8083,6 +8083,7 @@ static LRESULT LISTVIEW_KillFocus(LISTVI
static LRESULT LISTVIEW_LButtonDblClk(LISTVIEW_INFO *infoPtr, WORD wKey, INT x, INT y)
{
LVHITTESTINFO htInfo;
+HWND hwnd = infoPtr-hwndSelf;
TRACE((key=%hu, X=%hu, Y=%hu)\n, wKey, x, y);
@@ -8095,7 +8096,15 @@ static LRESULT LISTVIEW_LButtonDblClk(LI
/* send NM_DBLCLK notification */
LISTVIEW_HitTest(infoPtr, htInfo, TRUE, FALSE);
notify_click(infoPtr, NM_DBLCLK, htInfo);
-
+
+/* If during NM_DBLCLK processing the control was destroyed, don't try
+ * to continue execution, it's unsafe */
+if (!IsWindow(hwnd))
+{
+WARN(the control has been destroyed in NM_DBLCLK processing\n);
+return 0;
+}
+
/* To send the LVN_ITEMACTIVATE, it must be on an Item */
if(htInfo.iItem != -1) notify_itemactivate(infoPtr,htInfo);
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
Hi Michael, On Thu, 8 Sep 2005 23:10:18 +0200 Michael Jung [EMAIL PROTECTED] wrote: Wouldn't it be enough to call notify_click after notify_itemactivate? I've attached a modification of your patch, which does just this. Seems to work fine for me. Probably, but what if some apps depend on order in which these notifications are sent? (assuming we already send them in the right order) -- Ph.
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
On Fri, 26 Aug 2005 22:10:16 +0200 Michael Jung [EMAIL PROTECTED] wrote: 2) Did other people see this bug already? Yes, I confirm it. -- Ph.
Re: RICHED20: Avoid flicker
On Sun, 14 Aug 2005 17:53:33 +0400 Phil Krylov [EMAIL PROTECTED] wrote: this patch needs to be applied after the Re: RICHED20: Implement EM_SETRECT, EM_SETRECTNP and WM_SETREDRAW messages (fixed) patch. ChangeLog: Avoid flicker in RichEdit using proper update region invalidation and an offscreen bitmap. Anything wrong with this patch? -- Ph.
Re: RichEdit flicker
On Sat, 13 Aug 2005 18:51:06 +0400 Phil Krylov [EMAIL PROTECTED] wrote: The paragraph structure should include not MEPF_REWRAP and MEPF_REPAINT flags, but indexes of rows from which to start re-wrapping and repainting (e.g. nStartRewrap and nStartRepaint). The wrapping routine should check if it has actually changed wrapping and set nStartRepaint accordingly. ME_Repaint should not call ME_PaintContent directly. Instead, the wrapping routine (and probably others) should call InvalidateRect for screen areas that need to be repainted. On other hand, the current code is pretty stable although flickering. Probably flickering could be more easily by drawing to an offscreen bitmap which would be just exposed by WM_PAINT. I've just sent a patch that implements both approaches to wine-patches. -- Ph.
RichEdit flicker
Hi Krzysztof, I want to change wrapping and painting code to minimize flickering and maximize performance. From what I see, the following could be done: The paragraph structure should include not MEPF_REWRAP and MEPF_REPAINT flags, but indexes of rows from which to start re-wrapping and repainting (e.g. nStartRewrap and nStartRepaint). The wrapping routine should check if it has actually changed wrapping and set nStartRepaint accordingly. ME_Repaint should not call ME_PaintContent directly. Instead, the wrapping routine (and probably others) should call InvalidateRect for screen areas that need to be repainted. What do you as the author of that code think about my suggestions? Or it's possible that you are working in the same direction, and then it would be silly to implement one thing twice? -- Ph.
Re: RichEdit flicker
On Sat, 13 Aug 2005 12:47:19 +0400 Phil Krylov [EMAIL PROTECTED] wrote: The paragraph structure should include not MEPF_REWRAP and MEPF_REPAINT flags, but indexes of rows from which to start re-wrapping and repainting (e.g. nStartRewrap and nStartRepaint). The wrapping routine should check if it has actually changed wrapping and set nStartRepaint accordingly. ME_Repaint should not call ME_PaintContent directly. Instead, the wrapping routine (and probably others) should call InvalidateRect for screen areas that need to be repainted. On other hand, the current code is pretty stable although flickering. Probably flickering could be more easily by drawing to an offscreen bitmap which would be just exposed by WM_PAINT. -- Ph.
Re: Automatic ANSIUnicode message translation
On Tue, 26 Jul 2005 10:15:58 +1000
Troy Rollo [EMAIL PROTECTED] wrote:
If you call SendMessageW under native Windows the translation happens. If you
call SendMessageA it does not. This is all exactly what I would expect.
By my test, sending 0xf301 with SendMessageA gets 0xf301 on Windows, and with
SendMessageW gets 0x003f. Sending with SendMessageA on Wine gets 0x0001 and
with SendMessageW gets 0x003f.
Thanks for the clarification. Here is a patch that takes it into account.
But I don't know if and when the translation should be done in
PostThreadMessageA.
ChangeLog:
Translate Unicode-ANSI message wParams only when window type
(ANSI/Unicode) does not match message handling function postfix
(PeekMessageA/W etc.).
-- Ph.Index: dlls/user/message.c
===
RCS file: /home/wine/wine/dlls/user/message.c,v
retrieving revision 1.86
diff -p -u -r1.86 message.c
--- dlls/user/message.c 19 Jul 2005 19:14:32 - 1.86
+++ dlls/user/message.c 26 Jul 2005 06:43:23 -
@@ -2444,7 +2444,9 @@ LRESULT WINAPI SendMessageA( HWND hwnd,
*/
BOOL WINAPI SendNotifyMessageA( HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam )
{
-return SendNotifyMessageW( hwnd, msg, map_wparam_AtoW( msg, wparam ), lparam );
+if (IsWindowUnicode(hwnd))
+wparam = map_wparam_AtoW( msg, wparam );
+return SendNotifyMessageW( hwnd, msg, wparam, lparam );
}
@@ -2495,7 +2497,9 @@ BOOL WINAPI SendNotifyMessageW( HWND hwn
BOOL WINAPI SendMessageCallbackA( HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam,
SENDASYNCPROC callback, ULONG_PTR data )
{
-return SendMessageCallbackW( hwnd, msg, map_wparam_AtoW( msg, wparam ),
+if (IsWindowUnicode(hwnd))
+wparam = map_wparam_AtoW( msg, wparam );
+return SendMessageCallbackW( hwnd, msg, wparam,
lparam, callback, data );
}
@@ -2585,7 +2589,9 @@ DWORD WINAPI InSendMessageEx( LPVOID res
*/
BOOL WINAPI PostMessageA( HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam )
{
-return PostMessageW( hwnd, msg, map_wparam_AtoW( msg, wparam ), lparam );
+if (IsWindowUnicode(hwnd))
+wparam = map_wparam_AtoW( msg, wparam );
+return PostMessageW( hwnd, msg, wparam, lparam );
}
@@ -2734,7 +2740,7 @@ BOOL WINAPI PeekMessageW( MSG *msg_out,
BOOL WINAPI PeekMessageA( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags )
{
BOOL ret = PeekMessageW( msg, hwnd, first, last, flags );
-if (ret) msg-wParam = map_wparam_WtoA( msg-message, msg-wParam );
+if (ret IsWindowUnicode(hwnd)) msg-wParam = map_wparam_WtoA( msg-message, msg-wParam );
return ret;
}
@@ -2798,7 +2804,8 @@ BOOL WINAPI GetMessageW( MSG *msg, HWND
BOOL WINAPI GetMessageA( MSG *msg, HWND hwnd, UINT first, UINT last )
{
GetMessageW( msg, hwnd, first, last );
-msg-wParam = map_wparam_WtoA( msg-message, msg-wParam );
+if (IsWindowUnicode(hwnd))
+msg-wParam = map_wparam_WtoA( msg-message, msg-wParam );
return (msg-message != WM_QUIT);
}
@@ -2810,7 +2817,8 @@ BOOL WINAPI GetMessageA( MSG *msg, HWND
BOOL WINAPI IsDialogMessageA( HWND hwndDlg, LPMSG pmsg )
{
MSG msg = *pmsg;
-msg.wParam = map_wparam_AtoW( msg.message, msg.wParam );
+if (IsWindowUnicode(hwndDlg))
+msg.wParam = map_wparam_AtoW( msg.message, msg.wParam );
return IsDialogMessageW( hwndDlg, msg );
}
Re: Automatic ANSIUnicode message translation
On Tue, 26 Jul 2005 16:04:22 +0900 Dmitry Timoshkov [EMAIL PROTECTED] wrote: This patch is not correct. All messages which potentially go through wineserver should be posted/sent via unicode. OK, then how you would suggest to solve the problem described in previous messages of this thread? Perhaps map_wparam_AtoW and map_wparam_WtoA should translate the whole wparam, i.e. both high and low bytes. What about the character codes which can't be converted? What does Windows do if the current locale is DBCS (Chinese/Japanese/Korean), does it translate the whole wparam in that case? AFAIK in DBCS two separate messages are used. -- Ph.
Re: Automatic ANSIUnicode message translation
On Tue, 26 Jul 2005 16:31:50 +0900
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Phil Krylov [EMAIL PROTECTED] wrote:
This patch is not correct. All messages which potentially go through
wineserver
should be posted/sent via unicode.
OK, then how you would suggest to solve the problem described in previous
messages of this thread?
One solution is to translate the whole wparam.
How do you see it? Example: I do a
PostMessageA(hwndAnsi, WM_CHAR, 0xF301, 0);
map_wparam_AtoW takes the \x01\xF3 string, translates it to Unicode via
CP_ACP (for CP1251, this would be probably {'\x01', 0x443})... and how
does it fit this info back in LOWORD(wParam)?
AFAIK in DBCS two separate messages are used.
A test under Windows would say it for sure.
I can't test it as I don't have a Windows with DBCS locales installed, but
Internet says:
When entering non-ASCII characters on systems with DBCS input
locales, the lead byte and trail byte for the DBCS character are passed
in two successive WM_CHAR messages. So we are better off processing
WM_IME_CHAR messages because we get both bytes at once. If we move to
Unicode, however, we'll directly get UTF-16 in WM_CHAR; or on XP: UTF-32
in WM_UNICHAR.
-- Ph.
Re: Automatic ANSIUnicode message translation
Hi Dmitry,
On Tue, 26 Jul 2005 16:56:31 +0900
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
The key word is the whole wparam. So, there is no need to truncate it
by using LOWORD.
Oh sorry. For some reason I thought that HIWORD(wParam) is used for some
other data. Here is a new patch, is it ok?
AFAIK in DBCS two separate messages are used.
A test under Windows would say it for sure.
I can't test it as I don't have a Windows with DBCS locales installed,
Just install one of such locales then, NT/2k/XP have built-in support
for DBCS locales.
I'll try to find a distro that has. However, my 2000 and XP distros have an
installation option for CJK locales, but the needed files are not on the
installation CDs.
-- Ph.
Index: dlls/user/message.c
===
RCS file: /home/wine/wine/dlls/user/message.c,v
retrieving revision 1.86
diff -p -u -r1.86 message.c
--- dlls/user/message.c 19 Jul 2005 19:14:32 - 1.86
+++ dlls/user/message.c 26 Jul 2005 09:06:33 -
@@ -368,10 +368,12 @@ static WPARAM map_wparam_AtoW( UINT mess
case WM_SYSDEADCHAR:
case WM_MENUCHAR:
{
-char ch = LOWORD(wparam);
-WCHAR wch;
-MultiByteToWideChar(CP_ACP, 0, ch, 1, wch, 1);
-wparam = MAKEWPARAM( wch, HIWORD(wparam) );
+BYTE ch[2];
+WCHAR wch[2];
+ch[0] = (wparam 0xFF);
+ch[1] = (wparam 8);
+MultiByteToWideChar(CP_ACP, 0, ch, 2, wch, 2);
+wparam = MAKEWPARAM(wch[0], wch[1]);
}
break;
case WM_IME_CHAR:
@@ -407,10 +409,12 @@ static WPARAM map_wparam_WtoA( UINT mess
case WM_SYSDEADCHAR:
case WM_MENUCHAR:
{
-WCHAR wch = LOWORD(wparam);
-BYTE ch;
-WideCharToMultiByte( CP_ACP, 0, wch, 1, (LPSTR)ch, 1, NULL, NULL );
-wparam = MAKEWPARAM( ch, HIWORD(wparam) );
+WCHAR wch[2];
+BYTE ch[2];
+wch[0] = LOWORD(wparam);
+wch[1] = HIWORD(wparam);
+WideCharToMultiByte( CP_ACP, 0, wch, 2, (LPSTR)ch, 2, NULL, NULL );
+wparam = MAKEWPARAM( ch[0] | (ch[1] 8), 0 );
}
break;
case WM_IME_CHAR:
Re: change in dlls/version/info.c breaks IBM Translation Manager
Hi, On Mon, 25 Jul 2005 21:37:09 +0200 Paul Vriens [EMAIL PROTECTED] wrote: could you try the attached. I only convert the win32 to win16 if we are not getting a request for '\' or '\VarFileInfo\Translation'. Both requests do not need a conversion anyway. This is just a quick hack for now, info.c needs a lot of cleanup. It works (at least for IBM TM). :) -- Ph.
Re: change in dlls/version/info.c breaks IBM Translation Manager
On Sun, 24 Jul 2005 11:56:38 +0200 Paul Vriens [EMAIL PROTECTED] wrote: could you also send me a +ver trace? Here it is (attached). -- Ph. trace Description: Binary data
change in dlls/version/info.c breaks IBM Translation Manager
Hello, http://cvs.winehq.org/cvsweb/wine/dlls/version/info.c.diff?r1=1.47r2=1.48f=h This recent change in dlls/version/info.c breaks IBM Translation Manager on startup: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x7bb0f4ac in 32-bit code (0x7b4ce282). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7b4ce282 ESP:7baff860 EBP:7baff8b0 EFLAGS:00010283( - 00 -RIS1C) EAX:7bb0fa58 EBX:7b4d37dc ECX:fd34 EDX:7bb0f4ac ESI:7baffb24 EDI:7baffb40 Stack dump: 0x7baff860: 7baffb28 7baffd4c 0x7baff870: 7baffb3c 0002 0x7baff880: 7baff9da 7bb0fa58 7b4d3ae0 7bb0f4ac 0x7baff890: 7baffd4c 1794 7baf 7baf 0x7baff8a0: fd34 7b4d37dc 7bb0fa58 7baffb24 0x7baff8b0: 7baff908 7b4ce2ad 7baffd24 7baffb24 Backtrace: =1 0x7b4ce282 ConvertVersionInfo32To16+0x172(info32=0x7baffd24, info16=0x7baffb24) [/home/phil/build/wine/dlls/version/info.c:267] in version (0x7baff8b0) 2 0x7b4ce2ad ConvertVersionInfo32To16+0x19d(info32=0x7baff9d4, info16=0x7baff9d4) [/home/phil/build/wine/dlls/version/info.c:273] in version (0x7baff908) 3 0x7b4cf64c VerQueryValueA(pBlock=0x7baff9d4, lpSubBlock=0x569214, lplpBuffer=0x7baff9cc, puLen=0x7baff9d0) [/home/phil/build/wine/dlls/version/info.c:772] in version (0x7baff93c) fixme:dbghelp:sffip_cb NIY on 'P:\EQFD\BINNTCVP\EQFD.pdb' 4 0x00401bb6 in eqfd (+0x1bb6) (0x7baffdb8) 5 0x004aa8e7 in eqfd (+0xaa8e7) (0x7baffddc) 6 0x004745c8 in eqfd (+0x745c8) (0x7baffdf4) 7 0x0044ef54 EntryPoint+0x1a4 in eqfd (0x7bafff2c) 8 0x7bbb3f48 start_process+0x8d(arg=0x0) [/home/phil/build/wine/dlls/kernel/process.c:996] in kernel32 (0x7ba4) 9 0xb7fab48d wine_switch_to_stack+0x11 in libwine.so.1 (0x) 0x7b4ce282 ConvertVersionInfo32To16+0x172 [/home/phil/build/wine/dlls/version/info.c:267] in version: movzwl 0x0(%edx),%eax 267 while ( (DWORD)child32 (DWORD)info32 + wLength child32-wLength != 0 ) Wine-dbg -- Ph.
Re: RICHED20: TODO list additions
Hi Dmitry, On Sat, 23 Jul 2005 00:41:42 +0900 Dmitry Timoshkov [EMAIL PROTECTED] wrote: What kind of hyphenation richedit needs? Would an automatic, not dictionary based algorithm suffice? Actually I'm unsure if the original RichEdit implements any hyphenation algorithm itself. However, version 4.1 allows to specify a callback function for hyphenation via EM_SETHYPHENATEINFO message. I need to perform some tests to see if there is any default algorithm. If there is one, we should also implement it, and your code could be useful (but probably only for East Slavic languages as the algorithm must be language-specific). -- Ph.
Re: RICHED20: EM_SETZOOM / EM_GETZOOM implementation
On Fri, 22 Jul 2005 16:32:17 -0400 Dimi Paun [EMAIL PROTECTED] wrote: From: Phil Krylov [EMAIL PROTECTED] Added EM_GETZOOM and EM_SETZOOM RichEdit message handlers. + case EM_GETZOOM: +if (!wParam || !lParam) + return FALSE; +*(int *)wParam = editor-nZoomNumerator; +*(int *)lParam = editor-nZoomDenominator; +return TRUE; I don't know what Windows does, but it may also do: + case EM_GETZOOM: +if (wParam) *(int *)wParam = editor-nZoomNumerator; +if (lParam) *(int *)lParam = editor-nZoomDenominator; +return TRUE; Have you checked? No, but according to the documentation: The message returns TRUE if message is processed, which it will be if both wParam and lParam are not NULL -- Ph.
Re: Fix ntdll compilation in Darwin
Hi Dmitry, On Thu, 30 Jun 2005 22:27:01 +0900 Dmitry Timoshkov [EMAIL PROTECTED] wrote: Phil Krylov [EMAIL PROTECTED] wrote: Index: dlls/ntdll/cdrom.c === RCS file: /home/wine/wine/dlls/ntdll/cdrom.c,v retrieving revision 1.59 diff -p -u -r1.59 cdrom.c --- dlls/ntdll/cdrom.c 29 Jun 2005 19:18:54 - 1.59 +++ dlls/ntdll/cdrom.c 30 Jun 2005 11:27:41 - @@ -75,6 +75,11 @@ # include sys/scsiio.h #endif +#ifdef __APPLE__ +# include IOKit/IOKitLib.h +# include IOKit/scsi/SCSICmds_REQUEST_SENSE_Defs.h +#endif + #define NONAMELESSUNION #define NONAMELESSSTRUCT #include ntstatus.h @@ -1418,6 +1423,8 @@ static NTSTATUS CDROM_ScsiPassThroughDir #ifdef SENSEBUFLEN if (pPacket-SenseInfoLength SENSEBUFLEN) +#elif defined( __APPLE__ ) +if (pPacket-SenseInfoLength kSenseDefaultSize) #else if (pPacket-SenseInfoLength sizeof(struct request_sense)) #endif Please do not introduce even more platform dependent #ifdefs into cdrom.c, currently it already has enough mess with all that #if defined(linux)/(__FreeBSD__)/ (__NetBSD__). Add proper configure checks for headers and structures your platform needs. To be sure I get you right: would changing __APPLE__ to HAVE_IOKIT (and adding HAVE_IOKIT detection to configure) be sufficient? -- Ph.
Re: wine/dlls/crypt32 tests/encode.c encode.c
Hi, this change gives me a lot of errors when compiling: make[3]: Entering directory `/home/phil/build/wine/dlls/crypt32/tests' ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole encode.o main.o protectdata.o testlist.o -o crypt32_test.exe.so -L../../../ libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../ libs -lcrypt32 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../../i686-pc-linux- gnu/bin/ld: warning: creating a DT_TEXTREL in object. encode.o(.text+0x3b): In function `test_encodeInt': /home/phil/build/wine/dlls/crypt32/tests/encode.c:74: undefined reference to `CryptEncodeObjectEx' encode.o(.text+0x8f):/home/ phil/build/wine/dlls/crypt32/tests/encode.c:81: undefined reference to `CryptEncodeObjectEx' ... -- Ph.
Re: storage32.c fix for big endian arch
Please disregard, Pierre d'Herbemont already sent the same few hours before :) -- Ph. On Tue, 17 May 2005 21:41:41 +0400 Phil Krylov [EMAIL PROTECTED] wrote: ChangeLog: Fixed storage32.c compilation in big endian architectures. Patch: Index: dlls/ole32/storage32.c === RCS file: /home/wine/wine/dlls/ole32/storage32.c,v retrieving revision 1.87 diff -p -u -r1.87 storage32.c --- dlls/ole32/storage32.c14 May 2005 11:06:44 - 1.87 +++ dlls/ole32/storage32.c17 May 2005 17:20:06 - @@ -4130,8 +4130,8 @@ void StorageUtl_ReadULargeInteger(const ULARGE_INTEGER tmp; memcpy(tmp, buffer + offset, sizeof(ULARGE_INTEGER)); -value-LowPart = htole32(tmp.HighPart); -value-HighPart = htole32(tmp.LowPart); +value-u.LowPart = htole32(tmp.u.HighPart); +value-u.HighPart = htole32(tmp.u.LowPart); #else memcpy(value, buffer + offset, sizeof(ULARGE_INTEGER)); #endif @@ -4143,8 +4143,8 @@ void StorageUtl_WriteULargeInteger(BYTE* #ifdef WORDS_BIGENDIAN ULARGE_INTEGER tmp; -tmp.LowPart = htole32(value-HighPart); -tmp.HighPart = htole32(value-LowPart); +tmp.u.LowPart = htole32(value-u.HighPart); +tmp.u.HighPart = htole32(value-u.LowPart); memcpy(buffer + offset, tmp, sizeof(ULARGE_INTEGER)); #else memcpy(buffer + offset, value, sizeof(ULARGE_INTEGER));
Re: ie6install richedit regression
On Mon, 18 Apr 2005 21:43:46 +0200 Paul van Schayck [EMAIL PROTECTED] wrote: http://cvs.winehq.org/patch.py?id=17049 This richedit patch broke ie6install.exe (doesn't start). As far as I can see the character stream is not setuped correctly. There is an endless loop of ME_PropagateCharOffset. This is going wrong somewhere in ME_Stream*. Thanks for the info, fixed. -- Ph.
Re: Resend: RICHED20: fall back to simple test
On Thu, 21 Apr 2005 00:58:10 +0900 Mike McCormack [EMAIL PROTECTED] wrote: You've done great work, and I thought you would want to know about a problem with it so you could correct it. No need for sorry :) I wrote sorry because I feel sorry :) I should give a more thorough testing to this code. -- Ph.
Re: Riched20: thanks + regression beta not shown
On Fri, 01 Apr 2005 18:04:32 +0200 Tobias Burnus [EMAIL PROTECTED] wrote: Hmm, I think the reason for my boxes was that I didn't install symbol.ttf from Windows (I had only a Symbol Set BT and bitmap fonts before). Yes, I also noticed some problems with font substitution... -- Ph.
Re: Fwd: Wine install fails on Gentoo with `SYS_sigaction' undeclared
Hi, I am using Gentoo with a linux kernel of 2.6.10 on a dual-Xeon 3.2ghz 64-bit system. I am using Gentoo with 2.6.10 on 32-bit Athlon XP and don't have this problem, so I suppose it must be something with 64-bitness. -- Ph.
Re: Riched20: thanks + regression beta not shown
Hi,
On Thu, 24 Mar 2005 10:13:30 +0100
Tobias Burnus [EMAIL PROTECTED] wrote:
Regression: One of the later riched20 patches, possibly
http://cvs.winehq.org/patch.py?id=16672, caused a regression with the
richedit control in Diamond.
Before it showed a beta character from the Symbol font, now it only
shows a box ([]).
Did you check later CVS? I tried to read an RTF containing beta from the
Symbol font both as 'b' (CP_SYMBOL codepage) and as 0xF062 (Unicode),
and both did look like betas on the screen.
Anyway, thanks, because the RTF output you quote shows another bug in the
RTF writer which I'm addressing now.
{fs18\f2 \u61538?}
\u61538? should be b, and even if it was not in a symbol charset, it
should read \u-3598 - RTF uses signed 16-bit values here.
One feature request: Currently, tabs are shown as box ([]), how about
replacing them with a simple space - that would increase the readability
a lot.
I suppose this is more addressed to Krzysztof... The readability could be
even better if tab positions were supported :)
-- Ph.
Re: RICHEDIT: RTF reader i18n (now with font charset support)
On Mon, 21 Mar 2005 14:40:38 +0300 Vitaly Lipatov [EMAIL PROTECTED] wrote: Will we do this code in locale independent manner? Why we have ansiCodePage=1252 by default? It is locale independent. 1252 is the default value used if RTF does not specify another codepage (which almost never happens). If I used GetACP() here, the same RTF document would be differently imported depending on user locale. RTF is not supposed to act like this. If RTF If I try open RTF where codepage is not specified, guessed codepage must be the same as ACP. For instance if I get such file here in Russia, I suppose it in cp1251 codepage. does not specify any codepage it means that it uses CP1252. I recommend use GetACP, otherwise in will some disadvantage for non cp1252 users. How do you find this code is locale dependent? IMHO it's _in_dependent of locale. I worry only about default codepage. OK, I've made some tests using the original M$ richedit, and they show the following: \ansicpg keyword in the RTF header does not affect the used encoding when importing RTF. The encoding used for import is determined by \fcharset setting for the current font. If it specifies \fcharset1 (DEFAULT_CHARSET) or is omitted, GetACP() is used. If it specifies \fcharset0 (ANSI_CHARSET), CP1252 is used regardless of current locale. For other charsets, their respective codepages are used. I'll commit the required changes to the RTF reader soon. -- Ph.
Re: RICHEDIT: RTF reader i18n (now with font charset support)
On Fri, 18 Mar 2005 15:12:01 +0300 Vitaly Lipatov [EMAIL PROTECTED] wrote: 17 2005 13:20 Phil Krylov (a): this patch replaces my precious patch RICHEDIT: RTF reader i18n and needs to be applied after Krzysztof Foltman's RICHEDIT: RTF reader improvements and optimizations (TAB craziness fixed) patch. ChangeLog: Replaced slow and outdated character set handling in RTF reader by Unicode/codepages support. Added charset-codepage conversion. Will we do this code in locale independent manner? Why we have ansiCodePage=1252 by default? It is locale independent. 1252 is the default value used if RTF does not specify another codepage (which almost never happens). If I used GetACP() here, the same RTF document would be differently imported depending on user locale. RTF is not supposed to act like this. If RTF does not specify any codepage it means that it uses CP1252. How do you find this code is locale dependent? IMHO it's _in_dependent of locale. -- Ph.
Re: richedit patches by Phil Krylov
On Mon, 14 Mar 2005 20:25:52 +0100 Krzysztof Foltman [EMAIL PROTECTED] wrote: Phil Krylov wrote: The RTF reader still has to be teached Unicode. Currently most of my existing .rtf documents are totally garbled. Can you fix it ? Judging from your RTF writer code and your last name, you probably have more knowledge about Unicode and RTF than I have. I'll try when I have time... I looked in the reader code and it's not very clear (at least in the part which deals with character sets), it'll take some time to understand it. -- Ph.
Re: richedit patches by Phil Krylov
On Mon, 14 Mar 2005 19:31:25 +0100 Krzysztof Foltman [EMAIL PROTECTED] wrote: ChangeLog: Initial implementation of EM_STREAMOUT and RTF writer. Nice to see this functionality implemented (I really didn't want to implement it myself). Very good code too. Thanks. Thanks :) The new function ME_FindItemAtOffset isn't really necessary, you can achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should have used it in ME_GetTextW instead of reimplementing the same functionality). I'm going to get rid of it later. Oh sorry, I haven't noticed that it already exists. Now when both EM_STREAMIN and EM_STREAMOUT work, I can start implementing the rest of the clipboard code. The RTF reader still has to be teached Unicode. Currently most of my existing .rtf documents are totally garbled. -- Ph.
Re: richedit patches by Phil Krylov
On Mon, 14 Mar 2005 19:31:25 +0100 Krzysztof Foltman [EMAIL PROTECTED] wrote: ChangeLog: Initial implementation of EM_STREAMOUT and RTF writer. Nice to see this functionality implemented (I really didn't want to implement it myself). Very good code too. Thanks. Thanks :) The new function ME_FindItemAtOffset isn't really necessary, you can achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should have used it in ME_GetTextW instead of reimplementing the same functionality). I'm going to get rid of it later. Oh sorry, I haven't noticed that it already exists. Now when both EM_STREAMIN and EM_STREAMOUT work, I can start implementing the rest of the clipboard code. The RTF reader still has to be teached Unicode. Currently most of my existing .rtf documents are totally garbled. -- Ph.
Re: dlls/richedit/reader.c
Hello Ge, Friday, April 16, 2004, 3:56:41 PM, you wrote: GvG Changelog: GvG Ge van Geldorp [EMAIL PROTECTED] GvG Work around problem in NSIS installers which can't handle 1 char GvG at a time reading of RTF text. To make it fully compatible with MS richedit, the buffer size should be not 10 chars, but 4096. Although it's not documented, all versions of MS Richedit always use this value. -- Best regards, Philmailto:[EMAIL PROTECTED]
Re: Wine menu woes
Hello Geoffrey, Saturday, April 10, 2004, 9:20:56 PM, you wrote: GH I have an application that seems to work very well, except that the menus GH don't work (in wine, they are fine in Windows) GH The app is located here (free download): GH http://www.acumeninc.com/download/tzmax50v3.21.exe GH After some debugging, I found that the app creates a menu, then destroys GH it and recreates it using different titles. If it can help: it is also an issue with The Bat! - the menus stop working after their recreation on language change (from English to another). -- Best regards, Philmailto:[EMAIL PROTECTED]
Re: mdi: remove child activate optimization
Hello Huw, Tuesday, March 9, 2004, 1:46:20 PM, you wrote: HDMD Huw Davies [EMAIL PROTECTED] HDMD We need to at least refresh the window menu in ChildActivate, HDMD so for now remove the 'is already activated' optimization. This patch brings a regression: IBM Translation Manager enters an endless activation-switching loop when closing one of its MDI children (which is in some non-trivial way used as a parent for 4 more MDI children). -- Best regards, Philmailto:[EMAIL PROTECTED]
Re: Wine and Macromedia in (Heise) News
Hello Stefan, Saturday, March 6, 2004, 12:17:30 PM, you wrote: SL Hello, SL in http://www.heise.de/newsticker/meldung/45275 (german only) it is states SL that Macromedia currently modifies their Web-Authoring-System Flash MX to run SL with wine. After that they like to port it to linux. It'd be better (for wine) if they modified wine to run Flash.. SL Bye Stefan -- Best regards, Philmailto:[EMAIL PROTECTED]
Re[2]: Yeah - our RichEDit needs some work
Hello Joshua, Thursday, December 25, 2003, 11:04:28 PM, you wrote: JW If you need the source of a program that can uses RTF JW as it's native format, can spit out JW microsoft-compatible RTF files, has all the tools for JW editing Rick Text, and the source is aviliable in C... JW then use the Source for Ted JW http://www.nllgg.nl/Ted/ JW I would toss it in myself, but I suck a coding. I JW wouldn't even know where to begin. I have to note that richedit should also implement Text Object Model, that is, ITextDocument, ITextServices etc. (and to be really compatible with M$ one, it should be based on them). -- Best regards, Philmailto:[EMAIL PROTECTED]
Re[4]: Yeah - our RichEDit needs some work
Hello Dimitrie, Monday, December 29, 2003, 11:33:21 PM, you wrote: DOP Now, if you are familiar with the richedit problem, DOP can you come up with a list of tasks that will eventually DOP lead to a full blown richedit control? It is a big task, if DOP we break it into smaller, self contained ones (like the DOP ones you mentioned) maybe someone will start working on it. I'll try. First, I don't think that any part of the current richedit code can be used. It is very much of a stub. Hard Tasks: . COM interfaces. I have only started to implement the tom.h header file (for MinGW, but it should be easy to port). I am personally bad at COM programming (esp. in pure C)... There can be two approaches to this: a) implement everything without COM and then add simple COM wrappers. This may be easier because the official COM richedit interfaces are not very simple (for me :) b) implement everything in COM from scratch. . Internal rich text storage - how it should be done? Structures etc. (ITextDocument, ITextRange...) Maybe have a look at GtkTextBuffer from GTK+? . There are also some OLE interfaces, and I won't say anything here because I never used that. Easy Tasks: . Streaming RTF in and out of the internal storage. I have done a lot of RTF parsing/generation code, so this could help. . Rich text rendering. This seems relatively simple, I did some multifont text rendering code in Win32 API. . User interaction. Relatively simple too. That's it. It seems to me that the first thing to do is an internal rich text storage specification, because every other task depends on it. -- Best regards, Philmailto:[EMAIL PROTECTED]
Added support for inter-process GetWindowLong on the window extra bytes
Hello, This change prevents IBM Translation Manager from working correctly. It has a dialog named Export Folder which used to contain three buttons and a tabbed notebook with various options. After this update, the pages of the tabbed notebook are no longer displayed (and created). Hope I can provide some more details like a debug log if someone will tell me which channels should be traced. AJ ChangeSet ID: 10222 AJ CVSROOT:/opt/cvs-commit AJ Module name:wine AJ Changes by: [EMAIL PROTECTED] 2003/11/26 16:15:41 AJ Modified files: AJ windows: win.c AJ server : window.c trace.c protocol.def AJ include/wine : server_protocol.h AJ Log message: AJ Added support for inter-process GetWindowLong on the window extra AJ bytes. AJ Patch: http://cvs.winehq.com/patch.py?id=10222 AJ Old revision New revision Changes Path AJ 1.226 1.227 +132 -111 wine/windows/win.c AJ 1.25 1.26 +36 -4 wine/server/window.c AJ 1.185 1.186 +7 -3 wine/server/trace.c AJ 1.87 1.88 +6 -0 wine/server/protocol.def AJ 1.88 1.89 +7 -1 AJ wine/include/wine/server_protocol.h -- Best regards, Philmailto:[EMAIL PROTECTED]
