May 2012 - Wine-Devel - list.winehq.org

Re: [Programs] Notepad: sync with ReactOS notepad (2)

by Jerome Leclanche

On Sun, May 6, 2012 at 3:16 PM, Stefan Dösinger <stefandoesinger(a)gmx.at>wrote: > Hi, > > Wine has a policy of not accepting code from ReactOS due to the legal > uncertainty introduced by questionable reverse engineering techniques used > by > some ReactOS devs, and I am not aware of a change in that policy. > > Stefan > > I don't see how that would apply to notepad though. J. Leclanche

May 6, 2012

Re: [Programs] Notepad: sync with ReactOS notepad (2)

by Stefan Dösinger

Hi, Wine has a policy of not accepting code from ReactOS due to the legal uncertainty introduced by questionable reverse engineering techniques used by some ReactOS devs, and I am not aware of a change in that policy. Stefan

May 6, 2012

Re: [Programs] Notepad: sync with ReactOS notepad (2)

by carlo.bramix＠libero.it

Hello friends, >thank you for working on this. I think you will improve the chances for >your patches to be accepted if you give them individually meaningful >names, like > >"notepad: Don't use reserved MSVC keyword." > >for patch #2. Actually, I followed the tip I read into the wiki of WINE in "Patch submission guidelines", so I tried to imitate the style of other patches for WINE and for this reason I used an identical title with a progressive number as subject. If something different is prefered, no problem, I will follow your suggestion and I will use a more focused title. >Also, like Jerome said, we may have a problem if different people >commited these changes to ReactOS. I'm no expert on this, but as I >understand, Wine needs the patch to be credited to the author who >actually wrote the code. Well, ReactOS notepad had been imported from WINE long time ago and various people did some changes on it and I'm included in them since, in this specific case, the status bar implementation had been almost rewritten by me. I'm not an expert too, but since it is distribuited under the same license of WINE, with same coding restrictions and all people who sent patches have agreed to the same GPL as well, my intuition would say that there is no problem on this... because the owner who can providing this code to you is the ReactOS project itself. That's just my opinion of course... I will wait for your suggestions/orders... ;-) Sincerely, Carlo Bramini.

May 6, 2012

Re: [Programs] Notepad: sync with ReactOS notepad (2)

by Julian Rüger

Hi Carlo, thank you for working on this. I think you will improve the chances for your patches to be accepted if you give them individually meaningful names, like "notepad: Don't use reserved MSVC keyword." for patch #2. Also, like Jerome said, we may have a problem if different people commited these changes to ReactOS. I'm no expert on this, but as I understand, Wine needs the patch to be credited to the author who actually wrote the code. (Can someone else please comment on this, if I am mistaken?) Best regards, Julian

May 6, 2012

winetricks & DLL overrides

by wylda＠volny.cz

Hi Dan, i'm happy user of winetricks and thanks for all that work. Today i found out, that i wasn't able to reveal, that apps uses some native dll when using: winetricks settings alldlls=builtin further checking revealed, that winetricks(20120308) has several no longer available dll override compared to winecfg and some are missing, thus application uses them as native. So i add/del dlls from override_all_dlls list based on winecfg (1.5.3-164-gdec3d50) and the result is attached as a patch. Probably unusable for you, because: * no care about line length * i do not know whether removing no longer available dll's override is allowed (what's happen for users using old wine-1.0 and need dlls's override no longer available in wine-1.5.3) * shouldn’t be the dll's override in user.reg simply overwritten? As i noticed the names are there twice - 2nd one with "*" prefix making it confusing, which value will be used and the list in winecfg is twice as long. Thanks and regards, W.

May 6, 2012

Re: rpcrt4/tests: Fix build with PSDK headers.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18238 Your paranoid android. === WNT4WSSP6 (32 bit ndr_marshall) === ndr_marshall: unhandled exception c0000005 at 004081C6

May 5, 2012

Re: msi: Tweak msiexec's usage message.

by Frédéric Delanoy

On Fri, May 4, 2012 at 3:21 PM, Francois Gouget <fgouget(a)free.fr> wrote: > On Fri, 4 May 2012, Julian Rüger wrote: > >> Hi Francois and wine-devel, >> >> while we're at it, shouldn't these >> >> >"Advertise a product:\n" >> >"\t/j[u|m] package [/t transform] [/g languageid]\n" >> >"Apply a patch:\n" >> >"\t/p patch_package [property]\n" >> >"\t/p patch_package /a package [property]\n" >> >> also be put in curly brackets? >> >> Like this: >> >> \t/j[u|m] {package} [/t transform] ... >> \t/p {patch_package} [property]\n >> ... > > My understanding is that for msiexec the curly brackets are only used to > enclose cases where there is two or more alternatives: {a|b|c}. With > {required parameter} being an exception to the rule, maybe because it in > fact represents a list. > > It would be nice if all of Wine's tools used the same conventions for > the usage messages. The msiexec conventions look sane to me: [ ] for optional and { } for mandatory parameters (*only* when a choice/list is involved). It's also what's used in other wine commands "/?" results (e.g. 'start', 'ipconfig', 'regedit', etc.). Frédéric

May 5, 2012

Re: [Programs] Notepad: sync with ReactOS notepad

by Jerome Leclanche

On Sat, May 5, 2012 at 2:15 PM, carlo.bramix(a)libero.it < carlo.bramix(a)libero.it> wrote: > Attached patch synces the WINE's notepad with the improvements added into > ReactOS' Notepad. > > - Imported status bar implementation, it fixes Bug #18715. New menu voice > has > been introduced into the resource file. > This is the biggest part of the patch, that it caused to touch all files > modified by the patch. > Other minor fixes included here are: > > - Implemented GOTO function. Since its menu voice has been added into the > resource file when adding support the statusbar, the related dialog box > and the > source code have been introduced too. > > - Find/Replace functions have an extremely similar behavior, so the job > can be > implemented with a single function. > > - Find and Find next commands must be grayed if there is not a text to > search > into. > > - The "class" word is a reserved keyword in MSVC, so I also imported the > fix > into the creation of the class of the window: "class" has been replaced > with > "wndclass", no code change. > > Sincerely, > > Carlo Bramini > > It's not going to be accepted as one big patch. It needs to be split. Also, are you the author of all the patches or are these other contributors for this? J. Leclanche

May 5, 2012

Re: kernel32: add more tracing to GetDiskFreeSpaceW

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > @@ -1687,6 +1689,8 @@ BOOL WINAPI GetDiskFreeSpaceW( LPCWSTR root, LPDWORD cluster_sectors, > if (sector_bytes) *sector_bytes = info.BytesPerSector; > if (free_clusters) *free_clusters = info.AvailableAllocationUnits.u.LowPart; > if (total_clusters) *total_clusters = info.TotalAllocationUnits.u.LowPart; > + TRACE("%u, %u, %u, %u, capped=%d\n", cluster_sectors ? *cluster_sectors : 0, sector_bytes ? *sector_bytes : 0, > + free_clusters ? *free_clusters : 0, total_clusters ? *total_clusters : 0, capped); Why not print in the values directly from info structure? That way all the data are in the trace regardless of what info appication requested. I'd guess that printing valus in hex would be more readable, and once the data is printed in hex it should be obvious when the values were capped, making 'capped' flag redundant. -- Dmitry.

May 5, 2012

Re: [2/5] msvcm80: Add stub dll.

by Vincent Povirk

> As for doing native->CLR calls from within msvcm, there are a few > options, and I haven't chosen one yet: There is another possibility, which is to embed a .NET header and the code we need in msvcm, and use pinvokes/vtable fixups to call between native and managed code.

May 4, 2012