March 2005 - Wine-Devel - list.winehq.org

Re: More destinations for wineoss's mixer
by peter＠piments.com March 6, 2005

March 6, 2005

On 05 Mar 2005 12:34:26 -0500, Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote: > According to MSDN, DST_HEADPHONES can be the same as DST_SPEAKERS, > DST_LINE and DST_VOICEIN as DST_WAVEIN. > > Peter, does this one helps Dragon NS 7? > > Changelog: > Make wineoss's mixer know about DST_HEADPHONES, DST_LINE and > DST_VOICEIN. > Use proper constants instead of 0 and 1. > > Vincent Thanks , that got rid of the errors but did not make it work, sadly. I can get it to install reliably using Installshield. What I thought was blocking it was that there is a OK/Cancel dlg coming up _behind_ the splash screen. This is obviously a bug in that the dlg is modal but not visible when it comes up. The trick is to move the splash to one side before clicking Next. The prog now starts and works as much as it can without sound and a speach profile , ie not much but it can close cleanly. Attempting to set the mike volume is still the killer but there are now no messages, the set up dlg hangs and I have to close it using the X button on the frame. I can then exit NS. Progress none the less Thanks again. -- Using Opera e-mail on Gentoo Linux

1 0

Re: MultiByteToWideCharacter problem with CP 950 (Traditional Chinese)
by Andreas Mohr March 5, 2005

March 5, 2005

Hi, On Sun, Mar 06, 2005 at 04:49:13AM +0900, Mike McCormack wrote: > 1st problem: (pre-existing) No comments. > 2nd problem: (regression) > > There's another serious problem, which is a regression. Starting Office > 2000 (any language)with the Big5 code page as below, causes serious > trouble with my X server (X.org 6.7.0). The X cpu usage goes to 95%, > and the install hangs, more or less. > > LC_ALL=zh_TW.Big5 wine m:\setup > > The problem happens whether or not the Chinese truetype font is installed. This probably is the same issue that has prevented success for any attempt to use some relatively recent Wine versions on the notebook of my girlfriend (P3/450, Debian, Chinese simplified, non-Unicode setup: GB2312, XF86 4.3.x): whenever I started Wine, everything slowed to a crawl and I had veritable trouble trying to kill it (definitely points towards XF86 overload). I could offer to do some tests if need be. Haven't tried the new "non-official" Debian Wine packages, BTW. Andreas Mohr

1 0

Re: USER32: Error checking for sysparams tests
by Paul Vriens March 5, 2005

March 5, 2005

On Sat, 2005-03-05 at 06:42, jchevrier(a)nexicom.net wrote: > As discussed on wine-devel there are a handful of calls in the > SystemParametersInfo tests that don't check for returned errors and continue > on with testing a given parameter. This patch ensures that all initial calls > to SystemParametersInfoA in each parameter test have their returned errors > checked. To ease adding more error cases and reduce code duplication I have > consolidated error message handling into a single function. > > Changelog: > > * Consolidate error message handling > * Add error checking to all initial SystemParametersInfoA calls in each > parameter test to make sure that if a given parameter isn't supported or has > failed in some other way that we return and don't continue on with the test > * Remove a couple of TABS and align registry keys/values at the top of the > file Hi Justin, what about the attached one? Added/changed the following: - Always set LastError before calling test_error_msg - SPI_{GET,SET}ICONTITLEWRAP is supported on Win98, but was clouded by an error that was set after a previous call failed. Changelog: Justin Chevrier <jchevrier(a)nexicom.net> * Consolidate error message handling * Add error checking to all initial SystemParametersInfoA calls in each parameter test to make sure that if a given parameter isn't supported or has failed in some other way that we return and don't continue on with the test * SetLastError before calling test_error_msg * Remove a couple of TABS and align registry keys/values at the top of the file * SPI_{GET,SET}ICONTITLEWRAP is supported on Win98 Cheers, Paul.

2 1

Any resources about threading problems?
by Bill Medland March 5, 2005

March 5, 2005

