wine-devel January 2009

wine-devel@winehq.org

149 participants
339 discussions

Re: re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode
by Uwe Bonnes 25 Jan '09

25 Jan '09

>>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> That's how we used to do it, but tests showed that _filbuf really Dan> has to do the cr removal. Dan> On Jan 25, 2009 10:57 AM, "Uwe Bonnes" < Dan> bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> I'll have a look... Dan> For me it looks like our whole black magic handling for the CR Dan> removal in read_i() is wrong. Probably _filbuf() should fill the Dan> buffer as is, only fget(w)c() should skip CR in text mode and Dan> fread() in binary mode should use unaltered chunks of _filbuf() in Dan> binary mode and iterate through _filbuf() in text mode, skipping Dan> CR. Could it be that _filbuf also skips CR as return value in text mode? B.t.w., for a file like "\\r\\r\\r\\nEOF", native _filbuf returns 0x0d... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

returned status 2
by gnuoytr＠rcn.com 25 Jan '09

25 Jan '09

I was able to install some packages, but this and mdac27 can't find itself. The file is there.??? ubuntu 8.10 wine 1.1.13 I was able to install all packages needed on ubuntu 6.06 wine 1.0.1; different machine. thanks, Robert Location: http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer… [following] --2009-01-25 15:12:46-- http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer… Resolving ufpr.dl.sourceforge.net... 200.236.31.1, 200.17.202.1 Connecting to ufpr.dl.sourceforge.net|200.236.31.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 882263 (862K) [application/x-msdos-program] Saving to: `BZEditW32_1.6.5_Installer.exe' 100%[==========================================================================================>] 882,263 110K/s in 15s 2009-01-25 15:13:02 (57.7 KB/s) - `BZEditW32_1.6.5_Installer.exe' saved [882263/882263] Executing wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe wine: cannot find '/home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' Note: command 'wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' returned status 2. Aborting.

2 1

Talk at Google, "the Wine user experience"
by Owen Rudge 25 Jan '09

25 Jan '09

Hey all, I've been a bit quiet as of late with uni work and so on, but figured I'd let you guys know that I was visiting Google in Mountain View on Thursday, and while there gave a tech talk on "Windows Meets Linux: the Wine user experience" - basically going over some of the issues with getting Wine out to users, ensuring a smooth experience for these users, and the challenges involves in this. It seemed to be well-received, and the talk is now up on YouTube: http://uk.youtube.com/watch?v=5E2HDQw4xmM Cheers! -- Owen Rudge http://www.owenrudge.net/

1 0

re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode
by Dan Kegel 25 Jan '09

25 Jan '09

I'll have a look...

1 0

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64
by Dmitry Timoshkov 25 Jan '09

25 Jan '09

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > +/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of the structure > + * is the same as of TBBUTTON */ > typedef struct > { > INT iBitmap; > @@ -96,6 +98,9 @@ typedef struct > BYTE fsStyle; > BYTE bHot; > BYTE bDropDownPressed; > +#ifdef _WIN64 > + BYTE bReserved64[4]; > +#endif > DWORD_PTR dwData; > INT_PTR iString; > INT nRow; Then probably it would make sense to make TBBUTTON the first member of the above structure. That would help in avoiding possible layout problems in future. -- Dmitry.

3 5

A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Guillaume SH 25 Jan '09

25 Jan '09

Hi wine team, First let me thank you for providing wine software witch I see as a strong asset in the expansion of free software and as a useful tool for people (like me) already using free software wherever possible. At this point, Wine is at a very good level both in API coverage, quality (less and less hack, more and more nice and clean solutions) and efficiency. Reaching that level required a tremendous work in all kinds of domains (implementation, coordination, patch value judgment, test suite...). In this regard I want to thank you again and congratulate you all guys, what you have done so far is quite an achievement. This week however I was quite puzzled by one commit : "kernel32: Make GetOverlappedResult crash on NULL args as native does."(1) As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. Thinking about it I see only one argument justifying it's the good direction : for the sake or portability from wine to windows platforms. For example, a firm using wine on a free-OS platform, for software development with a Windows target platform. Relying on this assertion (which someone may demonstrate me to be false, secondary or incomplete), I'm afraid that wine take a step in the wrong direction from what seems to me the third major reason to switch from non-free OS platform (typically Windows) from free-OS platform. Those 3 main reasons are for me : 1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them) 2 - Free from charge 3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered) To summarize, I'm stating that removing the clean and safe way to handle NULL parameters in this function to fall back to bad and dirty crash, exposing security issue for user (a software can be created specifically by a ill-intentioned one to exploit this defect), all for the sake of being as bad as Windows is, is a step in the wrong direction. I feel sad enough about it, and I think it can prevent advertised people to use it but above all to recommends Windows user to go for free-OS platform with usage of wine for their needs not covered by free-software (like proprietary format). Nevertheless, just as I said, I'm still very enthusiast about wine and still think it's great and very useful. I will continue to use it, promote its usage when suitable, and also warn about its known defects people around me. Guillaume (1) for reference : 32cc4011ee04046d41a41549d5a6a6233647f756 from 22/01/2009 PS : I am fully aware that free software have defects too, some of them being security issue. I am also aware, that in a software as huge as wine, reaching even a medium security level is a real strong challenge, increased by the defects in Windows API design. I am also fully aware that security is a process, not a product.

4 4

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Ben Klein 25 Jan '09

25 Jan '09

2009/1/26 Guillaume SH <gsh.debianlists(a)gmail.com>: > I will be my last mail though because I understood that there is a > consensus that wine shouldn't be a safe and good tool enabling > transition from Windows to free-OS, but rather a tool with a > not-so-clear goal (again I'm not willing to start flaming, so please > don't). Wine's goal is perfectly clear: to provide, as best as possible, a complete and accurate implementation of win32 (and win64 long-term) and related APIs. If putting invalid data into a specific function causes a known crash on the only other implementation of win32 (Microsoft Windows), especially considering that win32 is standardised by the same company that produces Windows, it can be assumed that the crash is the correct behaviour and Wine should emulate it. >>> 1 - Freedom (possibility to browse sources, self-compile from sources >>> and even modifying them) >> >> This one commit does not making the source any less open. > I totally agree : this the first reason i evoked and it is 100% reached by wine > >>> 2 - Free from charge >> >> This one commit does not put a price tag on Wine. > I totally agree : this is the second reason I evoked and it is 100% > reached by wine > >>> 3 - Communicating openly about known defects in software, fixing >>> defects without respects for commercial stakes (ex: hide bug until the >>> xxth release, or not fixing a known bug until it is publicly >>> discovered) > I agree that wine doesn't try to hide defect, but Microsoft is, and > copycatting Microsoft behavior is like being accomplice of its silence > and lack of actions Microsoft's defect, if not already documented, has been revealed by this patch. It's not something they're likely to fix. If they fix it, then a matching fix has to go in Wine at some point (which could be interesting due to different behaviour on different Windows versions). Until they fix the bug and update win32 specifications to match, crashes directly caused by the commit in question are expected and can be assumed to be correct. > Regarding the security part, I am full aware of the facts you stated, > and this is a point that's dooming wine to have less success than It > could have. No, it's dooming Wine to have more success than it should have. Big difference. In implementing win32 API, Wine inherently opens up *nix to a whole new world of malware. Sure, it still needs to be explicitly run by the user, sure there is "wineserver -k" and "rm -rf ~/.wine", but that won't stop spyware, trojans, worms etc. completely. And it shouldn't, because if Wine attempts to stop malware, then legitimate applications will surely suffer too. Not to mention legitimate software that *acts* like malware, e.g. punkbuster :) > You are an intelligent man Ben, I happy to exchange with such a man. Lies, all lies! But thank you nonetheless.

2 2

A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Guillaume SH 25 Jan '09

25 Jan '09

Hi Dimitry, Thank you very much for bringing this explanation to my knowledge. As you name came over and over through wine-devel list, I am aware that you are an experimented and influential member within wine community (which make a huge difference with me, as this is the first time I try to bring a contribution to wine(1) ), so I will consider this explanation as the way most involved wine people are considering things up. The most interesting part in your answer is indeed this word of "Behaviour" you used. Indeed, in my understanding (but maybe "I am hoping" is more correct here) wine's goal is to provide the same functionalities as Windows API, not to implement those functionalities C statement for C statement with respect to Window's ones. Two reason comes to my mind : 1 - Just copycatting Windows implementation would brought wine very close to plagiarism, thus legally threaten is mere existence 2 - Obviously, Windows implementation is not always the most efficient nor the most secure, due to commercial stakes (release schedule, financial arbitrations...) Regarding the part of your mail where you wrote : "that's actually good that applications crash when they pass invalid data", I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back. Don't misunderstand me here, I'm not insulting you neither I'm not saying that I am better than you nor I'm not trying to start a flaming thread. I respect the assertion you stated, but honestly and deeply fail to understand why is it correct. Guillaume (1) Talking openly and honestly about a subject that may be considered a problem is a way of contributing, less concrete than patches, but real too.

5 4

Re: [2/3]: winemenubuilder: generate fd.o MIME and file type associations
by Frank Richter 25 Jan '09

25 Jan '09

On 24.01.2009 12:03, Damjan Jovanovic wrote: > +static char* wchars_to_unix_chars(LPCWSTR string) > +{ > + char *ret; > + INT size = WideCharToMultiByte(CP_UNIXCP, 0, string, -1, NULL, 0, NULL, NULL); Since that is used to write fd.o desktop and mime files: double-check the respective specs, I believe they mandate UTF-8 as the character encoding. UNIXCP isn't necessarily UTF-8. -f.r.

2 1

Updated testing DIB Engine
by Massimo Del Fedele 24 Jan '09

24 Jan '09

I did some update on the engine, I tried to post it here as a zipped patch, but didn't got published.... So I've put it on bug 421 page with instructions on how to use it. I'd like to have some feedback if the implementation way is the right one. Ciao Max

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2009