January 2007 - Wine-Devel - list.winehq.org

Re: Another report of malware running on Wine

by Pavel Troller

Hi! This weekend my son downloaded a trojan masking as keygen for a Symbian mobile application. After running a trojan, a tooltip in the systray appeared saying something like "Your computer is infected". After that, I inspected his .wine directory. There were many files added in various directories (system32, windows, even root of c:, they were partly .exe, partly .dll, ane one even .htm :-). I looked it in the web browser and it displayed a page saying that my comp is full of malware, spyware and various other *ware and that the only cure is to download a specialized application from them :-). They tried to make me shocked by displaying something that "THEY know that your computer has IP address <my real IP ADDRESS>, you are using Windows XP (hahaha) and your browser is MSIE 6 (hahahaha). However, this page was not displayed by the trojan, so I think that something has failed in it and it was unable to fire the formerly mentioned MSIE6 :-). Two unknown processes were permanently running by wine. After cleaning all this mess, normal wine operation has been fully restored. With regards, Pavel Troller

Jan. 30, 2007

Re: Test case for Bug 50 [Was: Bug 50]

by Dmitry Timoshkov

"Pedro Araujo Chaves Jr." <inckie(a)gmail.com> wrote: > Here's the picture: when an application calls TextOut() for printing > text, the usual (at least in my case) call sequence in Wine is > > TextOut() > TextOutA() > ExtTextOutA() > ExtTextOutW() (the one I patched) > GetTextExtentPointW() > GetTextExtentPoint32W() (the wide-char version of the one you mentioned) > GetTextExtentExPointW() > WineEngGetTextExtentExPoint() (the one that actually gets the > individual character widths) > > That is, at some point, TextOut() indirectly uses > GetTextExtentPoint32() to get the dimensions, okay. But what I need is > to check the text width *after* it was output by TextOut() -- in other > words, after the function has returned, to see if it output the text > properly. In Wine, I tried the trick of making ExtTextOutW() return > the said value, and the tests passed without a hitch, which means the > text is being properly justified. The problem is that such is not an > acceptable way of doing things, and, to use Dan Kegel's words, that is > not going to fly on Windows. > > To be a bit clearer, in my tests I do call GetTextExtent32() in order > to compute the remaining white space for the justification part, and > what I want to check is whether TextOut() understood it right or not. Then probably DrawText(DT_CALCRECT) could better suit your needs. -- Dmitry.

Jan. 30, 2007

Re: [Bug 6689] Created links do not reflect WINEPREFIX used

by Alexander Nicolaysen Sørnes

Mandag 29 januar 2007 20:58, skrev Kuba Ober: > On Monday 29 January 2007 12:50, Tomas Carnecky wrote: > > Lei Zhang wrote: > > > Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar > > > worked in KDE. In Gnome, it works if "run from the terminal" is set. > > > > > > Unfortunately the Freedesktop spec for desktop entries does not > > > specify a way to add environment variables. So yes, it looks like > > > we'll need a wrapper script, or perhaps add a --prefix option to Wine? > > > > or change the exec line to: > > /bin/sh -i -c "WINEPREFIX=foo wine" > > Instead, wouldn't > /bin/sh -i -c "WINEPREFIX=foo exec wine" > also properly dispose of the now useless copy of the shell? > You don't have to start a new shell if you use env WINEPREFIX=foo wine Regards, Alexander N. Sørnes > Cheers, Kuba

Jan. 29, 2007

Please help me debug wineserver

by Misha Koshelev

