wine-devel March 2004

wine-devel@winehq.org

128 participants
264 discussions

OT: How to patch?
by Fabian Cenedese 10 Mar '04

10 Mar '04

Hi Not directly wine related but I'm sure also useful to others. It was said on this list that the patches should be able to be applied with patch (-p1) patch.diff, hence the inlining in the mail. But the patch tool doesn't know anything about cvs. In the generated patch are infos about the diff'd versions. So for applying a patch in my view it would be best to update the sandbox to the version mentioned in the patch, apply the patch (which should work without error), then update to HEAD again. Because if you don't have the same file (maybe because the patch was from an older version) it won't apply anymore. I know that the unified format helps if there were small changes. Isn't there a way to do it with cvs? I mean it can generate diffs, maybe also apply (but I didn't find anything in the manual). Or general question: How do others work with patches? Always with the patch tool? Any switches I overlooked? (This problem came up as I'm trying to create and maintain a patch so it can be applied to the official distribution. But that's somehow useless if it won't work with newer versions than the one were the patch was created against, hence my idea with updating back and forth.) Thanks bye Fabi

1 0

Re: wine/. ANNOUNCE ChangeLog VERSION configure
by Vincent Béron 10 Mar '04

10 Mar '04

Le mar 09/03/2004 à 22:37, Alexandre Julliard a écrit : > ChangeSet ID: 11411 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/03/09 21:37:58 > > Modified files: > . : ANNOUNCE ChangeLog VERSION configure > > Log message: > Release 20040309. Unfortunately, I won't have time until the week-end to produce the binaries for various RH versions. Vincent

1 0

(fwd) Re: Serial port communication
by Rein Klazes 10 Mar '04

10 Mar '04

Hi, A bug reported in the users list. Because the reporter prefers just to work around the problem in his own code, I forward it here. In short: ReadFile reads a single byte alright from the serial port but at the same time returns an error GLE = ERROR_INVALID_PARAMETER. With multiple bytes there are no problems. There is a code snippet in the attached message. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: [DMUSIC] Improve dmusic loading
by Alexandre Julliard 10 Mar '04

10 Mar '04

Raphael <fenix(a)club-internet.fr> writes: > Changelog: > - debugstr_DMUS_OBJECTDESC more readable (not more limited to the 200 > characters of wine_dbg_sprintf) You should make it a separate dumping function instead of returning a single string, if the info is too large. Using a static buffer is not thread-safe. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: vsnprintf: glibc and win32 not compatible
by Jesse Allen 09 Mar '04

09 Mar '04

On Tue, Mar 09, 2004 at 01:45:59PM +0800, Jonathan Wilson wrote: > >Discovered an issue with null pointer passed for %s (Warcraft III likes to > >do that it seems). I handle it by printing "(null)". Other than that, it > >will > Have you made it do something usefull if the user passes a null for a wide > char string? (i.e. passes %S and a null string?) > (A reply to the list this time) OK, I have added %S and %C. They pretty much copy %s and %c. I have started to read through dlls/user/wsprintf.c to show me how it's really done. Though, it is not finished. So in the case if something asks for %S and gives a null pointer, it will do the same as %s and print "(null)". glibc does the same thing for %s and %ls. If anyone would like try the updated version they can download snprintf.c and snprintf.h, renamed since it implements snprintf now, from ftp://narf.dnip.net/ and copy it into dlls/msvcrt. Update Makefile.in and msvcrt.spec and it should work after that. But it it still very experimental and there is more to do. Jesse

1 0

Re: Contribution offer: Localization work
by Ivan Leo Murray-Smith 09 Mar '04

09 Mar '04

> Important: I did not want to change the sense of the original file. > Personally I think even bugs should be persistant between different > translations. ;-) Otherwise they would drift away from each other too > much (my opinion). On the other hand, I had to change some sections > slightly, as they would not make too much sense in german, could be > miss-interpreted or simply would sound ugly if translated very close to > the original. I don't know how the other translators handle this issue. As any latin student knows, you simply can't translate word by word, also you mustn't make a translation that sounds ugly. The important thing is that the file look as if it was written in the language you're translating to, not adapted from another one. Also, in computers it's important to use the same words that are already being used. For example, the italian translation of "Save file as" is "Salva file con nome" that literally means "Save the file with a name", so you can't translate literally, you have to use what is usually used for that functionality in other programs. Just go on as you have up to now. If you think something is wrong, send a patch that updates both the original and the translation. > If there is a translated Readme shouldn't there also be a translated licence > file? I'm sure there is already one translated available from GNU.org. Then > this should say LIZENZ instead of LICENSE. The GPL is licensed only for distribution without modification, you can't touch the GPL or the license information in any way shape or from. What you can do is add the translations released by the FSF, as long as you specify that the legally valid version is the english one.

