wine-devel

wine-devel@winehq.org

11 participants
84461 discussions

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

Some strange exception crash
by Lionel Ulmer 14 Feb '01

14 Feb '01

Hi all, While trying to debug DMute (http://www.mrao.cam.ac.uk/~gg215/dm/), I get the following crash : Call kernel32.674: SetUnhandledExceptionFilter(0042a8a0) ret=0042a898 fs=008f Ret kernel32.674: SetUnhandledExceptionFilter() retval=00000000 ret=0042a898 fs=008f (...) Call kernel32.473: InterlockedDecrement(fffffff4) ret=00438683 fs=008f trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 trace:seh:EXC_CallHandler calling handler at (nil) code=c0000005 flags=0 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 trace:seh:EXC_CallHandler calling handler at 0x4005ac40 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at (nil) code=c0000005 flags=10 And it never stops.... It does a segfault when not using --debugmsg +seh. So I am wondering why the exception handler is set to 'NULL' at this point (I am also wondering where that damn application got the 'fffffff4' to use as a 'mutex', but that is another problem :-) ). Anyone has a clue ? Lionel -- Lionel Ulmer - lionel.ulmer(a)free.fr My Advogato Wine diary : http://www.advogato.org/person/bbrox/

1 0

Re: Registry patch
by Alexandre Julliard 14 Feb '01

14 Feb '01

davep <davep(a)cyw.uklinux.net> writes: > > Could you please send me a +reg,+server trace of the offending calls? > > Attached. Thanks; does this fix it? Index: dlls/advapi32/registry.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/advapi32/registry.c,v retrieving revision 1.20 diff -u -r1.20 registry.c --- dlls/advapi32/registry.c 2001/01/06 01:29:18 1.20 +++ dlls/advapi32/registry.c 2001/02/13 22:11:00 @@ -447,6 +447,7 @@ return ERROR_INVALID_PARAMETER; status = NtQueryKey( hkey, KeyFullInformation, buffer, sizeof(buffer), &total_size ); + if (status && status != STATUS_BUFFER_OVERFLOW) goto done; if (class) { @@ -460,32 +461,30 @@ status = NtQueryKey( hkey, KeyFullInformation, buf_ptr, total_size, &total_size ); } - if (!status) + if (status) goto done; + + if (class_len && (info->ClassLength/sizeof(WCHAR) + 1 > *class_len)) { - if (class_len && (info->ClassLength/sizeof(WCHAR) + 1 > *class_len)) - { - status = STATUS_BUFFER_OVERFLOW; - } - else - { - memcpy( class, buf_ptr + info->ClassOffset, info->ClassLength ); - class[info->ClassLength/sizeof(WCHAR)] = 0; - } + status = STATUS_BUFFER_OVERFLOW; + } + else + { + memcpy( class, buf_ptr + info->ClassOffset, info->ClassLength ); + class[info->ClassLength/sizeof(WCHAR)] = 0; } } + else status = STATUS_SUCCESS; - if (!status || status == STATUS_BUFFER_OVERFLOW) - { - if (class_len) *class_len = info->ClassLength / sizeof(WCHAR); - if (subkeys) *subkeys = info->SubKeys; - if (max_subkey) *max_subkey = info->MaxNameLen; - if (max_class) *max_class = info->MaxClassLen; - if (values) *values = info->Values; - if (max_value) *max_value = info->MaxValueNameLen; - if (max_data) *max_data = info->MaxValueDataLen; - if (modif) *modif = info->LastWriteTime; - } + if (class_len) *class_len = info->ClassLength / sizeof(WCHAR); + if (subkeys) *subkeys = info->SubKeys; + if (max_subkey) *max_subkey = info->MaxNameLen; + if (max_class) *max_class = info->MaxClassLen; + if (values) *values = info->Values; + if (max_value) *max_value = info->MaxValueNameLen; + if (max_data) *max_data = info->MaxValueDataLen; + if (modif) *modif = info->LastWriteTime; + done: if (buf_ptr != buffer) HeapFree( GetProcessHeap(), 0, buf_ptr ); return RtlNtStatusToDosError( status ); } @@ -502,7 +501,7 @@ NTSTATUS status; char buffer[256], *buf_ptr = buffer; KEY_FULL_INFORMATION *info = (KEY_FULL_INFORMATION *)buffer; - DWORD total_size; + DWORD total_size, len; TRACE( "(0x%x,%p,%ld,%p,%p,%p,%p,%p,%p,%p,%p)\n", hkey, class, class_len ? *class_len : 0, reserved, subkeys, max_subkey, values, max_value, max_data, security, modif ); @@ -511,6 +510,7 @@ return ERROR_INVALID_PARAMETER; status = NtQueryKey( hkey, KeyFullInformation, buffer, sizeof(buffer), &total_size ); + if (status && status != STATUS_BUFFER_OVERFLOW) goto done; if (class || class_len) { @@ -524,39 +524,37 @@ status = NtQueryKey( hkey, KeyFullInformation, buf_ptr, total_size, &total_size ); } - if (!status) - { - DWORD len = WideCharToMultiByte( CP_ACP, 0, - (WCHAR *)(buf_ptr + info->ClassOffset), - info->ClassLength/sizeof(WCHAR), - NULL, 0, NULL, NULL ); - if (class_len) - { - if (len + 1 > *class_len) status = STATUS_BUFFER_OVERFLOW; - *class_len = len; - } - if (class && !status) - { - WideCharToMultiByte( CP_ACP, 0, - (WCHAR *)(buf_ptr + info->ClassOffset), - info->ClassLength/sizeof(WCHAR), - class, len, NULL, NULL ); - class[len] = 0; - } - } - } + if (status) goto done; - if (!status || status == STATUS_BUFFER_OVERFLOW) - { - if (subkeys) *subkeys = info->SubKeys; - if (max_subkey) *max_subkey = info->MaxNameLen; - if (max_class) *max_class = info->MaxClassLen; - if (values) *values = info->Values; - if (max_value) *max_value = info->MaxValueNameLen; - if (max_data) *max_data = info->MaxValueDataLen; - if (modif) *modif = info->LastWriteTime; - } + len = WideCharToMultiByte( CP_ACP, 0, + (WCHAR *)(buf_ptr + info->ClassOffset), + info->ClassLength/sizeof(WCHAR), + NULL, 0, NULL, NULL ); + if (class_len) + { + if (len + 1 > *class_len) status = STATUS_BUFFER_OVERFLOW; + *class_len = len; + } + if (class && !status) + { + WideCharToMultiByte( CP_ACP, 0, + (WCHAR *)(buf_ptr + info->ClassOffset), + info->ClassLength/sizeof(WCHAR), + class, len, NULL, NULL ); + class[len] = 0; + } + } + else status = STATUS_SUCCESS; + + if (subkeys) *subkeys = info->SubKeys; + if (max_subkey) *max_subkey = info->MaxNameLen; + if (max_class) *max_class = info->MaxClassLen; + if (values) *values = info->Values; + if (max_value) *max_value = info->MaxValueNameLen; + if (max_data) *max_data = info->MaxValueDataLen; + if (modif) *modif = info->LastWriteTime; + done: if (buf_ptr != buffer) HeapFree( GetProcessHeap(), 0, buf_ptr ); return RtlNtStatusToDosError( status ); } @@ -821,6 +819,7 @@ } else if (status != STATUS_BUFFER_OVERFLOW) goto done; } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = total_size - info_size; @@ -880,36 +879,35 @@ buf_ptr, total_size, &total_size ); } - if (!status) + if (status) goto done; + + if (is_string(info->Type)) { - if (is_string(info->Type)) + DWORD len = WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), + (total_size - info_size) /sizeof(WCHAR), + NULL, 0, NULL, NULL ); + if (data && len) { - DWORD len = WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), - (total_size - info_size) /sizeof(WCHAR), - NULL, 0, NULL, NULL ); - if (data && len) + if (len > *count) status = STATUS_BUFFER_OVERFLOW; + else { - if (len > *count) status = STATUS_BUFFER_OVERFLOW; - else - { - WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), - (total_size - info_size) /sizeof(WCHAR), - data, len, NULL, NULL ); - /* if the type is REG_SZ and data is not 0-terminated - * and there is enough space in the buffer NT appends a \0 */ - if (len < *count && data[len-1]) data[len] = 0; - } + WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), + (total_size - info_size) /sizeof(WCHAR), + data, len, NULL, NULL ); + /* if the type is REG_SZ and data is not 0-terminated + * and there is enough space in the buffer NT appends a \0 */ + if (len < *count && data[len-1]) data[len] = 0; } - total_size = len + info_size; - } - else if (data) - { - if (total_size - info_size > *count) status = STATUS_BUFFER_OVERFLOW; - else memcpy( data, buf_ptr + info_size, total_size - info_size ); } + total_size = len + info_size; } - else if (status != STATUS_BUFFER_OVERFLOW) goto done; + else if (data) + { + if (total_size - info_size > *count) status = STATUS_BUFFER_OVERFLOW; + else memcpy( data, buf_ptr + info_size, total_size - info_size ); + } } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = total_size - info_size; @@ -1056,6 +1054,7 @@ } } } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = info->DataLength; @@ -1151,6 +1150,7 @@ else memcpy( data, buf_ptr + info->DataOffset, total_size - info->DataOffset ); } } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = info->DataLength; -- Alexandre Julliard julliard(a)winehq.com