Hi, I am new to wine programming but have a fair amount of experience with C/C++ programming in general. I have recently decided to make the Vector NTI application work on Wine, and after overcoming quite a few installation difficulties by making an install shell script, I have run in to a problem that I have traced down to wineserver. This problem occurs after repeatedly changing folders in the Vector NTI "Open Molecule File" dialog, which does not use the standard open file Windows dialog (e.g., the "Open Shortcut" dialog in the same program works fine). Wineserver crashes with the following error message: wineserver: object.c:274: release_object: Assertion `obj->refcount' failed. On looking at the output of WINEDEBUG=+server, it seems that the "Vector NTI" thread is woken up, and then receives a USER_APC, at which time this crash occurs. I am including at the end of this message a wineserver gdb backtrace and the last few lines of the WINEDEBUG=+server output. If anyone sees anything that jumps out, I would appreciate your help. Thank you very much. Misha --- Backtrace: #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d56770 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7d57ef3 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d4fdbb in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x0805ad0a in release_object (ptr=0x83ad0a0) at object.c:274 #5 0x0806c196 in end_wait (thread=0x83ad100) at thread.c:451 #6 0x0806c9b7 in wake_thread (thread=0x83ad100) at thread.c:578 #7 0x0806cddd in queue_apc (process=<value optimized out>, thread=0x83ad100, apc=0x83ad888) at thread.c:751 #8 0x0806cebb in thread_queue_apc (thread=0x83ad100, owner=0x0, call_data=0xbffe77b8) at thread.c:764 #9 0x08052dc2 in async_terminate (async=0x82e7780, status=6) at fd.c:1294 #10 0x0804bf70 in dir_destroy (obj=0x83ad0a0) at file.h:131 #11 0x0805ac9a in release_object (ptr=0x83ad0a0) at object.c:279 #12 0x0806c196 in end_wait (thread=0x83ad100) at thread.c:451 #13 0x0806cf30 in thread_timeout (ptr=0x83aa1c0) at thread.c:598 #14 0x08051e3a in get_next_timeout () at fd.c:688 #15 0x08052ea0 in main_loop () at fd.c:456 #16 0x08057c4a in main (argc=2, argv=0xbffe8034) at main.c:136 Last few lines of WINEDEBUG=+server output: 0009: create_key() = 0 { hkey=0x168, created=0 } 0009: get_key_value( hkey=0x168, name=L"Desktop" ) 0009: get_key_value() = 0 { type=2, total=44, data={25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,4c,00,45,00,25,00,5c,00,44,00,65,00,73,00,6b,00,74,00,6f,00,70,00,00,00} } 0009: create_key( parent=0x6c, access=000f003f, attributes=00000000, options=00000000, modif=0, namelen=112, name=L"Software\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList", class=L"" ) 0009: create_key() = 0 { hkey=0x16c, created=0 } 0009: get_key_value( hkey=0x16c, name=L"ProfilesDirectory" ) 0009: get_key_value() = 0 { type=2, total=40, data={63,00,3a,00,5c,00,77,00,69,00,6e,00,64,00,6f,00,77,00,73,00,5c,00,70,00,72,00,6f,00,66,00,69,00,6c,00,65,00,73,00,00,00} } 0011: *wakeup* signaled=258 STATUS_TIMEOUT cookie=0x7bbfe880 0011: *wakeup* signaled=192 STATUS_USER_APC cookie=0x7bbfe880 wineserver: object.c:274: release_object: Assertion `obj->refcount' failed.

Jan. 29, 2007

Re: [Bug 6689] Created links do not reflect WINEPREFIX used

by Kuba Ober

On Monday 29 January 2007 12:50, Tomas Carnecky wrote: > Lei Zhang wrote: > > Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar > > worked in KDE. In Gnome, it works if "run from the terminal" is set. > > > > Unfortunately the Freedesktop spec for desktop entries does not > > specify a way to add environment variables. So yes, it looks like > > we'll need a wrapper script, or perhaps add a --prefix option to Wine? > > or change the exec line to: > /bin/sh -i -c "WINEPREFIX=foo wine" Instead, wouldn't /bin/sh -i -c "WINEPREFIX=foo exec wine" also properly dispose of the now useless copy of the shell? Cheers, Kuba

Jan. 29, 2007

Re: [Bug 6689] Created links do not reflect WINEPREFIX used

by Tomas Carnecky

