I have nothing against windows, all of my home PCs run it, and I’ve selected it over Linux and QNX for certain projects, so I am not a “fanatic” for one OS over another. The right tool for the right job IMO.
I used to do my QNX 4 development via Phindows so I could open multiple Photon sessions simultanouesly and spread them over my 2 21" monitors. Same with Linux - I use a Windows X server. As you know though, neither of those situations though is “cross development”.
Cross development, in and of itself, is a negative, not a positive, IMO. You’re forced to maintain TWO computers and two different OSs and make them work together.
You add an extra layer of complexity (e.g. the target based agent). You require network activity (or serial or whatever your connection to the target is) where none was required - this in and of itself generates interupts on your target and executes code that is not part of your system. Then you involve the host os (windows or linux) in the process. I just read a thread on the comp.os.qnx newsgroup where a mixed QNX/Windows system stopped working after daylight savings time happened. Turned out it was the windows software. But of course the QNX system was the suspect first. You don’t want to be guilty by association that way
This is one of the things i absolutely hate about our VxWorks setup - we always have this ridiculous target server PC (running windows) in the loop. I mean come on! I use a real-time OS that’s supposedly reliable, and then I have to rely on a target server running on windows?
Setting up the target filesystem is much more complicated than if the system was self-hosted. During my evaluation of QNX 6 I routinely use the Windows IDE to compile and then transfer the executable by hand to my environment (copying it from /tmp to where it needs to be). Ouch. I’m sure there’s a better way but my time is so limited.
I assume the reason QSSL developed the cross development system was to be able to have non-x86 targets, which is very necessary in the embedded OS business. That was a real positive for QNX 6, it just doesn’t affect me because for my applications I can always find some x86 platform.
I could run QNX on my crappy power pc vme boards, or i could just get a x86 vme board if I have to be in a vme bucket. The x86 SBCs i’ve looked at are ten times better than the power pc boards. Heck even apple has given up on the power PCs. I realize there are other embedded applications where other targets are required - but for most industrial apps I’d be hard pressed to choose a non-x86 target.
So one can’t say that for a person whose target is COTS x86 PCs (wether consumer grade, industrial, or embedded), that the advent of the Windows and Linux based IDE’s is an advantage. For this use - I’d much rather have a working self-hosted IDE and a working Phindows
It is a shame that the self-hosted system is just so slow and unstable compared to the windows IDE (on the same hardware) and that Phindows doesn’t work with the self-hosted IDE (the cursor destroys text - see my img attached in my other thread - verified by mario).
Frankly if I could get drivers for QNX 4 for modern hardware and a modern C++ compiler (i.e. template and exception support is not too much to ask) I would continue to use it.
Well in a week or two I’ll know if we’re going to use QNX for this particular project and I’ll get in touch w/QSSL again. I will certainly post follow ups if any of these issues have been addressed (Qnet, self-hosted IDE issues, phindows issues).