December 2003 - Wine-devel - list.winehq.org

FIXMEs in Alsa WaveIn
by Sylvain Petreolle 22 Dec '03

22 Dec '03

Hello, Could you explain the meaning of the FIXME("-\n") you put in ALSA_WaveInit when you added WaveIn support ? I would be happy to solve it but I didnt find a comment in your code nor in your patch. ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Current CVS dlls/winmm/winealsa/audio.c issue
by Carl Sopchak 22 Dec '03

22 Dec '03

I just did a cvs update on the wine tree, and tried to build it. The build failed when trying to link winealsa.drv.spec, with ALSA_widMessage reference undefined. The issue was that the majority of the code in audio.c, including one definition of the function ALSA_widMessage, is conditioned upon #if defined(HAVE_ALSA) && ((SND_LIB_MAJOR == 0 && SND_LIB_MINOR >= 9) || SND_LIB_MAJOR >= 1) Then, near the bottom, another version of ALSA_widMessage is compiled conditioned upon #ifndef HAVE_ALSA So, If HAVE_ALSA is defined, but the rest of the first condition causes it to evaluate to FALSE, neither version of ALSA_widMessage gets compiled. This is apparently what is happening to me. Unfortunately, I have no idea about what *should* be happening here. To get the build to continue, I just made the second half (&& onward) of the first condition into a second condition, added an #else, and copied the version of ALSA_widMessage that gets compiled #ifndef HAVE_ALSA into the #else clause. I'm not sure if ./configure is erroneously setting HAVE_ALSA, or if the SND_LIB_* values are not defined right, or if the #if conditions are wrong in audio.c. (I'd think that the later is at least *part* of the problem...) Sad to say, I don't have the expertise, time, or, quite frankly, the desire to look into this right now. (I'm actually trying to work on a problem with Quicken Delux 2000 printing partial page landscape checks that causes wine to crash which just started with a recent cvs update. But that's another e-mail...) But I thought someone who might be working on this code would be interested in knowing about it. Regards, Carl

2 1

Wine Status Page Pre-1
by Tom 22 Dec '03

22 Dec '03

Hello All, Here is the current DLL's Status Page. Ive made a number of changes since I last sent these partial pages to the dev-list. Here is a list of things I still need todo for completeness. 1) Proof Read! (against all my notes) 2) Doc links, (Thursday night Friday AM) 3) Send to Brian V for WWN coverage :) (Brian if you want you can get a early start) 4) Add/Remove todo's 5) changelog update 6) Give everyone a chance to respond.. Friday? ;) 7) diff -u & send 8) :) Happy Holidays, Tom

3 3

new old winetests
by Ferenc Wagner 21 Dec '03

21 Dec '03

Hi there, I've got a more or less standalone version which can run the tests and submit the results to a CGI script, if possible. It also differentiates between libwine and cross builds. I would be grateful for a review. One week point is its integration into the build system: I hacked something together which works, but not sure at all if that's the right way. One other is that I did not notice that the tests return the number of tests failed as their exit status. It adds a couple of lines to the output... Anyway: programs/winetests directory: Cross-compiled .exe without the dsound tests: http://afavant.elte.hu/~wferi/wine/tests.zip Submission point (for now you won't see anything and submissions overwrite each other, but this must be contactable for automatic submission): http://afavant.elte.hu/~wferi/cgi-bin/winetests.cgi Pretty much deuglifying work remains, but it does something (for me). Sorry for the slow progress... Feri.

4 30

Re: Allow direct device access ( cdrom, floppy)
by Hans Verkuil 20 Dec '03

20 Dec '03

Hello Uwe, Uwe Bonnes wrote: > appended patch opens the devicefile connected to a drive as connected by > the user in ~/.wine/config [Drive X] "Device" = "/dev/yyy". > The appropriate action on that file ( read, write, set_file_pointer, ...) > succeed according the the righte the user has on that device. > > That way, I am able to open a unencrypted DVD with "DVD Shrink", inspect > the structure and watch the movie, without mounting the DVD. ( For > encryted DVD, I have on my disk the needed translation of the > DeviceIOControls). Thank you for your patch! I was also looking into it when a google search turned up your message on the newsgroup. Are you planning to make a patch for the DeviceIOControls? I've added them myself in order to allow DVD Shrink to use encrypted DVDs. As the implementation is just passing on the DeviceIOControl calls to linux ioctls I wonder why you haven't submitted a patch for this. If you have no plans for creating a patch, then I'm willing to do so. Let me know what you intend to do, Regards, Hans Verkuil

