November 2001 - Wine-Devel - list.winehq.org

queries on internals...

by Roger Fujii

ok... getting reasonable output, but now I have some questions. First, it seems like wine can't find the audio codecs, though it seems to find the video ones. Is this a to-be-implemented or a bug and any clues on where to look? The next are portability / solaris questions... 1) For some unknown reason, the solaris version segfaults when it tries to load win87em.dll, but the linux one doesn't. I presume that this is trying to load the fpu emulator, but I'm not certain. In any case, what controls the loading of this in the first place? 2) regapi uses strsep, which solaris doesn't have. Is its usage in wine compatible with strtok, or should I cut/paste strsep into library/ports.c? 3) In win32/console.c, it seems that master/slave is reversed through the fork. This is only going off the docs, but if it is, how is this working under linux? That's all for now.... -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

Nov. 6, 2001

Extra info in scrollbar can be an handle.

by Marco Bizzarri

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. We have an application which crashes when trying to access the Window Long info in a scrollbar. After some tracking, it looked like the issue was that in some cases the wExtra data can contain an handle rather than a pointer. The included patch solves the problem by making an explicit GlobalLock, and returning that value. I'm not sure this is the correct solution, so comments are welcome. wine is from the latest cvs - -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE759zoXhfyAQQVoaIRApoGAJwOhVqzWtvYCz1oHZTcYSCYeCDQ6wCePBE3 DJ/zoeclED29BCnaC+9Ya8E= =rU+H -----END PGP SIGNATURE-----

Nov. 6, 2001

Re: RTS/CTS

by lawson_whitney＠juno.com

On Tue, 6 Nov 2001, Mike McCormack wrote: > > Hi Lawson, > > good detective work! > > i don't think DSR/DTR flow control is supported by termios at all (at > least not in Linux), so here's a patch to ignore it. > > Mike > Okay, that passes the smoke test, and also looks right to me. Thanks. Did you forget a ChangeLog? Lawson Big fleas have little fleas upon their backs to bite 'em. And little fleas have smaller fleas and so on, infinitem.

Nov. 6, 2001

Re: Winsock2 & overlapped IO

by Mike McCormack

Hi Ove, >Hm, by the way, when are you going to implemented overlapped >ConnectNamedPipe? That might make my rpcrt4 wait-for-connection code a bit >cleaner, so I don't have to spawn a separate thread per named pipe, and >worse, use TerminateThread to cancel the wait... OK. i'll have a look at it. Having a full time job, a part time job and a girlfriend to take care of kind of eats into my time though :-) >The challenges for winsock2 should be pretty much the same as those for >implementing something like ReadFileEx (which you've probably already >done) and the above-mentioned overlapped ConnectNamedPipe. Yeah, ReadFileEx is pretty much complete. Perhaps i'll have a look into overlapped sockets too... don't hold your breath though ;-) Mike btw. nice work on OLE/InstallShield stuff ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Nov. 6, 2001

Re: Winsock2 & overlapped IO

by Ove Kaaven

On Tue, 6 Nov 2001, Mike McCormack wrote: > i don't know much about Winsock, but i can tell you how overlapped I/O > is supposed to work in Wine. Hm, by the way, when are you going to implemented overlapped ConnectNamedPipe? That might make my rpcrt4 wait-for-connection code a bit cleaner, so I don't have to spawn a separate thread per named pipe, and worse, use TerminateThread to cancel the wait... > So to get winsock to do overlapped, you may have to modify the winsock > code to work like that... but the winsock code uses the service thread > to wait upon sockets. Not really, the wineserver does the grunt work. The service thread is only used to implement WSAAsyncSelect, to post messages when the wineserver says that it should. Winsock2 code is unlikely to use WSAAsyncSelect, they'd rather do either WSAEventSelect (which doesn't use the service thread, but is 100% wineserver-based), *or* overlapped I/O. The challenges for winsock2 should be pretty much the same as those for implementing something like ReadFileEx (which you've probably already done) and the above-mentioned overlapped ConnectNamedPipe.

Nov. 6, 2001

Re: Winsock2 & overlapped IO

by Mike McCormack

Hi Martin, i don't know much about Winsock, but i can tell you how overlapped I/O is supposed to work in Wine. The bulk of the implementation is in files/file.c and scheduler/synchro.c. When ReadFile is called on a handle, the following happens: 1. check that the handle is valid and was opened with FILE_FLAG_OVERLAPPED. 2. attempt to read any data that is available immediately, and perhaps return if we read enough already. 3. queue the operation onto CurrentTeb()->pending_list When the thread waits upon any server object, all (unix) fds with pending overlapped operations are polled on. This is a minor problem in the design; if the thread never waits upon an object the overlapped can never complete, however the thread must wait upon the overlapped's hEvent to check whether it has completed... The only part of the serial comms overlapped implementation the lives in the wineserver is the calculation of overlapped timeouts. So to get winsock to do overlapped, you may have to modify the winsock code to work like that... but the winsock code uses the service thread to wait upon sockets. The task is definitely not impossible, but it might take a bit of work :-) Maybe Ove K. can give you some advice? Mike > In particular, it uses the Winsock 2 feature of "Overlapped IO" > on sockets, with user-supplied callbacks that are called when > data is received on a socket etc. > > Browsing through the Wine Winsock code, I saw that this part of > Winsock2 is obviously unimplemented. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Nov. 6, 2001

