September 2005 - Wine-Devel

Re: dlls/x11drv/mouse.c

by Alexandre Julliard

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > No :-/ I can't explain it. The XQueryPointer call in X11DRV_GetCursorPos is > returning an incorrect value. I don't see anything wrong with the way we > are calling it. Maybe it's a bug in X. Would you be able to write a small test case demonstrating the problem? -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2005

Re: dlls/x11drv/mouse.c

by Ulrich Czekalla

On Fri, Sep 09, 2005 at 11:22:26AM +0200, Alexandre Julliard wrote: > This sounds like it's just masking the problem. Do you know precisely > why the mouse position is incorrect? No :-/ I can't explain it. The XQueryPointer call in X11DRV_GetCursorPos is returning an incorrect value. I don't see anything wrong with the way we are calling it. Maybe it's a bug in X. Older versions of Wine worked fine so I looked at what has changed since it broke and concluded that the removal of the XFlush call provokes the problem. /Ulrich

Sept. 9, 2005

Re: shell32: correct a failing test

by Saulius Krasuckas

* On Fri, 2 Sep 2005, Juan Lang wrote: > > This test was failing after the first time on Windows, so (hopefully) > fix it. > > ChangeLog: fix a test failing on Windows. Reported by Katerina Nizhnik. Unfortunately, this code pops up some window: --- wine/dlls/shell32/tests/shellpath.c 2005/08/16 16:00:07 1.11 +++ wine/dlls/shell32/tests/shellpath.c 2005/09/03 09:37:15 1.12 ... + shFileOp.pFrom = modifiedPath; + shFileOp.fFlags = FOF_NOCONFIRMATION | FOF_NOERRORUI | + FOF_SILENT; + SHFileOperationA(&shFileOp); which says: | Favorites is a Windows system folder and is required for Windows to run | properly. It cannot be deleted. And then exception of an access violation is thrown from the SHLWAPI.DLL. This happens on WinME. It seems here the flag FOF_NOERRORUI is ignored. I can't test this on other platforms and am going out of city for a weekend. Anyone feel free to fix it. :-P

Sept. 9, 2005

Re: dll/winmm/playsound.c

by Frank Richter

On 08.09.2005 18:28, Robert Shearman wrote: >> - TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX \n", >> + TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX \n", >> (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); Note that you're also printing the hex value of the pointer to mmckInfo.fccType ... you probably want to remove "(LPSTR)&". -f.r.

Sept. 9, 2005

Re: user: make A->W WM_GETTEXTLENGTH use WM_GETTEXT [try 2]

by Frank Richter

On 05.09.2005 18:13, Frank Richter wrote: > Frank Richter <frank.richter(a)gmail.com> > When doing A->W WM_GETTEXTLENGTH, use WM_GETTEXT behind the scenes to > obtain an exact length. This seems to match the behaviour of recent > Windowses and as well fixes a couple of regressions (caused by theming > suddenly making the standard controls Unicode). Any comment on this one? I mean, getting Delphi apps to work again would be nice after all... -f.r.

Sept. 9, 2005

Re: Problem detecting libxslt

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > It doesn't seem exactly right to me, but I'm not really sure of a better > way of fixing it. Maybe an AC_TRY_COMPILE()? Alexandre understands > configure better than I do, so you might try asking him. Looks good to me. -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2005

Re: Problem detecting libxslt

by Mike McCormack