3 3

Segfault in winedump (spotted by valgrind)
by Sylvain Petreolle 20 Dec '03

20 Dec '03

Trying to dump a winme dll, winedump crashed with a segfault. Valgrind gives these results, have someone a clue ? This file comes from a working Win9x installation. [syl(a)wine system]$ file commctrl.dll commctrl.dll: MS-DOS executable (EXE), OS/2 or MS Windows [syl(a)wine system]$ valgrind winedump spec commdlg.dll ==26058== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==26058== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==26058== Using valgrind-20031012, a program supervision framework for x86-linux. ==26058== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==26058== Estimated CPU clock rate is 1407 MHz ==26058== For more details, rerun with: -v ==26058== Can't get a suitable file signature, aborting ==26058== discard syms in /c/windows/system/commdlg.dll due to munmap() ==26058== Invalid read of size 4 ==26058== at 0x804FD3D: dll_next_symbol (pe.c:1239) ==26058== by 0x804A431: main (main.c:413) ==26058== by 0x126BAE: __libc_start_main (in /lib/libc-2.3.2.so) ==26058== by 0x8048E48: (within /usr/local/bin/winedump) ==26058== Address 0x4 is not stack'd, malloc'd or free'd Erreur de segmentation ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Re: last try for now: one desktop window
by Mike Hearn 20 Dec '03

20 Dec '03

After getting depressed at how broken InstallShield still is, I thought I'd check up on why this patch was never merged. I know Alexandre isn't on holiday, but maybe he'll see this when he gets back. thanks -mike On Tue, 2003-10-21 at 15:13, Alex Pasadyn wrote: > This is a first attempt at "fixing" desktop mode. The Winelib program > winedesktop creates and maintains one Wine desktop window that is shared > across all applications.

1 0

Bugs in wine-[pk]thread launch
by Mike Hearn 20 Dec '03

20 Dec '03

Hi, Since the NPTL runtime code split wine into two binaries, I've noticed the following problems (ignoring the winedbg breakage): * I get this message in my /var/log/messages file: application bug: wine-pthread(12443) has SIGCHLD set to SIG_IGN but calls wait(). * I often get lots of zombie wine processes, presumably because the parent wine launcher process never reaps the child. I don't know enough to fix either of these problems, but thought I'd report them anyway.... thanks -mike

1 0

Re: Problems with x11drv_main.c version 1.83
by Shachar Shemesh 20 Dec '03

20 Dec '03

Sami Aario wrote: >I did some Googling and found this link which I believe is relevant: >http://lists.debian.org/debian-kde/2003/debian-kde-200305/msg00357.html. >I've been launching applications from the console, where DISPLAY is not set. >Under an X bash shell however, 'echo $DISPLAY' gives me ':0.0' as expected, >and I don't get the error I mentioned previously when launching wine. > >Is this how it's supposed to work, i.e. should I specify DISPLAY explicitly >on >the console if I want to launch wine applications from there? > > When launching X applications the "DISPLAY" variable should be set. Wine is such an application. When you launch Wine from a term launched within the X environment, this variable is already set. If you want to launch an X application from outside that environment, you need to make sure that the app knows which X server to connect to (the DISPLAY variable), as well as have the proper authorization. In your case, the authorization was probably not an issue, because the same user that was running the app from X is the one who started the server (and thus had authorization to do so). As such, nothing besides setting the DISPLAY var is neccessary. If you are going to complicate your setup further, however, I would recommend you RTFM "xauth", as well as the XAUTHORITY environment variable. A simpler but less safe solution is to use "xhost". I would recommend against, however. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

1 0

Problems with x11drv_main.c version 1.83
by Sami Aario 20 Dec '03

20 Dec '03

Hi list, Version 1.83 of dlls/x11drv/x11drv_main.c does not work for me. This patch removes the Display option in the config file, and now I get this error message: "x11drv: Can't open display: " (and no display name given). I've had to revert to version 1.81. Is the display name supposed to be given somewhere else (e.g. the registry) or are things supposed to happen automagically? My system is a debian woody, and XFree86 -version reports 4.1.0.1.

3 5