Wine Traffic #130 For 25 Jul 2002

This is the 130th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

There were 61 different contributors. 28 posted more than once. 28 posted last week too.

Some speculation hit the list this week when it was announced China is going to develop it's own equivalent of Windows. A few people wondered if the effort involved Wine and what ramifications that might have. However, it's not clear that there's any intention to run Windows binaries. So far it seems like an initiative based on Red Flag Linux and a version of OpenOffice. Lately there's been a push for more internationalization of Wine, (as evidenced by some of these topics) so it may actually end up in the product.

Once again, the question of using DTR/DSR flow control in Wine came up. This has been covered in the past in Issue #116, Section #3 (21 Feb 2002: DTR Flow Control) and Kernel Traffic Issue #81, Section #2 (1 Aug 2000: DTR/DSR Handshaking Deferred To 2.5; Linus Firm On Code Freeze) . The most common solution is to just use the RTS/CTS flow control in the kernel but change the pinout on the cable to support DTR/DSR. From the Linux Serial Howto: " Just like RTS and CTS, these pins are paired. For DTE-to-DTE connections they are likely to cross over. There are two ways to use these pins. One way is to use them as a substitute for RTS/CTS flow control. The DTR pin is just like the RTS pin while the DSR pin behaves like the CTS pin. Although Linux doesn't support DTR/DSR flow control, it can be obtained by connecting the RTS/CTS pins at the PC to the DSR/DTR pins at the device that uses DTR/DSR flow control. DTR flow control is the same as DTR/DSR flow control but it's only one-way and only uses the DTR pin at the device. Many text terminals and some printers use DTR/DSR (or just DTR) flow control. " .

That usually translates into connecting the PC's pins 4 and 5 (on a 25-pin connector, or 7 and 8 on a 9-pin) to pins 6 and 20. This is what Miguel Feitosa did, but he still had some questions: " I am testing a serial printer driver that uses DTR/DTS hardware flow control on wine. While testing the driver running winedbg everything worked, not so when I ran the program directly from wine. I sent this problem to the printer manufacturer and they put a data scope on the serial line. It seems that the DTR/DTS signal was not being caught by the computer and therefore the computer was sending info over the serial port when the printer was not ready. I read on the net that the linux kernel does not implement DTR/DTS but only RTS/CTS hardware flow control. "

Mike McCormack suggested, added, " Your idea to build a cable that wires the printer's DTR/DSR to the computer's RTS/CTS may work, but you may also need some small hacks in wine to select RTS/CTS flow control when the program asks for DTR/DSR flow control. That won't garantuee that your program works, but it will at least be a little better... "

Miguel had also heard that Windows didn't implement any flow control itself, but Mike cleared that up, " I'm pretty sure that Windows 95 and Windows NT's standard drivers both implement hardware flow control (DTR/DSR and RTS/CTS). Windows 3.1 may be a different story though... "

Peter Lord ran across a problem with an application trying to access some unimplemented functions, " the stumbling block is when the application starts to use network operations, specifically WPUCompleteOverlappedRequest and WSAAddressToStringA. Right now, these are unimplimented and the java app crashes when trying to call them." He wondered if there were any plans to add those two Wine.

Overlapped IO means that you can schedule an IO request, keep on doing work, and receive the IO results later (unlike non-blocking IO, where you have to retry until data is available for reading or writing).

There is overlapped IO in wine, although the operations are not strictly asynchronous (they seem to be, from the application's point of view). I took an effort a few months ago to implement the basics of Winsock2 overlapped IO, and AFAIK it works ok.

WSAAddressToStringA() should be relatively trivial to code.

WPU... functions are a different animal. They are at the downside of Winsock2, which is AFAIK completely unimplemented in Wine. In Winsock2 it is possible to register protocols as separate drivers. Actually, the Winsock2 API only works as a generic interface that passes requests to the respective protocol driver(s). Protocol drivers can be stacked and pass information up and down. In some situations a protocol driver needs to obtain information or use services from the generic layer, that's where the "WPU..." ("Winsock Provider Upcall") calls come into play.

That is, WPU* functions are only relevant for externally registered protocols which are non-existent under Wine. It wouldn't make much sense to support them actually, because which network protocols are supported under Wine is dependent on what protocols the OS it is running on supports. This could be worked around by using raw sockets and re-implement the whole TCP/IP stack in Wine, but I guess this is not what we currently want to do.

You should find out under which circumstances your app calls WPU... functions. Normally this should never happen because Wine has no registered Protocol drivers, all protocol handling is done internally, and WPU... is called from "below" Winsock where control flow should never get.

It may be possible to setup a hackish primitive WSP/WPU interface in Wine that avoids crashing at calls of these functions while not really providing functionality. Even this, though, would require a fundamental clean-up of the current Winsock code.

Ooops... after writing all this, I just read that WPUCompleteOverlappedRequest() is unique in that it is the only WPU... function directly exported by WS2_32.DLL... talk to me about consistency. Still I think calling the function is restricted to service providers, it is not for user-land. Does you code require special protocols to be installed, or does Java register some? Check the installed protocols on your Windows box in the Network control panel.

Max asked, " Maybe it's a stupid question, but... is there a way to hard-code a breakpoint ? I need to check a bit of code that gets called too many times and I'd like to put a conditional breakpoints compiled in code; no way to use winedbg built-in conditional breaks, the condition is too complicated..... "

You can do:


  if (complex condition) {

      _CrtDbgBreak();

  }

Or equivalently:


  if (complex condition) {

      __asm__ ("\tint $0x3\n");

  }

The int 3 is a software breakpoint (or rather, a software breakpoint is an int 3). The bove code will cause you to drop in the debugger if the int 3 ever gets executed. This only works on x86 architectures but this is probably all you need.

David Hammerton suggested, " You could do a "raise(SIGSTOP)", or if your lazy, "raise(19)". Replace SIGSTOP with your faviourate signal. I know that works when debugging with gdb, I guess it should with winedbg... "

Personally, I do:


    if( condition)

        some meaningless nop;

And then set or clear the breakpoint on the nop if I want. This gives me debug time control over the breakpoint without giving up on the flexability.

Steve Lustbader inquired about the state of Winelib documentation, " I've been having some trouble using winelib (with spec files) following the documentation on the web site. A few people in the IRC channel were under the impression that winelib had changed and the docs aren't really relevant anymore. Is the documentation going to be updated to the current status of the source? "

Andriy Palamarchuk felt the docs were pretty close to being correct, but asked for more info on what was wrong. Steve specifically mentioned he was having a problem with import statements in spec files. Andriy explained that the documentation was indeed wrong:

Now it is done by the following definition in Makefile.in file:


IMPORTS   = advapi32 kernel32

As an example of using Winelib I advise you to look into Wine programs (see programs subdirectory of the Wine source tree). These programs are compiled as Winelib programs, you probably will want to do something similiar.

Francois Gouget also suggested, " You should look into winemaker. winemaker has been updated recently and I believe it should work though I did not have time to test it recently. "


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	19 Jul 2002 - 25 Jul 2002	(1 post)	News: Wine in China?
2.	23 Jul 2002 - 24 Jul 2002	(6 posts)	Flow Control in Wine
3.	19 Jul 2002 - 21 Jul 2002	(3 posts)	Overlapped IO
4.	22 Jul 2002 - 23 Jul 2002	(10 posts)	Coding Debug Breakpoints
5.	22 Jul 2002	(4 posts)	Imports in Winelib

Wine Traffic #130 For 25 Jul 2002

By Brian Vincent