June 2004 - Wine-Devel - list.winehq.org

Re: LISTBOX_Directory() returns LB_OKAY for invalid directory / f ilen ame

by Alexandre Julliard

Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > Yesssss! got it, stupid mistake.... > It should be... > if ((le == ERROR_NO_MORE_FILES) || (le == ERROR_FILE_NOT_FOUND)) return > LB_ERR; That makes more sense, but it still looks wrong, I don't see why you would ignore all other errors. I suspect what you are really trying to do is to revert the change in rev 1.94, but this causes other problems (cf. bug 1435). I think you'll have to write a regression test for that one. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2004

Re: Wine on FreeBSD current

by John Birrell

On Tue, Jun 22, 2004 at 11:36:16PM +0200, Gerald Pfeifer wrote: > On Sun, 20 Jun 2004, Alexandre Julliard wrote: > > Well, there's a reason for that reservation code, and it's that some > > Windows apps require it; so unless you find some other way to ensure > > that FreeBSD never allocates anything above 0x80000000, the > > reservation code can't really be made optional. > > ...and in fact, Alexandre, wouldn't it be better to have _some_ apps > broken under Wine on FreeBSD than a completely broken Wine on FreeBSD > for all apps? While there aren't many FreeBSD people using Wine, I can't see the Wine folks wanting to spend any time jumping through hoops for a negligible user base. In fact, it's possible that the code to change FreeBSD's mmap address allocation algorithm is actually simpler than the changes to Wine required to make the registration code optional. I need to do more work to confirm that, but that's my gut feeling at the moment. -- John Birrell

June 22, 2004

Re: Wine on FreeBSD current

by Gerald Pfeifer

On Mon, 21 Jun 2004, John Birrell wrote: > For FreeBSD5, which will become the stable branch sometime soon, I think > the kernel code needs to change. I have a FreeBSD src commit bit, but I'm not > a vm person, so I can only prototype a change and submit it for review. Excellent, thanks! Would you mind keeping me in the loop (as I'm maintaining the FreeBSD emulators/wine port)? > I'm not sure if the other developers will regard this change favourably, > though. They may take the attitude that if Wine can be made to work with > the FreeBSD kernel code as is, then Wine should be coded accordingly. Well, as long as they tell us _how_ to change Wine, and in a way that will be acceptable to Alexandre... :-) > If the Wine code was restructured to make the reservation code optional, > that would cover both FreeBSD4 and FreeBSD5. Then, if the FreeBSD mmap > algorithm was to change in the future, the build could start using the > reservation code at that time. I agree... On Sun, 20 Jun 2004, Alexandre Julliard wrote: > Well, there's a reason for that reservation code, and it's that some > Windows apps require it; so unless you find some other way to ensure > that FreeBSD never allocates anything above 0x80000000, the > reservation code can't really be made optional. ...and in fact, Alexandre, wouldn't it be better to have _some_ apps broken under Wine on FreeBSD than a completely broken Wine on FreeBSD for all apps? Gerald

June 22, 2004

RE: LISTBOX_Directory() returns LB_OKAY for invalid directory / f ilen ame

by Krishna Murthy

Yesssss! got it, stupid mistake.... It should be... if ((le == ERROR_NO_MORE_FILES) || (le == ERROR_FILE_NOT_FOUND)) return LB_ERR; Thanks, Krishna -----Original Message----- From: Dimitrie O. Paun [mailto:dpaun(a)rogers.com] Sent: Tuesday, June 22, 2004 2:01 PM To: Krishna Murthy Cc: 'Alexandre Julliard'; wine-devel(a)winehq.org Subject: Re: LISTBOX_Directory() returns LB_OKAY for invalid directory / f ilen ame On Tue, Jun 22, 2004 at 11:08:28AM -0700, Krishna Murthy wrote: > The 'le' is an integer value and not a bitwise value. This means it > could have only one error condition at a time. Right. Because of this fact: > if ((le != ERROR_NO_MORE_FILES) || (le != ERROR_FILE_NOT_FOUND)) > return LB_ERR; Will always return LB_ERR. Proof: (le != ERROR_NO_MORE_FILES) || (le != ERROR_FILE_NOT_FOUND) ## by deMorgan's Law == !((le == ERROR_NO_MORE_FILES) && (le == ERROR_FILE_NOT_FOUND)) ## by transitivity == !(ERROR_NO_MORE_FILES == ERROR_FILE_NOT_FOUND) ## by the definition of these error codes == !(18 == 2) ## different numbers are not equal == !(FALSE) ## by negation == TRUE ;) -- Dimi. P.S. I haven't done a formal proof since I was doing my M.Sc. at UofT :)

June 22, 2004

Re: LISTBOX_Directory() returns LB_OKAY for invalid directory / f ilen ame

by Dimitrie O. Paun

On Tue, Jun 22, 2004 at 11:08:28AM -0700, Krishna Murthy wrote: > The 'le' is an integer value and not a bitwise value. This means it could > have only one error condition at a time. Right. Because of this fact: > if ((le != ERROR_NO_MORE_FILES) || (le != ERROR_FILE_NOT_FOUND)) return > LB_ERR; Will always return LB_ERR. Proof: (le != ERROR_NO_MORE_FILES) || (le != ERROR_FILE_NOT_FOUND) ## by deMorgan's Law == !((le == ERROR_NO_MORE_FILES) && (le == ERROR_FILE_NOT_FOUND)) ## by transitivity == !(ERROR_NO_MORE_FILES == ERROR_FILE_NOT_FOUND) ## by the definition of these error codes == !(18 == 2) ## different numbers are not equal == !(FALSE) ## by negation == TRUE ;) -- Dimi. P.S. I haven't done a formal proof since I was doing my M.Sc. at UofT :)