2 1

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

14 Feb '01

Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> writes: > * THIS SOFTWARE IS NOT COPYRIGHTED > * > * This source code is offered for use in the public domain. You may > * use, modify or distribute it freely. > * > * This code is distributed in the hope that it will be useful but > * WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY > * DISCLAMED. This includes but is not limited to warranties of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > You can't get more clear than that, I think. Of course it would be good to > acklowdge their contribution and let them know their modified code is being > used. Since it's public domain then yes we can use it; but you should *always* add a comment when you use code from somewhere else stating where it came from, even if there is no license requiring it. It's just the polite thing to do. > One thing I _don't_ think we need to do is to try to use the headers when > building msvcrt and Francois suggested. I think its extra work for no real > benefit, bugs show themselves soon enough, and winapi_check catches several > kinds of parameter bugs already. I alos dont like having to use a different > build command for one dll (ie include he msvcrt header dir). The advantage of using the headers for building msvcrt is that they will then automatically get tested by anybody compiling Wine; while with the other approach they only get tested by people compiling Winelib apps, i.e. just about nobody <grin> OTOH the macros make the headers quite ugly, so I don't have any strong preference one way or the other. -- Alexandre Julliard julliard(a)winehq.com

2 1

howto use dll´s in C
by christian richter 14 Feb '01