Does anyone know any site or book or something with a decent discussion about the problems of the different threading models and their implementations? In the Developer's Guide in section 8.3 there are references to "the threading chapter". Is this a section that has not yet been written? As I understand it we (in the pthreads version) "override the native pthreads library". What does this mean? I am trying to research the issues associated with threading so that I understand the complications. The fact that Linux has two models and that Wine, FreeDCE and Samba (that I know of) seem to have found it necessary to bypass/hack/modify/override them indicates to me that there is something to understand. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

2 3

installshield and Wine
by wino＠piments.com March 5, 2005

March 5, 2005

What is the current state of play? It seems that InstallShield is pretty much and essential element in a working Wine env. But I tried to install Dragon NS 7 yesterday and it hung completely with a system wide modal in the middle of the screen. I had to kill the parent. There has been some regressions in Wine recently it seems , what would be the best wine version to install to get around this issue.? Thanks. -- Opera 7 mail on Linux

5 6

Dragon Naturally Speaking - working.
by wino＠piments.com March 5, 2005

March 5, 2005

Good news and what looks like a first. Dragon Naturally Speaking 4 working under Wine. ======================================= reqd riched32 and comdlg32 native from 98SE Gentoo Linux , 2.6.10-nitro4 kernel wine-20050111 Fresh Wine installation installed IE6 using sidenet Install Dragon from CD no major issues. copy missing dll's ran up Dragon , enter user name , setup sticks at setting mike level but exits cleanly. #wine gentrain.exe picks up user name , dictated training text . It saves the vocab/voix profiles the drops out with 3 repeat errors but the profile is safe #wine natspeak.exe Can now dictate in stand-alone mode as in windoze. I now need some help with the guts of Wine to see if I can capture the keystrokes output by Dragon and pipe it to another Linux thread. Any suggestions on that? TIA :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

3 3

Re: [user/tests/sysparams.c] More correct *MOUSEHOVER* tests (Don't apply)
by Paul Vriens March 5, 2005

March 5, 2005

On Fri, 2005-03-04 at 21:39, Paul Vriens wrote: > Hi, > > current checks for only GetLastError()==ERROR_INVALID_SPI_VALUE) are > bogus, at least on Win98 as the LastError is not set. > > Changelog > LastError is not set on failure for *MOUSEHOVER* on Win98 > > Cheers, > > Paul. Hi, no need to apply this one. I shouldn't have checked for ERROR_CALL_NOT_IMPLEMENTED (maybe only at the very first test). Justin's patch seems to be on the right track. Cheers, Paul.

1 0

Re: USER32: Error checking for sysparams tests
by Paul Vriens March 5, 2005

March 5, 2005

On Sat, 2005-03-05 at 06:42, jchevrier(a)nexicom.net wrote: > As discussed on wine-devel there are a handful of calls in the > SystemParametersInfo tests that don't check for returned errors and continue > on with testing a given parameter. This patch ensures that all initial calls > to SystemParametersInfoA in each parameter test have their returned errors > checked. To ease adding more error cases and reduce code duplication I have > consolidated error message handling into a single function. > > Changelog: > > * Consolidate error message handling > * Add error checking to all initial SystemParametersInfoA calls in each > parameter test to make sure that if a given parameter isn't supported or has > failed in some other way that we return and don't continue on with the test > * Remove a couple of TABS and align registry keys/values at the top of the > file Hi Justin, could you have a look at the patch I send in for *MOUSEHOVER* stuff. Apparently Win98SE returns 0 without setting last error for the *MOUSEHOVER* ones. Could you incorporate this into your patch? Mine is a bit 'overcomplete' as ERROR_CALL_NOT_IMPLEMENTED will probably never be returned (only for SystemParametersInfoA itself). Shouldn't we also always do a SetLastError(0xdeadbeef) before every call to SystemParametersInfoA? Cheers, Paul.

1 0

Drive detection stuff
by Mike Hearn March 5, 2005

March 5, 2005