Vincent Béron wrote: > --- configure.ac 3 Sep 2005 15:43:53 -0000 1.403 > +++ configure.ac 8 Sep 2005 23:08:04 -0000 > @@ -469,7 +469,10 @@ then > [AC_DEFINE(HAVE_LIBXSLT, 1, [Define if you have the libxslt library]) > XSLTLIBS="$ac_xslt_libs" > XSLTINCL="$ac_xslt_cflags"],,$ac_xslt_libs) > - ]) > + ],, > +[#ifdef HAVE_LIBXSLT_PATTERN_H > +# include <libxslt/pattern.h> > +#endif]) > CPPFLAGS="$ac_save_CPPFLAGS" > fi It doesn't seem exactly right to me, but I'm not really sure of a better way of fixing it. Maybe an AC_TRY_COMPILE()? Alexandre understands configure better than I do, so you might try asking him. Mike

Sept. 9, 2005

Re: dlls/x11drv/mouse.c

by Andreas Mohr

Hi, On Fri, Sep 09, 2005 at 11:22:26AM +0200, Alexandre Julliard wrote: > Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > > > We had a XFlush call in X11DRV_SetCursorPos before but it was removed for > > some reason. This restores the call and fixes a regression in JInitiator > > where the mouse position was being reported incorrectly. > > This sounds like it's just masking the problem. Do you know precisely > why the mouse position is incorrect? In case further testing/evidence is needed, http://www.dicker-turm.de/panorama-dicker-turm.exe has mouse position problems on Wine as well (Windows is ok) which could be the same issue. Andreas

Sept. 9, 2005

Re: dlls/x11drv/mouse.c

by Alexandre Julliard

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > We had a XFlush call in X11DRV_SetCursorPos before but it was removed for > some reason. This restores the call and fixes a regression in JInitiator > where the mouse position was being reported incorrectly. This sounds like it's just masking the problem. Do you know precisely why the mouse position is incorrect? -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2005

Re: Suggestions for improvement of the emulator

by Dmitry Timoshkov

"Mike Hearn" <mh(a)codeweavers.com> wrote: > >From a dictionary: > > "em·u·late: Computer Science. To imitate the function of (another > system), as by modifications to hardware or software that allow the > imitating system to accept the same data, execute the same programs, and > achieve the same results as the imitated system." You've just called Linux a Unix emulator :-) I'm always tempted to mention DRDOS, x86 processors, PC motherboards, PC BIOS'es around, VGA compatible video cards, Soundblaster compatible sound cards, netword cards of all flavours, language compilers, etc: all of them are the emulators according to the definition above. The better word is "clone" if you don't like a wordy "independent implementation". -- Dmitry.

Sept. 9, 2005

Re: kernel: Forward Atom APIs to ntdll

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > + if (!table) > { > - req->atom = atom; > - req->table = table; > - wine_server_set_reply( req, full_name, sizeof(full_name) ); > - if (!wine_server_call_err( req )) > + ATOM_BASIC_INFORMATION *abi; > + > + size = sizeof(*abi) + MAX_ATOM_LEN * sizeof(WCHAR); > + abi = HeapAlloc(GetProcessHeap(), 0, size); Using HeapAlloc will considerably slowdown the function, you can safely allocate the necessary buffer on the stack. The same for GetAtomNameW. -- Dmitry.

Sept. 9, 2005

Re: Safedisc 1 works on wine

by Ivan Leo Puoti

Tom Wickline wrote: > > Will this support versions 1.6.0 through version 1.50.20 ? > 1.6.0 was the first version of safedisk, version 1.11.0 introduced secdrv.sys > and NT support. And do you know if it supports "dplayerx.dll" and the > second layer of encryption that is applied on the ICD that is in > 1.50.20? 1.50.20 is the version we used to implement support in wine, so yes it supports secdrv.sys and dplayerx.dll and the encryption applied to the ICD. Ivan.

Sept. 9, 2005

CreateProcess - wine is not doing it right

by Vitaliy Margolen

Now I really need you help people. Ok, here is the problem: LdrInitializeThunk is called from within start_process - the first thing to be executed in the new process's context. But this is not right. All what I found so far indicates, that LdrInitializeThunk should be queued as an APC, so it executes first no matter what. To complicate matters more, LdrInitializeThunk calling wineserver to stop the process if it's created with CREATE_SUSPENDED flag set. This is wrong. New process should never make it to it's main thread yet. And even worse, none of this happens where it should be - in ntdll. Functions such as NtCreateProcess and NtCreateThread are stubs. So when I'm looking on-line for any information, they all refer to these ntdll functions. I'm looking at this code and can't figure out what part of it belongs where. In kernel we have: 1. CreateProcessW that figures out what the executable is and calls the one of the other functions. That's talk about PE for now (create_process). 2. create_process: I'm not sure what the first part does (something about child). It looks to me that most of the first part including new_process wineserver call should be a part of NtCreateProcess. Everything else from create_process should go into NtCreateThread. 3. THREAD_InitStack shoul probably stay, except all the memory allocation goes to NtCreateThread. 4. start_process should stay the way it is, except delete call to LdrInitializeThunk. 5. LdrInitializeThunk - have no clue what should stay, and what should go somewhere else. Then we have a wineserver's init_process_done. Some parts of it looks like should go into create_process. But I'm not sure here ether. -- Best regards, Vitaliy

Sept. 9, 2005

Re: Safedisc 1 works on wine

by Tom Wickline

On 9/8/05, Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > Finally we've got safedisc1 running on linux. > Thanks go to *Laurent* Pinchart, Vitaliy Margolen, *Brad DeMorrow, > Marcus Meissner, and Alexandre for contributing time/code/ideas. > The code is 100% DMCA compliant and hopefully can be cleaned up to be > good enough for cvs over the coming days and weeks. > Two games have been tested, they both use the same version of safedisc > (don't ask how we know, we do) > http://www.kievinfo.com/images/wine/HoM3_1.jpg > http://www.kievinfo.com/images/wine/safediscworks.jpg Will this support versions 1.6.0 through version 1.50.20 ? 1.6.0 was the first version of safedisk, version 1.11.0 introduced secdrv.sys and NT support. And do you know if it supports "dplayerx.dll" and the second layer of encryption that is applied on the ICD that is in 1.50.20? I suppose the only way to find out is to test allot of software that spans all the revisions, just thought I would be lazy and ask.... Tom > > Ivan. > * > > >

Sept. 9, 2005

Re: appdb developers please read

by Troy Rollo

On Thu, 8 Sep 2005 23:06, Francois Gouget wrote: > If it's something Alexandre uses to apply patches, then his requirement > that it be usable from his desktop environement (Emacs) precludes a > web-based system. Not really. A web based system could provide an alternative interface that allows for other front-ends (an XML interface for buzzword compliance). This would facilitate a split in development to that you don't need somebody who knows both PHP and elisp to develop it - get one who knows PHP and one who knows elisp. It would also lay the groundwork for having a variety of front-ends. More importantly, it would provide an opportunity for integration with bugzilla, and submission of patches via a web interface is likely to result in better consistency, specifically dealing with the following problems: 1. Submit the patch as a file through the web and you get the same result every time, submit it through email and everybody's mail client might do something slightly different and wrong, multiplied by configuration differences and PEBCAKs); 2. A web submission system could insist on a ChangeLog and possibly some additional explanatory text (why the change is needed, why it was done a particular way); 3. A web submission system could effectively provide for other niceties such as recording patch dependencies and when a newer patch supercedes an older one. You would have four phases: 1. Define the functionality required; 2. Implement functionality with web-based interface (probably in PHP since that's what's used for the appdb and so what the appdb coders are familiar with); 3. Implement an XML option for the functions that make sense inside an IDE (and I suppose you could call emacs the original IDE); and 4. Implement the emacs frontend for that interface. At the moment we're really only at (1) though. The broad basic requirements are: 1. Can receive patches via the web and/or wine-patches; 2. Provides an interface allowing for application of patches and changing the state of the patch, and whatever else Alexandre does; 3. Provides notification to the patch submitter whenever the state changes. Other niceties would include: 4. Gateways web submissions back to wine-patches; 5. Tracks discussion of a particular patch; 6. Ability to assign a patch to somebody else to review; 7. Ability to determine who has primary responsibility for a patch based on the files modified by the patch (so that if there are different committers for particular areas, then only the appropriate one needs to deal with the patch).

Sept. 8, 2005

Re: winnt32.exe on AMD64

by Filip Navara

Tom Kennedy wrote: > > All > > I have install Wine one an AMD 64 bit system running Redhat 3 update > 2. I am trying to run the > winnt32.exe prgram and I am getting the following load error. > > root(a)cert-amd1 ~]# wine "y:\amd64\winnt32.exe" > Trying to load PE image for unsupported architecture (Unknown-8664) > wine: could not load L"Y:\\amd64\\winnt32.exe" as Win32 binary > [root(a)cert-amd1 ~]# > > > I assue the 32 in the name of the executabel means it is a 32 bit > binary, but wine > is telling me it is not. Any clues as to why I am getting this error > message. Thanks. It's x64 PE executable (note the "amd64" directory). - Filip

