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

registry: order of insertion of values
by James Hawkins April 4, 2005

April 4, 2005

Hi, I've been fixing tests that fail on all of Win9x/XP/2003, and I've found a difference between the way we insert new values. What happens in advapi32/tests/registry.c - test_enum_value is that we already have 3 values created under the key Wine\\Test before the test starts. Then we make four calls to RegSetValueExA with 'Test' as the name of the value to set. Since this value does not exist, it is created. After these four calls, here are all the values under the test key: Environment Variables: %LONGSYSTEMVAR% = "bar" %FOO% = "ImARatherLongButIndeedNeededString" value: Test type: REG_SZ data: foobar data_count: 7, strlen("foobar") + 1 value: Test1 type: REG_EXPAND_SZ data: %LONGSYSTEMVAR%\subdir1 data_count: 24, same as above value: Test2 type: REG_SZ data: %LONGSYSTEMVAR%\subdir1 data_count: 24 value: Test3 type: REG_EXPAND_SZ data: %FOO%\subdir1 data_count: 14 We then go on to query RegEnumValueA with value index 0. In wine the key that is queried is Test because we insert new keys in alphabetical order and Test is before Test1..3. On all versions of windows, querying value index 0 returns information for Test1. I added another RegEnumValueA with value index 3 and it turns out that this is the index for Test, leading me to believe that windows just inserts the keys in order of creation. It says on msdn that "because values are not ordered, any new value will have an arbitrary index", but should we also store new values in creation order? If you remove the initial RegSetValueEx calls creating the 'Test' value and match the results of wine with those from windows, all the tests pass of wine and windows. I will be sending a patch to remove these RegSetValueEx tests, because they really should be in their own test (as seen by this bug), but it did give me the chance to raise the question of whether we should store new values in creation order or not. What's the verdict? -- James Hawkins

2 5

[riched20/list.c] Exception in ME_DumpDocument
by Paul Vriens April 4, 2005

April 4, 2005

Hi, After I found that one of the files still contained a debugchannel for riched20 (instead of richedit), I added both to see a trace (just for the fun of it). This however raised an exception in ME_DumpDocument: trace:riched20:ME_DumpDocument Start Paragraph(ofs=0) - StartRow - A-LOT-OF-TEXT Paragraph(ofs=266) - StartRow - A-LOT-OF-TEXT Paragraph(ofs=316) - StartRow - Run("L"\00b6"", 0) wine_dbg_vprintf: debugstr buffer overflow (contents: 'A-LOT-OF-TEXT') First chance exception: assertion failed in 32-bit code (0x001117a2). backtrace: Wine-dbg>bt Backtrace: =>1 0x001117a2 (0x00809b30) 2 0x0027d882 (0x00809c5c) 3 0x00157023 NTDLL_dbg_vprintf(format=0x112f5c48, args=0x809cd8) [/data/install/linux/wine-src/wine/dlls/ntdll/debugtools.c:267] in ntdll (0x00809c84) 4 0x001570c8 NTDLL_dbg_vlog+0x44(cls=0x3, channel=0x112ff48c, function=0x112f5c38, format=0x112f5c48, args=0x809cd8) [/data/install/linux/wine-src/wine/dlls/ntdll/debugtools.c:303] in ntdll (0x00809ca0) 5 0x0023f880 wine_dbg_log+0x28(cls=0x3, channel=0x112ff48c, func=0x112f5c38, format=0x112f5c48) [/data/install/linux/wine-src/wine/libs/wine/debug.c:234] in libwine.so.1 (0x00809cc0) 6 0x112ebca6 ME_DumpDocument(buffer=0x7f370510) [list.c:174] in riched20 (0x00809ce8) Questions: - Could the exception be because of the length of the TRACE string? - Is there a particular reason for the 'different' debugchannel? - Is ME_DumpDocument used just for debugging? The first line says: /* FIXME this is useless, */ Cheers, Paul.

2 2

Hints needed for riched20/scroll bug solving
by Paul Vriens April 4, 2005

April 4, 2005

Hi, When starting the Zoo Tycoon 1 demo for the first time, the license agreement appears. I know that nobody reads this ;-) but hey. When I click in the scrollbar (page down) the page goes down 1 page and the scrollbar changes. When I however click the down-arrow in the scrollbar, the page goes down (2 lines) but the scrollbar doesn't change. Who/what is responsible for this scrollbar? I've tried (extra) tracing for riched20 and scroll but nothing so far. Cheers, Paul.

2 2

Re: black-box implementation of CryptProtectData/CryptUnprotectData
by Mike McCormack April 4, 2005

April 4, 2005