So, there are 4 obvious problems with our current drive management code: 1) We add links to the floppy drive. We should blacklist it, as it causes a big delay in the file open dialogs as we poll the drive which sits there spinning its motors naval-gazing. How many people still use floppy disks in 2005 anyway? I'm hoping the answer is "virtually none" 2) We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom 3) The artwork in the file pickers sucks ass. Sorry, it does. It's ugly as sin and for some reason the Desktop icon is an arrow, not a desk. This doesn't matter when you only have C: and Z: drives. It does matter when you have 2 CD drives, 2 Windows drives, a floppy and a few other drives. Fixing this is theoretically easy but for some reason it never gets done. If any of you non-coders are reading this and want to contribute then this would be a good way to start. Good artwork already exists, it's just a case of finding it, converting it to the right format and getting the new bitmaps into CVS. 4) We don't detect new drives as they are mounted into the system, eg if I start a Windows program and then realize that my work is actually on a USB key, if I plug that key in Nautilus and GTK+ (and probably KDE) apps will detect it and see it, but we won't. Not even if I restart the app! This is bad. Fixing this is not, in theory, super hard. When HAL detects a new hotplug device it modifies the fstab file and mounts. If we watch the /etc/fstab file for changes and rerun drive detection therefore we can make this all magically work. Problems are: - Who triggers the resync? The wineserver is the obvious choice as there is only 1 per wineprefix but we'd need to integrate FAM support for that - How do we broadcast to apps that the drive definitions changed so we can update the UI, flush any caches etc? thanks -mike

13 21

Setting null region for window mask kills wine 20050112
by Kuba Ober March 4, 2005

March 4, 2005

Hi, I was testing my Qt 3.3.4 application with wine, and it appears that setting a null widget mask via QWidget::setMask(QRegion()) puts wine into an endless loop. It continuously spews complaints that it ran out of gdi heap. I can reproduce it at home and send the actual error message if need be. I presume that this could be reproduced with the GPL qt-win32 port, but I didn't try. Cheers, Kuba Ober

1 0

Re: Account for permissions on Win2k - dlls/advapi32/tests/security.c
by Paul Vriens March 4, 2005

March 4, 2005

On Fri, 2005-03-04 at 17:09, Jakob Eriksson wrote: > If we dont have permissions, we don't... > Checked for ERROR_NO_SUCH_PRIVILEGE > > Weirdly, Win2k does not recognize the last two, number 28 and 29. > > Evidence: > http://test.winehq.org/data/200503041000/2000_IDWASEMPTY/advapi32:security.… > It only fails for 1 w2k btw. The other 2 succeed, so it doesn't look like a general w2k problem. Couldn't it be a certain version of the dll? I've had the same issues with shlwapi/registry. Although the majority succeeds now, some 'old' dll's will still fail. Could it be an idea, to have every test (at least 1 in a dll test) tell the version of the tested dll? Or have a test within every dll that does exactly this (version checking). Cheers, Paul.

2 1

(no subject)
by Wine-devel March 4, 2005

March 4, 2005

1 0

Should CDLGetLongPathName[AW] be exported by ordinal
by Francois Gouget March 4, 2005

March 4, 2005

On Windows XP and 2003ES the CDLGetLongPathName[AW] ordinals are 4 and 5 respectively. On Windows 9x, NT4 and Windows 2000 they are 1 and 2 respectively. If Microsoft changed the ordinal of these APIs it means the ordinal does not matter so I'm tempted to post the following patch: Index: dlls/urlmon/urlmon.spec =================================================================== RCS file: /var/cvs/wine/dlls/urlmon/urlmon.spec,v retrieving revision 1.31 diff -u -p -r1.31 urlmon.spec --- dlls/urlmon/urlmon.spec 30 Nov 2004 21:14:21 -0000 1.31 +++ dlls/urlmon/urlmon.spec 23 Feb 2005 10:21:11 -0000 @@ -1,8 +1,8 @@ -1 stub CDLGetLongPathNameA -2 stub CDLGetLongPathNameW @ stub AsyncGetClassBits @ stub AsyncInstallDistributionUnit @ stub BindAsyncMoniker +@ stub CDLGetLongPathNameA +@ stub CDLGetLongPathNameW @ stub CoGetClassObjectFromURL @ stub CoInstall @ stdcall CoInternetCombineUrl(wstr wstr long wstr long ptr long) Yet in Windows 2000 Microsoft went out of its way to assign these ordinals to them so I suspect there is something more to this. Could it be that old versions of Internet Explorer import these APIs by ordinal and that since Windows XP and greater ships with a recent enough version of Internet Explorer Microsoft decided it was no longer necessary to keep the old ordinals for compatibility? What should we do if this turns out to be the case? Do we want to keep the ordinals anyway? I guess that the minimum would be to document this in the spec file. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 1

