Discussion:
EV_RXFLAG emulation
Valentine Sinitsyn
2007-07-09 07:33:24 UTC
Permalink
Hi all,

I spent the last couple of days trying to run one program in Wine. The
program (Easy Wireless Net, end-user tool to control many CDMA modems, if
you are interested in) extensively use EV_RXFLAG event which is
currently unimplemented in Wine. I've made a simplest implementation
possible (fire EV_RXLAG every time you have something in the serial
port input buffer - all the messages come in once anyway) and it
worked just fine with the aforementioned program, so I have two
questions now:

1. Would the patch with such "implementation" for EV_RXFLAG be
accepted to the mainline Wine (my take is having some sort of support
for the feature is always better that not having support at all) ?

2. Of course, a proper implementation of the feature is desirable - i.e.
one should look after EventChar in WaitCommEvent
(ntdll/serial.c:wait_for_event(), to be precise) but unfortunately
this lead to a trouble (I guess it's the reason why EV_RXFLAG is still
unimplemented): you need to "peek" into a buffer or read the data
twice: first time in WaitCommEvent to look for eventchar, and second -
in NtReadFile to actually obtain the data. And of course, it's not
possible, so some sort of buffering must be implemented. Alas, WINE's
architecture doesn't imply any buffering between Unix and Windows
layer as Developer's Guide states. My proposed solution is to read
data in serial.c:wait_comm_event() and store it somewhere; then, in
NtReadFile() one should check whether fd corresponds to serial file
and, if so, look in the corresponding buffer before doing actual read. Does this fit
nicely into WINE's design ? Or there are some other (more correct) approaches to perform
this task?

Thank you in advance.

Regards,
Valentine
Valentine Sinitsyn
2007-07-10 04:36:05 UTC
Permalink
Hi,

UB> The problem with EV_RXFLAG is, that the UNIX spec doesn't know it (to my
UB> knowledge). So most if not all kernel level drivers don't implement it. So
UB> we have to workaround or propose a kernel driver change.
Yeah, that's was what I wrote in the second item of the list
(actually, for my own internal developments, I've just implemented
missing ioctl() in the Linux TTY driver but I'm almost sure the change
wouldn't get accepted upstream). The question is - what's a best way
(in design terms: buffer serial I/O in ntdll/serial.c, at the server
level etc - there are many ways to do the same thing and nearly all of
them would probably work) to workaround the problem and I'm kindly asking someone with
a decent knowledge of the Wine architecture at the whole to comment on
my idea.

UB> As the latter is probably harder then to write code that Alexandre accepts,
UB> try to implement you proposal in a clean way. Start with adding test for the
UB> test suite, that really run on the different Win Flavours. Than implement
UB> your idea that make wine succeed in the test, and your test run on wine.
That's a tough part - it implies that I must have those different
Windows versions.

UB> Otherwise, in 2000 Ove Karven did some implementation for EV_RXFLAG
UB> http://source.winehq.org/source/misc/comm.c?v=wine20001002
UB> The code probably got lost in the move to handle devices in the server.
Thanks, I saw this one. The idea is somewhat close to mine although
implementation is different - I need to look further into it.

Regards,
Valentine Sinitsyn

Loading...