wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

RE: Documentation fixes
by Patrik Stridvall 15 Feb '01

15 Feb '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > * dlls/winedos/dosvm.c, > > dlls/winedos/module.c: > > - Added documentation > > - Reorganized the no-DOS support. > > I don't think adding a #ifdef around each function is a good > idea. It's much more readable with a single #ifdef around the whole > file IMO. More readable to a human, perhaps. I'm not sure that I agree, but I don't really care much either way. Let me explain why I did it insteed. Currently winapi_check tried to check whether API functions have the correct inline documentation and the future some other application will generate the .spec files from inline documentation and function prototype. In order to be able to easily do this, it is IMHO much better if all the compile time depend variants is groups together in some standardized way in order for the tool to easily understand that variants exist and under what cirumstances they exist. But sure, we could easily add a kludge in both winapi_check and any future tools what just ignore any multiple occurance of an already documented function. It will be more errorprone but since this is quite rare perhaps it will not matter so much. Anyway, I don't really very much, so just say how want it: 1. Some way similar to mine (easily parsable structure) 2. Just kludge over this rare case (ignore multiple) 3. Some other way.

1 0

Re: VerQueryValue[A|W]
by James Hatheway 15 Feb '01

15 Feb '01

> > To convert an ASCII string to Unicode, you can use the > > function HEAP_strdupAtoW, as in: > Wrong ;-) Yeah, I know, Huw already set me straight on that. ^_^ > HEAP_str* is deprecated (the header file says so). > Use MultiByteToWideChar() or WideCharToMultiByte() instead. I'll admit I wrote the email when my brain wasn't quite working (by def'n anytime after 1am), thought to myself "what is that API again?", did a quick search in WINE, said to myself "oh HEAP_strdupAtoW" sent a quick email and went to bed. :) That teaches me to send email without thinking. But that gets me to my point. HEAP_strdupAtoW is used in this capacity 78 times in the WINE source tree (WtoA another 182 times). We should probably change it sometime, since a lot of people who are writing new code are sure to use the current code base as an example of "how to do things". Out of curiosity, why are we killing these macros? They seem quite convenient. If it is because they aren't in standard windows headers, can't we put them somewhere in include/wine? -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

1 0

Re: New EnumPrinterDataEx
by Alexandre Julliard 15 Feb '01

15 Feb '01

Ian Pilcher <pilcher(a)concentric.net> writes: > In theory, yes. But what about the case of a mistake on my part (or > the part of the person who implemented the underlying call)? We all > do everything possible to produce error-free code, but mistakes *do* > happen. IMHO the likelihood that your macros are going to introduce new bugs is larger than the likelihood that you are ever going to catch a legitimate failure from HeapFree(). Not to mention that there are already WARNs in the heap code that will catch the problem first, so your messages are redundant. Checking for errors is good if you actually handle failures; but if you don't do anything it just obscures the code for no good reason. -- Alexandre Julliard julliard(a)winehq.com

2 1

VersionInfo for built-in DLLs
by Dmitry Timoshkov 15 Feb '01

15 Feb '01

Hello all. This patch adds version information to the built-in GDI32.DLL. Attached test program now able to retrieve and display version information for both 32-bit and 16-bit modules. For instance "about.exe notepad.exe" will show information about 16-bit notepad, "about.exe gdi32.dll" - about built-in gdi32.dll. To do: Add 16-bit version information. Before I'll send it to wine-patches I would like to hear your comments and suggestions.

1 0

Re: VerQueryValue[A|W]
by Alexandre Julliard 15 Feb '01

15 Feb '01

lawson_whitney(a)juno.com writes: > AOL 5.0 does this, so I guess it is allowed by some flavors of windows. > > ChangeLog: > * dlls/version/info.c: > Lawson Whitney <lawson_whitney(a)juno.com> > If VerQueryValueA is called with a PE resource, cast the call > to VerQueryValueW. Shouldn't you convert the lpSubBlock string to Unicode first? -- Alexandre Julliard julliard(a)winehq.com

4 5

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall 15 Feb '01

15 Feb '01

> Patrik Stridvall wrote: > > > > One fly in the legal ointment is that while the headers may not be > > > copyrighable, the shrinkwrap license may still be legal > as a contract. > > > There's a case where a court suggested that someone who > buys a copy > > > of a product that contains a shrinkwrap license agreement > and unwraps > > > it is legally bound to follow it, while the person who > later finds the > > > unwrapped CD 'on the street' with no such license is > allowed to copy > > > the portions that are unprotected by copyright. > > > > If that is so, wouldn't it mean that if you have a pirated > copy of the > > headers > > you can legally copy and distribute parts that are > unprotected by copyright. > > :-) > > > > Oh, the irony of it all. You don't need to use a pirated copy either just borrow a friends computer that has the headers legally installed and copy any part unprotected by copyright. Any "contract" can only bind him. :-)

1 0

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall 15 Feb '01

15 Feb '01

> One fly in the legal ointment is that while the headers may not be > copyrighable, the shrinkwrap license may still be legal as a contract. > There's a case where a court suggested that someone who buys a copy > of a product that contains a shrinkwrap license agreement and unwraps > it is legally bound to follow it, while the person who later finds the > unwrapped CD 'on the street' with no such license is allowed to copy > the portions that are unprotected by copyright. If that is so, wouldn't it mean that if you have a pirated copy of the headers you can legally copy and distribute parts that are unprotected by copyright. :-) Anyway, you don't need to go to such extremes, since the legal status of shrinkwrap licenses in Europe is much more doubtful, just have somebody in Europe do it. I can't see why something posted on wine-patches shouldn't be equal with found on the street, in the meaning that things that is unprotected by copyright can be legally incorperated in the main tree. This is probably true regardless of the legal status of shrinkwrap licenses in Europe, especially since it is IMHO entire reasonable, given existing European cases, to assume that they don't have an legally meaning. > It's unclear where > the anti-trust issue fits in there. I pass, not my area of expertize. :-) > Food for thought, anyhow... Yes.

3 2

Re: process.h patch
by Alexandre Julliard 15 Feb '01

15 Feb '01

Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> writes: > Until we have MS style headers, at least declare msvcrt functions extern "C" > so C++ Winelib programs will link. > > I didn't get any feedback to my headers patch. Alexandre, what do I need > to do to get some headers into CVS? Or is that not the plan? Well, I don't know, I was hoping to get some feedback from the winelib experts out there on whether this is better than the approach with macros suggested by David. -- Alexandre Julliard julliard(a)winehq.com

6 7

Re: Re: recording sound=?iso-8859-1?Q?=3F?=
by Eric Pouech 15 Feb '01

15 Feb '01

>winmm wave recording is supposed to be supported, at least at the >low-level wave API level. Maybe less so at the MCI level, though, support at the MCI level should be more or less ok... (at least the Macadamiam folks did a great effort there) >and not >supported at all yet in the DirectSound layer. What kind of API does it >use to record these sounds? You don't say what kind of app it is... post the output of runnnig with the -debugmsg +wave,+mciwave,+dsound would help us pinpointing the issue A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

4 7

Re: Documentation fixes
by Alexandre Julliard 14 Feb '01

14 Feb '01

Patrik Stridvall <ps(a)leissner.se> writes: > * dlls/winedos/dosvm.c, > dlls/winedos/module.c: > - Added documentation > - Reorganized the no-DOS support. I don't think adding a #ifdef around each function is a good idea. It's much more readable with a single #ifdef around the whole file IMO. -- Alexandre Julliard julliard(a)winehq.com

1 0

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