Wine MIDI Mapper
by Andrew Neil Ramage March 4, 2005

March 4, 2005

In trying to get a Windows music composition program (www.noteworthycomposer.com) working, I have been unable to hear playbacks of music because the Wine MIDI Mapper does not open. Does anyone have any idea what is causing this problem, and if there is a fix available ? I am using Mandrake 10.0, Gnome 2.4 and Wine-20050211. -- Andrew [hackcoughsniffle] Internal Virus Database corrupt

1 0

Re: Drive detection stuff
by Oliver Stieber March 4, 2005

March 4, 2005

> Ah, so this means that the directory change > notification mechanism > applies to volume notification as well? Or is it > still a somewhat separate > API? > > Nevermind, at least you just told us that this API > exists, so we should > try to get the hal/hotplug/fam stuff integratedf > towards this API. > On second thoughts additional, I was looking at doing something similar for linux installers using /dev/boot.ini and the registry. If you get anything working that way I'll take a look at making an installer that reads all the users settings from the windows registry for something like knopix and maybe look at implementing some of the windows settings in wine e.g. setting desktop wallpaper &co.. Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: Drive detection stuff
by Oliver Stieber March 4, 2005

March 4, 2005

> Ah, so this means that the directory change > notification mechanism > applies to volume notification as well? Or is it > still a somewhat separate > API? > > Nevermind, at least you just told us that this API > exists, so we should > try to get the hal/hotplug/fam stuff integratedf > towards this API. > take a look at how ivman http://ivman.sourceforge.net/ does things. > Andreas Mohr > > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

ESD sound support in Wine 20050111
by Kumaran Santhanam March 4, 2005

March 4, 2005

I found a patch for ESD (Enlightenment Sound Daemon) support in Wine from July 2004. I modified this to work with Wine-20050111 and compiled the wineesd.drv.so driver. This driver works in both Wine and CrossOver 4.1. The patch and instructions are attached to this email. I have been using it for a few weeks and it seems to be working well. It would be great if it could be incorporated into the main Wine tree. Please let me know if you have any questions. Best Regards, Kumaran Wine Enlightenment Sound Daemon support --------------------------------------- [Jul 2004] Original driver code by Zhangrong Huang <hzhr(a)users.sourceforge.net> [Feb 2005] Ported to Wine 20050111 and CrossOver Office Professional 4.1 by Kumaran Santhanam <rhapsody(a)users.sourceforge.net> Instructions: 0) Make sure that esound-devel is installed. 1) Untar Wine-20050111.tar.gz 2) cd wine-20050111 3) patch -p1 <wineesd-20050111.patch 4) autoconf configure.ac >configure 5) ./configure 6) make depend 7) make Binary is built as dlls/winmm/wineesd/wineesd.drv.so

3 2

MSVCRT still hisshandling Exception
by Uwe Bonnes March 4, 2005

March 4, 2005