RTS/CTS

by lawson_whitney＠juno.com

Good day! A couple of wine-users have said Wine doesn't work RTS/CTS right any more, so I did a +comm,+file trace of juno, and was rewarded with this: trace:comm:SetCommState handle 224, ptr 0x403f0578 trace:comm:SetCommState bytesize 8 baudrate 115200 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS trace:comm:SetCommState ~CRTSCTS Does something look wrong about that, or am I just seeing it crosseyed? In GetCommState we have this: if (port.c_cflag & CRTSCTS) { lpdcb->fDtrControl = DTR_CONTROL_ENABLE; lpdcb->fRtsControl = RTS_CONTROL_ENABLE; lpdcb->fOutxCtsFlow = 1; lpdcb->fOutxDsrFlow = 1; } else And in SetCommState this: if ( lpdcb->fOutxCtsFlow || lpdcb->fRtsControl == RTS_CONTROL_ENABLE ) { port.c_cflag |= CRTSCTS; TRACE("CRTSCTS\n"); } if (lpdcb->fDtrControl == DTR_CONTROL_ENABLE) { port.c_cflag &= ~CRTSCTS; TRACE("~CRTSCTS\n"); } So I guess if you want to turn off CRTSCTS, GetCommState(handle, lpdcb); SetCommState(handle, lpdcb); would about do it. I don't know what fDtrControl is 'spoze to do, but shutting off flow control entirely seems a bit extreme. Juno apparently asks for it by name, CRTSCTS was not on when it did GetCommState, but it asked for flow control, too. Lawson panic: detected rogue system administrator!! ---cut here

Nov. 6, 2001

Re: SystemParametersInfo

by Andreas Mohr

On Mon, Nov 05, 2001 at 07:21:00AM -0800, Andriy Palamarchuk wrote: > > --- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > On Mon, Nov 05, 2001 at 06:20:24AM -0800, Andriy > > Palamarchuk wrote: > > > 2) whether Windows application runs under Wine or > > > Windows? > > Eh ? I don't quite understand the logic behind this. > > Could you elaborate ? > > I'd like to use this in the unit tests to check > whether Wine internals work correctly. These tests > would use standard Windows API but have sense only > when the test application runs under Wine. Check for HKLM\\Software\\Wine\\Wine\\Config. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Nov. 5, 2001

Re: Duplicated StrRetToStr functions in shell32

by Dominik Strasser

Francois Gouget wrote: > > On Thu, 1 Nov 2001, Guy L. Albertelli wrote: > > > Francois, > > > > The reason that these routines were duplicated is that the builtin shell32 > > cannot find StrRetToBuf{A|W} in some of the native versions of shlwapi.dll. > > This dependency prohibited testing with builtin vs. native shlwapi. > > > > The change was submitted to winehq about 8/28 and committed soon thereafter. > > Aaaah. Ok. > > Then I suggest that we add a comment in the source that says so, in > both the shell32 and shlwapi implementations. This way when one > implementation is updated the others acutally have a chance of being > updated too. So why don't you implement it once and include the implementation twice, one time in shell32, the other time in shlwapi ? This could be either accomplished via #include or via a "vpath" in the Makefile. Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser(a)mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

Nov. 5, 2001

Re: SystemParametersInfo

by Andriy Palamarchuk

--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > On Mon, Nov 05, 2001 at 06:20:24AM -0800, Andriy > Palamarchuk wrote: > > Please, review the new version of > SystemParametersInfo > > implementation. > > > > Is there any way to check: > > 1) whether Wine process is the first process > started > > for current Wine server? > Heh, I should really know ;-) > CLIENT_IsBootThread(). Thank you for the information > > 2) whether Windows application runs under Wine or > > Windows? > Eh ? I don't quite understand the logic behind this. > Could you elaborate ? I'd like to use this in the unit tests to check whether Wine internals work correctly. These tests would use standard Windows API but have sense only when the test application runs under Wine. I don't want to create separate application for such tests and rather use check at the run-time instead of conditional compilation. In this way I can use the same executable under Wine and Windows without recompilation. Can you suggest different approach? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

Nov. 5, 2001