March 2014 - Wine-Devel - list.winehq.org

Re: [2/4] widl: Pass type attributes from write_array_tfs to write_pointer_description.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> >> > This allows to differentiate strings and write appropriate rpc type >> >> >> > (FC_C_C[W]STRING instead of FC_[W]CHAR). >> >> >> >> >> >> It also changes some pointers from UP to RP, that doesn't look right. >> >> > >> >> > I don't see any changes in server_c.c and server_s.c in dlls/rpcrt4/tests, >> >> > do you see this somewhere else? >> >> >> >> In many of the generated proxy files, in actxprxy for instance. >> > >> > As far as I can see new behaviour matches what midl generates, for instance >> > for wireBSTR/SAFEARR_BSTR. >> >> It generates FC_UP here (midl 7.0). Is it different in newer versions? > > I don't see differences between the code generated by midl shipped with > PSDK 7.1 (midl 7.00.0555) and Visual Studio Express 12.0 (midl 8.00.603). Do you really get FC_RP pointers in there? Did you build with the Wine headers? -- Alexandre Julliard julliard(a)winehq.org

March 20, 2014

Re: wintab32: fixing a typo which prevented sending correct pkSerialNumber

by Bruno Jesus

Please send to wine-patches. On Thu, Mar 20, 2014 at 6:33 AM, Eriks Dobelis <eriks.dobelis(a)biti.lv> wrote: > This submission Obsoletes patch id#103302. I split it into parts for easier > review and will later submit the rest of patches, but each of them will > resolve a single issue and they are not interdependent. Common goal is to > resolve http://bugs.winehq.org/show_bug.cgi?id=18517. > > This patch fixes a typo in a code, which was a cause for wrong > pkSerialNumber values to be sent in messages. TRACE entries showed correct > values, because TRACE statement was executed before actual sending of the > packet. Due to this it took quite a time to spot the problem :) > > dlls/wintab32/context.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > -- universe* god::bigbang (void); //and then it all began...

March 20, 2014

Re: [2/4] widl: Pass type attributes from write_array_tfs to write_pointer_description.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> > This allows to differentiate strings and write appropriate rpc type > >> >> > (FC_C_C[W]STRING instead of FC_[W]CHAR). > >> >> > >> >> It also changes some pointers from UP to RP, that doesn't look right. > >> > > >> > I don't see any changes in server_c.c and server_s.c in dlls/rpcrt4/tests, > >> > do you see this somewhere else? > >> > >> In many of the generated proxy files, in actxprxy for instance. > > > > As far as I can see new behaviour matches what midl generates, for instance > > for wireBSTR/SAFEARR_BSTR. > > It generates FC_UP here (midl 7.0). Is it different in newer versions? I don't see differences between the code generated by midl shipped with PSDK 7.1 (midl 7.00.0555) and Visual Studio Express 12.0 (midl 8.00.603). -- Dmitry.

March 20, 2014

wintab: Incorrectly classifying cursor as stylus instead of eraser

by Eriks Dobelis