Hallo, with a 2.6 kernel, _pn.exe from the Xilinx ISE suite crashes while loading the last process. With native MSVCRT, a message box pops up, reporting the error. With builtin msvcrt, the exception handling loops until a stack overflow happens. Find appended the beginning of the loop. With the second loop, trace:seh:EXC_CallHandler calling handler at 0x77ec1830 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 appears, with the third loop cointaining these lines doubled and so on. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- fixme:msvcrt:_setmbcp Unreal codepages (e.g. -3) not implemented fixme:ole:CoRegisterMessageFilter stub fixme:process:CreateProcessA BON: App "(null)" cmd ""C:\\ise-6.3\\bin\\nt\\findmgsg.exe"" err:comm:GetCommState tcgetattr or ioctl error 'Invalid argument' err:ole:CoGetClassObject couldn't load InprocServer32 dll C:\windows\system\vbscript.dll fixme:ole:CoCreateInstance no classfactory created for CLSID {3f4daca4-160d-11d2-a8e9-00104b365c9f}, hres is 0x80040150 err:x11drv:X11DRV_CreateWindow invalid window width -19 err:x11drv:X11DRV_CreateWindow invalid window width -19 fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x76726151 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=44455359 trace:seh:EXC_RtlRaiseException eax=44455355 ebx=b7212480 ecx=b7542c88 edx=ffffffff esi=b7542ca4 edi=b7542c88 trace:seh:EXC_RtlRaiseException ebp=77428a70 esp=77aa09dc cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00010206 trace:seh:EXC_CallHandler calling handler at 0x76774e9f code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x76ccdea5 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661d92b code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661d93d code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661bb36 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661f3e5 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661c926 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661ce51 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661c590 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x76618114 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x45bef5 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x6c402ef3 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x6c402e0a code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x6c402d82 code=c0000005 flags=0 trace:seh:cxx_frame_handler handling C++ exception rec 0x77aa0984 frame 0x77aafce8 trylevel 0 descr 0x6c424f50 nested_frame (nil) exception type: flags 8508c483 destr 0x8a4275c0 handler 0x548d1a47 type info 0xe0831024 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x7732567b trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=e0831024 trace:seh:EXC_RtlRaiseException eax=e0831024 ebx=77345620 ecx=00000000 edx=77eff031 esi=0a90274b edi=00000000 trace:seh:EXC_RtlRaiseException ebp=77aa0234 esp=77aa0198 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00010202 trace:seh:EXC_CallHandler calling handler at 0x77ec1830 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x76774e9f code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x76ccdea5 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661d92b code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661d93d code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661bb36 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661f3e5 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661c926 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661ce51 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x7661c590 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x76618114 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x45bef5 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x6c402ef3 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x6c402e0a code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x6c402d82 code=c0000005 flags=10 trace:seh:cxx_frame_handler handling C++ exception rec 0x77aa0140 frame 0x77aafce8 trylevel 0 descr 0x6c424f50 nested_frame (nil) exception type: flags 5028 destr 0xb7fffb90 handler 0xb7ff49e0 type info 0xb7f38c90 0: code=c0000005 flags=0 addr=0x773256b1 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=244c8b14 trace:seh:EXC_RtlRaiseException eax=7734142d ebx=77345620 ecx=b7fd5140 edx=00000007 esi=244c8b10 edi=00000000 trace:seh:EXC_RtlRaiseException ebp=77a9f9f0 esp=77a9f954 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00010246 trace:seh:EXC_CallHandler calling handler at 0x77ec1830 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x77ec1830 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x76774e9f code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 1 ... err:seh:setup_exception stack overflow 212 bytes in thread 0009 eip b7ec7425 esp 779b0f2c stack 0x779b0000-0x77ab0000

1 0

Re: Make QueryServiceConfigW return an empty string for empty dependencies
by James Hawkins March 4, 2005

March 4, 2005

On Fri, 4 Mar 2005 13:54:34 +1100, Troy Rollo <wine(a)troy.rollo.name> wrote: > QueryServiceConfigW currently returns a NULL pointer for lpDependencies when > there are no dependencies. The documentation states that an empty string has > the same meaning, and at least one application (an MSIEXEC.EXE from the > Office XP CD) will SEGV if this is NULL. Using the empty string avoids this. > > ChangeLog: > Return an empty string for service dependencies when there are no > dependencies, rather than a NULL pointer, which causes some apps > to SEGV. Can you write test cases for this behaviour? -- James Hawkins

1 0

Re: Make QueryServiceConfigW return an empty string for empty dependencies
by James Hawkins March 4, 2005