Sept. 8, 2005

Problem detecting libxslt

by Vincent Béron

Hi Mike, Doing ./configure on a RH8 box I get the following: checking libxslt/transform.h presence... yes configure: WARNING: libxslt/transform.h: present but cannot be compiled configure: WARNING: libxslt/transform.h: check for missing prerequisite headers? configure: WARNING: libxslt/transform.h: see the Autoconf documentation configure: WARNING: libxslt/transform.h: section "Present But Cannot Be Compiled" configure: WARNING: libxslt/transform.h: proceeding with the preprocessor's result configure: WARNING: libxslt/transform.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## The problem looks to come from my transform.h needing xsltInternals.h being included first. I added an #ifdef HAVE_LIBXSLT_PATTERN_H include to the AC_CHECK_HEADERS which defines HAVE_LIBXSLT, as that file does #include "xsltInternals.h". I don't think we should directly include xsltInternals.h. Could you please comment if the attached patch is correct or not? I'll send it to wine-patches if acceptable. Thank you, Vincent

Sept. 8, 2005

Re: winspool: EnumPrinterDrivers

by Detlef Riekenberg

Am Sonntag, den 07.08.2005, 19:16 +0200 schrieb Detlef Riekenberg: This Patch is not in CVS yet: http://www.winehq.org/pipermail/wine-patches/2005-August/019671.html > Changelog: > Let EnumPrinterDrivers return the number of drivers. > Any comments / suggestions ? -- By By ... ... Detlef

