you make some sense in places and some good points (although i don't pretend to understand the plumbing of vmware and an 'emulated' system) and some of your info is very useful. but i fail to understand how windows can accept what you are calling a 'counterfeit' chip and mac rejects it.
My point was that the MacOS driver is completely out of the loop when the device is passed through to Windows. The details of why the Windows driver is better than the MacOS driver stems from the fact that the former gets a lot more development attention and testing (as does the whole Windows USB stack, for that matter). By the way, lots of Windows folks have trouble with the drivers as well, but it seems like the last official version before Prolific started trying to exclude the counterfeit chips is an easy choice for most.
it seems to me that just because the code base is the same, it doesn't mean that code interacts with the os's the same. that is what i meant by my caveat ' ... on my particular system'. for example, there could be a usb bus timing issue (my symptoms could easily indicate this) that vmware/chirp//windows handles perfectly and mac/chirp doesn't tolerate at all.
There are several layers between CHIRP and the OS dealing with the serial line communication that are there to make that a non-issue. Further, the timing in question (especially with your particular radio) is extremely lax and not something that would be affected by minor differences in otherwise high-speed hardware. If you were complaining about a Yaesu driver, I'd be considering other options (or hiding :)
On MacOS, it's difficult because there's no native software to prove that the driver is to blame. On Windows, that's easy and clear, of course.
and yes, i own some of those clunky keyspan adaptors. this isn't my first rodeo on connecting radios to computers! [g] also, i used to have to have them to connect my macs to cisco console ports, so they are very useful, but clunky and i don't think i should have to haul one out and buy a serial cable to make this work.
Well, that's your call. You're on a platform that doesn't get nearly the attention of the other one. That means that not every combination of hardware is going to work flawlessly, as you have come to see. If you feel that you shouldn't have to use ugly hardware (as most Mac users seem to feel) then continuing to chase the driver issues is likely to be your preferred course. You could also try to find someone that makes a known-good programming cable with a USB hood on it (which is often difficult). However, the fact is, you're not going to get support for your chinese knock-off cable from the manufacturer, nor the manufacturer of the hardware they knocked off, nor your platform vendor.
We are telling you that the problem is well-understood and we're trying to provide you with ways around it. As a Lexus owner will tell you, it's a different TCO equation than owning a Toyota, even though it's just a car, and is made in the same factory, with nearly the same parts.
i do appreciate you guys trying to help, but i'm getting a very protective, defensive tone about the software here and i guess that's understandable. if i put hours of work into a project and it worked for most people and i was at the mercy of hardware and flaky installs, i'll bet i'd be a little touchy too. i troubleshoot for a living, so i do sympathize.
Yep, we're a little touchy. Mostly because we're well-aware of the issues, but really can't do much about them for you. You have, at times, sounded a little accusatory, and I can't really blame you for that. However, remember that we're all volunteers (as are the folks that attempt to write one of the MacOS drivers that tolerate counterfeit chips).
So, sorry for sounding a bit short. All we can do is tell you what we know, ask you to treat us with respect, and ask you to trust us that we're not just brushing you off.