March 4, 2005

On Fri, 4 Mar 2005 13:54:34 +1100, Troy Rollo <wine(a)troy.rollo.name> wrote: > QueryServiceConfigW currently returns a NULL pointer for lpDependencies when > there are no dependencies. The documentation states that an empty string has > the same meaning, and at least one application (an MSIEXEC.EXE from the > Office XP CD) will SEGV if this is NULL. Using the empty string avoids this. > > ChangeLog: > Return an empty string for service dependencies when there are no > dependencies, rather than a NULL pointer, which causes some apps > to SEGV. Can you write test cases for this behaviour? -- James Hawkins

1 0

wine-user.pdf feedback 2
by Dan W. March 4, 2005

March 4, 2005

Okay, now I found what I think is a more serious missing piece of info in wine-user.pdf. In page 20, last paragraph, it says one can start off by modifying the sample config file, which "can be found in the directory 'documentation/samples'... Problem is, I did a file search for 'documentation', and I get like 10 pages of hits I did a file search for samples, and same thing, or worse. In both cases I went through all those instances visually scanning for 'wine' or 'config' and found nothing at all. I know I ought to have the sources somewhere, because when I installed fc2, I said "install everything", and that included sources; but I have no idea where to look for the wine documentation folder. I have to give up on it for now. Far past my bedtime by now, anyways.. ;-) Cheers!

3 2

Re: MSI: Radio Buttons
by Dmitry Timoshkov March 4, 2005

March 4, 2005

