June 2006 - Wine-Devel - list.winehq.org

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, James Hawkins <truiken(a)gmail.com> wrote: > On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > > > > So, the current plan is to: > > - See if the "new Thomas patch" gets accepted during the nearest 2 weeks > > - If yes, rewrite the 1.0 fix and it send separately - it's totally > > incompatible with that patch > > - If not, resubmit the EM_GETLINE stuff, with proper credits this time, > > maybe as two separate patches (implementation and unit test) > > - Move EM_LINELENGTH fix and editor pointer check into separate patches > > (as soon as they're OK so I don't have to split them over and over) > > > > Does that sound reasonable? > > > > Yea that sounds good, though you should probably just wait a couple > days. If it doesn't get accepted before then, it was probably > dropped. > I meant to say, "wait a couple days instead of two weeks".

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > > So, the current plan is to: > - See if the "new Thomas patch" gets accepted during the nearest 2 weeks > - If yes, rewrite the 1.0 fix and it send separately - it's totally > incompatible with that patch > - If not, resubmit the EM_GETLINE stuff, with proper credits this time, > maybe as two separate patches (implementation and unit test) > - Move EM_LINELENGTH fix and editor pointer check into separate patches > (as soon as they're OK so I don't have to split them over and over) > > Does that sound reasonable? > Yea that sounds good, though you should probably just wait a couple days. If it doesn't get accepted before then, it was probably dropped. -- James Hawkins

June 30, 2006

Link or rename wcmd.exe to cmd.exe?

by Thomas Kho

I'd like to restart this old thread <http://www.winehq.com/hypermail/wine-users/2005/05/index.html#165> which brings up the point that there are applications that hard-code cmd.exe and (sometimes intentionally) ignore COMSPEC. One example is Perl, which has the following comment in win32/win32.c: /* we don't use COMSPEC here for two reasons: * 1. the same reason perl on UNIX doesn't use SHELL--rampant and * uncontrolled unportability of the ensuing scripts. * 2. PERL5SHELL could be set to a shell that may not be fit for * interactive use (which is what most programs look in COMSPEC * for). */ I'm currently looking into what would be required for something like a symlink to wcmd.exe, but at the same time I'm wondering the historical reasons for choosing 'wcmd' and if it should be changed to just 'cmd'. Thomas Kho

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by Krzysztof Foltman

James Hawkins wrote: > this problem. The previous version you sent in did have his name, > which is perfectly legit, but this version doesn't. You can either > add his name as well as yours to the changelog, or ask him to resend > the tests separately. So, the current plan is to: - See if the "new Thomas patch" gets accepted during the nearest 2 weeks - If yes, rewrite the 1.0 fix and it send separately - it's totally incompatible with that patch - If not, resubmit the EM_GETLINE stuff, with proper credits this time, maybe as two separate patches (implementation and unit test) - Move EM_LINELENGTH fix and editor pointer check into separate patches (as soon as they're OK so I don't have to split them over and over) Does that sound reasonable? Krzysztof

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > James Hawkins wrote: > > > I've just looked at this patch and the previous patch Thomas sent in, > > and saying that this is roughly based on his patch is putting it > > lightly. > > > > missing feature, but either way, he deserves credit for the code he > > wrote, and not just saying that your code was based off of his. > > He obviously does. The previous version of the patch (which I re-sent) > HAS his name as the sole author of the changes. > I'm not accusing you of intentionally ripping Thomas off, only that more credit is due than was given, and I gave possible solutions to this problem. The previous version you sent in did have his name, which is perfectly legit, but this version doesn't. You can either add his name as well as yours to the changelog, or ask him to resend the tests separately. -- James Hawkins

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by Krzysztof Foltman

James Hawkins wrote: > I've just looked at this patch and the previous patch Thomas sent in, > and saying that this is roughly based on his patch is putting it > lightly. The EM_GETLINE code is completely changed (I haven't even seen his "new" implementation - http://www.winehq.org/pipermail/wine-patches/2006-June/028096.html - before sending the patch in, and the old one was the one Alexandre wrote it needed fixing). Actually knowing about that patch would save me an hour or so of unnecessary work. The testing code is by Thomas and is completely unchanged, too. Yes, I should have emphasized that in the change log. But it wasn't meant to rip him off. > I see that you've added the 1.0 emulation change, but that > doesn't warrant you putting your name on his patch. I guess, let him decide about that. > then add your code in a new patch, or to make him aware of the > problems in his implementation, The fact is: - he sent the original patch long time ago, and he didn't fix the problems until very recently (because Alexandre only told us about the problem after I reminded him about his patch?) - the mail from Alexandre about the patch being wrong was explicitly addressed to me, so with lack of reaction from Thomas I assumed I should update the patch - "my" cleanup was created *independently* from the new (see above) patch from Thomas, and I'm not even sure which version I like more (the new version from Thomas is more compact, and multiplying nCopy by current character size may not be as patch-reject-prone as I initially thought, given Alexandre's stance about nBPC trick) - the cleanup involved removing lots of the original code and replacing it by my own (only in EM_GETLINE handler, not in the test code) - just compare the old vs "my" version; that's why I decided to add "roughly" - I think I have enough of "genuinely mine" and rather complex code in riched20 (like initial versions of style management, display, wrapper) to not be suspected of wanting to take credit for a loop doing (essentially) strcat and p=p->next, that I didn't code from scratch, at cost of Thomas :) > missing feature, but either way, he deserves credit for the code he > wrote, and not just saying that your code was based off of his. He obviously does. The previous version of the patch (which I re-sent) HAS his name as the sole author of the changes. Krzysztof