Kees Cook wrote: > This patch implements a functional replacement for crypt32.dll's > CryptProtectData and CryptUnprotectData. It does _not_ perform any > encrypt/decryption, but rather tracks the cipher/entropy/plain triplets > so that programs depending on the calls will operate correctly. Perhaps you could make it work "right" by using a key stored in ssh-agent? > diff -u -p -u -p -r1.92 ChangeLog Just writing a ChangeLog entry like this is OK: ChangeLog: * Added black-box implementation of CryptProtectData/CryptUnprotectData. You don't need to try patch ChangeLog, because it's going to change alot as patches are applied. Just write the message you want to put in there. > + hr = HRESULT_FROM_WIN32(RegOpenKeyExW(HKEY_CURRENT_USER, wszProtectDataMap, 0, KEY_READ, &hkeyMap)); > + if (!SUCCEEDED(hr)) Why do you convert the error code to a HRESULT here? Since you don't do it elsewhere in your code, why not compare the returned value to ERROR_SUCCESS, like you do below? > + if (RegEnumKeyExW(hkeyMap, dwIndex, wszIndexKey, &dwIndexKeyLength, NULL, NULL, NULL, NULL) != ERROR_SUCCESS) > + break; Personally, I prefer the following, as it makes the lines shorter, makes it easier to add a printf("%ld\n",r); and makes the comparison more obvious. r = RegEnumKeyExW(hkeyMap, ... if( r != ERROR_SUCCES ) break; > + if (WINE_TRACE_ON(crypt)) > + wine_dbg_printf("\tChecking Map Index %s\n", debugstr_w(wszIndexKey)); You don't need the WINE_TRACE_ON() check, because TRACE already does that for the default debug channel, so the following is the same: TRACE("\tChecking Map Index %s\n", debugstr_w(wszIndexKey); > + if (!bFound) { > + TRACE("no matches\n"); > + } Sometimes you used K&R style brackets and indenting, sometimes you used ANSI C style. It's better to choose one or the other and stick to it. > + return SUCCEEDED(RegSetValueExW(hkeyOpen,wszName,0,dwType, > + pData.pbData,pData.cbData)); The SUCCEEDED() macro is only for HRESULT values, so the above is going to succeed in alot of cases where it shouldn't. > + } > + > + DWORD dwDisposition; In an effort to maintain portability, we don't use C99 style variable declarations. Mike

3 5

WineConf Agenda
by Brian Vincent April 4, 2005

April 4, 2005

I'm going to start this off with a huge apology - there's a very real chance I've asked someone to do a presentation and it's not on this list. If so, you need to email me to remind me. If you were definitely planning on presenting something because I emailed you, let me know - there's lots of space available. I know this only affects 2 or 3 people, but I tossed around a few ideas and didn't want to leave any loose ends. (Any of those items would make nice topics.) This is the initial agenda for WineConf. I hope to add a few more items, but Jeremy suggested I pull the trigger and announce it. I agree - there's enough here to fill two days and leave a lot of time for people to get together in small groups. Only the first two items are in any formal order: Alexandre - Keynote (He said he's reusing last year's slides.) Dimi - to do list / status update Steven Edwards and the ReactOS crew Charles W Stevenson - Winelib / Winelib porting / and a commercial perspective Andrew Barlett / Samba team? - Samba 4, authentication, lots of intelligent ideas Juan Lang - Wine's RPC + Samba or something like that :) Jeremy White - CXTest Jason Edmeades - DirectX 9 / wined3d / eye candy I think a full agenda would be about 11 items. If you would like to present something let me know - there's definitely space available. If you've been wondering, "There's a neat project I'd like to do if I could only get a few more people interested", well, this is the perfect time to bring it up. If there's something strategic to Wine development, this is a great time to discuss it. For example, we've had mixed feelings regarding revision control and its been suggested to bring it up as a topic. Would anyone find it useful to discuss subversion vs. arch vs. cvs? We could probably get Mike Hearn to show off how he manages patches with SVK and then let him arm wrestle Alexandre about whether arch is better. Friday night we will have an informal dinner after meeting up at the hotel. The conference will kick off Saturday morning on campus around 8am. Lunch will be provided on Saturday and Sunday as well as dinner on Saturday. There will definitely be a lot of time for informal discussion. For the Samba guys - I think there's a great opportunity to share some knowledge to prevent anyone from reinventing the wheel. If there's any topic you'd find interesting, let me know. If you'd just like to hear a specific topic from the Wine folks, we can arrange that. For travel arrangements, please join wineconf(a)winehq.org ( http://www.winehq.org/mailman/listinfo/wineconf ) For instance, I'm actually flying into Frankfurt on April 23rd and it'd be cool to hang out with anyone arriving early. If you haven't made reservations at a hotel, don't worry too much. There's still rooms available as Mr. Schmid described here: http://www.winehq.com/hypermail/wine-devel/2005/03/1119.html If you haven't signed up on the RSVP list, please do so. It can be found on the WineConf page: http://www.winehq.com/site/wineconf Lastly, if you have any questions / comments / criticisms let me know. -Brian PS. Dimi owes me a beer from last year, so we're all obligated to go out Friday night. I'm looking forward to seeing everyone in Stuttgart!

8 15

Re: [SERVER] fix potential leak on window.c (bug2849)
by Dimitrie O. Paun April 4, 2005

April 4, 2005

On Mon, Apr 04, 2005 at 09:38:40AM +0200, Raphael wrote: > Hi, > > changelog: > - fix potential leak on window.c as seen in bug2849 + { + free_region( tmp ); + goto error; + } Can you please use 4-spaces indentation, like the rest of the file? -- Dimi.

1 0

Re: Wine device drivers proposal
by Damjan Jovanovic April 4, 2005

April 4, 2005

--- Kuba Ober <kuba(a)mareimbrium.org> wrote: > > > I've been trying to add STI (still image) > support to > > > Wine, and I've made some progress. However, I > see a > > > deep and unsurmountable need to add (at least > > > user-space) device drivers to Wine, and I would > like > > > some feedback on these ideas. > > > > Drivers belong in the kernel. > > Not necessarily. In fact, only the part that > directly touches the hardware > really belongs there. There's nothing wrong with > doing rest of the processing > (i.e. the non time-critical parts) in the userspace. > In fact, that likely > makes the kernel a safer place. > > > If there's no Linux driver for a device, > > then Wine cannot support it. > > That would be stupid. > > > In that case, the first step is to write a > > Linux device driver for it, which has the added > advantage that other > > native linux applications can use the hardware. > > Huh? What about sane? It can e.g. use libusb quite > nicely and *portably* to > say access usb scanners. I.e. it flies on both > windows *and* linux. > > > You can't load a Windows driver that accesses > hardware in Wine, as Wine > > is a user-space application with no I/O > privileges. > > You could, with help of a special kernel driver to > forward the requests > between hardware and userspace. libusb and usbfs do > that already for usb, > i.e. at the current point in time wine can be able > to natively support any > usb device minidriver that doesn't use a class > driver. Class drivers can be > easily developed by snatching code from linux > kernel, as long as licenses are > fine of course. All that without touching the kernel > in any way. And I mean > here full support for *any* usb device, rain or > shine. Network adapters > (visible in wine only, but so what?), scanners, > cheap webcams whose > manufacturers don't care enough to release the > specs, and the list goes on. > > Cheers, Kuba > I agree, Kuba. Which of the approaches I suggested (or any new ones) do you propose? Bye Damjan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

1 0

Wine device drivers proposal
by Damjan Jovanovic April 4, 2005

April 4, 2005

Hi I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas. Basically, many Windows device drivers are really trivial, but required for many apps. A scanner driver typically just accepts commands from a user-space app, does minimal processing, and forwards that to Windows. I've already hacked up Wine to get the same functionality, and it works - partially. I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver. The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() The problem is, how is a handle mapped to the appropriate driver? I've thought about it, and come up with 3 solutions. The first 3 don't require changes to the wineserver but aren't pretty. 1. Make the driver a true Linux kernel mode driver, and the handle its device file handle. Since ReadFile() and WriteFile() just do read() and write() system calls, this can be done. The problem is, DeviceIoControl() has to be implemented using ioctl(), and that's dangerous (sending the right codes to the wrong device can be catastrophic). Also, it's not portable to other OS's, and requires writing a kernel module (which isn't fun). 2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries. 3. KERNEL32.DLL and / or NTDLL.DLL keep their own handle table so they know which handles are driver handles and deal with those appropriately. Having to look up these tables for every call to ReadFile(), WriteFile() and DeviceIoControl() might be very inefficient, though. 4. Use an in-process solution, like a winelib DLL that has exports for dealing with ReadFile(), WriteFile() and DeviceIoControl(). This could be the most efficient, but then again, you need an efficient way to test a handle for being a driver handle, find the appropriate driver, and call the right exported function, which likely means the wineserver needs to have knowledge of these drivers and provide functionality for testing a handle for being a driver handle and have a way to find the driver. Let me know what you think. Bye Damjan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

6 6

Re: black-box implementation of CryptProtectData/CryptUnprotectData
by James Hawkins April 4, 2005

April 4, 2005