"Ulrich Czekalla" <ulrich.czekalla(a)utoronto.ca> wrote: > + if (control->hwnd) > + { > + WNDPROC oldproc = (WNDPROC) SetWindowLongPtrW(control->hwnd, GWLP_WNDPROC, > + (LONG)MSIRadioGroup_WndProc); Then it's better to cast to LONG_PTR instead of LONG. -- Dmitry.

1 0

Re: [ADVAPI] SetSecurityInfo
by Robert Shearman March 3, 2005

March 3, 2005

Raphael wrote: >Hi, > > Changelog: > - simple implementation of SetSecurityInfo > >(seems to be needed by War3 frozen throne, cf >http://forums.gentoo.org/viewtopic-t-303306.html?sid=3f962c702ae58ad8902ca8…) > > I have made a few comments on the implementation below: > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = advapi32.dll >-IMPORTS = kernel32 ntdll >+IMPORTS = winspool kernel32 ntdll > > Should be in DELAYIMPORTS. We don't want to slow down the loading of all applications because of this one uncommon case. >@@ -1418,6 +1422,87 @@ > { > FIXME("(%s) : stub\n", debugstr_w(lpFileName) ); > return TRUE; >+} >+ >+/****************************************************************************** >+ * SetSecurityInfo [ADVAPI32.@] >+ */ >+BOOL WINAPI SetSecurityInfo(HANDLE handle, >+ SE_OBJECT_TYPE ObjectType, >+ SECURITY_INFORMATION SecurityInfo, >+ PSID psidOwner, >+ PSID psidGroup, >+ PACL pDacl, >+ PACL pSacl) >+{ >+ SECURITY_DESCRIPTOR sd; >+ BOOL test; >+ >+ TRACE("(%p, %x, %x, %p, %p, %p, %p) : alomst stub\n", handle, ObjectType, SecurityInfo, psidOwner, psidGroup, pDacl, pSacl); > > Remove the "almost stub" part of it and just print FIXME's for the parts that aren't implemented, otherwise the next person that comes along to this function will spend hours trying to work out what isn't implemented, if they even realise this function is to blame. >+ >+ test = InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION); >+ if (!test) return FALSE; >+ >+ if (SecurityInfo & DACL_SECURITY_INFORMATION) { >+ test = SetSecurityDescriptorDacl(&sd, TRUE, pDacl, TRUE); >+ } >+ if (SecurityInfo & SACL_SECURITY_INFORMATION) { >+ test = SetSecurityDescriptorSacl(&sd, TRUE, pSacl, TRUE); >+ } >+ if (SecurityInfo & GROUP_SECURITY_INFORMATION) { >+ if (NULL == psidGroup) { >+ SetLastError( ERROR_INVALID_PARAMETER ); >+ return FALSE; >+ } >+ test = SetSecurityDescriptorGroup(&sd, psidGroup, TRUE); >+ } >+ if (SecurityInfo & OWNER_SECURITY_INFORMATION) { >+ if (NULL == psidOwner) { >+ SetLastError( ERROR_INVALID_PARAMETER ); >+ return FALSE; >+ } >+ test = SetSecurityDescriptorOwner(&sd, psidOwner, TRUE); >+ } >+ >+ switch (ObjectType) { >+ case SE_KERNEL_OBJECT: >+ test = SetKernelObjectSecurity(handle, SecurityInfo, &sd); >+ break; >+ case SE_SERVICE: >+ test = SetServiceObjectSecurity(handle, SecurityInfo, &sd); >+ break; >+ case SE_REGISTRY_WOW64_32KEY: >+ case SE_REGISTRY_KEY: >+ test = RegSetKeySecurity(handle, SecurityInfo, &sd); >+ break; >+ case SE_LMSHARE: >+ /*test = NetShareSetInfo(handle, SecurityInfo, &sd); TODO: don't exit on netapi */ >+ break; >+ case SE_PRINTER: >+ { >+ PRINTER_INFO_2A pr_info; >+ memset(&pr_info, 0, sizeof(pr_info)); >+ /** maybe we should do GetPrinter before SetSecurityDesc* ? */ >+ test = GetPrinterA(handle, 2, (LPBYTE) &pr_info, 0, NULL); >+ pr_info.pSecurityDescriptor = &sd; >+ test = SetPrinterA(handle, 2, (LPBYTE) &pr_info, PRINTER_CONTROL_SET_STATUS); >+ break; >+ } >+ >+ case SE_FILE_OBJECT: >+ /*SetFileSecurity ? */ >+ case SE_WINDOW_OBJECT: > > Call SetUserObjectSecurity. >+ case SE_DS_OBJECT: >+ case SE_DS_OBJECT_ALL: >+ case SE_PROVIDER_DEFINED_OBJECT: >+ case SE_WMIGUID_OBJECT: >+ case SE_UNKNOWN_OBJECT_TYPE: >+ default: >+ WARN("unsupported ObjectType %d\n", ObjectType); > > Change this to a FIXME. >+ test = TRUE; >+ } >+ >+ return test; > > This function returns a DWORD error code, not a BOOL. > } > > /****************************************************************************** > > Rob

1 0

Re: ntdll: Add NtCreateKey tests
by Alexandre Julliard March 3, 2005

March 3, 2005

James Hawkins <truiken(a)gmail.com> writes: > What are the steps I need to take to break registry initialisation? I > did wonder how anything in the real win32 registry could be created > though if you can't create a key directly under HKLM or HKU. If this > really does break initialisation, can we implement a different > create_key that has little restrictions and would only be used > internally, or would this just be scrapped entirely? I don't think there's any point in replicating that behavior. I doubt there's any such check on Windows either, it's most likely just a side effect of the way the registry files are "mounted" at different places in the tree. Once we have a proper implementation of RegLoadKey/RegUnloadKey we should get the same behavior automatically. -- Alexandre Julliard julliard(a)winehq.org

1 0

any way to unlink the symbolic link, not its target?
by Kuba Ober March 3, 2005

March 3, 2005

Hi, I'm using wine to cross compile projects using vc7.1 from a software configuration tool called aegis (http://aegis.sf.net) I'm maintaining a symlinked baseline with source and derived (.obj, .exe, .pdb) files in it. A change only has copies of changed files. So, when the compiler tries to output something, it first tries to unlink the file. But that won't work as wine tries to unlink target of the symlink, instead of the symlink itself. Is there any switch somewhere to revert to deleting the symbolic links, or if not -- what source file should I look into to patch that? Thanks a lot, Kuba Ober

1 0