Lei Zhang wrote: > Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar > worked in KDE. In Gnome, it works if "run from the terminal" is set. > > Unfortunately the Freedesktop spec for desktop entries does not > specify a way to add environment variables. So yes, it looks like > we'll need a wrapper script, or perhaps add a --prefix option to Wine? > or change the exec line to: /bin/sh -i -c "WINEPREFIX=foo wine" tom

Jan. 29, 2007

Re: Test case for Bug 50 [Was: Bug 50]

by Pedro Araujo Chaves Jr.

On 2007-01-29, Duane Clark wrote: > GetTextExtentPoint32 > > For some examples in Wine, look at almost any control in comctl32. I was afraid somebody would answer that... Thanks for the quick reply, but that isn't exactly what I need. Here's the picture: when an application calls TextOut() for printing text, the usual (at least in my case) call sequence in Wine is TextOut() TextOutA() ExtTextOutA() ExtTextOutW() (the one I patched) GetTextExtentPointW() GetTextExtentPoint32W() (the wide-char version of the one you mentioned) GetTextExtentExPointW() WineEngGetTextExtentExPoint() (the one that actually gets the individual character widths) That is, at some point, TextOut() indirectly uses GetTextExtentPoint32() to get the dimensions, okay. But what I need is to check the text width *after* it was output by TextOut() -- in other words, after the function has returned, to see if it output the text properly. In Wine, I tried the trick of making ExtTextOutW() return the said value, and the tests passed without a hitch, which means the text is being properly justified. The problem is that such is not an acceptable way of doing things, and, to use Dan Kegel's words, that is not going to fly on Windows. To be a bit clearer, in my tests I do call GetTextExtent32() in order to compute the remaining white space for the justification part, and what I want to check is whether TextOut() understood it right or not. - Pedro.

Jan. 29, 2007

Re: [Bug 6689] Created links do not reflect WINEPREFIX used

by Lei Zhang

Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar worked in KDE. In Gnome, it works if "run from the terminal" is set. Unfortunately the Freedesktop spec for desktop entries does not specify a way to add environment variables. So yes, it looks like we'll need a wrapper script, or perhaps add a --prefix option to Wine? On 1/27/07, Wine Bugs <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=6689 > > > > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2007-28-01 01:49 ------- > This is not going to work - it's not standard compliant. And I think it won't > work on Gnome either. The only way this can be fixed atm is using some wrapper > script. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > >

Jan. 29, 2007

Re: Test case for Bug 50 [Was: Bug 50]

by Duane Clark

Pedro Araujo Chaves Jr. wrote: > I've just finished writing a test case for Bug 50, but I'm missing *a > single thing* that prevents it from working under Windows: I still > don't know how to get the width of the text output by ExtTextOutW(). GetTextExtentPoint32 For some examples in Wine, look at almost any control in comctl32.

Jan. 29, 2007

Re: DirectPlay should initialize The session guid when creating a session

by Alessandro Pignotti

On Monday 29 January 2007 14:26, Kai Blin wrote: > On Sunday 28 January 2007 20:38, Tomas Carnecky wrote: > > > From Microsoft DirectX SDK Documentation it seems that directplay > > > should initialize the instance guid on session creation, this trivial > > > patch does that. > > > > Two questions: > > > > 1. Does windows do this, too? You can't rely on the MS SDK > > Documentation, always look what windows does and do it likewise. In many > > cases, a wine test should be written to verify the behavior. > > > > 2. Does it solve anything? A bug, a problem with an application? > > Right now, it doesn't, as Wine doesn't _have_ a working DirectPlay > implementation. However, Alessandro contacted me some time ago and was > interested in starting to implement it. As I'm still busy working on > figuring out the wire protocol used for dplay, I didn't get around to look > at the programming side of things much. > > Alex, what are you currently trying to do? I figure it would make sense to > kill the needed dll overrides for dplay dlls one by one, dplayx.dll might > be a good start to do so. > > I'll be happy to help you with writing a test case for your current patch. > > Cheers, > Kai I'm now trying to get my dpwsock.dll to work with native dplayx to figure out how the service provider implementation is expected to receive session data. Thanks a lot Bye -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mail are welcome

Jan. 29, 2007