Sept. 8, 2005

Re: winspool/tests: New Testsuite

by Detlef Riekenberg

Am Montag, den 29.08.2005, 00:53 +0200 schrieb Detlef Riekenberg: This Patch in not in the CVS yet. http://www.winehq.org/pipermail/wine-patches/2005-August/020289.html > Changelog: > > - New Testsuite for winspool.drv: > GetDefaultPrinterA/W and > GetPrinterDriverDirectoryA/W > - Verbose Output with "WINETEST_DEBUG" > 1 > Any suggestions / comments on this work ? -- By By ... ... Detlef

Sept. 8, 2005

Safedisc 1 works on wine

by Ivan Leo Puoti

Finally we've got safedisc1 running on linux. Thanks go to *Laurent* Pinchart, Vitaliy Margolen, *Brad DeMorrow, Marcus Meissner, and Alexandre for contributing time/code/ideas. The code is 100% DMCA compliant and hopefully can be cleaned up to be good enough for cvs over the coming days and weeks. Two games have been tested, they both use the same version of safedisc (don't ask how we know, we do) http://www.kievinfo.com/images/wine/HoM3_1.jpg http://www.kievinfo.com/images/wine/safediscworks.jpg Ivan. *

Sept. 8, 2005

Re: DSOUND: tolerate inexact conversion between different frequencies

by Robert Reif

Alex Villacís Lasso wrote: > During the winealsa tests, I am frequently annoyed by the following: > say, in playing a 11050Hz secondary buffer with an 8000Hz primary > buffer, the number of samples are converted form secondary->primary > and back. In the process, the number of consumed samples in the > secondary buffer drifts by a few frames from the actual value, and > this triggers the warning about "problem with underflow detection". > This patch allows a tolerance of up to 4 bytes before issuing the > message. > > Alex Villacís Lasso Or you could keep track of the round off errors (fractions) like winex does.

Sept. 8, 2005

winnt32.exe on AMD64

by Tom Kennedy