14 Feb '01

Hello, i have a dll which makes some string conversions, and i want to use it in my C-Programm in Linux, i found out that wine can execute win32 exe´s and so i thought it should be possible to use a winelib or something to use the dll-functions and to get back values from this dll . . please help me, i don´t want to convert the whole dll (written in M$ Visual Basic ) into C - sources .. thank you

2 1

Re: Registry patch
by Alexandre Julliard 13 Feb '01

13 Feb '01

davep <davep(a)cyw.uklinux.net> writes: > 123 calls RegQueryValueEx for the binary values with lpData set to NULL and > lpcbData non-NULL. RegQueryValueEx is supposed to return the size of the buffer > needed to hold the data, but Wine is returning the size of its initial buffer > (0xeb IIRC, sizeof(buffer)-sizeof(KEY_VALUE_PARTIAL_INFORMATION)). This causes > a crash when 123 immediately calls the same function again with a real buffer > address, presumably because 123 didn't allocate enough storage space. Could you please send me a +reg,+server trace of the offending calls? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Registry patch
by Alexandre Julliard 13 Feb '01

13 Feb '01

davep <davep(a)cyw.uklinux.net> writes: > RegQueryValue() & RegEnumValue() > > We need to return the data length for REG_BINARY value types as well as strings > when called with a null buffer pointer. I don't understand why you need that. We already return the data length in all cases, including REG_BINARY. Could you elaborate a bit on exactly what is going wrong? -- Alexandre Julliard julliard(a)winehq.com

2 1

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