> I have discovered that WinXP seems to be slower at handling > communications than Win98. Bizarre as this sounds, it seems to be > true. > > I have a VB6 program that uses a VC6-written (by me) serial comms OCX. > The OCX uses a separate thread to constantly monitor for incoming > comms. The same code (in my programs) runs on all systems - there is > no special compilation for different OSs. > > When run on a desktop PC running Win98 using a proper serial port, it > zips through the comms nicely. When run on a much newer desktop > running XP, also using a proper serial port, it is visually a touch > slower. > > Baffled, I tried on my laptop running XP - it was also visibly slower. > The laptop is still newer than the Win98 desktop. > > Now, the laptop doesn't have a serial port, so I'm using a > USB-to-serial converter. This is why I'm not sure if it's a hardware > issue, since it seems to be the same no matter what hardware is used > on the XP machines (I also tried the USB converter on the XP desktop - > same result). > > As a final test, after much faffing around, I got Win98 and WinXP both > on the laptop as multi-boot. So I can now run the same code with the > same hardware, and still the difference is noticeable. > > So it seems to be an OS issue - the only difference I can think of is > that the VB program will be using core system DLLs under the hood (out > of my control), which will be different for each OS. > > Has ANYONE experienced anything similar? Can anyone shed any light?
I have not personally experienced anything similar, but then again I have never written programs to interact with hardware like this. But there are some pices of advice I can give you: 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. If you're concerned about not having the same binary distribution for 9x and NT, this should be a non-issue, because: 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. 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. 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. 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. ------------- Ehsan Akhgari List Owner: [EMAIL PROTECTED] [ Email: [EMAIL PROTECTED] ] [ WWW: http://www.beginthread.com/Ehsan ] Mature manhood: that means to have rediscovered the seriousness one had as a child at play. -Beyond Good And Evil, F. W. Nietzsche
