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

registry: order of insertion of values
by James Hawkins 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

--- 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 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

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 04 Apr '05

04 Apr '05

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