- Wine-Devel - list.winehq.org

VersionInfo for built-in DLLs
by Dmitry Timoshkov Feb. 15, 2001

Feb. 15, 2001

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 Feb. 15, 2001

Feb. 15, 2001

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 Feb. 15, 2001

Feb. 15, 2001

> 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 Feb. 15, 2001

Feb. 15, 2001

> 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 Feb. 15, 2001

Feb. 15, 2001

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?
by Eric Pouech Feb. 15, 2001

Feb. 15, 2001

>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 Feb. 14, 2001

Feb. 14, 2001

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 Feb. 14, 2001

Feb. 14, 2001

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 Feb. 14, 2001

Feb. 14, 2001

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 Feb. 14, 2001

Feb. 14, 2001

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