On Apr 3, 2005 10:12 PM, Kees Cook <kees(a)outflux.net> wrote: > To store the triplets, these functions use the registry: > > Registry Layout: > HKEY_CURRENT_USER\Software\Wine\Crypt\ProtectData\Map\[index] > Cipher: HEX string > Entropy: HEX string > DataDescription: WCHAR > Plain: HEX string > I'll have to be honest that I haven't looked over the code yet, but I do have a concern. Do these values have to be stored under Software\Wine? That location is for wine-specific configuration options and not api use, unless I'm mistaken. Do we know if this data is stored in the registry in windows, and if so where is it stored? (because I know it's not Software\Wine ;-) -- James Hawkins

2 4

Re: WineConf Agenda
by Steven Edwards April 4, 2005

April 4, 2005

--- Andrew Tridgell <tridge(a)osdl.org> wrote: > Finally, if we have time, I'd like to discuss cooperation on IDL files > and MSRPC interfaces. Yes I would like to discuss this as well. Eirc Kohl has made quite a lot of changes to WIDL for ReactOS to support our MSRPC and PLug and Pray implementation and I would like to see these changes merged back in for Wine and Samba so we can adopt a common IDL compiler. Thanks Steven __________________________________ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest

2 2

Re: dsound: fix test to compile on vs
by Dimitrie O. Paun April 3, 2005

April 3, 2005

On Sun, Apr 03, 2005 at 01:25:22PM -0500, James Hawkins wrote: > Changelog > * LPLPVOID is unknown to Visual Studio, use LPVOID * instead. If so, how come it's defined in our headers? We should remove the definition if it's not standard. -- Dimi.

2 1

Re: [WAVEMAP] waveOutGetPosition bug
by Robert Reif April 3, 2005

April 3, 2005

