I'm trying to get a java application running under wine. Amazingly (at least to me :-) ), the application gets a fair way through loading lots of classes as it goes.
But, 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.
Before I start looking into these in more detail (I've really no idea what overlapped I/O is all about ...), does anyone plan to implement these in the near future ?
Oh, BTW, before you ask... the java app loads a native windows dll as part of its functionality, so I can't use the Linux jvm :-(
Cheers,
Pete
Am Sam, 2002-07-20 um 22.35 schrieb Peter Lord:
But, 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.
Before I start looking into these in more detail (I've really no idea what overlapped I/O is all about ...), does anyone plan to implement these in the near future ?
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.
Martin
Martin Wilck wrote:
Am Sam, 2002-07-20 um 22.35 schrieb Peter Lord:
You should find out under which circumstances your app calls WPU... functions.
Many thanks Mrtin for the complete reply.
This is being called somehow from a java app. I'll debug some more to see whats going on as you suggest,
Cheers,
Pete
-
Martin Wilck -
Peter Lord