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

Re: msvcrt/tests: convert file to UTF-8

by Austin English

2010/5/30 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > On Mon, May 31, 2010 at 00:23, Austin English <austinenglish(a)gmail.com> wrote: >> -- >> -Austin > > Not sure about it, but shouldn't this file stay in CP1252? > After all the specific locale is tested using CP1252 no? Hm, yeah. I hadn't meant to send this patch yet anyway, it's not correct (and after running make test, it fails). Please ignore, thanks. -- -Austin

May 30, 2010

Re: msvcrt/tests: convert file to UTF-8

by Frédéric Delanoy

On Mon, May 31, 2010 at 00:23, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin Not sure about it, but shouldn't this file stay in CP1252? After all the specific locale is tested using CP1252 no? Frédéric

May 30, 2010

Re: comdlg32: Fix Italian translation

by Matteo Bruni

> - LTEXT "File di &Tipo:", 1089, 6, 104, 90, 9 > + LTEXT "&Tippo del file:", 1089, 6, 104, 90, 9 One 'p' is enough :). More importantly, this and the shell32 patch have mangled accented letters (maybe the conversion to UTF8 didn't work out well?). No problems in the taskmgr patch though. By the way, thank you for your translations!

May 30, 2010

Re: msvcrt/tests: convert file to UTF-8

by testbot＠testbot.winehq.org

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=2395 Your paranoid android. === WINEBUILD (build) === Make failed

May 30, 2010

Re: Allowed reverse engineering methods

by Roderick Colenbrander

>> But which methods are allowed? I assume that "obvious" >> methods (reading header files, registry dumps, etc.) are >> acceptable, but can I e.g. analyze .pdb symbol files >> (availble in e.g. Microsoft's DirectX SDK)? >> >> > > You can do the above as long as they are readily available. The .pdb files > are accessible to all, then you can use them. If you have to copy them from > a running Windows installation, they are not. > .pdb files should not be used. For instance they show internal data structures, internal functions and much more. Stay away from them. Roderick

May 30, 2010

Re: RFC: msvcrt: support dates after year 2038 in mktime64

by James McKenzie

Robert Wilhelm wrote: > Hello James, > > seems I should better send patches as attachments. > http://testbot.winehq.org/JobDetails.pl?Key=2393 was more successfully. > > I am not sure I got your question. > On 64bit unix systems (which have 64bit time_t), mktime() will support > dates after year 2038. There is no need for my patch. > > Windows has mktime and _mktime64() already for ages. See > http://en.wikipedia.org/wiki/Year_2038_problem > I think I know your confusion here. Does UNIX and Windows implement these functions for the same date range or should we be rejecting a set of dates as being invalid? > Is it currently a problem to use gmx.net to send email to winehq? > I could use my googlemail acount instead. > > No. Please use your gmx.net account. Wine developement and Wine patches will accept it. I had blacklisted this ISP but I have removed them from the list as I have received no spam from them in a long time (there may have been a compromised computer or two that was sending stock 'pump and dump' messages to several Earthlink.net addresses.) Also, please bottom post or interleave post. Top posting makes message flow very hard to read. James McKenzie

May 30, 2010

Re: Allowed reverse engineering methods

by James McKenzie

Mariusz Pluciński wrote: > Hello > I'm working on implementation of Games Explorer for Wine > (in Google Summer of Code). My work gets progress, but to > finish it, I need to get more information about Windows > implementation. > > My question is: which reverse engineering methods are > legal and accepted while working in Wine project? > Only information I found is located on Wine's wiki page > (http://wiki.winehq.org/SummerOfCode) > > >> * You are not allowed to read or reuse Windows source code >> (leaked source / Windows >Research Kernel* / ...) >> (* we are following the SFLC's advice) >> * You are not allowed to reverse engineer Windows files by >> disassembling or >decompiling them >> * You are not allowed to analyze Windows files with the >> trace functions of Wine >> > > These are just the start. Any 'black box' method would be considered legal. So, you can go to MSDN, find the function and then run that function as a conformance test against the .dll that provides the function. For instance, a few others and I are working on the EM_FORMATRANGE function as provided in riched20.dll. We first wrote some tests that comply with what is in MSDN, and these tests are in /dlls/riched20/tests/editor.c. We then implemented code that reproduced these tests and gave the same result. However, this did not implement the full functionality of the the call. So, we wrote more tests, ran them against the .dll and retrieved the output. We then implemented more code to reproduce the call. This cycle should continue until: 1. You run out of test cases. 2. You cannot go any further in your implementation (that means all test cases are covered and all of the intended functions are implemented). Under NO circumstances are you to 'look under the hood' or to examine dll code directly. > But which methods are allowed? I assume that "obvious" > methods (reading header files, registry dumps, etc.) are > acceptable, but can I e.g. analyze .pdb symbol files > (availble in e.g. Microsoft's DirectX SDK)? > > You can do the above as long as they are readily available. The .pdb files are accessible to all, then you can use them. If you have to copy them from a running Windows installation, they are not. > Can I copy executable from Windows (.exe) and analyze it in Wine > using winedebug's "relay" channel? (last point from website > I linked above says that I can't analyze "Windows files" this way, > but I'm not sure is it apply for executables in way I described). > > If you have a program that is available, you can analyze what Wine's code is doing. You cannot substitute in a Windows native dll and do this. Again, anything that is allowed in black box is allowed in Wine. So, if a program expects input A and Wine's code gives input B, then you have to figure out what needs to be added without looking at code and how Windows implements a certain function. One thing is that you can look on the web for hints and tricks (they have to be evaluated very closely as if they are partial/complete traces of Windows functions, then they are not allowed as these are not 'black box'.) I know this is not very clear, but what are you trying to do and maybe we can give you hints and advice on where to go next. James McKenzie

May 30, 2010

Re: Allowed reverse engineering methods

by Nikolay Sivov

On 5/30/2010 21:41, Mariusz Pluciński wrote: > Hello > I'm working on implementation of Games Explorer for Wine > (in Google Summer of Code). My work gets progress, but to > finish it, I need to get more information about Windows > implementation. > Hi, Mariusz. > My question is: which reverse engineering methods are > legal and accepted while working in Wine project? > Only information I found is located on Wine's wiki page > (http://wiki.winehq.org/SummerOfCode) > > >> * You are not allowed to read or reuse Windows source code >> (leaked source / Windows>Research Kernel* / ...) >> (* we are following the SFLC's advice) >> * You are not allowed to reverse engineer Windows files by >> disassembling or>decompiling them >> * You are not allowed to analyze Windows files with the >> trace functions of Wine >> > But which methods are allowed? I assume that "obvious" > methods (reading header files, registry dumps, etc.) are > acceptable, but can I e.g. analyze .pdb symbol files > (availble in e.g. Microsoft's DirectX SDK)? > The main method is to write test. Reading headers is allowed of course, the rule here is not to copy code blocks from them to Wine's headers. Clean way is to study, then close it and write it itself. Windows registry editor doesn't hide things AFAIK, so you obviously can read keynames, default values etc. Wine uses same namings for keys for compatibility reasons, so that's allowed. I don't know what kind of information is store in .pdb files, but assuming it's a private binary format for machine consumption I think you should avoid it. > Can I copy executable from Windows (.exe) and analyze it in Wine > using winedebug's "relay" channel? (last point from website > I linked above says that I can't analyze "Windows files" this way, > but I'm not sure is it apply for executables in way I described). > It depends what executable are you talking about. If it's your program but linked (or uses) to a module you're testing AND this native module is setup to be used by Wine - then no, you can't. In general Wine's tracing functionality shouldn't be used to get inside native modules provided by MS to re-implement them. Often it happens that users do +relay by request for bug reports for example, I believe this is fine as long as you don't use this trace data to implement module. > Mariusz Pluciński >

May 30, 2010

Re: RFC: msvcrt: support dates after year 2038 in mktime64

by Robert Wilhelm

Hello James, seems I should better send patches as attachments. http://testbot.winehq.org/JobDetails.pl?Key=2393 was more successfully. I am not sure I got your question. On 64bit unix systems (which have 64bit time_t), mktime() will support dates after year 2038. There is no need for my patch. Windows has mktime and _mktime64() already for ages. See http://en.wikipedia.org/wiki/Year_2038_problem Is it currently a problem to use gmx.net to send email to winehq? I could use my googlemail acount instead. Regards, Robert On Sun, 2010-05-30 at 10:23 -0700, James McKenzie wrote: > (Marvin) wrote: > > 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=2394 > > > > Your paranoid android. > > > > > > === WINEBUILD (build) === > > Patch failed > > > > > > > > > One question on this patch: > > Does this duplicate activities within Vista/Windows7 (the only versions > of Windows Retail that have 64 bitness)? > > I had blocked out your ISP due to a large amount of unsolicited messages > asking me to sign up with them. > > James McKenzie

May 30, 2010

Re: kernel32 nls file codepage conversion

by Michael Stefaniuc

On 05/30/2010 06:05 PM, Frédéric Delanoy wrote: > 2010/5/30 Dmitry Timoshkov<dmitry(a)codeweavers.com>: >> Frédéric Delanoy<frederic.delanoy(a)gmail.com> wrote: >> >>> I'm intending to convert dlls/kernel32/nls/fr.nls from CP 1252 to CP >>> 65001 (UTF-8), >> >> Is there a ny reason behind that? > > Uniformisation? Universality? All other rc files (at least Fr ones, > and most of the others) have already been > converted. Yeah, go ahead. There are already a few nls file in UTF-8. It would be good to have only one codepage used throughout the Wine code and UTF-8 is the way to go. Alexandre isn't opposed to this but the translators have to do/request it. >>> but I've some questions first: >>> - most nls files are non-UTF8... is it intended? or just "legacy"? >> >> nls files in Wine use Windows code page appropriate for the language >> in that file, which a resource compiler understands, and which can be >> corerctly converted to unicode. > > So it can be in any code page, provided the #pragma codepage is set > accordingly I guess? Well, all the codepages that provide the needed characters ;) >>> - can LOCALE_IDEFAULTANSICODEPAGE be set to 65001 or should it be left >>> at its current "1252" value, i.e. is it necessary for compatibility >>> with older win versions where UTF-8 is not the default (correct me if >>> I'm wrong)? >> >> Noone Windows version uses UTF-8 for locales. LOCALE_IDEFAULTANSICODEPAGE >> must be set to the ANSI code page used by Windows for that laguage (i.e. >> leave it alone). > > OK. If I understand correctly, the codepage of the nls file is > orthogonal to that of LOCALE_IDEFAULTANSICODEPAGE? Yes. >>> - LOCALE_SCURRENCY is set to char code 80 (<80> in vim). What is that >>> exactly? The code for the euro sign in a specific code page? which >>> one? >> >> The code page the file uses (1252 for fr.nls). > > OK Yeah, most editors and afair file too misinterpret CP1252 as ISO-8859-1; they are very similar but not the same. Using UTF-8 "fixes" this. bye michael

May 30, 2010