Robert Reif wrote: > dlls/winmm/wavemap/wavemap.c > Correctly handle where waveOutGetPosition changes timepos.wType > because the requested type is not supported. > > dlls/winmm/tests/wave.c > Changed regression test to make sure position is correctly > checked when a different type is returned. > > > This revised patch adds the following: dlls/winmm/wavemap/wavemap.c Adds Jeremy White's waveOutGetPosition fix to waveInGetPosition. dlls/winmm/tests/capture.c Adds Jeremy White's WAVE_FORMAT_DIRECT/WAVE_MAPPER fix. Adds waveInGetPosition checks. Index: dlls/winmm/tests/capture.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/tests/capture.c,v retrieving revision 1.15 diff -u -p -r1.15 capture.c --- dlls/winmm/tests/capture.c 3 Nov 2004 22:13:44 -0000 1.15 +++ dlls/winmm/tests/capture.c 3 Apr 2005 17:30:59 -0000 @@ -50,6 +50,87 @@ static const char * wave_in_error(MMRESU return long_msg; } +static void check_position(int device, HWAVEIN win, DWORD bytes, + LPWAVEFORMATEX pwfx ) +{ + MMTIME mmtime; + DWORD samples; + double duration; + MMRESULT rc; + DWORD returned; + + samples=bytes/(pwfx->wBitsPerSample/8*pwfx->nChannels); + duration=((double)samples)/pwfx->nSamplesPerSec; + + mmtime.wType = TIME_BYTES; + rc=waveInGetPosition(win, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveInGetPosition(%s): rc=%s\n",dev_name(device),wave_in_error(rc)); + if (mmtime.wType != TIME_BYTES && winetest_debug > 1) + trace("waveInGetPosition(%s): TIME_BYTES not supported, returned %s\n", + dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveInGetPosition(%s): returned %ld bytes, " + "should be %ld\n", dev_name(device), returned, bytes); + + mmtime.wType = TIME_SAMPLES; + rc=waveInGetPosition(win, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveInGetPosition(%s): rc=%s\n",dev_name(device),wave_in_error(rc)); + if (mmtime.wType != TIME_SAMPLES && winetest_debug > 1) + trace("waveInGetPosition(%s): TIME_SAMPLES not supported, " + "returned %s\n",dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveInGetPosition(%s): returned %ld samples, " + "should be %ld\n", dev_name(device), bytes_to_samples(returned, pwfx), + bytes_to_samples(bytes, pwfx)); + + mmtime.wType = TIME_MS; + rc=waveInGetPosition(win, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveInGetPosition(%s): rc=%s\n",dev_name(device),wave_in_error(rc)); + if (mmtime.wType != TIME_MS && winetest_debug > 1) + trace("waveInGetPosition(%s): TIME_MS not supported, returned %s\n", + dev_name(device), wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveInGetPosition(%s): returned %ld ms, " + "should be %ld\n", dev_name(device), bytes_to_ms(returned, pwfx), + bytes_to_ms(bytes, pwfx)); + + mmtime.wType = TIME_SMPTE; + rc=waveInGetPosition(win, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveInGetPosition(%s): rc=%s\n",dev_name(device),wave_in_error(rc)); + if (mmtime.wType != TIME_SMPTE && winetest_debug > 1) + trace("waveInGetPosition(%s): TIME_SMPTE not supported, returned %s\n", + dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveInGetPosition(%s): SMPTE test failed\n", + dev_name(device)); + + mmtime.wType = TIME_MIDI; + rc=waveInGetPosition(win, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveInGetPosition(%s): rc=%s\n",dev_name(device),wave_in_error(rc)); + if (mmtime.wType != TIME_MIDI && winetest_debug > 1) + trace("waveInGetPosition(%s): TIME_MIDI not supported, returned %s\n", + dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveInGetPosition(%s): MIDI test failed\n", + dev_name(device)); + + mmtime.wType = TIME_TICKS; + rc=waveInGetPosition(win, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveInGetPosition(%s): rc=%s\n",dev_name(device),wave_in_error(rc)); + if (mmtime.wType != TIME_TICKS && winetest_debug > 1) + trace("waveInGetPosition(%s): TIME_TICKS not supported, returned %s\n", + dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveInGetPosition(%s): TICKS test failed\n", + dev_name(device)); +} + static void wave_in_test_deviceIn(int device, LPWAVEFORMATEX pwfx, DWORD format, DWORD flags, LPWAVEINCAPS pcaps) { HWAVEIN win; @@ -107,6 +188,9 @@ static void wave_in_test_deviceIn(int de pwfx->nSamplesPerSec, pwfx->wBitsPerSample, pwfx->nChannels, nSamplesPerSec, wBitsPerSample, nChannels); + /* Check that the position is 0 at start */ + check_position(device, win, 0, pwfx); + frag.lpData=malloc(pwfx->nAvgBytesPerSec); frag.dwBufferLength=pwfx->nAvgBytesPerSec; frag.dwBytesRecorded=0; @@ -131,6 +215,9 @@ static void wave_in_test_deviceIn(int de ok(rc==MMSYSERR_NOERROR,"waveInAddBuffer(%s): rc=%s\n", dev_name(device),wave_in_error(rc)); + /* Check that the position is 0 at start */ + check_position(device, win, 0, pwfx); + rc=waveInStart(win); ok(rc==MMSYSERR_NOERROR,"waveInStart(%s): rc=%s\n", dev_name(device),wave_in_error(rc)); @@ -141,6 +228,7 @@ static void wave_in_test_deviceIn(int de ok(frag.dwBytesRecorded==pwfx->nAvgBytesPerSec, "frag.dwBytesRecorded=%ld, should=%ld\n", frag.dwBytesRecorded,pwfx->nAvgBytesPerSec); + /* stop playing on error */ if (res!=WAIT_OBJECT_0) { rc=waveInStop(win); @@ -316,11 +404,12 @@ static void wave_in_test_device(int devi format.nAvgBytesPerSec=format.nSamplesPerSec*format.nBlockAlign; format.cbSize=0; wave_in_test_deviceIn(device,&format,win_formats[f][0],0, &capsA); - wave_in_test_deviceIn(device,&format,win_formats[f][0], - WAVE_FORMAT_DIRECT, &capsA); - if (device != WAVE_MAPPER) + if (device != WAVE_MAPPER) { + wave_in_test_deviceIn(device,&format,win_formats[f][0], + WAVE_FORMAT_DIRECT, &capsA); wave_in_test_deviceIn(device,&format,win_formats[f][0], WAVE_MAPPED, &capsA); + } } /* Try a PCMWAVEFORMAT aligned next to an unaccessible page for bounds @@ -342,11 +431,12 @@ static void wave_in_test_device(int devi pwfx->nBlockAlign=pwfx->nChannels*pwfx->wBitsPerSample/8; pwfx->nAvgBytesPerSec=pwfx->nSamplesPerSec*pwfx->nBlockAlign; wave_in_test_deviceIn(device,pwfx,WAVE_FORMAT_2M08,0, &capsA); - wave_in_test_deviceIn(device,pwfx,WAVE_FORMAT_2M08, - WAVE_FORMAT_DIRECT, &capsA); - if (device != WAVE_MAPPER) + if (device != WAVE_MAPPER) { + wave_in_test_deviceIn(device,pwfx,WAVE_FORMAT_2M08, + WAVE_FORMAT_DIRECT, &capsA); wave_in_test_deviceIn(device,pwfx,WAVE_FORMAT_2M08, WAVE_MAPPED, &capsA); + } } VirtualFree(twoPages, 2 * dwPageSize, MEM_RELEASE); } Index: dlls/winmm/tests/wave.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/tests/wave.c,v retrieving revision 1.50 diff -u -p -r1.50 wave.c --- dlls/winmm/tests/wave.c 18 Mar 2005 10:25:48 -0000 1.50 +++ dlls/winmm/tests/wave.c 3 Apr 2005 17:31:00 -0000 @@ -303,7 +303,7 @@ static const char * wave_out_caps(DWORD #undef ADD_FLAG } -static const char * wave_time_format(UINT type) +const char * wave_time_format(UINT type) { static char msg[32]; #define TIME_FORMAT(f) case f: return #f @@ -373,6 +373,34 @@ const char * get_format_str(WORD format) return msg; } +DWORD bytes_to_samples(DWORD bytes, LPWAVEFORMATEX pwfx) +{ + return bytes / pwfx->nBlockAlign; +} + +DWORD bytes_to_ms(DWORD bytes, LPWAVEFORMATEX pwfx) +{ + return bytes_to_samples(bytes, pwfx) * 1000 / pwfx->nSamplesPerSec; +} + +DWORD time_to_bytes(LPMMTIME mmtime, LPWAVEFORMATEX pwfx) +{ + if (mmtime->wType == TIME_BYTES) + return mmtime->u.cb; + else if (mmtime->wType == TIME_SAMPLES) + return mmtime->u.sample * pwfx->nBlockAlign; + else if (mmtime->wType == TIME_MS) + return mmtime->u.ms * pwfx->nAvgBytesPerSec / 1000; + else if (mmtime->wType == TIME_SMPTE) + return ((mmtime->u.smpte.hour * 60.0 * 60.0) + + (mmtime->u.smpte.min * 60.0) + + (mmtime->u.smpte.sec) + + (mmtime->u.smpte.frame / 30.0)) * pwfx->nAvgBytesPerSec; + + trace("FIXME: time_to_bytes() type not supported\n"); + return -1; +} + static void check_position(int device, HWAVEOUT wout, DWORD bytes, LPWAVEFORMATEX pwfx ) { @@ -380,6 +408,7 @@ static void check_position(int device, H DWORD samples; double duration; MMRESULT rc; + DWORD returned; samples=bytes/(pwfx->wBitsPerSample/8*pwfx->nChannels); duration=((double)samples)/pwfx->nSamplesPerSec; @@ -388,60 +417,69 @@ static void check_position(int device, H rc=waveOutGetPosition(wout, &mmtime, sizeof(mmtime)); ok(rc==MMSYSERR_NOERROR, "waveOutGetPosition(%s): rc=%s\n",dev_name(device),wave_out_error(rc)); - if (mmtime.wType == TIME_BYTES) - ok(mmtime.u.cb==bytes, - "waveOutGetPosition(%s): returned %ld bytes, should be %ld\n", - dev_name(device),mmtime.u.cb, bytes); - else + if (mmtime.wType != TIME_BYTES && winetest_debug > 1) trace("waveOutGetPosition(%s): TIME_BYTES not supported, returned %s\n", dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveOutGetPosition(%s): returned %ld bytes, " + "should be %ld\n", dev_name(device), returned, bytes); mmtime.wType = TIME_SAMPLES; rc=waveOutGetPosition(wout, &mmtime, sizeof(mmtime)); ok(rc==MMSYSERR_NOERROR, "waveOutGetPosition(%s): rc=%s\n",dev_name(device),wave_out_error(rc)); - if (mmtime.wType == TIME_SAMPLES) - ok(mmtime.u.sample==samples, - "waveOutGetPosition(%s): returned %ld samples, should be %ld\n", - dev_name(device), mmtime.u.sample, samples); - else + if (mmtime.wType != TIME_SAMPLES && winetest_debug > 1) trace("waveOutGetPosition(%s): TIME_SAMPLES not supported, " "returned %s\n",dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveOutGetPosition(%s): returned %ld samples, " + "should be %ld\n", dev_name(device), bytes_to_samples(returned, pwfx), + bytes_to_samples(bytes, pwfx)); mmtime.wType = TIME_MS; rc=waveOutGetPosition(wout, &mmtime, sizeof(mmtime)); ok(rc==MMSYSERR_NOERROR, "waveOutGetPosition(%s): rc=%s\n",dev_name(device),wave_out_error(rc)); - if (mmtime.wType == TIME_MS) - ok(mmtime.u.ms==floor(duration*1000.0), - "waveOutGetPosition(%s): returned %ld ms, should be %ld\n", - dev_name(device), mmtime.u.ms, (long)floor(duration*1000.0)); - else + if (mmtime.wType != TIME_MS && winetest_debug > 1) trace("waveOutGetPosition(%s): TIME_MS not supported, returned %s\n", - dev_name(device),wave_time_format(mmtime.wType)); + dev_name(device), wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveOutGetPosition(%s): returned %ld ms, " + "should be %ld\n", dev_name(device), bytes_to_ms(returned, pwfx), + bytes_to_ms(bytes, pwfx)); mmtime.wType = TIME_SMPTE; rc=waveOutGetPosition(wout, &mmtime, sizeof(mmtime)); ok(rc==MMSYSERR_NOERROR, "waveOutGetPosition(%s): rc=%s\n",dev_name(device),wave_out_error(rc)); - if (mmtime.wType == TIME_SMPTE) - { - BYTE frames=(BYTE)ceil(fmod(duration*mmtime.u.smpte.fps, mmtime.u.smpte.fps)); - ok(mmtime.u.smpte.hour==(BYTE)(floor(duration/(60*60))) && - mmtime.u.smpte.min==(BYTE)(fmod(floor(duration/60), 60)) && - mmtime.u.smpte.sec==(BYTE)(fmod(duration,60)) && - mmtime.u.smpte.frame==frames, - "waveOutGetPosition(%s): returned %d:%d:%d %d, " - "should be %d:%d:%d %d\n", dev_name(device), mmtime.u.smpte.hour, - mmtime.u.smpte.min, mmtime.u.smpte.sec, mmtime.u.smpte.frame, - (BYTE)(floor(duration/(60*60))), - (BYTE)(fmod(floor(duration/60), 60)), - (BYTE)(fmod(duration,60)), - frames); - } - else + if (mmtime.wType != TIME_SMPTE && winetest_debug > 1) trace("waveOutGetPosition(%s): TIME_SMPTE not supported, returned %s\n", dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveOutGetPosition(%s): SMPTE test failed\n", + dev_name(device)); + + mmtime.wType = TIME_MIDI; + rc=waveOutGetPosition(wout, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveOutGetPosition(%s): rc=%s\n",dev_name(device),wave_out_error(rc)); + if (mmtime.wType != TIME_MIDI && winetest_debug > 1) + trace("waveOutGetPosition(%s): TIME_MIDI not supported, returned %s\n", + dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveOutGetPosition(%s): MIDI test failed\n", + dev_name(device)); + + mmtime.wType = TIME_TICKS; + rc=waveOutGetPosition(wout, &mmtime, sizeof(mmtime)); + ok(rc==MMSYSERR_NOERROR, + "waveOutGetPosition(%s): rc=%s\n",dev_name(device),wave_out_error(rc)); + if (mmtime.wType != TIME_TICKS && winetest_debug > 1) + trace("waveOutGetPosition(%s): TIME_TICKS not supported, returned %s\n", + dev_name(device),wave_time_format(mmtime.wType)); + returned = time_to_bytes(&mmtime, pwfx); + ok(returned == bytes, "waveOutGetPosition(%s): TICKS test failed\n", + dev_name(device)); } static void wave_out_test_deviceOut(int device, double duration, @@ -1030,7 +1068,7 @@ static void wave_out_tests() "waveOutGetDevCapsW(%s): MMSYSERR_NOERROR or MMSYSERR_NOTSUPPORTED " "expected, got %s\n",dev_name(WAVE_MAPPER),mmsys_error(rc)); else - ok(rc==MMSYSERR_BADDEVICEID || rc==MMSYSERR_NODRIVER || + ok(rc==MMSYSERR_BADDEVICEID || rc==MMSYSERR_NODRIVER || rc==MMSYSERR_NOTSUPPORTED, "waveOutGetDevCapsW(%s): MMSYSERR_BADDEVICEID or MMSYSERR_NODRIVER " " or MMSYSERR_NOTSUPPORTED expected, got %s\n", Index: dlls/winmm/tests/winmm_test.h =================================================================== RCS file: /home/wine/wine/dlls/winmm/tests/winmm_test.h,v retrieving revision 1.8 diff -u -p -r1.8 winmm_test.h --- dlls/winmm/tests/winmm_test.h 19 Aug 2004 01:13:58 -0000 1.8 +++ dlls/winmm/tests/winmm_test.h 3 Apr 2005 17:31:00 -0000 @@ -72,3 +72,7 @@ extern const char* wave_open_flags(DWORD extern const char* mmsys_error(MMRESULT); extern const char* wave_out_error(MMRESULT); extern const char* get_format_str(WORD format); +extern const char* wave_time_format(UINT type); +extern DWORD bytes_to_samples(DWORD bytes, LPWAVEFORMATEX pwfx); +extern DWORD bytes_to_ms(DWORD bytes, LPWAVEFORMATEX pwfx); +extern DWORD time_to_bytes(LPMMTIME mmtime, LPWAVEFORMATEX pwfx); Index: dlls/winmm/wavemap/wavemap.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/wavemap/wavemap.c,v retrieving revision 1.42 diff -u -p -r1.42 wavemap.c --- dlls/winmm/wavemap/wavemap.c 15 Mar 2005 15:39:18 -0000 1.42 +++ dlls/winmm/wavemap/wavemap.c 3 Apr 2005 17:31:01 -0000 @@ -428,9 +428,10 @@ static DWORD wodGetPosition(WAVEMAPDATA* if (lpTime->wType == TIME_MS) timepos.wType = TIME_BYTES; + /* This can change timepos.wType if the requested type is not supported */ val = waveOutGetPosition(wom->u.out.hInnerWave, &timepos, dwParam2); - if (lpTime->wType == TIME_BYTES || lpTime->wType == TIME_MS) + if (timepos.wType == TIME_BYTES) { DWORD dwInnerSamplesPerOuter = wom->nSamplesPerSecInner / wom->nSamplesPerSecOuter; if (dwInnerSamplesPerOuter > 0) @@ -464,10 +465,12 @@ static DWORD wodGetPosition(WAVEMAPDATA* /* Once we have the TIME_BYTES right, we can easily convert to TIME_MS */ if (lpTime->wType == TIME_MS) - lpTime->u.cb = MulDiv(lpTime->u.cb, 1000, wom->avgSpeedOuter); + lpTime->u.ms = MulDiv(lpTime->u.cb, 1000, wom->avgSpeedOuter); + else + lpTime->wType = TIME_BYTES; } - else if (lpTime->wType == TIME_SAMPLES) - lpTime->u.cb = MulDiv(timepos.u.cb, wom->nSamplesPerSecOuter, wom->nSamplesPerSecInner); + else if (lpTime->wType == TIME_SAMPLES && timepos.wType == TIME_SAMPLES) + lpTime->u.sample = MulDiv(timepos.u.sample, wom->nSamplesPerSecOuter, wom->nSamplesPerSecInner); else /* other time types don't require conversion */ lpTime->u = timepos.u; @@ -962,15 +965,62 @@ static DWORD widUnprepare(WAVEMAPDATA* w static DWORD widGetPosition(WAVEMAPDATA* wim, LPMMTIME lpTime, DWORD dwParam2) { DWORD val; - + MMTIME timepos; TRACE("(%p %p %08lx)\n", wim, lpTime, dwParam2); - val = waveInGetPosition(wim->u.in.hInnerWave, lpTime, dwParam2); - if (lpTime->wType == TIME_BYTES) - lpTime->u.cb = MulDiv(lpTime->u.cb, wim->avgSpeedOuter, wim->avgSpeedInner); - if (lpTime->wType == TIME_SAMPLES) - lpTime->u.cb = MulDiv(lpTime->u.cb, wim->nSamplesPerSecOuter, wim->nSamplesPerSecInner); - /* other time types don't require conversion */ + memcpy(&timepos, lpTime, sizeof(timepos)); + + /* For TIME_MS, we're going to recalculate using TIME_BYTES */ + if (lpTime->wType == TIME_MS) + timepos.wType = TIME_BYTES; + + /* This can change timepos.wType if the requested type is not supported */ + val = waveInGetPosition(wim->u.in.hInnerWave, &timepos, dwParam2); + + if (timepos.wType == TIME_BYTES) + { + DWORD dwInnerSamplesPerOuter = wim->nSamplesPerSecInner / wim->nSamplesPerSecOuter; + if (dwInnerSamplesPerOuter > 0) + { + DWORD dwInnerBytesPerSample = wim->avgSpeedInner / wim->nSamplesPerSecInner; + DWORD dwInnerBytesPerOuterSample = dwInnerBytesPerSample * dwInnerSamplesPerOuter; + DWORD remainder = 0; + + /* If we are up sampling (going from lower sample rate to higher), + ** we need to make a special accomodation for times when we've + ** written a partial output sample. This happens frequently + ** to us because we use msacm to do our up sampling, and it + ** will up sample on an unaligned basis. + ** For example, if you convert a 2 byte wide 8,000 'outer' + ** buffer to a 2 byte wide 48,000 inner device, you would + ** expect 2 bytes of input to produce 12 bytes of output. + ** Instead, msacm will produce 8 bytes of output. + ** But reporting our position as 1 byte of output is + ** nonsensical; the output buffer position needs to be + ** aligned on outer sample size, and aggressively rounded up. + */ + remainder = timepos.u.cb % dwInnerBytesPerOuterSample; + if (remainder > 0) + { + timepos.u.cb -= remainder; + timepos.u.cb += dwInnerBytesPerOuterSample; + } + } + + lpTime->u.cb = MulDiv(timepos.u.cb, wim->avgSpeedOuter, wim->avgSpeedInner); + + /* Once we have the TIME_BYTES right, we can easily convert to TIME_MS */ + if (lpTime->wType == TIME_MS) + lpTime->u.ms = MulDiv(lpTime->u.cb, 1000, wim->avgSpeedOuter); + else + lpTime->wType = TIME_BYTES; + } + else if (lpTime->wType == TIME_SAMPLES && timepos.wType == TIME_SAMPLES) + lpTime->u.sample = MulDiv(timepos.u.sample, wim->nSamplesPerSecOuter, wim->nSamplesPerSecInner); + else + /* other time types don't require conversion */ + lpTime->u = timepos.u; + return val; }

1 0

Riched20: thanks + regression "beta" not shown
by Tobias Burnus April 3, 2005

April 3, 2005

Hello, first I'd really like to thank the riched20 workers, notably Krzysztof Foltman and Phil Krylov. For the application Diamond it made a big difference: Instead of "[[Aring]]" etc. one sees the proper symbol and it looks much nicer. But the biggest advantage is that one can now copy or save the text; before the app was simply crashing when attempting to do so. Regression: One of the later riched20 patches, possibly http://cvs.winehq.org/patch.py?id=16672, caused a regression with the richedit control in Diamond. Before it showed a beta character from the Symbol font, now it only shows a box ("[]"). If one saves the output (rtf export) one sees ------------------- {\rtf1\ansi\ansicpg1252\uc1\deff0\deflang1031\deflangfe1031{\fonttbl{\f0 Times New Roman;} {\f1\fcharset0 System;} {\f2\fcharset2 Symbol;} }{\*\generator Wine Riched20 2.0.????;}\pard\li0\fi0\ri0{\b\fs18\ul Bibliographic data} \par\pard\li0\fi0\ri0 [...] \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 b}{\fs18 = 5.8312(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 c}{\fs18 = 7.9564(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\fs18\f2 \u61538?}{\fs18 = 100.77(0) \u176?} ------------------- In the last line, after the \f2 (Symbol font), there should be a beta ("b" + Symbol font). Trace (starting from the "b = 5.8312(2)"): ------------ trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 177), counted = 177, len = 1, txt = "L"b"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 178), counted = 178, len = 14, txt = "L" = 5.8312(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 192), counted = 192, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 193, counted = 193 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 193), counted = 193, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 194), counted = 194, len = 1, txt = "L"c"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 195), counted = 195, len = 14, txt = "L" = 7.9564(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 209), counted = 209, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 210, counted = 210 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 210), counted = 210, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 211), counted = 211, len = 1, txt = "L"\f062"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 212), counted = 212, len = 14, txt = "L" = 100.77(0) \00b0"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 226), counted = 226, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 ------------ * * * * One feature request: Currently, tabs are shown as box ("[]"), how about replacing them with a simple space - that would increase the readability a lot. Currently, one gets (WINE-CVS): http://www.physik.fu-berlin.de/~tburnus/wine/diamond3.png (Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png) Tobias

6 7

wineps: rewriting in terms of 32-bit functions
by Dimitrie O. Paun April 3, 2005

April 3, 2005

Hi Huw, Currenty wineps.dll is one of the worse offenders in terms of using non-standard, 16-bit entry points. Namely, wineps makes use of the following 16-bit functions: CloseJob16() DrvGetPrinterData16() DrvSetPrinterData16() OpenJob16() SelectVisRgn16() WriteSpool16() I was wondering if there's anything that holds us back from using 32-bit APIs instead of the 16-bit ones like so: CloseJob16() --> ClosePrinter() DrvGetPrinterData16() --> GetPrinterDataEx() DrvSetPrinterData16() --> SetPrinterDataEx() OpenJob16() --> OpenPrinter() SelectVisRgn16() --> ? WriteSpool16() --> WritePrinter() I haven't looked too deeply into the problem, but given that you probably know the code inside out, maybe you can help me put this into perspective... -- Dimi.

1 0

Wine and twain
by Brouard Nicolas April 2, 2005

April 2, 2005

Hi, I haven't seen recent information on wine and twain. I already sent a similar mail to wine-users two weeks ago without answer. I am trying to test a Finereader Office (version 5) with an USB scanner. Everything seems working. But I get scanner not ready when searching for scanner. Sane, gimp or whatever are working well with my scanner. Doing WINEDEBUG=+loaddll wine finereader.exe I get: ... trace:loaddll:load_dll Loaded module L"C:\\program files\\abbyy finereader 5.0 office\\scan\\scanman0.dll" : native trace:loaddll:load_dll Loaded module L"c:\\windows\\system\ \msvcrt.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\ \msvcrt.dll" : builtin err:module:load_builtin_dll loaded .so for L"Twain.dll" but got L"twain_32.dll" instead - probably 16-bit dll trace:loaddll:MODULE_LoadModule16 Loaded module "c:\\windows\ \Twain.dll" : builtin Scanning driver not ready. But the scanner is ready: # sane-find-scanner -v searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid argument) checking /dev/usb/scanner0... failed to open (Invalid argument) ... checking /dev/usbscanner15... failed to open (Invalid argument) found USB scanner (vendor=0x03f0 [hp], product=0xb402 [photosmart 7700 series]) at libusb:002:002 found USB scanner (vendor=0x04b8 [EPSON], product=0x010f [EPSON Scanner 010F], chip=LM9832/3) at libusb:001:003 # scanimage -L device `plustek:libusb:001:003' is a Epson Perfection 1250/Photo USB flatbed scanner device `net:localhost:plustek:libusb:001:003' is a Epson Perfection 1250/Photo USB flatbed scanner Thus the device is something like "plustek:libusb:001:003" and # scanimage -d plustek:libusb:001:003 >foo.pnm works. Is there any wine test (windows exe) in order to test twain? Regards, Nicolas -- Brouard Nicolas <nicolas.brouard(a)libertysurf.fr>

1 0

Re: Improve the HHCTRL.OCX stub
by Jacek Caban April 2, 2005

April 2, 2005

Hi. Two small suggestions. +static char *command_to_string(UINT command) It could be const char. +{ +#define X(x) case x: return #x + + switch (command) + { + X( HH_DISPLAY_TOPIC ); + X( HH_DISPLAY_TOC ); + X( HH_DISPLAY_INDEX ); + X( HH_DISPLAY_SEARCH ); + X( HH_SET_WIN_TYPE ); + X( HH_GET_WIN_TYPE ); + X( HH_GET_WIN_HANDLE ); + X( HH_ENUM_INFO_TYPE ); + X( HH_SET_INFO_TYPE ); + X( HH_SYNC ); + X( HH_RESERVED1 ); + X( HH_RESERVED2 ); + X( HH_RESERVED3 ); + X( HH_KEYWORD_LOOKUP ); + X( HH_DISPLAY_TEXT_POPUP ); + X( HH_HELP_CONTEXT ); + X( HH_TP_HELP_CONTEXTMENU ); + X( HH_TP_HELP_WM_HELP ); + X( HH_CLOSE_ALL ); + X( HH_ALINK_LOOKUP ); + X( HH_GET_LAST_ERROR ); + X( HH_ENUM_CATEGORY ); + X( HH_ENUM_CATEGORY_IT ); + X( HH_RESET_IT_FILTER ); + X( HH_SET_INCLUSIVE_FILTER ); + X( HH_SET_EXCLUSIVE_FILTER ); + X( HH_INITIALIZE ); + X( HH_UNINITIALIZE ); + X( HH_PRETRANSLATEMESSAGE ); + X( HH_SET_GLOBAL_PROPERTY ); + } + +#undef X +} If command is not one of specificed in switch, function won't return a valid string. Thanks, Jacek

1 0

Nearly all Installshield installers fail
by Joaquín Fernández April 2, 2005

April 2, 2005

> With my application (Route 66), it enables me to start copying files, > however the progress bar never moves. However, the installer is doing > something but seems to be stuck somewhere. Maybe some deadlocks. Español: Yo tuve varios problemas con algunos programas que usan InstallShield como instalador (alrededor de 3 o 4) pero pude instalarlos usando WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". Puedes probar esto a ver si te funciona, para mí si funciona con estos programas en Wine 2004XXXX y 2005XXXX. Obviamente, verifica que tengas esas DLLs en el sistema. English: I have had many problems with InstallShield but i was able to install the programs (about 3 or 4 programs using InstallShield that i need) using WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". You can probe with this.. it worked for this programs in Wine 2004XXXX and 2005XXXX. Obviously, you must verify that this DLLs exist in the system dir. Regards Joaquin -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

2 1

Re: wine/dlls wininet/netconnection.c user/text.c ...
by Dimitrie O. Paun April 2, 2005

April 2, 2005

On Tue, Mar 29, 2005 at 01:49:22PM -0600, Alexandre Julliard wrote: > Log message: > Peter Berg Larsen <pebl(a)math.ku.dk> > Janitorial: Get rid of strncpy/strncpyW. This is cool stuff. Now it would be nice if someone hacks winapi_check to ... check for strncpy() business so it doesn't sneak back in. Other than that, are all strncpy() instances gone? If so we should also nuke strncpyW() from wine/unicode.h too. -- Dimi.

2 1

discusion about a message loop in listview.c
by Dietrich Teickner April 1, 2005

April 1, 2005

I have some weeks before reported, FlashFXP v3.02 loops with a message-loop in listview.c after login. It does this in Odin and in Wine. In Odin it stops in smaller time (deep 1000). Wine has a bigger stack, and so needs wine more time for this, bat I can see in the loog, the args for the function are more and more locatet at lower stack adresses. I have written this workarout for testing this problem in wine and in odin. with this FlashFXH 3.02 will display the contence of the server dir very fast at both environment. In the log I can see, that the message-loop was reported and stopped. I thing, we need a flag inside any item to report every function, that can called recursive, this item is in work (function-separart, or global ?), that can stop recursions of this type in the future or many programms. I have also found this try does also helps Agent 2.0 in the groups->defailt propertys (only odin-tested). This does also every crashs in earlyer builds with stack overflow in odin. Dietrich Index: wine/dlls/comctl32/listview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.406 diff -u -r1.406 listview.c --- wine/dlls/comctl32/listview.c 25 Mar 2005 20:49:00 -0000 1.406 +++ wine/dlls/comctl32/listview.c 29 Mar 2005 16:31:48 -0000 @@ -139,6 +139,7 @@ * WM_CREATE does not issue WM_QUERYUISTATE and associated registry * processing for "USEDOUBLECLICKTIME". */ +#define __T__ #include "config.h" #include "wine/port.h" @@ -7050,10 +7051,23 @@ * SUCCESS : TRUE * FAILURE : FALSE */ +#ifdef __T__ +static int zIndex = -2; +typedef struct { + PVOID lTol; + HWND cHwnd; + HWND cHwndParent; + INT cItem; + } SetItemStateLink, *PSetItemStateLink; +#endif static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *infoPtr, INT nItem, const LVITEMW *lpLVItem) { BOOL bResult = TRUE; LVITEMW lvItem; +#ifdef __T__ + int saveLastError = GetLastError(); + SetItemStateLink cTol = { NULL, infoPtr->hwndSelf, infoPtr->hwndNotify, nItem}; +#endif lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -7062,6 +7076,34 @@ lvItem.stateMask = lpLVItem->stateMask; TRACE("lvItem=%s\n", debuglvitem_t(&lvItem, TRUE)); +#ifdef __T__ + if (-2 == zIndex) + { + zIndex = TlsAlloc(); + SetLastError(saveLastError); + } /* endif */ + if (zIndex >= 0) + { + cTol.lTol = TlsGetValue(zIndex); + if (cTol.lTol < (PVOID)&cTol) + { + cTol.lTol = NULL; + } /* endif */ + SetLastError(saveLastError); + if (cTol.lTol + && (((PSetItemStateLink)cTol.lTol)->cHwnd == infoPtr->hwndSelf) + && (((PSetItemStateLink)cTol.lTol)->cHwndParent == infoPtr->hwndNotify) + && (((PSetItemStateLink)cTol.lTol)->cItem == nItem)) + { + TRACE_(listview)("(DT) Hwnd:%x,%x Parent:%x,%x Item:%d,%d, stop the recursion\n", infoPtr->hwndSelf, ((PSetItemStateLink)cTol.lTol)->cHwnd, + infoPtr->hwndNotify, ((PSetItemStateLink)cTol.lTol)->cHwndParent, + nItem, ((PSetItemStateLink)cTol.lTol)->cItem); + return TRUE; + } + TlsSetValue(zIndex,(LPVOID)&cTol); + SetLastError(saveLastError); + } +#endif if (nItem == -1) { /* apply to all items */ @@ -7070,6 +7112,14 @@ } else bResult = LISTVIEW_SetItemT(infoPtr, &lvItem, TRUE); +#ifdef __T__ + if (zIndex >= 0) + { + saveLastError = GetLastError(); + TlsSetValue(zIndex,(LPVOID)cTol.lTol); + SetLastError(saveLastError); + } +#endif /* *update selection mark

2 1

Nearly all Installshield installers fail
by Uwe Bonnes April 1, 2005

April 1, 2005

Hello, nearly all recent install shield installer fail for me, similar like: ... fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:sync:SetNamedPipeHandleState 0x1f0 0x42ad30e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x214 0x42ddc0e0 (nil) (nil) fixme:ole:RpcChannelBuffer_GetDestCtx (0x42551d8c,0x42551d90), stub! fixme:sync:SetNamedPipeHandleState 0x214 0x432080e0 (nil) (nil) fixme:ole:NdrConvert (pStubMsg == ^0x406cca80, pFormat == ^0x431041ba): stub. fixme:ole:NdrConvert (pStubMsg == ^0x42551d18, pFormat == ^0x431041ba): stub. err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, 0x00000000 fixme:ole:RpcChannelBuffer_GetDestCtx (0x42551d88,0x42551d8c), stub! fixme:sync:SetNamedPipeHandleState 0x1e8 0x42ff00e0 (nil) (nil) fixme:ole:NdrConvert (pStubMsg == ^0x406cca7c, pFormat == ^0x431041c8): stub. fixme:ole:NdrConvert (pStubMsg == ^0x42551d14, pFormat == ^0x431041c8): stub. fixme:sync:SetNamedPipeHandleState 0x1e4 0x432080e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x1e4 0x42bd60e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x1e4 0x42ad30e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x1ec 0x42bd60e0 (nil) (nil) fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0x8) 42de13b4 Do I have some bogus registry entries, did I miss some dll registration or is this the expected behaviour? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 6

RE: WineConf Agenda
by Charles W. Stevenson April 1, 2005

April 1, 2005

In presenting the commercial value of wine and why we chose to use it, etc. How much time do I have for the presentation? -----Original Message----- From: Jakob Eriksson [mailto:jakov(a)vmlinux.org] Sent: Thursday, March 31, 2005 11:20 PM To: wineconf(a)winehq.org Cc: Wine Devel; Charles.W.Stevenson(a)guptaworldwide.com Subject: Re: WineConf Agenda Brian Vincent wrote: >I think a full agenda would be about 11 items. If you would like to >present something let me know - there's definitely space available. >If you've been wondering, "There's a neat project I'd like to do if I >could only get a few more people interested", well, this is the >perfect time to bring it up. If there's something strategic to Wine >development, this is a great time to discuss it. > > I don't know if I can find the time to prepare a proper presentation, but if I do, I'd like talk about and get some input from you on the subject of testing. 1) I want the conformance tests done faster. (I have a clear idea how.) 2) What's almost never been brought up on wine-devel is the unit testing in the XP sense. 1 has been discussed on wine-devel quite a bit, so I'll skip it in this mail. regarding 2: CXTest is like application testing. This is good, high-level testing. The conformance tests test the Windows API. But in the case of a complicated API (and Windows is complicated) maybe we need to test the smaller units behind the API. So, the conformance tests often are somewhere between application testing and unit testing. Can we have an infrastructure for running unit tests of small units of code private to the implementation? I.e. these tests, we could call them "private tests", would not run on Windows, but during build of Wine. Would it be acceptable to just include extra test code in the implementation c file, surrounded by #ifdef COMPILE_PRIVATE_TESTS ? regards, Jakob

1 0

Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...
by Dimitrie O. Paun April 1, 2005

April 1, 2005

On Fri, Mar 25, 2005 at 11:11:04AM -0600, Alexandre Julliard wrote: > Modified files: > windows : scroll.c > dlls/x11drv : scroll.c > dlls/user/tests: win.c msg.c > > Log message: > Rein Klazes <wijn(a)wanadoo.nl> > ScrollDC and X11DRV_SCROLLDC should scroll only pixels coming from > within the visible region, clipped to the clipping region if that > exists. Add the destination of pixels coming from the outside of this > region to the update region. With tests that depend on this. > > Patch: http://cvs.winehq.org/patch.py?id=16854 Unfortunately, this patch doesn't fix bug 1091: http://bugs.winehq.org/show_bug.cgi?id=1091 -- Dimi.

2 3

Fwd: Re: [Wine]winetest and winrash
by Mitchell Mebane April 1, 2005

April 1, 2005

Ivan Leo Puoti wrote: > Mitchell Mebane wrote: > >> Hey there, >> >> I ran it on my XP Pro SP2 desktop and Windows Server 2003 under >> VMWare just fine, but when I ran it on Win2K Pro SP4 under VMWare, it >> told me the log was too large (6.4 MB > 1 MB) and it would only send >> partial results. Is there any reason this log would be almost an >> order of magnitude larger than the others? >> > From the log it appears to be a problem with the PathIsValidCharA API, > you may want to report this to wine-devel. > > Ivan. > > . > OK, I'll do so. Results are on this page: http://test.winehq.com/data/200503311000/ Specifically, this: http://test.winehq.com/data/200503311000/2000_mmebane/shlwapi:path.txt The OS setup I ran the test under is pretty much a bare-bones Win2K Pro SP4 install. If you want any more information about it, let me know. --Mitchell -- The roots of education are bitter, but the fruit is sweet. --Aristotle

1 0