June 22, 2004

Re: Port to native x86_64?

by Alexandre Julliard

"Sean Kormilo" <sean(a)kormilo.ca> writes: > Thanks for your perspective. Is this largely because WINE is not an > emulator? I would have thought it possible to have WINE itself compiled > as a 64 bit application (such that it can pick up and use 64 bit linux > libraries), but still represent itself as a 32 bit environment for the > windows binaries. But, you know way more about it than I do - if you say > that isn't possible, then I won't bother starting. Well, it would be possible, but it would require adding a translation layer for every single API call, which would be a huge task for very little benefit. It's much easier to do it at the syscall level. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2004

Re: Remote operations -- need for advice

by Roger Olson

Monday, June 21, 2004 4:00 AM "Alexander Yaworsky" <yaworsky(a)migusoft.ru> Wrote: > I'm thinking how to implement CreateRemoteThread and besides fix memory management functions. > The complete (afaik) list includes: > RtlCreateUserThread > NtAllocateVirtualMemory > NtFreeVirtualMemory > NtProtectVirtualMemory > NtQueryVirtualMemory > NtLockVirtualMemory (do nothing?) > NtUnlockVirtualMemory (do nothing?) > NtFlushVirtualMemory > NtMapViewOfSection > NtUnmapViewOfSection > > Suggested implementation. > Let's add two groups of handlers to the wineserver, something like remote_operation_xxxx > and remote_operation_xxxx_complete. > remote_operation should do the following: > 1) suspend_for_ptrace(); > 2) inject a piece of code into required process and start its execution; > 3) resume_after_ptrace(); > 4) place calling thread into suspended state (or into some wait state?) > > remote_operation_complete should prepare reply and resume thread suspended by remote_operation. > Injected code should call required function and then remote_operation_complete > in context of required process. > The question is: how to correctly get address of function? > imho possible solutions are: > 1) assume ntdll loaded at the same address for all processes -- unreliable; > 2) get dll base address from per-process dll list and parse ELF by hand -- too complicated (?); > 3) pass relative offsets and add them later to the ntdll's base address -- unreliable > a bit: ntdll may be replaced, although, it is unlikely; > 4) extend the struct process (server/process.h) and the request init_process with > pointers to required functions -- most reliable and simple but looks ugly. > What do you think? > Mike Hearn has a couple of suggestions here: http://www.winehq.org/hypermail/wine-devel/2004/05/0164.html I have a VB6 app (United Devices Agent) that requires this api in order to function correctly and have been attempting to learn C for the past month or so and starting to get a handle on it but I have a lot to learn about posix and signaling yet and generally how things work. If you need or would like a volunteer to help test and troubleshoot using an actual app, my hand is up :-). Meantime, I'm continuing to try to learn how all this works Thanks, Roger

June 22, 2004

Re: bug in sound support?

by Ivan

I haven't tested any non-directx software, anyway, both the winmm and dsound tests give quite a few errors, the logs are attached. I can hear the test tones, BTW the dsound one is much louder than the winmm one for no obvious reason. Ivan.

June 22, 2004

Re: bug in sound support?

by Francois Gouget

On Mon, 21 Jun 2004, Ivan wrote: > Wine oss doesn't work with the via82cxxx_audio audio driver shipped in the linux > kernel, no other app has any problems, so I'm wondering if it's wine related. > What info is needed to debug this? You should first determine if your application uses DirectSound or not. For that a +loaddll will tell you if dsound.dll is loaded. Then I would recommend the following trace options: +relay,+seh,+winmm,+wave. IF DirectSound is used, then add +dsound. It may also be useful to run the regression tests in interactive mode to determine if basic sound is working. In a source tree do: cd dlls/winmm/tests make WINETEST_INTERACTIVE=1 ../../../tools/runtest -P \ wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c And to test basic DirectSound functionality: cd dlls/dsound/tests make WINETEST_INTERACTIVE=1 ../../../tools/runtest -P \ wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.

June 22, 2004

RE: LISTBOX_Directory() returns LB_OKAY for invalid directory / f ilen ame

by Krishna Murthy

The 'le' is an integer value and not a bitwise value. This means it could have only one error condition at a time. The condition: if ((le != ERROR_NO_MORE_FILES) && (le != ERROR_FILE_NOT_FOUND)) return LB_ERR; Could never return LB_ERR even if file was not found. Hence we have changed to the logical OR condition which could trigger error either if no more files or file not found: if ((le != ERROR_NO_MORE_FILES) || (le != ERROR_FILE_NOT_FOUND)) return LB_ERR; Please find attached sample executable (DIRLIST.exe.zip has the executable), which demonstrate the behavior change between windows and wine. Run the sample and enter invalid path name or file name and press enter (click on Display button). On windows it displays error message "DlgDirList Failed...". Same steps when repeated on wine, it does not display this error message because of the above logical error. Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Friday, June 18, 2004 11:20 AM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: LISTBOX_Directory() returns LB_OKAY for invalid directory / filen ame Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > diff -u -r1.103 listbox.c > --- wine/controls/listbox.c 1 Apr 2004 04:57:12 -0000 1.103 > +++ wine/controls/listbox.c 17 Jun 2004 21:50:20 -0000 > @@ -1760,7 +1760,7 @@ > if ((handle = FindFirstFileW(filespec, &entry)) == INVALID_HANDLE_VALUE) > { > int le = GetLastError(); > - if ((le != ERROR_NO_MORE_FILES) && (le != ERROR_FILE_NOT_FOUND)) return LB_ERR; > + if ((le != ERROR_NO_MORE_FILES) || (le != > + ERROR_FILE_NOT_FOUND)) return LB_ERR; This makes the test completely useless, it can't be right. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2004