All I have install Wine one an AMD 64 bit system running Redhat 3 update 2. I am trying to run the winnt32.exe prgram and I am getting the following load error. root(a)cert-amd1 ~]# wine "y:\amd64\winnt32.exe" Trying to load PE image for unsupported architecture (Unknown-8664) wine: could not load L"Y:\\amd64\\winnt32.exe" as Win32 binary [root(a)cert-amd1 ~]# I assue the 32 in the name of the executabel means it is a 32 bit binary, but wine is telling me it is not. Any clues as to why I am getting this error message. Thanks. Tom

Sept. 8, 2005

Re: Suggestions for improvement of the emulator

by Mike Hearn

On Tue, 06 Sep 2005 21:29:22 -0700, Juan Lang wrote: > This is frustrating, and some people do seem to be put off by it. I have > no idea how many potential contributors we lose this way. FWIW, I share these concerns though given my non-existant patch writing speed lately I'm not sure how much my opinion counts here ;) Let's take a few examples of patches that were rejected but I feel ought not to have been: * System tray patch. I wrote this when I was 18, I'm now 21. It's taken over three _years_ and this patch is still not deemed correct. In the intervening three years our users have constantly asked why the system tray simply does not work for them. I have no idea what is wrong with this patch. Rob tried to get it merged too, again, he came away empty handed. Last I remember, Alexandre felt the desktop integration code needed better design, or more precise design, or something but I'm not really sure what. I don't care anymore, long since given up on this one. While I'm all for getting desktop integration right, I don't feel the system tray is so vital that it's an all-or-nothing scenario. It doesn't need to be perfect first time around, it needs to work and make our users happy which by and large it does (did?) * Delay logging. This is the patch where you could press set an environment variable and then F12 would toggle logging on/off. It's helpful when the debug output is so verbose it prevents you getting to the part of the app that is buggy. IIRC not merged because it was putting policy into the core code, or it was felt a system based on piping/awk etc would achieve the same thing. I don't remember which but at the time, I remember showing that the performance benefits that motivated it didn't stay with a pipe/awk based approach. Yesterday a newbie Wine hacker was asking how he could debug an app given that he couldn't reach the buggy part with debug logging on. Needless frustration for new developers! Exactly what a project facing manpower issues doesn't need. * Building winetest by default, despite it crushing less powerful machines (gas really hates trying to assemble 20-30mb of input). The reasoning given was that otherwise it might bitrot or fail to build, but we already have automated systems to compile winetest that would notify us if it failed to build. At the very least it could be a configure option. Now, like everybody here I have huge respect for Alexandre and the work he does. I could not do it. But, I agree with Troy and Juan here. I see no reason not to push parallel branches or version control systems as a way to scale up the project. This would have two simple benefits: 1) It would allow sub-maintainership of certain DLLs, if we wanted to do that. 2) It would add some flexibility to the system so that if Alexandre makes a bad judgement call, it's possible to notice (because patches he rejects are being merged in to other trees, or vice-versa). This is what the kernel project does, and it works well for them. Linus tends to be quite conservative, so other maintainers can merge in more risky patches and find out if they work. At the very least we should try and do more to attack the 90 degree learning curve associated with Wine development. Documentation is good but it seems nobody is really working on pulling new developers in any more. A sentiment I've heard echoed in the past is that Wine is just hard - well, it *is* hard, but then so is kernel (technical) and GNOME (user interface) development yet these projects have many developers. We should try and figure out why. thanks -mike

Sept. 8, 2005

ShellExecuteExW

by Ge van Geldorp

