wine-devel July 2005

wine-devel@winehq.org

152 participants
298 discussions

mscms/tests/profile.c
by Uwe Bonnes 03 Jul '05

03 Jul '05

Hallo, make test in dlls/mscms/tests fails in profile.c. It seems that the test expects an installed ColorProfile.exe. However I think our police for the tests is to have them succeed without any other prerequisit. Hans, can you perhaps rethink your test strategy? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 5

Re: MSHTML: Added test of IOleObject::[SG]etClientSite
by Alexandre Julliard 03 Jul '05

03 Jul '05

Jacek Caban <jack(a)itma.pwr.wroc.pl> writes: > Changelog: > - Added test of IOleObject::[SG]etClientSite > - Fix IOleObject_SetClientSite to pass tests The test fails here: htmldoc.c:232: Test failed: *pchKey=0x7fc7d2d9, expected NULL -- Alexandre Julliard julliard(a)winehq.org

1 0

Bug in dlls/comctl32/comctl32undoc.c
by Sascha Cunz 03 Jul '05

03 Jul '05

Hi, playing around a bit with wine, i found a thing that is obviously a bug. In lines 1944 and 1977 of dlls/comctl32/comctl32undoc.c the value "0x7FFF" is used to check for the boundary of a 32 bit integer. However, there should be used MAX_INT instead. By the way: Looking at current MSDN, DPA and DSA looks rather documented than "undoc" :-) Regards Sascha P.S.: Please CC me on answers as i'm not subscribed here.

2 3

Get Firefox Button
by James Liggett 02 Jul '05

02 Jul '05

Tom, I've been following your discussion about putting a Get Firefox button on the WineHQ front page. While I'm a big fan of Firefox, I think that we should advocate the more generic W3C standards instead, and use XHTML that is valid against those. That way, we can support pretty much any browser. What do you think? Regards, James Liggett

2 1

Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-03c.diff]
by Mike McCormack 02 Jul '05

02 Jul '05

Hi Gerold Gerold J. Wucherpfennig wrote: > And now take this... Gulp. > + p_fci_internal->perf->erfOper = FCIERR_NONE; > + p_fci_internal->perf->erfType = ERROR_INVALID_DATA; > + p_fci_internal->perf->fError = TRUE; > + SetLastError(ERROR_INVALID_DATA); Your code seem to be doing this over and over again. Is there any reason not to make a macro so you can do something like: FCI_SET_ERROR(FCIERR_NONE, ERROR_INVALID_DATA ); maybe something like this: #define FCI_SET_ERROR( oper, type ) \ p_fci_internal->perf->erfOper = oper; \ p_fci_internal->perf->erfType = type; \ p_fci_internal->perf->fError = TRUE; \ SetLastError(type); Also it would be nice to split this into two patches, one changing all the error codes as per above, and one with all the other minor changes you made. A 75k patch will take a long time for Alexandre to digest... Mike

2 1

Re: [X11DRV] Add resolution for Desktop mode
by Uwe Bonnes 02 Jul '05

02 Jul '05

>>>>> "Lionel" == Lionel Ulmer <lionel.ulmer(a)free.fr> writes: Lionel> Changelog: - add 400x300 resolution to modes supported by Lionel> Desktop mode Isn't 1400x1050 also a valid mode? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: [X11DRV] Add resolution for Desktop mode
by Maxime Bellengé 02 Jul '05

02 Jul '05

Hi Lionel, I didn't see the whole code, but shouldn't you change the #define to 9 ? a+ Maxime -static const unsigned int widths[] = {320, 512, 640, 800, 1024, 1152, 1280, 1600}; -static const unsigned int heights[] = {200, 384, 480, 600, 768, 864, 1024, 1200}; +static const unsigned int widths[] = {320, 400, 512, 640, 800, 1024, 1152, 1280, 1600}; +static const unsigned int heights[] = {200, 300, 384, 480, 600, 768, 864, 1024, 1200}; #define NUM_DESKTOP_MODES (8) /* create the mode structures */ On Sat, 2005-07-02 at 16:26 +0200, Lionel Ulmer wrote: > Changelog: > - add 400x300 resolution to modes supported by Desktop mode >

1 0

CreateURLMoniker misbehaving
by Uwe Bonnes 02 Jul '05

02 Jul '05

