wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

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

Sponsoring by IBM, lets get it done
by Roland 15 Jan '02

15 Jan '02

Hello, to put an end to this discussion, I will start trying to contact people at IBM for sponsoring, unless someone more qualified wants to do it. Anyone? Ok, so where do I start, can someone give me an email adress? I also wanted to know some technical terms: 1. How do you call the person who is TECHNICALLY responsible for a project, in this case, for the Linux stuff at IBM? 2. How do you call the person who is FINANCIALLY responsible for a project, in this case, for the Linux stuff at IBM? If someone can provide the answer to 1 and 2, it would help, the email adress I will figure out myself...if no one can provide one... Thanks...Roland

1 0

Listview Unicodification (take 3) (fwd)
by Dimitrie O. Paun 15 Jan '02

15 Jan '02

[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:) ] Hi folks, Here is the latest version of the Unicode ListView control: http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff It fixes a silly (e.g. brown paper bag type of bug, really) pointed to me by Gerard (thanks!). It does fix a problem with the subitem handling (before, the subitems were simply ignored). Tested with the Common Control Spy Sample thingy from MS. I still could not get Gerard's examples going, and it seems I really need to test with those... If things look OK, I will forward it to Alexandre soon. -- Dimi.

1 0

Re: async_private + ReadFile() etc. immediate completion
by lawson_whitney＠juno.com 15 Jan '02

15 Jan '02

On Fri, 11 Jan 2002, Martin Wilck wrote: > > Here are 2 small patches. > Both apply on top of the patch I sent yesterday which started this > thread. > > 1) fixes a bug that I discovered myself, > 2) Adds TRACES to several functions to simplify debugging. > > 2) Is not meant for applying to CVS!!! > > However, Lawson it would be nice if you produce a new trace with these two > patches applied. > > start your app with --debugmsg trace+file,trace+thread,trace+comm. > > Regards, > Martin > The app works with those patches, so the trace is much bigger. The app also works with those patches, but without tracing (sometimes tracing might change an app's behavior). Disclaimer: juno 1.49 is _a_ brain-dead 16 bit comms app, but not the only brain-dead comms app. I can't promise all of them will work. I don't guess all of wine-devel wants the trace. Anybody who does may have it for the asking. Lawson ---oof

2 1

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