June 30, 2006

Re: [TOOLS] Re: Gecko installer

by Jacek Caban

Jeremy Newman wrote: > This is now live at: > http://source.winehq.org/winegecko.php > > On Sun, 2006-06-25 at 11:40 +0200, Jonathan Ernst wrote: > >> Le samedi 24 juin 2006 à 20:06 +0200, Jacek Caban a écrit : >> >>> Hi, >>> >>> >> [...] >> >>> - We need php script redirecting to SourceForge similar to one that >>> forwards to Mozilla ActiveX control. >>> >> Here you are. >> Thanks Jeremy and Jonathan. I'll send patches that will add the last missing part. Jacek

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by H. Verbeet

On 30/06/06, Thomas Kho <tkho(a)ucla.edu> wrote: > I'm not 100% clear what the problem is. My interpretation of your > first email was that there was a necessary distinction in type between > user/gdi handles as stored in the server, but now my understanding is > that you're concerned gdi objects in MENUITEM/MENUITEMINFO should not > be mutable by external processes. Is that right? The basic problem is that if you create a HBITMAP in one process, then pass the handle to another process, you can't read the contents of the bitmap in that other process. So suppose you create a menu item in one process and set a custom bitmap on the menu item. Should the menu then display correctly in another process if you pass it the menu handle? > I did some probing and was able to change the values of the four gdi > objects (MENUINFO.hbrBack, and bitmap, (un-)check bitmaps in > MENUITEMINFO) from an external process. Specifically, I changed the > brush to one returned by GetStockObject(WHITE_BRUSH), changed the > bitmap to one of the predefined handles, and set (un-)check bitmaps to > an invalid value that was correctly returned upon a GetMenuItemInfo > query. So, I think regardless of the scope of gdi objects, it's the > right behavior for the menu code to blindly set and get the gdi > handles. Stock objects are somewhat special, since they're not created / owned by the current process.

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > ChangeLog: > * EM_GETLINE support (roughly based on code by Thomas Kho, although > there are important changes, for example, it works correctly in RichEdit > 1.0 emulation mode) (bug #4305) > * Workaround for wrong window handles (bug# 4452) > * EM_LINELENGTH handles paragraph ends properly (bug #5375) > > I'm sending it as one patch, just in case it gets rejected again - > trying to split the patch seems to give me some mysterious git problems. > I've just looked at this patch and the previous patch Thomas sent in, and saying that this is roughly based on his patch is putting it lightly. I see that you've added the 1.0 emulation change, but that doesn't warrant you putting your name on his patch. The correct way to go about this would be to wait till his patch gets accepted and then add your code in a new patch, or to make him aware of the problems in his implementation, so he can rewrite it or add the missing feature, but either way, he deserves credit for the code he wrote, and not just saying that your code was based off of his. -- James Hawkins

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by Thomas Kho

On 6/30/06, Robert Shearman <rob(a)codeweavers.com> wrote: > Thomas Kho wrote: > > > On 6/30/06, Robert Shearman <rob(a)codeweavers.com> wrote: > > > >> Thomas, can you regenerate this patch using "void *" for bmpitem (or > >> perhaps add a new gdi_handle_t type)? > > > > > > I'll add the gdi_handle_t type and resubmit two patches (I caught > > another use in the menu struct). > > > As others have said, GDI objects are not shared between processes. GDI > objects are DCs, regions, bitmaps, palettes, fonts, and brushes. I > assumed that they were shared, because icons are shared, but they are a > user32 object. > > You'll have to write a test to see whether Windows allows you to > retrieve and use the bitmap for a menu from another process. I'm not 100% clear what the problem is. My interpretation of your first email was that there was a necessary distinction in type between user/gdi handles as stored in the server, but now my understanding is that you're concerned gdi objects in MENUITEM/MENUITEMINFO should not be mutable by external processes. Is that right? I did some probing and was able to change the values of the four gdi objects (MENUINFO.hbrBack, and bitmap, (un-)check bitmaps in MENUITEMINFO) from an external process. Specifically, I changed the brush to one returned by GetStockObject(WHITE_BRUSH), changed the bitmap to one of the predefined handles, and set (un-)check bitmaps to an invalid value that was correctly returned upon a GetMenuItemInfo query. So, I think regardless of the scope of gdi objects, it's the right behavior for the menu code to blindly set and get the gdi handles. Tommy

June 30, 2006