> 1) Have you written the VC part of the code so that it's Unicode-enabled?
> If so, by all means, try to have a Unicode build for NT systems. See, COM
> is itself Unicode-based, and the native NT API's are all Unicode.
> Your OCX
> has to convert Unicode-data it receives from the client to ANSI, then it
> passes it to the OS, which again has to do the conversion to Unicode to do
> anything useful with the data. The same goes for the other side of the
> trip.
>
> And if your code is not Unicode-enabled, then I suggest you review it for
> Unicode compatibility if feasible.
It certainly should be Unicode-capable; I have been using _T( ) and _txxx()
for some time now. It would certainly be interesting to see how it compares!
And finally I get a chance to use some proper Unicode code {:v)
> A) you can use MSLU if desired, and ship the same Unicode binary to the 9x
> world (but it might make 98 perform worse).
> B) all setup packages I know of give you relatively easy control to choose
> the right binary module for each type of OS.
I'd be quite happy to detect OS and install a different binary.
>
> 2) Have you tried profiling the code? Only it's by profiling that you can
> get which part of the code is misbehaving. You can profile the
> code both on
> 98 and XP, and notice the differences, if any.
Great idea! Since I've never ever profiled before, it just never occurred to
me. Remind me how? {:v)
>
> 3) If the communication thread is IO-bound (it should be from your
> explanation), then you may try raising its priority. This might
> help, since
> it can cause the little CPU-burdon of the code perform faster, yet not
> affect the rest of the system, because most of the time, the thread is
> waiting on an IO to be completed.
It doesn't use an "IO completion port" (at least I don't think so; it DOES
use overlapped comms though). The receive thread basically blocks in a
::WaitCommEvent() call until something happens, and then if EV_RXCHAR is the
event, it goes and uses ::ReadFile() (and of course GetOverlappedResult() )
to get the data.
>
> 4) Is there any non-polling approach for your job on the NT part? Some
> possible use of IOCP's, maybe? Generally, polling is the least efficient
> method to do anything, and NT provides several nice kernel
> objects which get
> signalled when necessary. This way, you don't call into the kernel more
> than necessary - you wait the kernel to call into your code.
At the moment the calling code (in most of the programs I'm responsible for)
has to poll because it can't return to /its/ calling code until it either
has an answer to the message it sent, or a timeout occurs. Since it is VB
code doing the calling, I don't have the luxury of being able to sleep until
an event is signalled from there. {:v(
In the future I plan to write another OCX will act as a layer on top of this
one; it will understand Modbus, and thus /it/ will do the waiting until
something happens and it can then check if it has a complete message (thus,
being more efficient than polling continuously). Sadly as we all know they
want the software NOW, so I haven't got the time to write that part yet! I
only got the chance to write this one because it solved a VB problem (in VB
comms, you have to pump Windows messages to enable incoming comms to be
received - but this opens up the danger of the user clicking another button
or a background timer kicking in during the wait for a response, which could
try and send another message, and it just gets stupid from there - the OCX
means I can poll without pumping messages).
If someone can point me to some useful info on IOCPs, what they are exactly,
why they're better than the ::WaitCommEvent() approach + overlapped, etc.,
I'd be grateful. I don't understand enough about it to use it effectively.
--
Jason Teagle
[EMAIL PROTECTED]
