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).
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
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.
Martin Wilck replied with a lengthy description of some of Winsock's behavior:
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.....
A bunch of people jumped in with suggestions. First, Francois Gouget suggested:
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...
Shachar Shemesh had another approach:
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.
Marcus Meissner had the shortest suggestion,
Just call DbgBreakPoint();
.
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 kernel32As 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.