wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 15 Feb '01

15 Feb '01

Gavriel State <gav(a)transgaming.com> writes: > Definitely a drawback, I agree. But the shared memory area could be relatively > high in the address space, so that a stray pointer is much more likely to run > into unmapped memory and segfault before overwriting crucial data. This is only one failure case, but there are many others; for instance stack corruption that causes the app to jump somewhere inside ReleaseMutex, which will then happily modify the right address in the wrong way. > The only way we're going to be able to get both speed and safety though is > to have some kernel support. While that's beyond the scope of what I'd like > to accomplish in the short term, I think that it's something worth thinking > about more. While the solution proposed by David Howells may be overkill, I'm > not sure that simply changing the communication mechanism as you suggested > (http://www.winehq.com/News/2000-37.html#0) will speed things up enough - > we'll still have the context switch overhead. The main problem is the TLB flush due to switching address spaces; but I don't see any way to avoid this if we want memory protection (which we definitely do). The only way to know if we can make it fast enough is to implement it and benchmark it... > At least in the case of mutexes, I believe that all we need to do is > make sure that the count field is always modified through interlocked > increment/decrement/etc including the wineserver. I think you underestimate the complexity of getting this right. For instance, how do you determine the address of the count field from the mutex handle, keeping in mind that handles can be manipulated from other threads or even other processes (cf. DuplicateHandle)? How do you cope with a thread dying in the middle of an operation? Of course you can ignore all these special cases, and it will even work most of the time. But it's clearly not a viable general solution... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 15 Feb '01

15 Feb '01

Gavriel State <gav(a)transgaming.com> writes: > After some more thinking, Ove and I have come up with a mechanism that should eliminate > most of the wineserver overhead for mutexes and semaphores, without the need to resort > to a kernel module. We're probably going to give this a try over the next few days, so > any feedback will be very much appreciated. I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important. As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: dlls/ntdll/debugtools.c patch
by Alexandre Julliard 15 Feb '01

15 Feb '01

Chris Morgan <cmorgan(a)wpi.edu> writes: > Resubmit of this patch. Alexander, is this patch ok? Looks good, but I wonder if we shouldn't add an assert() instead. People are not supposed to use the debug interface to print out huge strings, and printing partial lines messes up the output in multi-threaded programs. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Documentation fixes
by Patrik Stridvall 15 Feb '01

15 Feb '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > More readable to a human, perhaps. > > Uh, yes, the source code is meant to be read by humans. winapi_check > is a nice tool but it doesn't justify making the code less readable; Sure but grouping all the variants together doesn't nessary make it less readable to human. It entirely depends on how diffrent the variants are. If for example one variant is an optimized i386 assembler variant and the other is a pure C variant it might be more sensible to group them together, in order to more make people making changes remember to change the other variant. In this case, I personally didn't find either way preferable so I did what was best for winapi_check. > instead it should be fixed to understand the existing constructs That is a quite complicated in this case. > (or > at least don't complain about them). OK. I can easily make it ignore multiple definitions. I will do that.

1 0

Re: Documentation fixes
by Alexandre Julliard 15 Feb '01

15 Feb '01

Patrik Stridvall <ps(a)leissner.se> writes: > More readable to a human, perhaps. Uh, yes, the source code is meant to be read by humans. winapi_check is a nice tool but it doesn't justify making the code less readable; instead it should be fixed to understand the existing constructs (or at least don't complain about them). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: howto use dll´s in C
by christian richter 15 Feb '01

15 Feb '01