This patch: http://www.winehq.org/pipermail/wine-cvs/2005-August/017595.html broke execution of Control Panel items. The cpanel code would concatenate the name of the .cpl file and the display name and pass that in the lpFile member of the SHELLEXECUTEINFO struct. This is solved by passing .cpl in lpFile and display name in lpParameters. I ran into another problem: just before calling the execfunc(), any parameters would be appended to wszApplicationName. Unfortunately, sei_tmp.lpFile points to wszApplicationName at that point, so if the execfunc() fails (e.g. for a .cpl file) sei_tmp.lpFile is messed up. Fixing this allowed one of the todo tests to succeeed. Since looking at/tracing through the ShellExecuteEx code makes me scream in agony every time, I would appreciate a review of the patch below. Ge van Geldorp. Index: dlls/shell32/cpanelfolder.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/cpanelfolder.c,v retrieving revision 1.20 diff -u -r1.20 cpanelfolder.c --- dlls/shell32/cpanelfolder.c 27 Jul 2005 11:10:52 -0000 1.20 +++ dlls/shell32/cpanelfolder.c 8 Sep 2005 21:38:08 -0000 @@ -970,6 +970,7 @@ SHELLEXECUTEINFOW sei_tmp; PIDLCPanelStruct* pcpanel; WCHAR path[MAX_PATH]; + WCHAR params[MAX_PATH]; BOOL ret; int l; @@ -990,12 +991,13 @@ /* pass applet name to Control_RunDLL to distinguish between applets in one .cpl file */ path[l++] = '"'; - path[l++] = ' '; + path[l] = '\0'; - MultiByteToWideChar(CP_ACP, 0, pcpanel->szName+pcpanel->offsDispName, -1, path+l, MAX_PATH); + MultiByteToWideChar(CP_ACP, 0, pcpanel->szName+pcpanel->offsDispName, -1, params, MAX_PATH); memcpy(&sei_tmp, psei, sizeof(sei_tmp)); sei_tmp.lpFile = path; + sei_tmp.lpParameters = params; sei_tmp.fMask &= ~SEE_MASK_INVOKEIDLIST; sei_tmp.lpVerb = wCplopen; Index: dlls/shell32/shlexec.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shlexec.c,v retrieving revision 1.71 diff -u -r1.71 shlexec.c --- dlls/shell32/shlexec.c 8 Sep 2005 18:54:52 -0000 1.71 +++ dlls/shell32/shlexec.c 8 Sep 2005 21:38:09 -0000 @@ -1263,9 +1263,10 @@ lpFile = wfileName; + strcpyW(wcmd, wszApplicationName); if (sei_tmp.lpParameters[0]) { - strcatW(wszApplicationName, wSpace); - strcatW(wszApplicationName, wszParameters); + strcatW(wcmd, wSpace); + strcatW(wcmd, wszParameters); } /* We set the default to open, and that should generally work. @@ -1273,7 +1274,7 @@ if (!sei_tmp.lpVerb) sei_tmp.lpVerb = wszOpen; - retval = execfunc(wszApplicationName, NULL, FALSE, &sei_tmp, sei); + retval = execfunc(wcmd, NULL, FALSE, &sei_tmp, sei); if (retval > 32) return TRUE; Index: dlls/shell32/tests/shlexec.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/tests/shlexec.c,v retrieving revision 1.5 diff -u -r1.5 shlexec.c --- dlls/shell32/tests/shlexec.c 23 Aug 2005 09:37:30 -0000 1.5 +++ dlls/shell32/tests/shlexec.c 8 Sep 2005 21:38:09 -0000 @@ -704,9 +704,7 @@ okChildInt("argcA", 5); okChildString("argvA3", "Open"); sprintf(filename, "%s\\test file.shlexec", tmpdir); - todo_wine { okChildPath("argvA4", filename); - } sprintf(filename, "%s\\test_shortcut_exe.lnk", tmpdir); rc=shell_execute_ex(SEE_MASK_NOZONECHECKS, NULL, filename, NULL, NULL);

Sept. 8, 2005

Re: Suggestions for improvement of the emulator

by Mike Hearn

On Mon, 05 Sep 2005 18:21:18 -0500, Evil wrote: > No, of course not. Now, if the gas had to be converted to a completely > different substance before it could power the car, then it would probably > be an emulator. Ah, car analogies, the developers favourite tool :) >From a dictionary: "em·u·late: Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system." Seems like a good description of Wine to me. It imitates the Win32 API.

Sept. 8, 2005