1 0

unsubscribe banana67
by Andrew de Quincey 09 Mar '04

09 Mar '04

2 1

Re: Implement Drag List Control
by Dimitrie O. Paun 09 Mar '04

09 Mar '04

On March 9, 2004 2:20 pm, Robert Shearman wrote: > This patch adds full support for drag list common controls. There are no > known bugs, so as far as I am concerned this is 100% complete compared > to ComCtl32 v5.81 and probably v6.0 too. Nice! Now, to keep track of these things, I've added the following note to each of the controls that I have audited/fixed: * NOTE * * This code was audited for completeness against the documented features * of Comctl32.dll version 6.0 on Sep. 9, 2002, by Dimitrie O. Paun. * * Unless otherwise noted, we believe this code to be complete, as per * the specification mentioned above. * If you discover missing features, or bugs, please note them below. It would be nice to add something like this to the drag control as well (also, now that you have it fresh in your mind, maybe you can audit it against v6.0, as this is the version that I used for other controls). Take a look at dlls/comctl32/updown.c, dlls/comctl32/comboex.c, etc. for examples. -- Dimi.

1 0

Re: Wine as shared library patch
by Peter Dennis Bartok 09 Mar '04

09 Mar '04

Alexandre, et. al, Our WinMain doesn't get called because our patch prevents it. If it were to get called, we'd be on a different (Wine-created) stack, with all kinds of things that are hard to undo, like the exception handling, etc. The goal of my patch was to have minimal impact on Wine, and allow the *same* wine code/binaries to be used for regular use as well as shared library, so any future Wine version you create will automatically also support shared library use. I modeled the global __wine_shared_lib variable after the __wine_main_argX globals you introduced last year, assuming that following that style would create the least resistance of getting my patch accepted. Having Wine set up the TEB and stack environment and actually call our WinMain and us then trying to 'undo' that in WinMain creates potential for future breakage of our library, in case you change something related to the TEB & stack. Having a variable in kernel that prevents creation of these, on the other hand, is easy to maintain, and really has no impact on performance or coding. I will be happy to implement any suggestions you may have on how to solve it another way in a single codebase that doesn't intruce the potential of breaking it in the future. I may very well have overlooked something. Regards, Peter -----Original Message----- From: "Alexandre Julliard" <julliard(a)winehq.org> To: "Miguel de Icaza" <miguel(a)ximian.com> Cc: "Peter Dennis Bartok" <peter(a)novonyx.com>; "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk>; <wine-devel(a)winehq.org> Date: 07 March, 2004 17:37 Subject: Re: Wine as shared library patch >Miguel de Icaza <miguel(a)ximian.com> writes: > >> Well, the issue is that our WinMain is never called, and we would >> rather not depend on this in our patch, but instead get the small >> global that says `Hey Wine, just return'. > >The global variable thing is ugly; we could export a different entry >point instead, but I'm not sure it's really necessary. Why doesn't >your WinMain get called? > >-- >Alexandre Julliard >julliard(a)winehq.org > > >

6 12

statvfs breakage
by Gerald Pfeifer 09 Mar '04

09 Mar '04

I'm afraid the following change date: 2004/03/05 21:03:46; author: julliard; state: Exp; Use statvfs instead of statfs, and provide a default implementation in libwine_port if necessary. is not portable, as seen on FreeBSD 4.8: acrux[71]:/sw/test/wine/libs/port% make /sw/gcc-3.3.2/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o statvfs.o statvfs.c statvfs.c: In function `statvfs': statvfs.c:60: error: structure has no member named `f_namelen' Would you mind adding an autoconf test for that? (I saw that there are already a couple of those for statvfs.) Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 1

← Newer
1
...
18
19
20
21
22
23
24
...
27
Older →

Jump to page:

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 March 2004