wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

Re: GetPrivateProfileInt*() fix
by Alexandre Julliard 21 Jan '02

21 Jan '02

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > these functions were pretty much broken (overflow and signed/unsigned > behaviour), so I fixed almost every problem. Why did you add an exception handler? Do you have an app that passes garbage pointers to GetPrivateProfileInt? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Unnecessary imports?
by Ove Kaaven 21 Jan '02

21 Jan '02

On Mon, 21 Jan 2002, Francois Gouget wrote: > Compiling Wine I noticed many warnings saying that the dlls we import > are not used. Is there any reason to still import them? I suppose it could in many cases be because someone *plan* to import stuff from there sometime later (after they've churned out some code to fill the stubs in the dll implementation with)...

3 2

Re: struct async-private - now tested and cleaned up
by Mike McCormack 21 Jan '02

21 Jan '02

Hi Martin, Each DLL should only import standard win32 api functions exported by other (lower level) DLLs. Where possible, the code should be able to be compiled and run on a windows box. (ok, that excludes kernel, gdi, user, winsock, etc). That is necessary to support dll=native linking. In theory, we should only have to implement ntdll and the device driver interfaces, then Microsoft's kernel, gdi, user, etc. would all run on top of those too. Practically, some of our low level DLLs need the wineserver interface. Your client side register_async() func should be present in all the dlls that use it because Windows has no equivilent export from NTDLL (or any other dll). Maybe you could create an inline function in a header? My guess is that WinNT implements WSARecv() and ReadFile() using something like NtReadFile(). http://www.osr.com/ntinsider/1996/native.htm Mike > On 16 Jan 2002, Alexandre Julliard wrote: > > > Also note that because of dll separation you cannot use functions like > > register_async() from winsock. If absolutely necessary they could be > > exported, but I think it would be much better to use straight server > > calls (and in theory these functions shouldn't be used from comm.c > > either). > > Hmm. I guess I don't fully understand dll separation. Are you telling me > that the scheduling mechanism for async requests shouls be implemented > separately in each DLL? If so, I could have spared my efforts to build > a "generic" interface to async requests. I'd just mention that > this would be error-prone, because different parts of wine with > equivalent functionality would need to be maintained. Note > that an app is allowed to mix ReadFile() and WSARecv() calls > for a socket (however braindead that would be). I'd assume that > in Windows there must be a hidden layer for asynchronous requests > somewhere, too, or do you think their respective code is completely > separate? ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

MapVirtualKeyExA fixme
by John Atkinson 21 Jan '02

21 Jan '02

I've been using an app that the shortcut keys don't work, I get the following messages. fixme:keyboard:MapVirtualKeyExA (17,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (68,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (18,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (90,0,0x04090409), hkl unhandled! Does anyone know how to fix this type of problem. TIA

1 0

Re: small configure patch
by Andreas Mohr 21 Jan '02

21 Jan '02

On Sun, Jan 20, 2002 at 09:49:49PM +0100, Ove Kaaven wrote: > Log: > Andrew Lewycky <andrew(a)transgaming.com> > Ove Kaaven <ovek(a)transgaming.com> > Check for common broken nVidia+Mesa OpenGL library setups. > Add some quoting. > > Index: wine/configure.in > diff -u wine/configure.in:1.1.1.25 wine/configure.in:1.50 > --- wine/configure.in:1.1.1.25 Wed Jan 16 10:58:58 2002 > +++ wine/configure.in Fri Jan 18 09:28:22 2002 > @@ -253,6 +281,14 @@ > ) dnl *** End of X11/Xlib.h check > > dnl Check for the presence of OpenGL > + > + if test -e /usr/X11R6/lib/libGL.a -a ! -e /usr/X11R6/lib/libGL.so > + then > + AC_MSG_ERROR( > +[/usr/X11R6/lib/libGL.a is present on your system. > +This prevents linking to OpenGL. Delete the file and restart configure.]) > + fi Umm, doesn't this get cached in config.cache ? Shouldn't we therefore add to delete config.cache before restarting, too ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

Fix for the web site (WineHQ)
by Francois Gouget 21 Jan '02

21 Jan '02

This fixes a bug in the Web site: a pre tag was not closed properly. Changelog: * dev.shtml Fix a mis-closed <pre> tag -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

3 2

Re: struct async-private - now tested and cleaned up
by Alexandre Julliard 21 Jan '02

21 Jan '02

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > It is a polished resubmit of my former posting, without the GetOverlappedResult() stuff > which will follow in a separate patch. It is against clean CVS 2002-01-15. > > I would be really grateful if this patch was applied, because it is a prerequisite for me to > get going with Winsock2 overlapped IO. The comm.c part doesn't apply, are you sure this is against a clean CVS? You should probably consider using cvs diff, it helps making sure you do the diff against the right file. Also note that because of dll separation you cannot use functions like register_async() from winsock. If absolutely necessary they could be exported, but I think it would be much better to use straight server calls (and in theory these functions shouldn't be used from comm.c either). -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: SetEndOfFile fix
by Andreas Mohr 21 Jan '02

21 Jan '02

On Sun, Jan 20, 2002 at 08:13:53PM +0100, Rein Klazes wrote: > hi, > > This fixes office 97 MSword error (disk full or write protected) when > saving files on a vfat partition. MSword calls SetEndOfFile() which > uses ftruncate() that, in Linux, cannot grow files in this filesystem. Ah ! :-))) I already suspected this to be the case. At least I already found due to some error code that some ftruncate() must have failed, and I think I thus called it an ftruncate problem. Oh, and yes, that error condition was in the server, too, so it must have been this ftruncate. And one more: In several cases, some guys reported that programs needed some "touch"ing before being able to save a file. What do you wanna bet that *this* is the problem that's now solved ?? :) In short: a very important fix, I think. I guess we can call you a Wine Master now ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re: SetEndOfFile fix
by lawson_whitney＠juno.com 20 Jan '02

