Dual-Core and 64-bit processors supported by QNX 6.3.0 SP2

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 :slight_smile:

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 :stuck_out_tongue:

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).

First let me say that I agree completely with you about cross development. With respect to building QNX onnon x86 targets, I’d still rather have QNX as the host. Specifically why QSSL provides cross development, I believe it was a marketing thing. A lot of Big customers, big in the sense of being big companies insist on Windows being the place you work. I know that there are some advantages from the point of a big company. They can use their existing networked source control system for example. This of course helps the company, not necessarily the programmer.

The IDE supports CVS on all hosts platform. The plug-in for perforce also seems to work on self-hosted (didn’t test extensively though)

I think the bigger OEM don’t use x86. I’m not sure how many customer they have that used the solaris self hosted. My guess is only a few with deep pocket.

Although not “modern” Watcom 10,6 supports exception and templates. (STL 4.0 works nicely). Just have to provide an handler that will throw an exception if new fails ( by default it returns NULL). There is no RTTI though.

I got a quote - will cost us close to $10k to be able to deploy an SMP image on 1 machine :frowning:

RT-Linux and INtime can use multiple processors (I don’t care if its SMP or AMP at this point) at no additional cost. Sad face :slight_smile:

It’s very sad indeed, when you think that in just a few month you won’t even be able to buy a PC that doesn’t have a dual core in it.