Hallo, with native urlmon(and ole32,oleaut32,rpcrt4), Atmel Avrstudio brings up the "Program AVR" option in the "Tools" pulldown menu, with builtin this item is missing. Here the relay trace of the CreateURLMoniker call with builtin: 0009:CALL urlmon.CreateURLMoniker(<unknown, check return>) ret=69bdb8bf 0009:Call kernel32.IsBadWritePtr(7baada74,00000004) ret=702b3c80 0009:Ret kernel32.IsBadWritePtr() retval=00000000 ret=702b3c80 0009:Call kernel32.IsBadReadPtr(7f8be518,00000002) ret=702b3c9b 0009:Ret kernel32.IsBadReadPtr() retval=00000000 ret=702b3c9b 0009:Call shlwapi.154(7f8be518 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml",702b2118 L"http",00000004) ret=702b219d 0009:Ret shlwapi.154() retval=fffffffe ret=702b219d 0009:Call shlwapi.154(7f8be518 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml",702b20f4 L"file",00000004) ret=702b219d 0009:Ret shlwapi.154() retval=00000000 ret=702b219d 0009:Call shlwapi.UrlCanonicalizeW(7f8be518 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml",7baab950,7baab93c,00010000) ret=702b240e 0009:Call ntdll.RtlAllocateHeap(7bc10000,00000000,0000007e) ret=7b74d606 0009:Ret ntdll.RtlAllocateHeap() retval=7bcf5d48 ret=7b74d606 0009:Call ntdll.RtlFreeHeap(7bc10000,00000000,7bcf5d48) ret=7b74d766 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7b74d766 0009:Ret shlwapi.UrlCanonicalizeW() retval=00000000 ret=702b240e 0009:Call kernel32.lstrlenW(7baab950 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml") ret=702b3c28 0009:Ret kernel32.lstrlenW() retval=0000003e ret=702b3c28 0009:Call kernel32.lstrlenW(7baab950 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml") ret=702b3ce3 0009:Ret kernel32.lstrlenW() retval=0000003e ret=702b3ce3 0009:CALL ole32.CoTaskMemAlloc(0000007e) ret=702b2506 0009:Call ntdll.RtlAllocateHeap(7bc10000,00000000,0000007e) ret=65f014f0 0009:Ret ntdll.RtlAllocateHeap() retval=7bcf5d48 ret=65f014f0 0009:RET ole32.CoTaskMemAlloc() retval=7bcf5d48 ret=702b2506 0009:Call shlwapi.StrCpyW(7bcf5d48,7baab950 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml") ret=702b3d02 0009:Ret shlwapi.StrCpyW() retval=7bcf5d48 ret=702b3d02 0009:CALL ole32.CoTaskMemAlloc(00000014) ret=702b2506 0009:Call ntdll.RtlAllocateHeap(7bc10000,00000000,00000014) ret=65f014f0 0009:Ret ntdll.RtlAllocateHeap() retval=7bcf5dd0 ret=65f014f0 0009:RET ole32.CoTaskMemAlloc() retval=7bcf5dd0 ret=702b2506 0009:RET urlmon.CreateURLMoniker(00000000,7f8be518 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml",7baada74) retval=00000000 ret=69bdb8bf and here with builtin: 0009:Call urlmon.CreateURLMoniker(00000000,7f9be518 L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml",7baada74) ret=69bdb8bf trace:urlmon:CreateURLMoniker ((nil), L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml", 0x7baada74) 0009:Call ntdll.RtlAllocateHeap(7bc10000,00000000,0000000c) ret=7e4986fb 0009:Ret ntdll.RtlAllocateHeap() retval=7bcd5340 ret=7e4986fb trace:urlmon:URLMonikerImpl_Construct (0x7bcd5340,(null),L"file:///C:/Program%20Files/Atmel/AVR%20Tools/STK500/STK500.xml") 0009:Call ntdll.RtlAllocateHeap(7bc10000,00000000,0000007e) ret=7e4987aa 0009:Ret ntdll.RtlAllocateHeap() retval=7bcd5f28 ret=7e4987aa 0009:CALL ole32.CoTaskMemFree(00000000) ret=7e4987f7 0009:RET ole32.CoTaskMemFree() retval=00000000 ret=7e4987f7 trace:urlmon:URLMonikerImpl_QueryInterface (0x7bcd5340)->({0000000f-0000-0000-c000-000000000046},0x7baada74) trace:urlmon:URLMonikerImpl_AddRef (0x7bcd5340)->(ref before=0) 0009:Ret urlmon.CreateURLMoniker() retval=00000000 ret=69bdb8bf Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 4

rpcrt4.dll NdrGetUserMarshalInfo() problem
by J. Grant 02 Jul '05

02 Jul '05

Hello, I am getting the attached error when running an install of Overnet v0.52. Basically it cannot find NdrGetUserMarshalInfo(), despite it being in the dll at entry point: 77d43452h, order 199. Any ideas what this problem could be? I'm expecting this to be the symptom of some wider problem. Any help appreciated. Kind regards JG p.s. Is there any way to get these mangled function names to be displayed un-mangled please? c:\opt\overnet_0_52>overnet c:\opt\overnet_0_52>err:module:import_dll No implementation for MSVCRT.dll.??_U@YAPAXI@Z imported from L"C:\\opt\\overnet_0_52\\MSVCIRT.dll", setting to 0xdeadbeef err:module:import_dll No implementation for MSVCRT.dll.??_V@YAXPAX@Z imported from L"C:\\opt\\overnet_0_52\\MSVCIRT.dll", setting to 0xdeadbeef -- Homepage: http://jguk.org/ Blog: http://jguk.org/index.html#blog Radio: http://jguk.org/index.html#radio

3 3

(long) From the front lines: 20050628 release impressions
by Holly Bostick 02 Jul '05

02 Jul '05

Hi, This didn't seem appropriate for the user's list, as I don't intend to report "problems" that I want "solved" but to provide an overview of how the recent changes affect users like me -- for good (mostly) and ill-- in the Real World (TM). First of all, good job! Last night I upgraded from 20050111 to 20050628 (wiped my .wine folder and uninstalled completely), and my first impression is: snazzy! This was the first time in a long time I've installed using ./tools/wineinstall from the source package (the ebuild isn't in Portage yet, or wasn't last night, anyway), and I was pleased to find that it went 99% perfectly. What I loved (Install): 1. It compiled, no problems, errors, or hitches of any kind (and pretty fast, too-- I wouldn't really have been able to watch that video it was recommended I rent). This may have been true for a long time of course, but it was New To Me using wineinstall, so I was happy. 2. It *asked me* about things I might want to change-- and didn't make assumptions about its own detection!! No, I really don't have a Windows drive, so you were right, but I don't want my c_drive in ~/.wine so put it somewhere else, thank you very much. After all the discussion on whichever list about wanting to put the c_drive somewhere else, it's really nice to see that we can now do that. Of course the Problem ? is that since most users will be installing pre-compiled packages, the install will probably just take the defaults (as it has done in the past? Has this capability been available for months now?) rather than proposing the questions, which is a real shame. Other small disappointment: I did request a config file: Create local config file ~/.wine/config? (yes/no) yes ....but did not get one: Configuring Wine for a no-windows install in /home/motub/local_games/wine/drive_c... /home/motub/.wine updated successfully. cp: cannot stat `documentation/samples/config': Onbekend bestand of map Created /home/motub/.wine/config using default Wine configuration. You probably want to review the file, though. cp: cannot stat `/tmp/wineinstall.conf': Onbekend bestand of map Admittedly, I don't necessarily need one, now that we have winecfg, but I still feel a bit insecure without one, and I did after all assent to one when I was offered it. So I see that as a problem-- either the install should not offer it, or it should be able to give it to you when you say yes to the offer. And it certainly shouldn't say that it gave you a config file when it didn't! But OK, it gives me an excuse to fire up Winecfg. First of all, good job! I give it a 90% on all points (attractiveness, understandablility, useability). What I loved (Winecfg): It works. No hitches, crashes, sloppy or missing text, it's snappy (doesn't take an eon to do anything) and it is very much a "normal" app insofar as it provides the type of feedback that I expect from an application (buttons grey out and become active exactly as I would expect, notably the "Apply" button), so I "know" (in the sense that a user 'knows' anything) that the program is working. It's pretty smart. The detection of my current environment seems good-- of course everything was 'correct', such as ALSA being selected in the Audio section, but the important thing is that I the user believed that winecfg had correctly selected the proper choice from a range of possibilities, rather than just the first thing on the drop-down list. I could very well be wrong (having just tried the autodetection, and therefore switched to OSS) but I *feel* nonetheless confident that, were I using OSS (only) or aRTs, that would have been selected instead-- and to a great extent, it's my belief that's important, rather than the truth. Even if I am wrong, it's nice to see sufficient confidence in the ALSA driver that it would be the default setting on a system like mine, rather than OSS as it has been in the past. If the driver was so bad that the OSS driver was far and away the better choice, even alphabetization shouldn't/wouldn't save ALSA from being first on the list (and thus the default for users who can't be bothered to configure their systems). It's pretty smart. Love the fact that I can set per-application defaults in the program. I haven't installed any native DLLs yet, so the Overrides are grayed out-- except for the text entry, so my impression is that if there was an available DLL to appear in that menu, the dialog would become active. This is supported by the 'not implemented yet' that I saw in another section of winecfg. If something doesn't work, you demonstrably mark it as not yet working, so being greyed out means what it's supposed to mean-- "not active because the conditions have not been met to activate" as opposed to "not working", or "half-working" or $DEITY knows what. I appreciate that and it increases my confidence in the application. It's pretty smart-- or is it? OK, the Drives tab was kind of a mixed bag for me. It works, and does what it says on the tin, as it were, but it seems kind of inflexible, which threw me off somewhat. Minor useablility niggle: You have to select the drive letter to adjust any setting; clicking on the drive's mapping in the list doesn't change the selection (but decolors the active selection). This is really confusing, especially since the mapping takes up a much bigger area than the drive letter, so is more likely to be clicked-- and more especially if one has not shown the expanded options, so you can see what you're actually working with. Major useability niggle: In the default setup, the D drive did not appear-- it was (as it has been for some time) invisibly mapped to my CD-ROM device, but incorrectly, so (it was mapped to /cdrom, which does not exist on my system; my device is mounted at /media/cdrecorder). Since the mapping was invisible (did not appear in winecfg's list, as in fact no CD-ROM device did), I tried the 'Automatic detection' to see if that would cause it to pop up. It did, since there's a mapping to /media/cdrecorder in my /etc/fstab-- but so did everything else in my /etc/fstab, much of which I did not want to be mapped as I don't expect to be using certain mounts with Wine. Using autodetect, /proc/sys/fs/binfmt_misc is mapped to the I drive, for goodness' sake! But I can remove mappings, so I did that.... and then I had big gaps in my drive lettering, which would make it difficult if not impossible to remember which drive letter pointed to what mount or folder. Unfortunately, only two of the eleven drives listed had an entry in the expanded "Manual Installation=> Name" field that suggested that if I changed the name there, it would change the drive letter; the other 9 drives were blank in that field. I found this alarming, so I renamed and redirected the symlinks in a file manager the way I normally would. Reopening winecfg afterwards displayed the changed settings properly (which is good), but my impression was that I shouldn't have had to be d*cking around with a file manager at all-- certainly if I wasn't already familiar with Wine configuration, I would have had a mess on my hands. So fine, Wine was now configured; time to install and run a program. My choice was Pretty Good Solitaire version 10.2.0 (trial version available from http://www.goodsol.com ). In the past, this program always installed fine, but would not run without DCOM installed, and with oleaut32 overridden. So first of all, good job! The OLE implementation is distinctly better! The program installed fine (of course, it generally does), and this is one of the apps that allows you to launch it at the end of the install. So I did. And it ran! The trial version splash opened up "normally" (meaning in a normal amount of time, and fully drawn). Some of the text was displaced (the buttons were fine, but the message area some text was on top of other text), but the buttons worked properly and I was able to enter a username and serial number (still not with the right-click "paste" command, which still causes a CTD, but ctrl-v worked perfectly well), the data was accepted, and I was able to create a user and enter the program. That's pretty much where the good news ends, though-- the game menu text (not the window text, but the game selector menus) is *huge* (it's clear, it's legible, it's complete, it's just noticeably way too big), and trying to select anything from any menu at all (window menu, game selector, toolbar button) results in a Run-time error '6': overflow [OK] dialog. Clicking OK closes the program cleanly, leaving me looking at a huge number of fixme: ole errors in the terminal. So then I installed DCOM98 (I have a Win98 license, so I try to stick with Win98 DLLs wherever possible), overriding ole32, oleaut32, and rpcrt4, and then ran the program from the terminal with the same overrides. It ran fine (naturally), but what surprised me was that the game selector menu text was now displayed at a normal font size for my resolution. Now it was time to see if I could set a per-application override using winecfg. This turned out to be confusing, and ultimately crashed winecfg (!). First I added the application on the Applications tab, but all that let me do was set the Win version for that app-- I was not really clear if having the application selected in the first tab would mean that settings in subsequent tabs would apply to that application only. So I removed PGS from the first tab, and went to the Libraries tab. I was able to type 'oleaut32.dll' in the text field, and, as I had thought, this activated the "Add" button, which then added oleaut32 (native, builtin) correctly-- but then I thought that I was perhaps making that the default setting, which I didn't want. So I removed that, and went to restart the process by adding PGS again to the Applications tab. I selected it fine (btw, *very* nice that the application's proper Windows icon appears in the file browser-- the file browser is also much, *much* faster), but when I hit OK to add it, winecfg crashed: winecfg fixme:winecfg:mode_to_label translate mewine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x41b26a33). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:41b26a33 ESP:7ba8cf94 EBP:7bab3820 EFLAGS:00010202( - 00 - -RI1) EAX:00000056 EBX:41be7ff4 ECX:7badbfe8 EDX:00000076 ESI:00000000 EDI:00000056 Stack dump: 0x7ba8cf94: 7bab74ac 7bc88810 7babf290 7ba8cfdc 0x7ba8cfa4: 7bab0e9c 7bab3820 00000000 7bc88fe0 0x7ba8cfb4: 7bab5ecb 7ba8cfcc 7bab74ac 7bab2029 0x7ba8cfc4: 7babefd4 7bab5ecb 7bc88ec8 7bab74ac 0x7ba8cfd4: 7bab3c29 00010036 7ba8d754 7baaaa54 0x7ba8cfe4: 00000044 7bc88fe0 7bab3820 7bab3c29 Backtrace: =>1 0x41b26a33 __strcasecmp+0x43 in libc.so.6 (0x7bab3820) 0x41b26a33 __strcasecmp+0x43 in libc.so.6: movzbl 0x0(%esi),%eax Modules: Module Address Debug info Name (60 modules) ELF 0x41a9e000-41ab7000 Deferred ld-linux.so.2 ELF 0x41ab9000-41bec000 Export libc.so.6 ELF 0x41bee000-41c14000 Deferred libm.so.6 ELF 0x41c16000-41c1a000 Deferred libdl.so.2 ELF 0x41c1c000-41ce9000 Deferred libx11.so.6 ELF 0x41ceb000-41cfa000 Deferred libxext.so.6 ELF 0x41cfc000-41d0d000 Deferred libz.so.1 ELF 0x41d0f000-41d22000 Deferred libpthread.so.0 ELF 0x41d24000-41d2d000 Deferred libsm.so.6 ELF 0x41d2f000-41d46000 Deferred libice.so.6 ELF 0x41d48000-41dbb000 Deferred libfreetype.so.6 ELF 0x41dbd000-41ddd000 Deferred libexpat.so.0 ELF 0x41ddf000-41e06000 Deferred libfontconfig.so.1 ELF 0x41e12000-41e1a000 Deferred libxrender.so.1 ELF 0x41eb3000-41eb9000 Deferred libxxf86dga.so.1 ELF 0x41f0a000-41f13000 Deferred libxcursor.so.1.0.2 ELF 0x41f15000-41f19000 Deferred libxrandr.so.2 ELF 0x42047000-42050000 Deferred libgcc_s.so.1 ELF 0x422c8000-42380000 Deferred libgl.so.1 ELF 0x42605000-4261d000 Deferred libnsl.so.1 ELF 0x4261f000-42628000 Deferred librt.so.1 ELF 0x43010000-43015000 Deferred libxxf86vm.so.1 ELF 0x7b3f3000-7b41b000 Deferred winspool.drv<elf> \-PE 0x7b400000-7b41b000 \ winspool.drv ELF 0x7b41b000-7b4da000 Deferred comctl32<elf> \-PE 0x7b430000-7b4da000 \ comctl32 ELF 0x7b4da000-7b4fa000 Deferred iphlpapi<elf> \-PE 0x7b4e0000-7b4fa000 \ iphlpapi ELF 0x7b4fa000-7b545000 Deferred rpcrt4<elf> \-PE 0x7b510000-7b545000 \ rpcrt4 ELF 0x7b545000-7b5d4000 Deferred gdi32<elf> \-PE 0x7b560000-7b5d4000 \ gdi32 ELF 0x7b5d4000-7b707000 Deferred user32<elf> \-PE 0x7b600000-7b707000 \ user32 ELF 0x7b707000-7b749000 Deferred advapi32<elf> \-PE 0x7b720000-7b749000 \ advapi32 ELF 0x7b749000-7b7d8000 Deferred ole32<elf> \-PE 0x7b760000-7b7d8000 \ ole32 ELF 0x7b7d8000-7b837000 Deferred shlwapi<elf> \-PE 0x7b7f0000-7b837000 \ shlwapi ELF 0x7b837000-7b900000 Deferred shell32<elf> \-PE 0x7b850000-7b900000 \ shell32 ELF 0x7b900000-7b990000 Deferred comdlg32<elf> \-PE 0x7b910000-7b990000 \ comdlg32 ELF 0x7ba96000-7bac0000 Deferred winecfg<elf> \-PE 0x7baa0000-7bac0000 \ winecfg ELF 0x7bb0f000-7bc20000 Deferred kernel32<elf> \-PE 0x7bb40000-7bc20000 \ kernel32 ELF 0x7bd37000-7bd42000 Deferred libnss_files.so.2 ELF 0x7bd42000-7bd4d000 Deferred libnss_nis.so.2 ELF 0x7bd4d000-7bd58000 Deferred libnss_compat.so.2 ELF 0x7bd74000-7be69000 Deferred libwine_unicode.so.1 ELF 0x7be85000-7bf00000 Deferred ntdll<elf> \-PE 0x7bea0000-7bf00000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7f852000-7f856000 Deferred iso8859-15.so ELF 0x7f878000-7ff7a000 Deferred fglrx_dri.so ELF 0x7ff7a000-80000000 Deferred winex11.drv<elf> \-PE 0x7ff90000-80000000 \ winex11.drv ELF 0xb7fcb000-b7fe4000 Deferred libwine.so.1 Threads: process tid prio (all id:s are in hex) 00000008 (D) c:\windows\system\winecfg.exe 00000009 0 <== WineDbg terminated on pid 0x8 ... maybe that means something to you. I reopened winecfg, and added and selected goodsol.exe again. *Now* I see that the titlebar changes to "Wine configuration for goodsol.exe" as I progress through the other tabs! That's actually quite nifty, but who really looks at their titlebar? I wish I could think of a more "in your face" indication that I was now creating a per-application setting rather than a default one, but I can't, so this will have to do (and it is, after all, nifty). So I added ole32 and oleaut32 (at first with .dll, but then I took that out), saved and ran just plain old wine goodsol.exe (I was in the directory), and it ran properly. So winecfg does that right, too. PGS is the only app I've tried so far, and the only problem I've found is that I usually run with the game's sound off, but I turned it on to test and the game essentially slowed to a crawl when dealing the cards, then redraw seemed to hang (I switched desktops, and when I came back I had only a titlebar, no game window. All it said in the terminal was ALSA lib pcm_dmix.c:746:(snd_pcm_dmix_open) The dmix plugin supports only playback stream I then set a per-application setting using winecfg that this application should use OSS, and that solved it. So the long and the short of it is that winecfg does make it easier for you to solve many of these problems and configure Wine properly (excepting registry entry creation issues), but it doesn't make it any easier to recognize what the problem in fact is-- you still have to be able to figure that out yourself and know what needs to be done. But once you do, winecfg makes putting it all together much easier, and is, in and of itself, a real nice app. Wine has also incorporated noticeable improvements, which I could see even in this very limited test, so while I expect that apps I commonly run will still encounter problems, I feel that things are on the upswing once again and that, during the upcoming months, I will see more problems I currently have melting away... which is just what I, as a user, want to see, and how I want to feel when I install a new Wine. So thanks!! Good work!! And I hope that this feedback is useful to you. Holly

6 6

DCOM Regression
by Jan Schiefer 02 Jul '05

02 Jul '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When I run DCOM98.exe with newest CVS I get "A required resource appears to be corrupted". Also no text in the license aggreement. Greetings, Jan Schiefer! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCxlwizC00UKXFdVcRAlPKAKDFEoQ9ALVxL6cw8sFf1Tw4OXlb8gCgp/dT XP9Gc/1eDtl83BckBRlDnts= =Hurd -----END PGP SIGNATURE-----

1 0

Re: wine/dlls/winmm lolvldrv.c
by Eric Pouech 02 Jul '05

02 Jul '05

Alexandre Julliard a écrit : > ChangeSet ID: 18492 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/06/27 14:51:41 > > Modified files: > dlls/winmm : lolvldrv.c > > Log message: > Get rid of the WaveMapper and MidiMapper options, the defaults should > be good enough in all cases. the only issue with this is that names for mappers changed over time in windows from the good ol' days, they were msacm.drv and midimap.drv there are now msacm32.drv and midimap.dll A+ -- Eric Pouech

1 0

kernel32 test
by Eric Pouech 02 Jul '05

02 Jul '05

can someone run the attached test (which is an evolution of dlls/kernel/tests/atom.c) on a win9x box and send me back the results... the semantics for getting an atom name with a buffer too small are so inconsistent on XP, I'd like to get an idea of what gives on Win9x (and even NT if there are some takers) TIA -- Eric Pouech

1 0

The wine-patches archives
by Tom Wickline 02 Jul '05

02 Jul '05

Looks like ""Downloadable version" is stuck at 9 MB last time I checked we were at a new record of 10.2 MB ......... Newman to the rescue ? Cheers, Tom

2 2

Re: RICHED20: add textserv.h (3rd try)
by Robert Shearman 02 Jul '05

02 Jul '05

Mike McCormack wrote: > > Use DECLARE_INTERFACE macros. > > Mike > > > ChangeLog: > * add textserv.h > >------------------------------------------------------------------------ > >+#ifndef __WINE_TEXTSERV_H >+#define __WINE_TEXTSERV_H >+ >+#ifdef __cplusplus >+extern "C" { >+#endif >+ >+DEFINE_GUID(IID_ITextServices,0x8d33f740,0xcf58,0x11ce,0xa8,0x9d,0x00,0xaa,0x00,0x6c,0xad,0xc5); >+DEFINE_GUID(IID_ITextHost, 0xc5bdd8d0,0xd26e,0x11ce,0xa8,0x9e,0x00,0xaa,0x00,0x6c,0xad,0xc5); >+DEFINE_GUID(IID_ITextHost2, 0xc5bdd8d0,0xd26e,0x11ce,0xa8,0x9e,0x00,0xaa,0x00,0x6c,0xad,0xc5); >+ >+/***************************************************************************** >+ * ITextServices interface >+ */ >+typedef struct ITextServices ITextServices; >+ >+#define INTERFACE ITextServices >+DECLARE_INTERFACE_(ITextServices,IUnknown) > > This would be much easier in IDL. Why did you do it all by hand? -- Rob Shearman

2 1

Re: Wine avitools/aviplay fails with CO_E_NOTINITIALIZED for any AVI file
by Alex Villacís Lasso 01 Jul '05

01 Jul '05

>It worked in the past. When pclsidHandler is set to NULL it performs >a registry lookup as the native version does it. If these registry >entries are missing it has a problem and could perhaps return the >mentioned error - don't know as I have never tested it. > >In the past these informations were part of the default registry of >wine but with the addition of the self-registration of many libraries >this has been removed. Don't ask me how to get the library to >register itself - guess it has to do with regsrv32.exe, but I am not >sure. I am already too long out of the substance. > > Based on a certain verification in the source code, I made aviinfo to work by adding the following to the registry: [Software\\Classes\\CLSID\\{00020000-0000-0000-C000-000000000046}\\InProcServer32] 1110571609 @="avifil32.dll" "LoadWithoutCOM"=dword:00000000 As far as I can see, the key "LoadWithoutCOM" only needs to exist; it does not need to be set to any particular value. The aviplay program has yet to work because the 128x128 AVI file I was using for the test in one machine (apparently) mandates a 128x128 screen resolution which is (yet) unsupported by my X configuration, and the ideal 640x480 test AVI is on the other (currently inaccessible) machine: trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 128: 320x240x16 @60 Hz (XRandR) trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 129: 360x200x16 @85 Hz (XRandR) trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 130: 320x200x16 @85 Hz (XRandR) trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 131: 320x175x16 @85 Hz (XRandR) trace:x11settings:X11DRV_Settings_CreateDriver Setting up display settings for DDRAW (XRandR) fixme:avifile:AVIFileInit (): stub! [Stream 0: vids.cvid, cineapk.avi v�eo #0] trace:x11settings:X11DRV_ChangeDisplaySettingsExW ((null),0x707bf768,(nil),0x00000004,(nil)) trace:x11settings:X11DRV_ChangeDisplaySettingsExW flags=FULLSCREEN trace:x11settings:X11DRV_ChangeDisplaySettingsExW DM_fields=BITSPERPEL,PELSWIDTH,PELSHEIGHT trace:x11settings:X11DRV_ChangeDisplaySettingsExW width=128 height=128 bpp=24 freq=1887172668 (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsExW No matching mode found! (XRandR) ddraw.SetDisplayMode: 0x88760078 (change resolution!) But this raises the following questions: * Why is not avifil32.dll adding this key on registration by regsvr32? (I could submit a patch to do it, but see next questions) * Is this the correct usage of avifil32.dll? The loading of this dll occurs via SHCoCreateInstance in shell32/shellole.c, and the comment on the usage of the LoadWithoutCOM key goes like this: //* if a special registry key is set, we load a shell extension without help of OLE32 *// bLoadWithoutCOM = (ERROR_SUCCESS == SHQueryValueExW(hKey, sLoadWithoutCOM, 0, 0, 0, 0)); Is this the correct (or even supported) usage for avifil32.dll? This LoadWithoutCOM kludge does not appear anywhere else in my registry, and it looks like it is intended for shell extensions only. What is the meaning of "shell extension" here? Does avifil32.dll qualify? (I think not, because avifil32 is concerned with AVI file handling, not with user interface. However, I might be wrong.) The last thing I want is to submit a patch, only to be rejected because it attempts to use a DLL in a way not intended by its design. So, is this approach correct (adding LoadWithoutCOM as part or regsvr32 initialization of avifil32.dll), or should an apartment actually be initialized in full COM style? Do you know if LoadWithoutCOM is used anywhere else in Wine? Alex Villacís Lasso

3 2

Wine CVS gl headers error in configure and compilation errors
by Martin Wolf 01 Jul '05

01 Jul '05

hello i just wanted to compile recent wine cvs and configure gives me this output als you expect compilation is broken too. checking GL/glx.h presence... yes configure: WARNING: GL/glx.h: present but cannot be compiled configure: WARNING: GL/glx.h: check for missing prerequisite headers? configure: WARNING: GL/glx.h: see the Autoconf documentation configure: WARNING: GL/glx.h: section "Present But Cannot Be Compiled" configure: WARNING: GL/glx.h: proceeding with the preprocessor's result configure: WARNING: GL/glx.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## here is the compilation error. make[2]: Leaving directory `/home/martin/wine/dlls/glu32' make[2]: Entering directory `/home/martin/wine/dlls/glut32' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon64 -pipe -fomit-frame-pointer -o glut.o glut.c gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon64 -pipe -fomit-frame-pointer -o user.o user.c gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon64 -pipe -fomit-frame-pointer -o window.o window.c ../../tools/winebuild/winebuild -D__WINESRC__ -o glut32.dll.dbg.c --debug -C. glut.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon64 -pipe -fomit-frame-pointer -o glut32.dll.dbg.o glut32.dll.dbg.c ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./glut32.spec glut.o glut32.dll.dbg.o -o glut32.dll.so -L../../dlls -L../../dlls/kernel32 -lkernel32 -L../../libs/wine -lwine -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXext -lX11 -lGL -lGLU -lglut -lXmu -lXi -L../../libs/port -lwine_port make[2]: Leaving directory `/home/martin/wine/dlls/glut32' gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon64 -pipe -fomit-frame-pointer -o winstation.o winstation.c make[2]: Entering directory `/home/martin/wine/dlls/d3d8' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon64 -pipe -fomit-frame-pointer -o basetexture.o basetexture.c gcc -o wineserver atom.o change.o class.o clipboard.o console.o context_alpha.o context_i386.o context_powerpc.o context_sparc.o debugger.o event.o fd.o file.o handle.o hook.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o ptrace.o queue.o region.o registry.o request.o semaphore.o serial.o signal.o snapshot.o sock.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o -L../libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port In file included from /usr/X11R6/include/GL/glx.h:336, from d3d8_private.h:34, from basetexture.c:31: /usr/X11R6/include/GL/glxext.h:267: Fehler: Redefinition des typedef »GLXFBConfigSGIX« /usr/X11R6/include/GL/glx.h:156: Fehler: vorherige Deklaration von »GLXFBConfigSGIX« war hier make[2]: *** [basetexture.o] Fehler 1 make[2]: Leaving directory `/home/martin/wine/dlls/d3d8' make[1]: *** [d3d8] Fehler 2 make[1]: Leaving directory `/home/martin/wine/dlls' make: *** [dlls] Fehler 2 make: *** Warte auf noch nicht beendete Prozesse... make[1]: Leaving directory `/home/martin/wine/server' i hope you can help me... regards martin PS: get direct input8 working ;)

1 0

Re: SHELL32/tests: Re: add a test for IShellFolder_ParseDisplayName
by Alexandre Julliard 01 Jul '05

01 Jul '05

Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > ChangeLog: > Saulius Krasuckas <saulius.krasuckas(a)ieee.org> > Added test for IShellFolder_ParseDisplayName. The test fails here: shlfolder.c:90: Test failed: ParseDisplayName returned 80070002, expected E_FAIL -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSHTML: Added test of IOleObject::[SG]etClientSite
by Paul Vriens 01 Jul '05

01 Jul '05

On Fri, 2005-07-01 at 20:38, Jacek Caban wrote: > > #include "mshtml.h" > +#include "mshtmhst.h" > + > +#include "mshtml.h" You've included mshtml.h twice. Cheers, Paul.

1 0

IE4 support for msxml
by Vijay Kiran Kamuju 01 Jul '05

01 Jul '05

Hi, Are we supporting IE4? There are some changes in the interfaces for msxml and also there are changes in guids in the subsequent versions. How to handle ie4 finterface changes in msxml.idl? Thanks, Vijay

2 3

winecfg audio question
by Robert Reif 01 Jul '05

01 Jul '05

Here is a patch that adds an audio driver configure button and tries to send a DRV_CONFIGURE message to the selected audio driver. It doesn't work because it can't find the audio driver. However, hard coding the driver name to "joystick.drv" does display the joystick config dialog so it should work. Any ideas why it doesn't work? Once this works, it should be possible to implement a real config dialog for each audio driver. Index: programs/winecfg/En.rc =================================================================== RCS file: /home/wine/wine/programs/winecfg/En.rc,v retrieving revision 1.41 diff -p -u -r1.41 En.rc --- programs/winecfg/En.rc 19 May 2005 11:14:52 -0000 1.41 +++ programs/winecfg/En.rc 27 Jun 2005 00:07:29 -0000 @@ -139,6 +139,8 @@ BEGIN LTEXT "Audio driver: ",IDC_STATIC,10,20,60,8 COMBOBOX IDC_AUDIO_DRIVER,70,18,85,85,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP PUSHBUTTON "Autodetect",IDC_AUDIO_AUTODETECT,170,20,49,14 + PUSHBUTTON "Configure",IDC_AUDIO_CONFIGURE,170,40,49,14 + PUSHBUTTON "Control Panel",IDC_AUDIO_CONTROL_PANEL,170,60,49,14 END STRINGTABLE DISCARDABLE Index: programs/winecfg/Makefile.in =================================================================== RCS file: /home/wine/wine/programs/winecfg/Makefile.in,v retrieving revision 1.13 diff -p -u -r1.13 Makefile.in --- programs/winecfg/Makefile.in 9 Mar 2005 16:41:30 -0000 1.13 +++ programs/winecfg/Makefile.in 27 Jun 2005 00:07:29 -0000 @@ -4,7 +4,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = winecfg.exe APPMODE = -mwindows -IMPORTS = comdlg32 comctl32 shell32 ole32 shlwapi user32 advapi32 kernel32 +IMPORTS = comdlg32 comctl32 shell32 ole32 shlwapi user32 advapi32 kernel32 winmm C_SRCS = \ appdefaults.c \ Index: programs/winecfg/audio.c =================================================================== RCS file: /home/wine/wine/programs/winecfg/audio.c,v retrieving revision 1.9 diff -p -u -r1.9 audio.c --- programs/winecfg/audio.c 23 Jun 2005 11:42:54 -0000 1.9 +++ programs/winecfg/audio.c 27 Jun 2005 00:07:29 -0000 @@ -37,6 +37,7 @@ #include <shlguid.h> #include <shlwapi.h> #include <shlobj.h> +#include <mmsystem.h> #include "winecfg.h" #include "resource.h" @@ -64,6 +65,46 @@ static void selectAudioDriver(HWND hDlg, } } +static void configureAudioDriver(HWND hDlg, const char *drivername) +{ + int i; + const AUDIO_DRIVER *pAudioDrv = NULL; + + if ((pAudioDrv = getAudioDrivers())) + { + for (i = 0; *pAudioDrv->szName; i++, pAudioDrv++) + { + if (!strcmp (pAudioDrv->szDriver, drivername)) + { + HDRVR hdrvr; + char wine_driver[MAX_NAME_LENGTH + 8]; + sprintf(wine_driver, "wine%s.drv", pAudioDrv->szDriver); + hdrvr = OpenDriverA(wine_driver, 0, 0); + if (hdrvr != 0) + { + if (SendDriverMessage(hdrvr, DRV_QUERYCONFIGURE, 0, 0) != 0) + { + DRVCONFIGINFO dci; + LONG lRes; + dci.dwDCISize = sizeof (dci); + dci.lpszDCISectionName = (LPWSTR)0; + dci.lpszDCIAliasName = (LPWSTR)0; + lRes = SendDriverMessage(hdrvr, DRV_CONFIGURE, 0, (LONG)&dci); + } + CloseDriver(hdrvr, 0, 0); + } + else + { + char str[1024]; + sprintf(str, "Couldn't open %s!", wine_driver); + MessageBox(NULL, str, "ERROR", MB_OK | MB_ICONERROR); + } + break; + } + } + } +} + static void initAudioDlg (HWND hDlg) { char *curAudioDriver = get_reg_key(config_key, "Drivers", "Audio", "alsa"); @@ -172,6 +213,15 @@ AudioDlgProc (HWND hDlg, UINT uMsg, WPAR selectAudioDriver(hDlg, (char*)pAudioDrv[selected_driver].szDriver); } break; + case IDC_AUDIO_CONFIGURE: + { + const AUDIO_DRIVER *pAudioDrv = getAudioDrivers(); + int selected_driver = SendDlgItemMessage(hDlg, IDC_AUDIO_DRIVER, CB_GETCURSEL, 0, 0); + configureAudioDriver(hDlg, (char*)pAudioDrv[selected_driver].szDriver); + } + break; + case IDC_AUDIO_CONTROL_PANEL: + break; } break; Index: programs/winecfg/resource.h =================================================================== RCS file: /home/wine/wine/programs/winecfg/resource.h,v retrieving revision 1.24 diff -p -u -r1.24 resource.h --- programs/winecfg/resource.h 19 May 2005 11:14:52 -0000 1.24 +++ programs/winecfg/resource.h 27 Jun 2005 00:07:29 -0000 @@ -123,3 +123,6 @@ /* audio tab */ #define IDC_AUDIO_AUTODETECT 1300 #define IDC_AUDIO_DRIVER 1301 +#define IDC_AUDIO_CONFIGURE 1302 +#define IDC_AUDIO_CONTROL_PANEL 1303 +

2 2

Steam Problems
by Ivan Gyurdiev 01 Jul '05

01 Jul '05

I am experiencing two problems w/ Steam: 1) It's always on top of all other windows,on all workspaces of GNOME, which is very annoying, and makes it impossible to try HL2. If clicked while HL2 is on startup screen it will crash the game. 2) If you click on any game, go to Update News, it will crash every time. If there are Update News when Steam is started, it will crash (but it will work after that). Here's the output, although it doesn't look very helpful to me: ALSA lib control.c:739:(snd_ctl_open_noupdate) Invalid CTL plug:hw:0 err:mmio:MMIO_ParseExtA No . in szFileName: "" err:mmio:MMIO_ParseExtA No . in szFileName: "C:\\Program Files\\Valve\ \Steam\\" fixme:sync:CreateIoCompletionPort (0xffffffff, (nil), 00000000, 00000000): stub. fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 Win32 MiniDump Helper version 1.0.0.0 (c) Copyright 2000-2003 Valve Corporation All rights reserved. Expected argument 'ProcessId'. Usage: WriteMiniDump [@argfile] [/?|h|help] [/v|version] [/Type <value>] <ProcessId> <DumpFile> @argfile Read arguments from a file. /? Show usage. /v Show version. /Type <value> Select dump type values are: normal full ProcessId Select process id for which to generate a dump DumpFile Select path of output dump file Shutting down. . . 1 -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

2 3

Re: advapi32: Branch the LSA functions from security.c to lsa.c [RESEND]
by Robert Shearman 01 Jul '05

01 Jul '05

James Hawkins wrote: >--- /dev/null 2005-06-27 14:12:40.646578496 -0500 >+++ dlls/advapi32/lsa.c 2005-06-27 16:51:17.000000000 -0500 >@@ -0,0 +1,433 @@ >+/* >+ * Implementation of the Local Security Authority API >+ * >+ * This library is free software; you can redistribute it and/or >+ * modify it under the terms of the GNU Lesser General Public >+ * License as published by the Free Software Foundation; either >+ * version 2.1 of the License, or (at your option) any later version. >+ * >+ * This library is distributed in the hope that it will be useful, >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >+ * Lesser General Public License for more details. >+ * >+ * You should have received a copy of the GNU Lesser General Public >+ * License along with this library; if not, write to the Free Software >+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >+ */ > > You should include a copyright line that states the major copyright owners of the code. You can do this by looking through the CVS history or just by copying the copyright lines from security.c -- Rob Shearman

1 0

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 July 2005