wine-devel

wine-devel@winehq.org

84463 discussions

The 4th Coming : Mmsystem Question
by Sylvain Petreolle 16 Jan '02

16 Jan '02

Hi, Using The 4th Coming game (directx game), wine crashes (no debugger is launched) after displaying following some error messages : (game is at http://t4cweb.aliens.com/download/T4csetup.exe) you can use the following game account : T4CWineUser pass: test4U err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=044f err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=043f err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=008f err:mmsys:MULTIMEDIA_GetIData IData not found for pid=0806b920. Suicide !!! (displayed 4 times) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

1 0

Re: async immediate completion - now tested
by l_whitney＠juno.com 16 Jan '02

16 Jan '02

On Tue, Jan 15, 2002 at 08:06:22PM +0100, Martin Wilck wrote: > > PATCH: async-immediate.diff > > This patch uses a more elegant and (IMO) more wine-ish method to check for > possible immediate completion of asynchronous IO requests in ReadFile() and > WriteFile(). > If you get this, async-struct and async-immediate don't harm the 16 bit app. Just making sure I tested exactly what is being proposed. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

2 1

Re: Listview Unicodification (take 3) (fwd)
by Gerard Patel 16 Jan '02

16 Jan '02

At 01:58 PM 1/15/02 -0500, you wrote: >[once again, I attached the patch by mistake, and the mail did not go >through...oh well, that happens if you don't sleep at night:) ] I think that by zipping the patch it should be below 64K and be fine. >Here is the latest version of the Unicode ListView control: >http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff Better - all columns have something now - but only the first character. This fixes it : @@ -5075,7 +5076,14 @@ else if (lpLVItem->mask & LVIF_TEXT) { if (internal) lpLVItem->pszText = *ppszText; - else textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW); + else + { + if (isW) + textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW); + else + WideCharToMultiByte(CP_ACP,0,*ppszText,-1,lpLVItem->pszText, + lpLVItem->cchTextMax,NULL,NULL); + } } if (lpLVItem->iSubItem == 0) I'll let you turn into something correct since it's now more than 2 in the morning and I need some sleep even if you don't. Gerard

2 1

Listview Unicodification (take 4)
by Dimitrie O. Paun 16 Jan '02

16 Jan '02

OK guys, This one fixes the bug found by Gerard (thanks a lot -- very good spotting). You can find the patch here: http://www.cs.toronto.edu/~dimi/listview-unicode-4.diff This one can go to Alexandre, as far as I'm concerned. So if you still see big problems, please let me know. -- Dimi.

1 0

Re: WSAAccept
by Martin Wilck 16 Jan '02

16 Jan '02

Hi Daniel, I have some concerns wrt your WSAAccept implementation you sent to wine-patches on Sunday. I have thought a bit about this function (did you notice my preliminary implementation on Nov. 7 (subject "[EXPERIMENTAL PATCH]: Winsock2" ?). The problem I see is related to the treatment of the peer when the user-supplied condition function returns CF_REJECT or CF_DEFER. Your implementation calls WS_Accept _before_ calling the condition function. That is, the peer will think its connection request was accepted, and possibly start to send or poll for data. Then if the Condition function returns CF_REJECT, the connection is closed. Even worse, for CF_DEFER, the peer receives nothing, the new socket cs returned by WS_Accept remains open but is forgotten after WSAAccept() returns (correct me if I'm wrong). So the peer will think it's connected, but no future WSAAccept or WS_Accept call will ever return a socket connected to it, and it'll be sending data into the void. I think you must at least closesocket(cs) for CS_DEFER as well to avoid this situation. Alternatively (that's the way I did it) the new socket can be stored in the wineserver to be returned by future WSAAccept calls. The Winsock2 specs say that "[WSAAccept] extracts the first connection on the queue of pending connections" (after a CF_DEFER, that should be the previously deferred connection, until it's either accepted or rejected). Moreover, it says that "[In the CF_DEFER case] no action about this connection request should be taken by the service provider". Taken seriously, this means that it's wrong to call accept() on this request before a positive decision was made by the Condition function. Summarizing, the peer should see: CF_ACCEPT: his request is accepted (this case is OK). CF_REJECT: his request is rejected (not ok, he receives an accept followed by a close). CF_DEFER: nothing (not OK, he receives an accept followed by ???) I have no idea how this affects behaviour of "real" applications. The essential problem is that there is no way (well, I have found none) to obtain the peer's socket address on Linux without accept()ing first. I guess that is what made you call accept() before the condition routine. Perhaps someone can come up with a method to read the socket address of a waiting connection request before it's accepted, but my guess is this won't work without a kernel hack. At the very least, though, I consider it necessary to include a FIXME that tells users that this function may behave different from what the specs say. Please don't get me wrong, it's great to see other people work on Winsock, and your code is clean. I just thought I need to express these concerns. Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 3

Filesystem Regression Test, was: Re: RESEND: Fix return value ...
by Uwe Bonnes 16 Jan '02

16 Jan '02

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> Hello. Please use this patch instead of the previous one. I'll Dmitry> try to find some time and figure out how to write regression Dmitry> test for this functions. Please let us know if you find some sensible way to test filesystem functions. What I do now is - export some filesystem tree with SMB(NCP) - import it in Vmware with some drive letter - use the same drive letter in the wine-config for the same filesystem tree I don't think this solution is very sensible for a more generalized test... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 7

Using Python with Wine
by Gerard Patel 16 Jan '02

16 Jan '02

I have finally succeeded in using Python to make test applications. I find the idea pretty interesting to build quick-and-dirty applications to test a specific api. Here is how it can be done. Get from www.python.org : Python 2.1.1 for windows http://www.python.org/ftp/python/2.1.1/ Get from ftp://ftp.nightmare.com/pub/python/python-ext/ npstruct-2001-05-20.zip calldll-2001-05-20.zip dynwin-2001-05-20.zip Install python under Wine : ./wine -managed <path to python installer>Python-2.1.1.exe unzip the 3 additional packages under the Python directory (c:\program files\python21) add these 3 directories to the Python path. The easier way is to create a dir.pth file in the main Python directory containing : c:\\Program Files\\Python21\\calldll c:\\Program Files\\Python21\\npstruct c:\\Program Files\\Python21\\dynwin add the path to the main python directory to the Wine path. launch python (the command line version, I did not try the gui version) : wine python Here are some commands I tried (I edited out most of the Wine Fixme and Err, and removed prompts) : import windll (.... 1. Basic example) user32=windll.module("user32") cstr=windll.cstring MessageBox=user32.MessageBox MessageBox(0,cstr('test'),cstr('example'),0) 1 (1 is the value returned by MessageBox - success) (.... 2. more involved example, using buffers) winmm=windll.module('winmm') winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) 279 (error 279) buf=windll.membuf(256) winmm.mciGetErrorString(279,buf,255) 1 import calldll print calldll.read_string(buf) Cannot use 'all' as the device name with the specified command. (I fix line 516 of mci.c to return a correct error message and compile Wine, try again) i = winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) fixme:mci:MCI_LoadMciDriver Couldn't load driver for type WAVEAUDIO. If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini print i 306 (I had indeed commented out the waveaudio entry in my system.ini -> fix user error and try again) winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) 0 (well, the mci call returns 0 - success - the sound is not played completely - but that's another story :-//) (.... 3. complete example of testing a gui function : TextOut) import windll cstr = windll.cstring gdi32 = windll.module ('gdi32') import wingdi import windc import winwin class test(winwin.python_window): style = winwin.WS_OVERLAPPEDWINDOW def WM_DESTROY (self, wparam, lparam): winwin.user32.PostQuitMessage (0) def WM_PAINT (self, wparam, lparam): dc = self.begin_paint() gdi32.TextOut(dc.handle,50,50,cstr("text output"),11) self.end_paint() if __name__ == '__main__': import msgloop w = test("test 1").create() w.show_window() msgloop.go() (in this example most of the code use calls to higher level functions hiding somewhat the Win32 Api, except the api call, that uses the 'handle' member of the dc object to access the Win32 object) There is a Python error message when the gui app terminates, however this is a problem with the python system (it shows the same under WinNT, for example) Note : don't begin command by spaces - Python interpreter don't like it. Also, Python don't care for case but Wine does, so writing 'mcisendstring' will fail, for example.

1 0

fixme:richedit:RICHED32_WindowProc Unknown message 129
by lawson_whitney＠juno.com 15 Jan '02

15 Jan '02

Good day! Thanks, Daniel Walker, for your work on riched32. I don't know what or why is richedit and I'm kind of GUI-challenged, or I'd have a go at implementing these myself, but I have an app that uses it, so if traces would help, just say which traces and if you want them for builtin or native riched32. The app fails with a bogus message box: "Insufficient memory or disk space" after these three fixme's with the builtin, so those traces should be pretty short, but maybe it would also be useful to try to use spy on the native riched32. If spying on msvcrt, mfc42, and/or the app's own dll's is likely to make noise, I can filter it out, but at this point I don't know. fixme:richedit:RICHED32_WindowProc Unknown message 129 fixme:richedit:RICHED32_WindowProc Unknown message 528 fixme:richedit:RICHED32_WindowProc Unknown message 130 Regards, Lawson

3 4

C testing framewok. Updated. SystemParametersInfo unit test.
by Andriy Palamarchuk 15 Jan '02

15 Jan '02

Attached are new version of the C testing framework. Changed SystemParametersInfo unit test to use this framework. Alexandre, I need to use a couple switches for the test application: - output verbosity level - die on failure indicator Can you suggest how to implement these switches - as command-line arguments or environment variables? Using environment variables is easier for me - I don't need to do parsing of 2 types of command line (main and WinMain formats), no need to force test developers to use function like start_test( args ) in the beginning of their tests. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 1

Re: What are you really aiming to do with winetest?
by Alexandre Julliard 15 Jan '02

15 Jan '02

Patrik Stridvall <ps(a)leissner.se> writes: > It would be nice if you commented on what you > think about my spec2pm script for automatically > generating Perl modules for calling the Windows API. Sure; I was looking into integrating it, but found some problems. I agree generating modules automatically is a good idea; the main problem right now is that we cannot get the return type of the functions, and this breaks functions returning a string. > Also, I'm not sure that you are trying to do: > The files generated by make_symbols are quite useless, > they just contain a lot of LOCAL variables. They seem to work just fine for me, but I'm no Perl expert, so if you think your approach is better I'll do it that way. -- Alexandre Julliard julliard(a)winehq.com

1 0

Jump to page:

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