Thanks, specmaker could use the dll, but i tried specmaker with severall dll´s and there were only four functions: unload_class, registerServer unregisterServer or something like that, i heared this is because of the COM,ActiveX nature of the dll´s ... can i use those classes in C ??? how,is it maybe possible with corba ? -----Ursprüngliche Nachricht----- Von: Jon Griffiths [mailto:tntjpgriff@tsnxt.co.uk] Gesendet: Mittwoch, 14. Februar 2001 14:45 An: christian richter; 'wine-devel(a)winehq.com' Betreff: Re: howto use dll´s in C Hi, If you have the wine sources, or browse them from www.winehq.com, checkout tools/specmaker/README. Also see the Winelib developer guide for details on Winelib in general. Note that if all you want is the string routines, thats a lot of overhead for a few routines. You might find they are available in source form from somewhere else. Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

2 1

Speeding up wineserver syncronization objects with shared memory
by Gavriel State 15 Feb '01

15 Feb '01

Hi everyone, We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes. Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock. After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module approach. After re-reading the thread and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work. After some more thinking, Ove and I have come up with a mechanism that should eliminate most of the wineserver overhead for mutexes and semaphores, without the need to resort to a kernel module. We're probably going to give this a try over the next few days, so any feedback will be very much appreciated. Here's what we've been discussing in private email: ============================================================================================ Ove writes: > Gav writes: > > > Alternatively, I wonder if there's some way to speed up synchronization stuff > > through the use of some kind of shared memory area that all wine processes know > > about. The shared memory area could be used to do mutexes with atomic test-and- > > set operations. > > Maybe. But we probably don't want extensive busy waits, so we'd need to > call the wineserver when we need to wait. And the wineserver isn't really > designed to do bus-locked atomic access to such shared areas itself. But > perhaps with some client cooperation... in win32, a mutex is just a > different (and slower) kind of a critical section, anyway (but since it's > handle-based it can work across address spaces). > > If each mutex had a wcount field shared among all clients, we could do... > > ReleaseMutex: > wc = InterlockedDecrement(&wcount) > if wc > 0 > call wineserver's ReleaseMutex > > WaitForSingleObject: > wc = InterlockedIncrement(&wcount) > if wc < 0 > return WAIT_OBJECT_0 > call wineserver's WaitForSingleObject > > which would at least do something about the > ReleaseMutex/WaitForSingleObject pairs in the same thread... That's exactly the kind of thing I was thinking about. We can probably do the same for the CriticalSection semaphores as well. I don't think that we can do anything to speed up Events though. So the next question is: what's the best way to manage the shared area for each mutex/semaphore? We could just expose the wineserver handle table directly in the shared memory area, expanding the handle_entry struct in the server with a DWORD to server as the count field. Theoretically it brings up security concerns, but I don't think that we care that much at this point. ============================================================================================ Thoughts, anyone? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

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

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

running a daemon ?
by Philippe Moutarlier 13 Feb '01

13 Feb '01

Hi, this is not really a development question .. sorry . I am trying to see if I could use wine for running an lmgrd.exe daemon. How can I do this (and do you think it would work) ? When I just run > wine lmgrd.exe it starts running seemingly correctly and then exits instead of keeping running. Thanks Philippe

2 1

RE: Should Wine use alloca or not?
by Patrik Stridvall 13 Feb '01

13 Feb '01

> On Monday 12 February 2001 15:33, Patrik Stridvall wrote: > > > > So perhaps we should debate whether we should use alloca or not. > > It seems this has been decided. Yes, see below. > I haven't examined or used > alloca in years, > so its possible that my personal objections don't apply in todays > implementations ( a quick test shows gcc on i386 _doesn't_ > use a function > call these days, for example, so thats no longer a valid > reason). So rather > than saying its evil, I'll tone down to it simply being > unesessary, and > continue to avoid it for (no doubt dubious) reasons of 'style'. I would rather say that the problem of using it, is that it, as Alexandre pointed out, introduces unrecovorable/undetectable errors if we allocate more than one page memory and if we only need a maximum of one page we can just allocate that or less if we know the exact maximum. The only problem I can see with this approach is that it uses an unnessary amount of stack space for recursive functions, but then I know of no such function in Wine and even if there is one, it is probably better to rewrite it as a non-recursive function anyway. So yes, the issue is decided.

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