Did not attach the patch in my last email :( For Wacom Pen & Touch Intuos tablet eraser cursor is incorrectly detected as stylus. The tablet returns its eraser cursor name as: Wacom Intuos PT S Pen eraser and type as: ERASER Current code classifies this as STYLUS, because name of the cursor contains the word 'Pen'. It is very unlikely that a cursor with type ERASER is STYLUS. With the patch eraser is correctly detected. Without the patch eraser works as stylus. dlls/winex11.drv/wintab.c | 3 +++ 1 file changed, 3 insertions(+)

March 20, 2014

wintab: Incorrectly classifying cursor as stylus instead of eraser

by Eriks Dobelis

For Wacom Pen & Touch Intuos tablet eraser cursor is incorrectly detected as stylus. The tablet returns its eraser cursor name as: Wacom Intuos PT S Pen eraser and type as: ERASER Current code classifies this as STYLUS, because name of the cursor contains the word 'Pen'. It is very unlikely that a cursor with type ERASER is STYLUS. With the patch eraser is correctly detected. Without the patch eraser works as stylus. dlls/winex11.drv/wintab.c | 3 +++ 1 file changed, 3 insertions(+)

March 20, 2014

Re: [PATCH 1/6] wined3d: Remove the version parameter (try 2).

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-20 12:46, schrieb Henri Verbeet: > I don't think that really matches Windows. Going by the testbot > results, I think creating a D3D object should succeed, and > creating a (hardware) device should fail. Do we care enough about this? The behavior of my patch matches the behavior if OpenGL is not available. To change this we'd have to put this check in every d3d object method (or rather its wined3d counterpart) that accepts a device type. A quick search through our bug database didn't bring up any application that fails with the current handling and would otherwise do something reasonable if we returned an error during device creation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTKt7VAAoJEN0/YqbEcdMwvukP/2HOlconJnHL/j/BdveDDUHX jUvFBVZ9wHU6Zebwcx5FBm17LeGIE62q5xzB2pfVym52QfACumPygx7kqqUI9DGy 0E0aKWES/WNM6nogX1RUEbpFckVqUmONKWFgNNvIYi3H8PfPlIKe+sdYwaLmnIkd 6GBKjpMtUb/2ArL3PNRiwTYhhxr1bR1UyHbcQjJC8pH/1elRZYJc7ISJleAvg6wM oQZkzURc6KIS3MtfXdoHSGXhUp6P6/aJGPkJzIAiD6ANSE6s2c7MGadSzu3ITD4v s6tkWQUQwQBu9o5d1OIAuWhT4MHPJV+QIX2Ble+W99fom/jqxO0+g7Dqx/+h+bKV tZcHyccI+VfcU8GmIC0tZplEcy0QD4hzbp0wZa0gMHZylw/V7Xf/gFzU91qI+1HR IUy6X/7DvEfDtIxbqJAYtMNs27T7sE2OkMmJURheT+8lk+6G2FqCVgg/OMkHWIlX xVVPjmWlJM+YL0G3Csw0qgXV4T/CRsczB0xkqKyGA3qcR/PD+chtDCMbzF92wdv+ 3QXp3s9yuMorqXI5xVSecF487tfCcG6tY45Kd+oQ2avq5Y5yVDk5mQbFzZxWAGgl EroHZCkoEIhFuUb0aiStN3wVONRVc+aH6F2ZHF0aPziijMS1Zpa0/qgGE7Joluxe Ja734UvcYXf0N1xJL95P =HgH8 -----END PGP SIGNATURE-----

March 20, 2014

Re: [2/4] widl: Pass type attributes from write_array_tfs to write_pointer_description.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> > This allows to differentiate strings and write appropriate rpc type >> >> > (FC_C_C[W]STRING instead of FC_[W]CHAR). >> >> >> >> It also changes some pointers from UP to RP, that doesn't look right. >> > >> > I don't see any changes in server_c.c and server_s.c in dlls/rpcrt4/tests, >> > do you see this somewhere else? >> >> In many of the generated proxy files, in actxprxy for instance. > > As far as I can see new behaviour matches what midl generates, for instance > for wireBSTR/SAFEARR_BSTR. It generates FC_UP here (midl 7.0). Is it different in newer versions? -- Alexandre Julliard julliard(a)winehq.org

March 20, 2014

Re: [2/4] widl: Pass type attributes from write_array_tfs to write_pointer_description.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > This allows to differentiate strings and write appropriate rpc type > >> > (FC_C_C[W]STRING instead of FC_[W]CHAR). > >> > >> It also changes some pointers from UP to RP, that doesn't look right. > > > > I don't see any changes in server_c.c and server_s.c in dlls/rpcrt4/tests, > > do you see this somewhere else? > > In many of the generated proxy files, in actxprxy for instance. As far as I can see new behaviour matches what midl generates, for instance for wireBSTR/SAFEARR_BSTR. -- Dmitry.

March 20, 2014

Re: [PATCH 1/6] wined3d: Remove the version parameter (try 2).

by Henri Verbeet

On 20 March 2014 12:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (!(caps.ddraw_caps.caps & WINEDDCAPS_3D)) > + { > + WARN("Created a wined3d object without 3D support.\n"); > + wined3d_decref(d3d8->wined3d); > + goto done; > + } I don't think that really matches Windows. Going by the testbot results, I think creating a D3D object should succeed, and creating a (hardware) device should fail.

March 20, 2014

GSoC 2014 proposal - Implement VBScript built-in functions

by 孟帅

Hi all! I'm Shuai Meng, a student from software school of Beihang University, China, GMT+08:00. I'm pursuing a master degree and now in grade one. You can call me shuaimeng, that's my nickname used in irc. Now I'm here to apply for GSoC to work for Wine. I'm familiar with C, and I can code with python as well. Besides, I know a little about html and vbscript. From May to August, I have plenty of free time. About one year ago I started my way to linux, it's not smooth for a person who had got used to windows then embrace linux. Soon I got a problem: QQ(the most popular IM software in China) doesn't support linux, but I really need it. Fortunately I knew wine through searching google, it helped me solve this problem.Since then I have become a wine user. In the past three months, I had focused on dlls/vbscript/global.c, searching MSDN for related documents[1]~[4]. Accordding those documents, I added more tests in dlls/vbscript/tests/api.vbs, then got some similar bugs and only reported one[5]. In order to fix them, I read wine source code in dlls/vbscript/global.c, again and again. Finally I finished a few draft patches[6] and I will send them to wine-patches later. As I have made so much effort in this module and gain a little experience, during GSoC this part will go on to occupy most of my attention. On the basis of difficulty to be implemented, I divide all the functions in dlls/vbscript/global.c into four groups as following: 1: Abs ScriptEngine ScriptEngineBuildVersion ScriptEngineMajorVersion IsArray IsDate IsNumeric IsObject Sgn TypeName VarType These are the easiest to implement, I will take about one week to finish the unimplemented. 2: FormatCurrency FormatDateTime FormatPercent Hour FormatNumber Join Minute Month Oct Rnd Second Space TimeValue Year The second group will occupy two weeks of the whole GSoC time. They are not as easy as the first group and there are more to be accomplished. Most of them are involved in time functions while a few is about strings. 3: Asc Ant Cos DateAdd DateDiff DatePart DateSerial Day Exp LBound Log Replace Sin Sqr String Tan TimeSerial UBound Weekday CBool CByte CCur CDate CDbl CInt CLng CSng CStr InStrRev Int Fix StrComp Timer These are more difficult. However a large part is conversion functions and they have been implemented or improved by me. You can find the details in attchment. Optimistically speaking, I need at least three weeks to complete all of them. When I finish that, this bug[7] will be fixed. 4: Array Date DateValue Escape Eval Filter GetLocale GetRef InputBox LoadPicture Now RGB SetLocale Split Time Unescape Here come the most difficult ones. I am not so sure whether I can fix or even understand them, but I will try my best. Maybe after I have finish the above three groups, I can gain a little confidence to face them. This group would cost me four weeks or even longer. If I have a good luck, maybe I can fix this bug[8]. To be prudent, I'll spare at least one week to do a review on all my codes. Write a summary as a guidence for my work to be continued after GSoC. Though I have a rough plan now, as a greenhand to wine, I hava too much to learn and I badly need advice from all of you. I hope I can make a proper schedule after communicating with my mentor. Any comment or advice is greatly appreciated. Thank you! [1]http://msdn.microsoft.com/en-us/library/9e7a57cf(v=vs.84).aspx [2]http://msdn.microsoft.com/en-us/library/t7zd6etz(v=vs.84).aspx [3]http://msdn.microsoft.com/en-us/library/3ca8tfek(v=vs.84).aspx [4]http://msdn.microsoft.com/en-us/library/10wcf65z(v=vs.84).aspx [5]http://bugs.winehq.org/show_bug.cgi?id=35441 [6]In the attachment [7]http://bugs.winehq.org/show_bug.cgi?id=34913 [8]http://bugs.winehq.org/show_bug.cgi?id=35472

March 20, 2014