20 Jan '02

On Sun, 20 Jan 2002, Rein Klazes wrote: > hi, > > BTW. A google search shows that the ftruncate problem has been > mentioned at least 3 times on c.e.m.w. in the last 6 months Since > nobody entered a fix, I could be overlooking something... Not exactly, I think. I remember several mentions of MSword (disk full or write protected), but nobody called it an ftruncate problem. I did think up some other rather ingenious ways you could misconfigure a fat filesystem to cause wine to be unable to save a file, but I missed ftruncate. I thought ftruncate only didn't work with umsdos, but I see I was wrong. I think you have just been paying better attention than some others of us. Good catch! > > Rein. > Lawson

1 0

Re: Questions for developing functions
by David Elliott 20 Jan '02

20 Jan '02

On 2002.01.20 12:46 Gerhard W. Gruber wrote: > On Sun, 20 Jan 2002 11:38:48 -0500, David Elliott <dfe(a)tgwbd.org> wrote: > > >Well, if the code you contribute could be considered a derived work of > the > >code you disassembled then you'd have problems. But for instance if you > > >disassembled for the purposes of figuring out how many arguments the > >function takes and what not but didn't actually directly write your code > > >based on the disassembly, then you should be in the clear as far as that > > >is concerned. > > Of course I primarily use that insight to get information on what > arguments > are used. I don't intend to make a 1:1 representation of the binary code > to C. > :) > > >Now, as for the breaking of the license agreement on your software. > That > >mostly concerns you as you are the person under the license, not the > Wine > >project. So if you feel like you would get into legal trouble by even > >disassembling something to simply see what types of parameters it takes, > > >then I would suggest that you didn't do it. However if you feel that > you > >would not get into legal trouble, and assuming you don't create your > >implementation directly from the disassembly (i.e. you reimplement from > >scratch, but just use the disassembly to get some ideas of function > >parameters) then you should be very much in the clear, and so should the > > >wine project. > > Thanks. :) > Remember though.. I am not a lawyer, and I am not Alexandre Julliard. > >Hey man, if no one responds in this mailing list within a reasonable > >timeframe then probably no-one is working on it. Just have a go and if > >someone else beats you to it without saying anything you can always do a > > >peer-review of the code and see if maybe something should be done > >different. Two pairs of eyes are better than one. > > OK. Sorry to bother you with this, but I'm just starting out, so I don't > know > much about the procedure on how to contribute a bit. :) I'd also hate to > start > investingating when a few days later a patch is thrown at the list that > does > what I just started out to do. :) I also think that it wasted time on > behalf > of wine if many developers work on the same things and leave other areas > to > its own. > No, it's not a bother.. the fact that you just posted saying that you were gonna work on it is desirable. -Dave

1 0

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