QNX Sales SUCKS!
Tim Anderson
people at QNX?
I've been working on a Pentium based embedded project with several other
people and due to the comlexity of the software for it, we decided to
look at using an off the shelf RTOS.
I found an Intel Embedded development system for doing evaluation and
development. Its main selling point was that they bundle QNX, VxWorks,
and several NT Real Time extension software packages so that you can try
them out and decide if this is the right embedded OS for your particular
appliction. Sounds like a good deal? NOT!
To start out with, after spending some serious $$ on the development
system, I find out that the QNX that they send is a "crippled demo". In
fact they include literature that says that it does not have the full
functionality of the "real" development system. The literature says
quote:"If you'd like a free evaluation version of the QNX Development
System, contact QNX Software Systems at 1-800-363-9001"
OK. So I called them up and spoke with salesperson #1. He asks me all
kinds of questions about my application, quantities, schedule, etc,
etc. I answer all of these questions and then ask him about getting a
"real" development system. After all, I thought that that's what I
would get with the Intel development system. He said that somebody
would be contacting me soon. Of course nobody calls me back.
So, I call up again and talk to sales person #2. I explain the
situation and ask about the "real" development system. Is he of any
help? No. He goes into his sales pitch about QNX and how he can arrange
great quantity discounts for CPU licenses, etc, etc. Then he asks me if
I want a quote for all this. I tell him that I just want the
development system to evaluate QNX. He takes my number and say he'll
get back to me. Yeah, right. Of course, no call.
Frustrated, I then mentioned this chain of events to our materials and
layout person. " No problem" , he says. "I'm used to dealing with these
types". So he calls up and gets nowhere with sales person #3. He can't
even get a verbal quote on pricing from these people. He says in disgust
that sales person #3 is the "most evasive sales person that he has ever
dealt with"
Finally, our marketing guy who can shmooze with the best of them, calls
up and gets in touch with sales person #4. Of course, he meets with
just as much success as we have previously. All he manages to get is a
formal quote emailed to him.
After all these problems, I thought I'd at least have a look at the
"crippled demo" after forking out all those bucks. Of course, it has an
expiration date of Dec 31, 1999 so after a few weeks of operation, it
won't even boot now.
At this point, the thought of having to deal with these people again
just pisses me off. Has anyone else had similar experiences, or am I
just unfortunate enough to get stuck with dregs of the QNX sales force?
Armin Steinhoff
>
>Has anyone else had as frustrating a time as I have with the sales
>people at QNX?
Well ... that's a well known problem =:-[ The quality of the QSSL sales and
marketing is far behind the quality of their products.
Try to call up a local QSSL sales office ...
Armin
William Boyle
are they repping you? QNX, pay heed to this. Don't make it difficult to
buy your product. It is great, but it shouldn't have to be painful to
get information, feedback, and support. This person has been turned off
to the product now, and you have a real bit of work cut out for you to
turn it around.
Just MHO.
-Bill Boyle
CR91LJL
>>people at QNX?
>
>Well ... that's a well known problem =:-[ The quality of the QSSL sales and
>marketing is far behind the quality of their products.
>
>Try to call up a local QSSL sales office ...
>
This is a real bad sign. Usually, when you can't find out something as simple
as a price or how to order, it means a company is about to go out of business
and have made serious staff reductions. Maybe not, though, since someone did
answer the phone!
Mario Charest
CR91LJL wrote in message <19990109213622...@ng21.aol.com>...
take over all
the sales channles to increase their mark-up (and everybody else in the
embedded market
is doing it this way). But the way I see it, is they totaly under-estimated
what
was involved and so far they are no sign that things are improving.
I think their idea is sound but they don't seems to know how to properly get
there.
Inge Vabekk
<3697BF6A...@mediaone.net>...
>Well, if a sales rep makes it difficult to purchase your
product, why
>are they repping you? QNX, pay heed to this. Don't make it
difficult to
>buy your product. It is great, but it shouldn't have to be
painful to
>get information, feedback, and support. This person has
been turned off
>to the product now, and you have a real bit of work cut out
for you to
>turn it around.
I think QSSL's, and the sales representatives' problem, is
that there are
so many "unserious" people asking about QNX. By "unserious"
I mean
people who would do just as well, probably better, with
Linux, or even
Windows.
QNX is a realtime system, and it's primarily supposed to be
purchased
by developers who are developing a product for resale. The
end-user,
in many cases (most?) isn't even aware that there's an
operating system
called QNX, and even more unaware that their product runs
it.
Personally I didn't experience any of the problems above,
but I've been doing program development on a relatively
advanced level for many years, and my first purchase of QNX
was a complete system, program development and graphics
included. The price I paid seemed to be quite high, but the
savings on hardware alone was more than enough to pay back
the price (at that time most RT systems required some kind
of proprietary hardware).
I'd suggest that what you do is:
1. Sell your services to whoever needs you to develop a
system. Include the price for the developent system in the
total price.
2. Order the development system. That way the sales reps
will know that you're serious and you're not going to waste
their time.
3. Develop the software, finish the product and add the
end-user licence(s) to sell with it.
4. Start your next project. This time, the initial price for
the development system remains in your bank account......
Oh, one more thing: Don't sell yourself cheap. My experience
is that the amount of work required for developing RT
systems is far lower with QNX than for competing systems, at
least if you've worked with genuine RT systems before. Also,
less hardware is needed because of QNX's low resource
requirements. There's a risk that you won't be taken
seriously if your price is too low.
--
in...@arxi.nospam (remove spam....)
CR91LJL
>take over all
>the sales channles to increase their mark-up (and everybody else in the
>embedded market
>is doing it this way). But the way I see it, is they totaly under-estimated
>what
>was involved and so far they are no sign that things are improving.
>
>I think their idea is sound but they don't seems to know how to properly get
>there.
>
>
is to tell someone you will call them back and not do it.
I have a suggestion for QSSL marketing if they don't want to screw with the
small fish. Offer the product at list price through www.qnx.com just like
amazon.com or any other modern business. All you need to buy it is a credit
card. When someone calls and QSSL doesn't have time to mess with it, give the
potential customer a URL and tell them to visit that site. Included at the
site would be a questionaire the customer could fill out to identify the
company, it's size, D&B reference, number of potential applications, number of
real-time capable programmers, speed of their fastest cpu, their web site,
number of spaces in the parking lot, number of 5 star restaurants within 30
minutes of corporate headquarters, and other pertinent marketing information.
The order could be filled that day, shipped via FedX and received the next day.
Hey QSSL, your're welcome. And I don't even have an MBA.
Jay Tribick
| people at QNX?
| I've been working on a Pentium based embedded project with several
| other people and due to the comlexity of the software for it, we
| decided to look at using an off the shelf RTOS.
| I found an Intel Embedded development system for doing evaluation and
At least you actually got to speak to them, they didn't answer
the phone when I rang (got the usual voice-pbx type thingie..)
Regards,
Jay Tribick <neta...@fastnet.co.uk>
[| Network Admin | FastNet International | http://fast.net.uk/ |]
[| Finger neta...@fastnet.co.uk for contact info & PGP PubKey |]
[| +44 (0)1273 T: 677633 F: 621631 e: neta...@fast.net.uk |]
Earth Administrator
> Has anyone else had as frustrating a time as I have with the sales
> people at QNX?
>
Try e-mailing to Paul Kilgour (p...@qnx.com). He is the Application Manager.
--
Claudio Cardozo
Infax Tecnologia & Sistemas
QNX Distributor in Brazil
Guy Macon
>I don't think there about to go out of business. I think they are trying to
>take over all
>the sales channles to increase their mark-up (and everybody else in the
>embedded market
>is doing it this way). But the way I see it, is they totaly under-estimated
>what
>was involved and so far they are no sign that things are improving.
That's fine if they want to do it that way, but they need to have a
helpful salesperson to replace the channel that they took over.
QNX ignoring one system developers is like a farmer who only buys
equipment for harvesting his crops and ignores planting - after all,
there's no mony to be had by putting seeds into the ground...
Nobody
>
<Staff deleted>
> Well, I hope someone at QSSL is listening. The worst possible marketing ploy
> is to tell someone you will call them back and not do it.
> I have a suggestion for QSSL marketing if they don't want to screw with the
> small fish. Offer the product at list price through www.qnx.com just like
> amazon.com or any other modern business. All you need to buy it is a credit
Do you think "small fish" developers can afford $3000+ development
package ?
> card. When someone calls and QSSL doesn't have time to mess with it, give the
> potential customer a URL and tell them to visit that site. Included at the
> site would be a questionaire the customer could fill out to identify the
> company, it's size, D&B reference, number of potential applications, number of
> real-time capable programmers, speed of their fastest cpu, their web site,
> number of spaces in the parking lot, number of 5 star restaurants within 30
> minutes of corporate headquarters, and other pertinent marketing information.
>
> The order could be filled that day, shipped via FedX and received the next day.
>
>
> Hey QSSL, your're welcome. And I don't even have an MBA.
Okay, let's say QSSL offers a QNX development package at low price
($300). Yes, many
"small fish" developers will order the package on-line and receive it
Fedex the
next day. But, what about "small fish" Developer Supports ? How much
supports
do you think QSSL can offer to developer for $300 ? None or very
little. Soon or later
these "small fish" developers will turn into a group of angry developers
and
flood QSSL's phone lines with demand for technical supports for FREE.
Get real ! If you can not afford the $3000+ development package, it
doesn't matter
where you placed your development package order. (Sales Rep. or on-line)
P.S. If you are serious about developing for QNX, you will find the
money to buy the
development package. All "big fish" have R&D budgets for buying
evaluation products.
CR91LJL
Price and support are different issues. I was commenting on the marketing
practices of failing to communicate with customers. I think they should just
make it easy (and public) to determine the price as a function of volume. They
should also have easy entry for development. I think it would be a good
strategy to give away the development tools and charge for support. Forums
like this provide the alternative support for the "small fish". This doesn't
affect me, the applications I develop for are $200k installations. We don't
worry about the cost of the O/S or development tools. The biggest problem I
have with QSSL is their not meeting promises on product delivery and their
abandonment of the factory automation field.
>
>
>
>
Igor Kovalenko
>
> Okay, let's say QSSL offers a QNX development package at low price
> ($300). Yes, many
> "small fish" developers will order the package on-line and receive it
> Fedex the
> next day. But, what about "small fish" Developer Supports ? How much
> supports
> do you think QSSL can offer to developer for $300 ? None or very
> little. Soon or later
> these "small fish" developers will turn into a group of angry developers
> and
> flood QSSL's phone lines with demand for technical supports for FREE.
>
Micro$oft charges under $100 for Windows, then something like $200 per
incident for support. Something like that applies to their development
systems as well. However, people use their software and M$ doesn't looks
like a company overwhelmed by phone requests for support for FREE.
Rather, it looks like a rich company.
Don't forget about community. People sometimes can help others for free.
- Igor
Frank Kolnick
Igor Kovalenko <o...@palmira.net> writes:
> Micro$oft charges under $100 for Windows, then something like $200 per
> incident for support. Something like that applies to their development
> systems as well. However, people use their software and M$ doesn't looks
> like a company overwhelmed by phone requests for support for FREE.
> Rather, it looks like a rich company.
>
> Don't forget about community. People sometimes can help others for free.
Not to mention that there are two books available about QNX :-)
Frank Kolnick,
Software Consultant (QNX, real-time, tech. writing)
Basis Computer Systems Inc.
to...@ikp.liu.se
> The biggest problem I
> have with QSSL is their not meeting promises on product delivery and their
> abandonment of the factory automation field.
What do you mean with "their abandonment of the factory automation field"?
This worries me since I am in the factory/vehicular automation field and
plan to use QNX.
Tomas Hogstrom
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Armin Steinhoff
>
>
>> The biggest problem I
>> have with QSSL is their not meeting promises on product delivery and their
>> abandonment of the factory automation field.
>
>What do you mean with "their abandonment of the factory automation field"?
>This worries me since I am in the factory/vehicular automation field and
>plan to use QNX.
The statement "their abandonment of the factory automation field" is just
blanked nonsens ...
Yes, QSSL doesn't any specific development for the factory automation .. IMHO
that is not their job. There are a lot of third parties delivering solutions
for that area ... visit our web site :-)
Armin Steinhoff
A. Steinhoff
>
>In article <36A2524E...@palmira.net>
>Igor Kovalenko <o...@palmira.net> writes:
>
>> Micro$oft charges under $100 for Windows, then something like $200 per
>> incident for support. Something like that applies to their development
>> systems as well. However, people use their software and M$ doesn't looks
>> like a company overwhelmed by phone requests for support for FREE.
>> Rather, it looks like a rich company.
>>
>> Don't forget about community. People sometimes can help others for free.
>
> Not to mention that there are two books available about QNX :-)
Great, but the QSSL marketing doesn't promote these books in any way!!
Are there any reasons why the QNX web site doesn't have a 'book store'
button ???
Why do they only a lousy promotion of the book from Rob Krten ??
Why do they just ignore the new great book from Frank Kolnick ??
Why are these books not mentioned in the literature section of their web
site ??
This provincial farce sucks !!
Armin
Mikhail...@kelk.com
I haven't have any kind of relation to QNX sales, but I believe you guys.
What I found interesting in "FREE" support is:
THE QNX TECH SUPPORT ENTIRELY INCOMPETENT!
THE COMPILER:
I have reported to them about my technical problems I experienced with
Watcom C Compiler and the guy in Tech Support was trying to send me
to the Sales Department with the problems ! (What a f*ck is this ?,
Am I a sales guy ?)
I noticed them that is a serious bug which has to be fixed ASAP.
No competent reply. ( lots of suggestions to put the module code
right into the main module, play with the switches).
I must agree, they are not able to fix problems with the Watcom C compiler.
Tell me guys is '_strncpy' equal to 'strncpy' ? ( QSSL tech support thinks it
is equal!)
The bug was and is still ralated to the ES (segment reg.) reloading in the
optimazed compiler mode with the stack check option disabled.
THE OS:
I discovered a situation when the Dev16 dies. In my report and clues the
QSSL is completely deaf. The response from the developers was like:
I have a single memory bit error on my PC, sounds fine, except:
I have more than 20 PC's and it happens in a certain point on all of them and
only on the 16 bits applications.
No attempts to fix the bug (now I have 4.25, its still the same).
THE IEDIT:
I have made more than one attempt to get the information about the IEDIT.
I have never received any answer.
The situation with this seems to me is very simple:
They are trying to force me to use Photon with all this extremely restricted
environment (PhAB). Yes I'm not a such good programmer to fight with
all Photon's heavy weight stuff.
They cut the most powerful future of the QNX Windows which is the external
"configuration" file (I mean PICT file). I consider this move a "great"
thing! ( example:
You need to shift a text label just a little bit in a window:
Very simple!, Let's re-compile the whole thing again.
*It works very nice when a customer on a thousands kilometers away from you*
THE BOOKS:
I own both books we are talking about in the comp.os.qnx, The book
promoted by QSSL is very basic. (I prefer to read QNX OS Architecture instead)
Frank's book is a great book (I MUST recommend this book).
Does anybody see the book on the QNX web ? NO!
Tell me why ?
Yes, Igor you are right the QSSL has extreme case of politics and
I guess in human relation too.
They just try to kill Photon's competitor, QNX Windows
--> Hey guys!, great move!
Sorry guys, but I can't keep all this * inside of me.
SY Mike.
--
This are my personal views of the situation and not those of my employer.
Igor Kovalenko
>
> Just couple of more words about the QNX sales and Tech support.
>
> I haven't have any kind of relation to QNX sales, but I believe you guys.
> What I found interesting in "FREE" support is:
> THE QNX TECH SUPPORT ENTIRELY INCOMPETENT!
>
I told you Mike, don't waste time trying to destroy a wall by your head.
For my experience, you can get competent responce directly from a
developer, but it depends heavily from their personal attitude to you.
They usually fix bugs, provided you feed then with qualified report and
they can reproduce it.
However, with Watcom we got bad luck. It is not their product and they
can't fix it. As for Dev16, I'm not sure what is going on. You may try
to contact some higher level managers.
> thing! ( example:
> You need to shift a text label just a little bit in a window:
> Very simple!, Let's re-compile the whole thing again.
> *It works very nice when a customer on a thousands kilometers away from you*
>
To be honest, you are wrong here. You don't need to recompile, just to
rebind the executable with new resource file. Of course, it implies your
customer thousand kilometers away have that phab to edit resource file
and phabbind utility, which are parts of expensive development package.
But this is not problem of technology itself, just wrong
packaging/marketing, which indeed sucks. Well, the same actually applies
to IEdit.
> THE BOOKS:
> I own both books we are talking about in the comp.os.qnx, The book
> promoted by QSSL is very basic. (I prefer to read QNX OS Architecture instead)
> Frank's book is a great book (I MUST recommend this book).
> Does anybody see the book on the QNX web ? NO!
> Tell me why ?
> Yes, Igor you are right the QSSL has extreme case of politics and
> I guess in human relation too.
>
It is not first case when I hear that Frank's book is great. The reason
why QSSL doesn't promote his book is probably some sort of agreement
with Rob Krten wrt his (competing) book. And we got to accept their
'business model' which consists primarily from undercover moves. Nobody
can find any kind of rational idea behind their whole distribution
model. Amen.
> They just try to kill Photon's competitor, QNX Windows
> --> Hey guys!, great move!
>
Copyright for QNX Windows belongs to Basis Comp. Systems. The only part
from QSSL are IEdit and graphic drivers, which both sucks desperately
anyway. If Basis wants to keep QNX Windows alive, they can do simple
thing:
1. Write a wrapper for SCI Tech drivers set.
2. Implement a good object oriented GUI class library with _really_
customizeable look and feel
(e.g., just port Qt/Harmony or Gtk or whatever)
If they can port Qt, a lot of good applications including several visual
application builders and Netscape will be available automatically. Then
I wouldn't bet much on Photon ;)
> Sorry guys, but I can't keep all this * inside of me.
Do you feel better now?
Cheers,
- Igor
Mikhail...@kelk.com
> > I must agree, they are not able to fix problems with the Watcom C compiler.
> > Tell me guys is '_strncpy' equal to 'strncpy' ? ( QSSL tech support thinks >
> is equal!)
> _strncpy() is not listed in the on-line docs. Is there some reason you
> want to use it? No doubt if you have a problem with strncpy() it has
> to be pretty subtle as this is one of the more commonly used
> compiler provided routines.
> Ok, so if you can give us an example with a makefile, maybe we
> can help. I know there are a lot of pitfalls related to compiler
> options. A customer of mine spent a couple of weeks finding a
> problem that sounds suspiciously like yours. In their case they
> were cross compiling from NT to QNX and needed to find out the
> right compiler switches.
Ok, Here at the end of the message, I put the source codes for the "seed"
function and the Makefile and the Main module.
I gonna be happy if somebody can help me.
SY Mike.
--- _strncpy.c begins ---
#include <string.h>
#include <stdlib.h>
/* The _strncpy() function is used to copy not more than the max_len
* byte(s) from the source buffer, pointed by the src, to the
* destination buffer, pointed by the dst. The src buffer is null terminated
* string. If the source buffer is longer than the max_len the
* function will copy (max_len - 1) byte(s) and append termination
* zero at the end.
*/
char *_strncpy( char *dst, char *src, int max_len ) {
int len;
len=min( strlen( src ), max_len );
memcpy( dst, src, len );
dst[len] = 0;
return dst;
}
--- _strncpy ends ---
--- Makefile begins ---
OBJS = _strncpy.o
problem: problem.c $(OBJS)
$(CC) -w3 -T1 problem.c -o problem $(OBJS)
_strncpy.o: _strncpy.c
wcc386 -oi -w3 -s _strncpy.c
# ^ here it is
--- Makefile ends ---
--- main.c begins ---
#include <stdio.h>
#include <sys/inline.h>
#include <string.h>
#include <i86.h>
#include <sys/seginfo.h>
#pragma off( check_stack );
extern char *_strncpy( char *dst, char *src, int max_bytes );
char dst[ 256 ];
/********************************************************** PRL_PORT_BASE()
***/
static unsigned short
prl_port_base( int lpt_no ) {
unsigned bios_prn_sel;
unsigned short far *port_base;
if( lpt_no > 2 || lpt_no < 0 ) /* Invalid lpt no. */
return 0;
if( (bios_prn_sel = qnx_segment_overlay( 0x408, 0x1000 )) == -1 )
return 0; /* Can't overlay
the BIOS printer data area */
port_base = (unsigned short far*) MK_FP( bios_prn_sel, 0 );
return port_base[ lpt_no ];
}
/******************************************************************* MAIN()
***/ int main() { char *src = "Some data...";
printf( "PORT BASE ADDRESS: %04X\n",
prl_port_base( 0 ) );
_strncpy( dst, src, sizeof( dst ) );
printf( "dst = '%s'\n", dst );
return 0;
}
--- main.c ends ---
Mitchell Schoenbrun
> I haven't have any kind of relation to QNX sales, but I believe you guys.
> What I found interesting in "FREE" support is:
> THE QNX TECH SUPPORT ENTIRELY INCOMPETENT!
While the readers of this newsgroup are entirely open to all
sorts of griping, It would help your cause if you were a
little more specific about why you think this.
> THE COMPILER:
> I have reported to them about my technical problems I experienced with
> Watcom C Compiler and the guy in Tech Support was trying to send me
> to the Sales Department with the problems ! (What a f*ck is this ?,
> Am I a sales guy ?)
> I noticed them that is a serious bug which has to be fixed ASAP.
> No competent reply. ( lots of suggestions to put the module code
> right into the main module, play with the switches).
Maybe you could let us know what the problem is. I don't know
why you were sent to the Sales department. You should be aware
of the fact that the Watcom compiler is supported by another
company. For basic questions QSSL should be able to help,
but if you have a real but to fix, they will have to
contact Watcom.
> I must agree, they are not able to fix problems with the Watcom C compiler.
> Tell me guys is '_strncpy' equal to 'strncpy' ? ( QSSL tech support thinks it
> is equal!)
_strncpy() is not listed in the on-line docs. Is there some reason you
want to use it? No doubt if you have a problem with strncpy() it has
to be pretty subtle as this is one of the more commonly used
compiler provided routines.
> The bug was and is still ralated to the ES (segment reg.) reloading in the
> optimazed compiler mode with the stack check option disabled.
Ok, so if you can give us an example with a makefile, maybe we
can help. I know there are a lot of pitfalls related to compiler
options. A customer of mine spent a couple of weeks finding a
problem that sounds suspiciously like yours. In their case they
were cross compiling from NT to QNX and needed to find out the
right compiler switches.
> THE OS:
> I discovered a situation when the Dev16 dies. In my report and clues the
> QSSL is completely deaf. The response from the developers was like:
> I have a single memory bit error on my PC, sounds fine, except:
> I have more than 20 PC's and it happens in a certain point on all of them and
> only on the 16 bits applications.
I've had some problems with Dev16 also. I only try to run it for
Dev.net. It is more of a problem getting QSSL to fix the 16 bit
stuff. Is it possible for you to use the 32 bit version? Maybe
you could elaborate as to what the problem is.
> THE IEDIT:
> I have made more than one attempt to get the information about the IEDIT.
> I have never received any answer.
Am I right in assuming that this is a QNX Windows program? I believe
Frank Kolnick is providing the support for this product.
Mitchell Schoenbrun --------- masc...@pobox.com
Frank Kolnick
Mitchell Schoenbrun <masc...@tsoft.com> writes:
> > THE IEDIT:
> > I have made more than one attempt to get the information about the IEDIT.
> > I have never received any answer.
>
> Am I right in assuming that this is a QNX Windows program? I believe
> Frank Kolnick is providing the support for this product.
Ah, no :-)
We did the *server* (screen, screen_event and dialog), but QSSL
provides all of the drivers, Olwm and Iedit. I am not able to provide
any support for the latter. We''ve provided Bwm as an alternative
for Olwm and Bpict as a *complement* (someday, perhaps, to develop into
a replacement) for Iedit.
Guy Macon
>The biggest problem I have with QSSL is [...] and their abandonment of
>the factory automation field.
In what way has QSSL abandoned the factory automation field?
Igor Kovalenko
>
> This field is owned by Microsoft. Pick up a copy of Control Engineering or a
> similar technical rag. Find any product offerings based on QNX. Find anyone
> developing automation tools based on QNX.
Hmm. Armin can comment better than me on this. But there are offerings.
Moreover, there are big projects currently in development, which use
products like RealFlex, Sitex, PCP Virgo, etc. Their biggest problem
however, currently most of them are based on QNX Windows, which indeed
is abandoned by QSSL. Photon versions are about to appear in this year.
> And, now the biggest problem - find
> a manufacturer of process I/O who advertises or offers driver support for QNX.
> How many of the fieldbuses are supported by QNX drivers?
I know about QNX drivers for Profibus, CAN, LON, Interbus. If you don't
know, you probably just looking in wrong places. Particularly, US does
not appear to be a leader in this field yet, so try to look at globe
map... there are other countries. Try Germany for instance.
> How about USB? Can
> you buy a USB driver from QNX?
USB and FireWire are responsibility of QSSL I think. I remember, some
time ago (like a year) I read something like 'we are sitting on a
documentation and waiting for customer requests to pop up' wrt FireWire.
Still sitting I guess. Perhaps it is too comfortable to sit that way :)
> Can you get a USB driver for QNX from any of
> the process I/O manufacturers who are now offering products with USB interfaces
> (National, I/O Tech, Keithley-Metrabyte, etc.). Call them up. Tell them you
> insist on using QNX for your application because it is truely a real-time
> operating system and one of very high integrity and ask them if they have heard
> of it and plan on offering drivers or know where you can get them. Tell them
> you won't buy their product without a QNX solution. I have done this many
> times. The answer you get is, "we will sell you the source code for our MS
> drivers for a nominal amount and you can take it from there".
>
> There are only two approaches available and these turn away 99% of potential
> customers. 1) develop your own drivers (as we have done), 2) Search for 3rd
> party support. Sometimes you can find this - usually pretty expensive.
>
> I say QSSL has abandoned this field because they offer no visible support for
> it.
>
Actually, they trying to do it once in a while. May be they just didn't
choose a right 'strategic partner' for alliance yet.
> This doesn't mean that QNX is not a good solution. I wouldn't know how to
> accomplish what we do with QNX using any other O/S and probably couldn't get
> the job done with twice the staff if I had to use NT or CE.
So, you doing the same thing like most of us here. Hate it and love it
:)
- Igor
CR91LJL
>> have with QSSL is their not meeting promises on product delivery and their
>> abandonment of the factory automation field.
>
This field is owned by Microsoft. Pick up a copy of Control Engineering or a
similar technical rag. Find any product offerings based on QNX. Find anyone
developing automation tools based on QNX. And, now the biggest problem - find
a manufacturer of process I/O who advertises or offers driver support for QNX.
How many of the fieldbuses are supported by QNX drivers? How about USB? Can
you buy a USB driver from QNX? Can you get a USB driver for QNX from any of
the process I/O manufacturers who are now offering products with USB interfaces
(National, I/O Tech, Keithley-Metrabyte, etc.). Call them up. Tell them you
insist on using QNX for your application because it is truely a real-time
operating system and one of very high integrity and ask them if they have heard
of it and plan on offering drivers or know where you can get them. Tell them
you won't buy their product without a QNX solution. I have done this many
times. The answer you get is, "we will sell you the source code for our MS
drivers for a nominal amount and you can take it from there".
There are only two approaches available and these turn away 99% of potential
customers. 1) develop your own drivers (as we have done), 2) Search for 3rd
party support. Sometimes you can find this - usually pretty expensive.
I say QSSL has abandoned this field because they offer no visible support for
it.
This doesn't mean that QNX is not a good solution. I wouldn't know how to
accomplish what we do with QNX using any other O/S and probably couldn't get
the job done with twice the staff if I had to use NT or CE.
Ton C. Jaspers
>/******************************************************************* MAIN()
>***/ int main() { char *src = "Some data...";
> printf( "PORT BASE ADDRESS: %04X\n",
> prl_port_base( 0 ) );
> _strncpy( dst, src, sizeof( dst ) );
How about:
_strncpy ( dst, src, sizeof( dst ) - 1 ) ;
your _strncpy may move a '\0' to dst[len] !
> printf( "dst = '%s'\n", dst );
> return 0;
>}
>--- main.c ends ---
Ton C. Jaspers
(t...@xs4all.nl)
Armin Steinhoff
says...
>
>>> The biggest problem I
>>> have with QSSL is their not meeting promises on product delivery and their
>>> abandonment of the factory automation field.
>>
>>What do you mean with "their abandonment of the factory automation field"?
>
>This field is owned by Microsoft.
Sorry ... that field isn't owned by M$, it's more or less owned by third parties
of M$! The industry is actually moving to LINUX and RTOSystems like QNX :-)
> Pick up a copy of Control Engineering or a similar technical rag.
Good example :-) ... Have a look to the advertisement of FF Automation e.g.!!
Their products are QNX based and they use PROFIBUS FMS under QNX!!
> Find any product offerings based on QNX.
No problem ... visit e.g. the third party directory at the QSSL home page
> Find anyone developing automation tools based on QNX.
No problem ... visit e.g. our homepage.
>And, now the biggest problem - find a manufacturer of process I/O who
>>advertises or offers driver support for QNX.
The 'special problem' for CUMMINS Engine is that there are no QNX driver SOURCES
available from manufactures or system integrators ... for free :-)
> How many of the fieldbuses are supported by QNX drivers?
You know since years that we are offering QNX drivers (complete implementations)
for all really important fieldbus systems as COTS products...
There are a lot of big and small fieldbus installations running under QNX in the
field.(Oil platforms, steel production, motor test systems, material flow
systems with more than 40 QNX systems in one installation ... etc)
Available fieldbus support:
- PROFIBUS FDL (ISA / PC104)
- PROFIBUS FMS (ISA / PC104)
- PROFIBUS DP master (12Mb/s) (ISA / PC104, CompactPCI)
- PROFIBUS DP slave (12Mb/s) (ISA / PC104)
- PROFIBUS PA
- INTERBUS master (ISA / PC104)
- native CAN (ISA / PC104, CompactPCI)
- CANOpen (1Mb/s) (ISA / PC104, CompactPCI)
- CAN for Selectron I/Os
- LonWorks (PCLTA, PC104 -> MIP/P50, MIP DPS)
- ASI (ISA / PC104)
These are the most important fieldbusses in the industry ...
BTW, combine the fieldbus I/Os with network transparent IEC1131-3 graphical
programming and system independent GUI tools like TILCON and you will get a
great base for factory automation.
> How about USB?
USB is NOT a fieldbus ..
> Can you buy a USB driver from QNX?
Why from QNX??? It's available from TWO third parties !!!
>Can you get a USB driver for QNX from any of the process I/O manufacturers >who
>are now offering products with USB interfaces (National, I/O Tech,
>>Keithley-Metrabyte, etc.). etc. ??
Why from the manufacturers??? USB is an OPEN STANDARD, that means their USB
products have to work with any USB compliant driver !!
>Call them up. Tell them you insist on using QNX for your application because
>>it is truely a real-time operating system and one of very high integrity and
>>ask them if they have heard of it
That means nothing ...
>and plan on offering drivers or know where you can get them. Tell them you
>>won't buy their product without a QNX solution. I have done this many times.
>The answer you get is, "we will sell you the source code for our MS drivers >for
>a nominal amount and you can take it from there".
Yes ... they will SELL their source code :-) Where's the problem ??
>There are only two approaches available and these turn away 99% of potential
>customers. 1) develop your own drivers (as we have done),
Interesting ... do you sell your source code too??
>2) Search for 3rd party support. Sometimes you can find this - usually pretty
>>expensive.
Their stuff is as 'usually pretty' expensive as the stuff from your company.
Why is Cummins Engine not selling the design of their engines ??
Why do they insist to sell their expensive products ??
>I say QSSL has abandoned this field because they offer no visible support for
>it.
It's simply not their job !
>This doesn't mean that QNX is not a good solution. I wouldn't know how to
>accomplish what we do with QNX using any other O/S and probably couldn't get
>the job done with twice the staff if I had to use NT or CE.
You couldn't get the job done in the same quality with NT or CE.
Armin Steinhoff
Armin Steinhoff
>
>CR91LJL wrote:
>>
>> This field is owned by Microsoft. Pick up a copy of Control Engineering or a
>> similar technical rag. Find any product offerings based on QNX. Find anyone
>> developing automation tools based on QNX.
>
>Moreover, there are big projects currently in development,
... and a lot are running since years, in the US too :-)
> which use
>products like RealFlex, Sitex, PCP Virgo, etc. Their biggest problem
>however, currently most of them are based on QNX Windows, which indeed
>is abandoned by QSSL. Photon versions are about to appear in this year.
Yes ... e.g. SITEX will be available as "PHOCUS" under PHOTON with e.g.
PROFIBUS-FMS, PROFIBUS-FDL and PROFIBUS-DP (12Mb/s master/slave)
The new TILCON TRTD version will include a tool to generate GRAPHICAL EDITORS
for e.g. PHOTON, so you can easily create your own visualization tool.
See http://www.tilcon.com ...
[ clip .. ]
>> I say QSSL has abandoned this field because they offer no visible support for
>> it.
>
>Actually, they trying to do it once in a while. May be they just didn't
>choose a right 'strategic partner' for alliance yet.
Igor, what is the right 'strategic partner' for QSSL ???
Armin
Jamie Villeneuve
: Award software has a USB driver for QNX ...
USB Access
Award Software
777 East Middlefield Road
Mountain View, CA
94043-4023
Voice: +1 650-237-6800
Fax: + 1 650-968-0274
Web: www.award.com
Description
A turnkey solution for USB connectivity, USB Access speeds integration
of USB devices into products based on the QNX operating system. A full
implementation of the current USB specification, USB Access includes the
host controller software stack and host class drivers. It supports USB
standard functions and scales to different applications.
Because of its modular design, USB Access is easily customized to
support OEM-specific design requirements. It is portable to different
CPU platforms, including Intel x86, MIPs, Power PC, ARM, and StrongARM.
Its bus abstraction layer permits quick adaptation to different bus
interfaces; it supports both OHCI and UHCI USB controllers.
Award's extensive line of embedded systems software products implement
existing PC technologies on QNX. These include connectivity software
solutions for both the USB and the IEEE-1394 standards, remote preboot
system administration, diagnostics and repair, embedded systems BIOS,
and complete software integration and engineering services.
Third party solutions can be found at http://www.qnx.com/tippy/index.html
Regards,
-Jamie
Michael Hunter
I have no idea why you had a hard time talking to TS about this.
I work with them on a daily basis and all I can say is that I have
a lot of respect for them. On a daily basis they are working in
widely different fields with wildly different people on all kinds
of strange problems. I'm sure that between misunderstandings and
mistakes that some issues like yours have crept through but I don't
believe it is not a common occurance.
Now, on to your technical issues...
: --- _strncpy.c begins ---
[...]
: char *_strncpy( char *dst, char *src, int max_len ) {
: int len;
: len=min( strlen( src ), max_len );
: memcpy( dst, src, len );
: dst[len] = 0;
: return dst;
: }
: --- _strncpy ends ---
This code fails. Try
char dst[3];
char *src = "abc";
_strncpy(dst, src, sizeof dst);
You end up with a buffer overrun. What you really need to do is
either 1) state up front that max_len is one smaller then the
destination buffer or 2) [better IMHO] 'len=min(strlen(src), max_len - 1);'.
: --- Makefile begins ---
: OBJS = _strncpy.o
: problem: problem.c $(OBJS)
: $(CC) -w3 -T1 problem.c -o problem $(OBJS)
: _strncpy.o: _strncpy.c
: wcc386 -oi -w3 -s _strncpy.c
: # ^ here it is
Don't use wcc386 directly. We ship cc as the driver for two reasons
1) the cc commandline is standardized
2) its easier to use (as you'll see below your error was here)
problem.c == main.c?
: --- Makefile ends ---
[looks OK at first blush]
: --- main.c ends ---
It turns out that the were not handing the right command line to wcc386.
If you change you makefile to
---start Makefile---
OBJS = _strncpy.o
main: main.c $(OBJS)
$(CC) -w3 -T1 main.c -o main $(OBJS)
_strncpy.o: _strncpy.c
wcc386 -i=/usr/include -ms -oi -w3 -s _strncpy.c
---end Makefile---
Now your executable will work.
Better yet, try:
---start better Makefile---
CFLAGS = -s -w3
LDFLAGS = -T1
main: main.o _strncpy.o
---end better Makefile---
Michael Hunter
--
* Michael Hunter (mphu...@qnx.com, http://www.qnx.com/~mphunter)
Mikhail...@kelk.com
mphu...@qnx.com (Michael Hunter) wrote:
> Mikhail...@kelk.com wrote:
..
> huge snip
..
Dear Gentlemen!,
Thank you for your reply.
I must say thank you very much for your attention and
I should appologi[s|z]e for misleading you.
I got all of you comments, but, please, let me point again to the
original contents.
I was speaking about the Watcom C Compiler 10.6 bug (but not about the
makefile, sorry Michael).
I am seriosly upset by your comment, because it tells me:
You haven't tried to start the program. Please try it.
The thing is:
ES is not equal to DS when you call the _strncpy() function!
You can create the asm files from the obj files and you'll see
how ES is reloaded and forgotten.
The same trouble with ES/DS happens when you have assigned a structure to a
structure.
THE QNX TECH SUPPORT one more chapter:
Some where around 8 months ago we had trouble, one of our processes
was dying from time to time. We tried to analyze the traceinfo buffer.
We discovered that the message:
18 Msg fault <pid> 0002 0002 <process_name>
may have some iteresting information. We understood couple of parameters
from the list (like process id, process name ;-)), but some of the numbers are
still unknown. Since QNX doesn't provide the description of the trace codes,
we've called the QNX tech Support with the request to explain the codes.
After a 2 (two) weeks delay, we got the answer:
The code 0002 is an undocumented code, but if it is 000C or 000B it means
you have the stack curruption.
Great ?
SY Mike.
Michael Hunter
: In article <782e2l$ckp$1...@gateway.qnx.com>,
: mphu...@qnx.com (Michael Hunter) wrote:
: > Mikhail...@kelk.com wrote:
: ..
: > huge snip
: ..
: > --
: > * Michael Hunter (mphu...@qnx.com, http://www.qnx.com/~mphunter)
: Dear Gentlemen!,
: Thank you for your reply.
: I must say thank you very much for your attention and
: I should appologi[s|z]e for misleading you.
: I got all of you comments, but, please, let me point again to the
: original contents.
Unfortunately you snipped them. At the end of this article I'll
include the parts that are relevant for context.
: I was speaking about the Watcom C Compiler 10.6 bug (but not about the
: makefile, sorry Michael).
These two things are linked. You havn't proven yet that there is
a compiler bug. You have shown that if you compile two different
source modules with different calling conventions that they won't
work together. How you compile (thus my comments on your makefile)
is central to this.
: I am seriosly upset by your comment, because it tells me:
: You haven't tried to start the program. Please try it.
I ran your program. Both miscompiled with the original source
(thus seeing it fault) and after I fixed the makefile and seeing
it succeed. Did you try what I suggested?
: The thing is:
: ES is not equal to DS when you call the _strncpy() function!
Correct. You use different calling conventions in main.c and
_strncpy.c. You shouldn't expect that they work together.
mph
--->from previous posting (with comments pointing out the important parts)
#: --- Makefile begins ---
#: OBJS = _strncpy.o
#
#: problem: problem.c $(OBJS)
#: $(CC) -w3 -T1 problem.c -o problem $(OBJS)
#
#: _strncpy.o: _strncpy.c
#: wcc386 -oi -w3 -s _strncpy.c
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Your makefile. Notice what is different between this line and...
#: # ^ here it is
#
#Don't use wcc386 directly. We ship cc as the driver for two reasons
#
#1) the cc commandline is standardized
#2) its easier to use (as you'll see below your error was here)
#
#problem.c == main.c?
#
#: --- Makefile ends ---
#[looks OK at first blush]
#: --- main.c ends ---
#
#It turns out that the were not handing the right command line to wcc386.
#If you change you makefile to
#
#---start Makefile---
#OBJS = _strncpy.o
#
#main: main.c $(OBJS)
# $(CC) -w3 -T1 main.c -o main $(OBJS)
#
#_strncpy.o: _strncpy.c
# wcc386 -i=/usr/include -ms -oi -w3 -s _strncpy.c
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this one?
#---end Makefile---
#
#Now your executable will work.
#
#Better yet, try:
#
#
#---start better Makefile---
#CFLAGS = -s -w3
#LDFLAGS = -T1
#
#main: main.o _strncpy.o
#---end better Makefile---
qnx...@ibm.net
outlined in this thread.
Selling our products directly in North America is a strategic decision that
is intended to better service our customers. This is not to say this was not
the case when using other forms of distribution. However a direct presence,
regional offices with sales and technical capabilities, together with the
infrastructure here at QSSL corporate was put together for the benefit of
you, our customers.
This approach resulted in a restructuring within the North American sales
force so we could handle the business previously covered by our
distributors. This restructuring is ongoing, and feedback such as that given
in this thread is invaluable. We don't claim to have everything right
straight off the bat, but we are continuing to make appropriate changes so
that we realize the goal we have set - so that customers like yourselves
have a close working relationship with the representatives you deal with at
QSSL.
I know that sometimes we have to vent to reveal our frustrations. Thats
fine, all of us need to do that sometimes, but that feedback also needs to
get back to QSSL so that we can look at investigating and solving problems.
Mr Anderson did just that and I believe we have come to an appropriate
resolution of his problem. There were certainly misunderstandings and
problems that contributed to his situation that we expect to improve
considerably in the near future. These problems had already been identified
by QSSL management and we are putting procedures in place to address them.
Customer feedback is imperative to improving the way we deal with you. Feel
free to send us email at in...@qnx.com detailing your problem, as did Mr
Anderson, and we will look at taking appropriate steps to address your
concerns. Of course, posting to this newsgroup is also an avenue for you to
determine whether other members of the QNX community have experienced
similar problems.
I hope this helps address some of the concerns in this thread. We're here to
help, so
please feel free to contact us.
Greg Bergsma
Vice President, North American Sales
________________________________________________________
QNX Software Systems Ltd | Phone: +1 (613) 591 0931
175 Terence Matthews Crescent| Fax: +1 (613) 591 3579
Kanata, Ontario, Canada | Email: gber...@qnx.com
K2M1W8 | WWW: http://www.qnx.com
________________________________________________________
Gene Heskett
Ok Greg, glad to see someone with a sign on his desk has surfaced.
Thank you for giving me a publicly visible 'target' to shoot at. :)
I think a future question needs to be addressed, if only behind the
scenes for right now. I've been lurking this group/list since the
announcement about the Amiga was made. And as you can see by the sig,
an Amiga user.
That will have to do with what I understand is to be the NEUTRINO
kernal, as you have agreed to furnish to Amiga Inc (or whomever they are
by the time they have product to sell again) for the 'Next Generation
Amiga' and its pre-announced OS5 operating system.
That question is: Will sufficient documentation, as detailed as can be
had for the current, and past versions of Ados, be provided to the end
user such that you won't have to be bothered by RTFM questions? Or is
it going to be one of being almost forced to dis the thing in order to
figure out what its doing, and what registers we should load with what
in order to write usefull, efficient code for this (to us) new system?
If indeed the next Amiga takes off, it might be possible that sales of
your contribution to this new OS might be your largest single item at
the end of the year, not this one since so far, no Amiga Inc. stated
timetable has even come close to being met, but the next one, maybe...
That I think depends on how much PR is actually used to launch, and to
keep it in the publics face for long enough to establish a new userbase.
How is the support and documentation to be made available? Bearing in
mind that this hypothetical end user who buys a 'Next' Amiga, isn't
going to even consider it if he has already been put on notice that
'support', or a copy of the "includes" might cost him $3000, as a
message or such as read here in this group has tended to indicate. I
could see that IF the sales measured < 100, but once it gets to 10,000,
if it does, then it will have become viable. At that point, I would
want to see it as something readily obtainable, and priced in line with
the 'other guys', certainly under $500, hopefully in due time, under
$100 by the time sales have passed the 100,000 mark.
One of the things that helped make the Amiga so popular amongst the
techie types was, without a doubt, Commodores 'CATS' program, where
anybody with the price of a subscription to it and BIX, was the equal to
the best of them with regard to access to the info required to write
that program he had an idea for.
What say you? Give us a morsel to keep us going? Or squash it before
it ever gets started?
Cheers, Gene
--
Gene Heskett, CET, UHK |Amiga A2k Zeus040 50 megs fast/2 megs chip
Ch. Eng. @ WDTV-5 |A2091,GuruRom,1g Seagate,CDROM,Multiface III
<gene_h...@iolinc.net> or |Buddha + 4 gig WDC drive, 525 meg tape
<gene_h...@westvirginia.net>|Stylus Pro, EnPrint, Picasso-II, 17" vga
RC5-Moo! 22kkeys/sec isn't much, but it all helps
--
Geoff Roberts
> Mikhail...@kelk.com wrote:
>
> I have no idea why you had a hard time talking to TS about this.
> I work with them on a daily basis and all I can say is that I have
> a lot of respect for them. On a daily basis they are working in
> widely different fields with wildly different people on all kinds
> of strange problems. I'm sure that between misunderstandings and
> mistakes that some issues like yours have crept through but I don't
> believe it is not a common occurance.
Yes. In 10 years I have _NEVER_ heard such a complaint about QSSL Tech
Support! Quite the contrary - QSSL TS is renowned as being superior in
this area - second to none. There are often comments to this effect here
in this newsgroup.
Geoff Roberts.
>
> Now, on to your technical issues...
>
> : --- _strncpy.c begins ---
> [...]
> : char *_strncpy( char *dst, char *src, int max_len ) {
> : int len;
> : len=min( strlen( src ), max_len );
> : memcpy( dst, src, len );
> : dst[len] = 0;
> : return dst;
> : }
> : --- _strncpy ends ---
>
> This code fails. Try
> char dst[3];
> char *src = "abc";
> _strncpy(dst, src, sizeof dst);
>
> You end up with a buffer overrun. What you really need to do is
> either 1) state up front that max_len is one smaller then the
> destination buffer or 2) [better IMHO] 'len=min(strlen(src), max_len - 1);'.
>
> : --- Makefile begins ---
> : OBJS = _strncpy.o
>
> : problem: problem.c $(OBJS)
> : $(CC) -w3 -T1 problem.c -o problem $(OBJS)
>
> : _strncpy.o: _strncpy.c
> : wcc386 -oi -w3 -s _strncpy.c
> : # ^ here it is
>
> Don't use wcc386 directly. We ship cc as the driver for two reasons
>
> 1) the cc commandline is standardized
> 2) its easier to use (as you'll see below your error was here)
>
> problem.c == main.c?
>
> : --- Makefile ends ---
> [looks OK at first blush]
> : --- main.c ends ---
>
> It turns out that the were not handing the right command line to wcc386.
> If you change you makefile to
>
> ---start Makefile---
> OBJS = _strncpy.o
>
> main: main.c $(OBJS)
> $(CC) -w3 -T1 main.c -o main $(OBJS)
>
> _strncpy.o: _strncpy.c
> wcc386 -i=/usr/include -ms -oi -w3 -s _strncpy.c
> ---end Makefile---
>
> Now your executable will work.
>
> Better yet, try:
>
>
> ---start better Makefile---
> CFLAGS = -s -w3
> LDFLAGS = -T1
>
> main: main.o _strncpy.o
> ---end better Makefile---
>
>
> Michael Hunter
>
> --
> * Michael Hunter (mphu...@qnx.com, http://www.qnx.com/~mphunter)
>
>
--
Realtime Technology Systems Pty Ltd.
2 Hadleigh Circuit,
Isabella Plains,
Canberra,
ACT 2905,
AUSTRALIA.
Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
email: ge...@rtts.com.au
Mitchell Schoenbrun
> I am seriosly upset by your comment, because it tells me:
> You haven't tried to start the program. Please try it.
I for one am now intrigued about this conversation.
I downloaded this code and tried to make and run it.
At first I got compiler errors because the wcc386 command
did not look for include files in the right place.
I added Mikes modification " -i=/usr/include" and it
compiled. I ran it and got the following:
PORT BASE ADDRESS: 0378
dst = 'Some data...'
Is there something wrong with this?
Am I missing something?
> The thing is:
> ES is not equal to DS when you call the _strncpy() function!
If this is a problem, I'm not saying yes or no, what is
the result.
> how ES is reloaded and forgotten.
> The same trouble with ES/DS happens when you have assigned a structure to a
> structure.
You did not indicate how to get the source file, so I did the
following:
wdisasm -s _strncpy.o -l=_strncpy.S
Below is a simplified version of what I got.
Listed are the push'es and pop's. In one
place in the code is a jmp which goes to
the same level of stack. The numbers on the
left are my own indication of what level of
stack the program is in.
1 push ecx
2 push esi
3 push edi
4 push ebp
----------------
5 push es
----------------
5 pop es
----------------
5 push es
----------------
-5 pop es
----------------
5 push es
----------------
6 push edi
----------------
-6 pop edi
-5 pop es
----------------
-4 pop ebp
-3 pop edi
-2 pop esi
-1 pop ecx
ret
Is something wrong here?
I'm an innocent bystander and after two postings you've
failed to demonstrate something wrong. This does
not help your credibility with the Tech support
side.
CR91LJL
>>>> have with QSSL is their not meeting promises on product delivery and
>their
>>>> abandonment of the factory automation field.
>>>
>>>What do you mean with "their abandonment of the factory automation field"?
>>
>
>parties
>of M$! The industry is actually moving to LINUX and RTOSystems like QNX :-)
>
>
>Their products are QNX based and they use PROFIBUS FMS under QNX!!
>
>
First, a potential customer would have to know that QNX existed or stumble onto
one of these 3rd party suppliers.
>
>> Find anyone developing automation tools based on QNX.
>
>No problem ... visit e.g. our homepage.
>
>>And, now the biggest problem - find a manufacturer of process I/O who
>>>advertises or offers driver support for QNX.
>
>The 'special problem' for CUMMINS Engine is that there are no QNX driver
>SOURCES
>available from manufactures or system integrators ... for free :-)
I don't demand free source, just reasonable. We have purchased driver source
from Metrabyte, Analog Devices, Datel, MTL(Transition Technology),Data
Translation, IOTech, and Softing (CAN) from which we build QNX drivers. But,
you see, we develop proprietary applications strictly for internal use, support
a wide variety of I/O systems, and don't re-sell anything. We have developed a
general purpose data acquisition and control software package which performs a
variety of testing and data logging functions and yet is limited in quantity
and distribution. For this reason, I don't want to spend $50,000 for the
source unless it is a fairly high volume for us and includes unlimited
distribution within our corporation (we are willing to sign non-disclosure
agreements, etc.). For some of the more important stuff we have invested
nearly that much in driver development. FYI, we have about 200-250
installations worldwide with a potential for nearly double that. We have paid
list price for all QNX licenses and don't complain about the price. This
includes X-Windows, Photon, QNX-Windows, TCP/IP on most systems.
>
>> How many of the fieldbuses are supported by QNX drivers?
>
>You know since years that we are offering QNX drivers (complete
>implementations)
>for all really important fieldbus systems as COTS products...
True. We may even do some business someday if we can find a supplier of some
good instrumentation-quality analog I/O on Profibus for under $200/channel.
>
>There are a lot of big and small fieldbus installations running under QNX in
>the
>field.(Oil platforms, steel production, motor test systems, material flow
>systems with more than 40 QNX systems in one installation ... etc)
>
>Available fieldbus support:
>
> - PROFIBUS FDL (ISA / PC104)
> - PROFIBUS FMS (ISA / PC104)
> - PROFIBUS DP master (12Mb/s) (ISA / PC104, CompactPCI)
> - PROFIBUS DP slave (12Mb/s) (ISA / PC104)
> - PROFIBUS PA
>
> - INTERBUS master (ISA / PC104)
>
> - native CAN (ISA / PC104, CompactPCI)
> - CANOpen (1Mb/s) (ISA / PC104, CompactPCI)
> - CAN for Selectron I/Os
>
> - LonWorks (PCLTA, PC104 -> MIP/P50, MIP DPS)
>
> - ASI (ISA / PC104)
>
>These are the most important fieldbusses in the industry ...
>
>BTW, combine the fieldbus I/Os with network transparent IEC1131-3 graphical
>programming and system independent GUI tools like TILCON and you will get a
>great base for factory automation.
We have a small number of installations on we we run TILCON developed GUIs.
Most of our GUI development is done with PV-WAVE, a high level data analysis
and visualization package that runs in X-Windows and for which we paid $200,000
for porting to QNX and unlimited distribution within Cummins. Visual Numerics
even came to a QNX conference to show it off and found zero interest from the
QNX community.
>
>> How about USB?
>
> USB is NOT a fieldbus ..
>
>> Can you buy a USB driver from QNX?
>
>Why from QNX??? It's available from TWO third parties !!!
I had some discussions with Award about a year ago. They estimated about
$50,000 to apply their driver to Keithley-Metrabyte's Smartlink I/O system.
Maybe the situation has changed now. Who is offering it other than Award.
>
>>Can you get a USB driver for QNX from any of the process I/O manufacturers
>>who
>>are now offering products with USB interfaces (National, I/O Tech,
>>>Keithley-Metrabyte, etc.). etc. ??
>
>Why from the manufacturers??? USB is an OPEN STANDARD, that means their USB
>products have to work with any USB compliant driver !!
>
>>Call them up. Tell them you insist on using QNX for your application
>because
>>>it is truely a real-time operating system and one of very high integrity
>and
>>>ask them if they have heard of it
>
>That means nothing ...
It means that people shun an operating system for which there is little 3rd
party support.
>
>>and plan on offering drivers or know where you can get them. Tell them you
>>>won't buy their product without a QNX solution. I have done this many
>times.
>>The answer you get is, "we will sell you the source code for our MS drivers
>>for
>>a nominal amount and you can take it from there".
>
>Yes ... they will SELL their source code :-) Where's the problem ??
The problem is that you still have to convert it to run on QNX. This always
costs more than the source. The supplier of hardware is happy to sell or give
you a driver if it means you will buy their hardware.
>
>>There are only two approaches available and these turn away 99% of potential
>>customers. 1) develop your own drivers (as we have done),
>
>Interesting ... do you sell your source code too??
Not yet, but we would -- up to the point we consider it to contain
engine-specific proprietary technology.. About 90% of our code is not
engine-specific and could be sold. We have explored some options. Anyone
interested? We have invested about $2.5M in software development on a
QNX-based platform.
>
>>2) Search for 3rd party support. Sometimes you can find this - usually
>pretty
>>>expensive.
>
>Their stuff is as 'usually pretty' expensive as the stuff from your company.
>
>Why is Cummins Engine not selling the design of their engines ??
We do. We have joint ventures with Iveco, Scania, and various companies in
China, India, etc. to manufacture our designs locally.
>Why do they insist to sell their expensive products ??
>
>>I say QSSL has abandoned this field because they offer no visible support
>for
>>it.
>
>It's simply not their job !
If I were running QSSL, I would hire 3rdparty companies to develop process I/O
drivers and then give them to the hardware manufacturers. The only requirement
being that their advertisements say, "drivers available for Windows 3.1,
'95/'98, NT4.0, CE, and QNX4". (MS stuff optional)
>
>>This doesn't mean that QNX is not a good solution. I wouldn't know how to
>>accomplish what we do with QNX using any other O/S and probably couldn't get
>>the job done with twice the staff if I had to use NT or CE.
>
>You couldn't get the job done in the same quality with NT or CE.
Hey, we agree on something. I wouldn't even want to try.
Unfortunately, I have to continually argue and explain about why we aren't
converting everything to NT, since it is obviously the way the world is going.
An interesting situation is also developing with Linux. It is officially
verboten, but we use it as a web-server, database server, and Netscape browser
server (running in a QNX xterm) to support our QNX test systems. Now the Linux
community is beginning to push real-time. Meanwhile our corporate systems
people view Linux as a virus.
Len Logterman
ps. Okay, a few more things. I have never been contacted by anyone in the QSSL
marketing organization since their change in distribution structure. Not a
good sign, but I suppose they don't consider us an important customer. On the
other hand, I have always considered their technical support to be outstanding.
Of course, until September we always purchased the Gold Support. But, back in
the good old QNX2 days when all support was free, it was still outstanding.
>
>Armin Steinhoff
>
Nobody
>
> Nobody wrote:
> >
> > Okay, let's say QSSL offers a QNX development package at low price
> > ($300). Yes, many
> > "small fish" developers will order the package on-line and receive it
> > Fedex the
> > next day. But, what about "small fish" Developer Supports ? How much
> > supports
> > do you think QSSL can offer to developer for $300 ? None or very
> > little. Soon or later
> > these "small fish" developers will turn into a group of angry developers
> > and
> > flood QSSL's phone lines with demand for technical supports for FREE.
> >
>
> incident for support. Something like that applies to their development
> systems as well. However, people use their software and M$ doesn't looks
> like a company overwhelmed by phone requests for support for FREE.
> Rather, it looks like a rich company.
Ok!
Let's have a vote. How many of you, QNXers, are willing to pay $300 for
the
entire QNX development package and have absolutely NO SUPPORT for the
product.
(This includes no supports for compiler bugs, updates and any types
problem resolution).
90% of QNXers would vote YES!!!!!!!! (Including me!)
You know what is going to happen? QSSL will sell thousands of these
development packages. But, very soon many QNXers will start discovering
bugs that hidden in these development packages. What would you do, if
you
discovered a very nasty compiler bug that stopped your application dead
in
the water ?
This is what I would do, I would call up QSSL and demand for
a quick fix. Ahh... Isn't this called "Technical Support" ?
What if, QSSL refuse to fix the bug on the ground that the
low cost development packages were sold "as is" without support.
I would said, "But...But...But..." What but? There is no support
"period".
The next thing I would do, just like Mr. Mikhail_Nefedov did in his
previous newsgroups
posting, is to bad mouth QSSL.
I can go on....on....on... and on.
Can you see a disaster happening ?
> Don't forget about community. People sometimes can help others for free.
>
> - Igor
I agreed with you on this. But, there are many bugs that only QSSL
could fix.
Geoff Roberts
> Mikhail...@kelk.com wrote:
> > I am seriosly upset by your comment, because it tells me:
> > You haven't tried to start the program. Please try it.
>
> I for one am now intrigued about this conversation.
> I downloaded this code and tried to make and run it.
>
> At first I got compiler errors because the wcc386 command
> did not look for include files in the right place.
> I added Mikes modification " -i=/usr/include" and it
> compiled. I ran it and got the following:
>
> PORT BASE ADDRESS: 0378
> dst = 'Some data...'
>
> Is there something wrong with this?
> Am I missing something?
I don't think so Mitch - you don't miss much! ;-)
I did this also, and it failed. Add a -d3 to it and it works.
Then I changed the wcc386 in the Makefile to a cc command, and
it all works fine - debug or not.
I have to agree with Mike (for what it's worth) and state that I don't believe
direct invocation of wcc386 is a good idea. I know people who have had no end
of trouble as a result of this. Certainly in this case uniform use of cc would
have prevented the acrimony we saw demonstrated - as the problem would not have
occured.
My 0.63 US cents worth...
Geoff.
--
Igor Kovalenko
>
> Ok!
>
> Let's have a vote. How many of you, QNXers, are willing to pay $300 for
> the
> entire QNX development package and have absolutely NO SUPPORT for the
> product.
> (This includes no supports for compiler bugs, updates and any types
> problem resolution).
>
> 90% of QNXers would vote YES!!!!!!!! (Including me!)
>
> You know what is going to happen? QSSL will sell thousands of these
> development packages. But, very soon many QNXers will start discovering
> bugs that hidden in these development packages. What would you do, if
> you
> discovered a very nasty compiler bug that stopped your application dead
> in
> the water ?
>
> This is what I would do, I would call up QSSL and demand for
> a quick fix. Ahh... Isn't this called "Technical Support" ?
>
> What if, QSSL refuse to fix the bug on the ground that the
> low cost development packages were sold "as is" without support.
>
Wrong idea. Nothing what you sell for more than media + shiping should
be 'as is'. Freeware is 'as is' but you know what you are doing, right?
If you sell for $300, you got to fix bugs. That means you may not be
obliged to work closely with a customer on each bug like QSSL does now,
but you certainly should collect bug reports and fix them periodically
with scheduled maintainance releases. If you want to stay in business,
you got to improve your product and provide new versions as well.
Eligibility to get them may be subject to some subscription fee however.
> I would said, "But...But...But..." What but? There is no support
> "period".
>
> The next thing I would do, just like Mr. Mikhail_Nefedov did in his
> previous newsgroups
> posting, is to bad mouth QSSL.
>
Mike was just too emotional. Sometimes things just get crazy. But be
sure, QSSL got a lot of money from Russia due to his job in past. And I
bet, still getting due to his current job.
> I agreed with you on this. But, there are many bugs that only QSSL
> could fix.
Let our fantasy fly without limits :)
What about adopting Open Source development model? Huh?
It may look scary, but in fact most their customers are corporate
customers/develpers. They are required to have a vendor behind any used
software by corporate policies. So, they will buy anyway, as long as
they going to use it for anything serious. Thos who are not serious,
will not buy anyway. But this single move would change the landscape of
this business.
In fact, I'm sure that earlier or later some player in this business
will do it. Then it will be too late for others.
- Igor
Geoff Roberts
> Igor Kovalenko wrote:
> >
> > Nobody wrote:
> > >
> > > Okay, let's say QSSL offers a QNX development package at low price
> > > ($300). Yes, many
> > > "small fish" developers will order the package on-line and receive it
> > > Fedex the
> > > next day. But, what about "small fish" Developer Supports ? How much
> > > supports
> > > do you think QSSL can offer to developer for $300 ? None or very
> > > little. Soon or later
> > > these "small fish" developers will turn into a group of angry developers
> > > and
> > > flood QSSL's phone lines with demand for technical supports for FREE.
> > >
> >
> > Micro$oft charges under $100 for Windows, then something like $200 per
> > incident for support. Something like that applies to their development
> > systems as well. However, people use their software and M$ doesn't looks
> > like a company overwhelmed by phone requests for support for FREE.
> > Rather, it looks like a rich company.
>
>
> Let's have a vote. How many of you, QNXers, are willing to pay $300 for
> the
> entire QNX development package and have absolutely NO SUPPORT for the
> product.
> (This includes no supports for compiler bugs, updates and any types
> problem resolution).
>
> 90% of QNXers would vote YES!!!!!!!! (Including me!)
I think the average QNX developer is a little more discerning than that.
> You know what is going to happen? QSSL will sell thousands of these
> development packages. But, very soon many QNXers will start discovering
> bugs that hidden in these development packages. What would you do, if
Hidden bugs? What are you saying here exactly?
> you
> discovered a very nasty compiler bug that stopped your application dead
> in
> the water ?
>
> This is what I would do, I would call up QSSL and demand for
> a quick fix. Ahh... Isn't this called "Technical Support" ?
>
> What if, QSSL refuse to fix the bug on the ground that the
> low cost development packages were sold "as is" without support.
>
> I would said, "But...But...But..." What but? There is no support
> "period".
>
> The next thing I would do, just like Mr. Mikhail_Nefedov did in his
> previous newsgroups posting, is to bad mouth QSSL.
This was unfortunate, but I am prepared to put it down to a little spleen
venting which everyone does from time to time. I wish he hadn't attacked
the guys in TS though - they really don't deserve it.
As it turns out, it may not be a compiler bug at all....
> I can go on....on....on... and on.
>
> Can you see a disaster happening ?
I can if the price for everything I needed were to drop to $300!
>
> > Don't forget about community. People sometimes can help others for free.
> >
> > - Igor
>
> I agreed with you on this. But, there are many bugs that only QSSL
> could fix.
And they will . Gee... sometimes overnight! I've had "quick fixes" and special
diagnostic tools slipped into my home dir on QUICS a few times. As have
many others who frequent this group.
Geoff.
pwaec...@qnx.de
> Igor Kovalenko wrote:
> >
> >
> > Micro$oft charges under $100 for Windows, then something like $200 per
> > incident for support. Something like that applies to their development
> > systems as well. However, people use their software and M$ doesn't looks
> > like a company overwhelmed by phone requests for support for FREE.
> > Rather, it looks like a rich company.
>
> Ok!
>
> Let's have a vote. How many of you, QNXers, are willing to pay $300 for
> the
> entire QNX development package and have absolutely NO SUPPORT for the
> product.
> (This includes no supports for compiler bugs, updates and any types
> problem resolution).
>
> 90% of QNXers would vote YES!!!!!!!! (Including me!)
>
> development packages. But, very soon many QNXers will start discovering
> bugs that hidden in these development packages. What would you do, if
> discovered a very nasty compiler bug that stopped your application dead
> in the water ?
>
> This is what I would do, I would call up QSSL and demand for
> a quick fix. Ahh... Isn't this called "Technical Support" ?
>
Nope. This is called "feedback".
If QSSL is interested in high quality software, they should fix
the reported bug with the next release.
If you demand a service (perhaps you don't understand TFM) or
have questions that aren't covered in the docs, then I will
call that support.
> What if, QSSL refuse to fix the bug on the ground that the
> low cost development packages were sold "as is" without support.
>
It is the interest of QSSL to get rid of bugs in there products.
> I would said, "But...But...But..." What but? There is no support
> "period".
>
No. Be thankful if they fix the bug. Both parties have the same interest.
I _believe_ that this model will work. Do you know about the discussions
with Troll Tech and their product Qt which is the base of KDE?
Modification and Redistribution of Qt were not allowed.
This doen't prevent developers from reporting bugs.
They were all fixed ASAP by Troll, because it is there inner interest.
That's the way motivation works...
The next major release will be under a NPL-like license with modifications
allowed...
> The next thing I would do, just like Mr. Mikhail_Nefedov did in his
> previous newsgroups
> posting, is to bad mouth QSSL.
>
> I can go on....on....on... and on.
>
> Can you see a disaster happening ?
>
Nope. There will be always people who begin to shout and treat
others in an unfair manner. Seems to be human...
> > Don't forget about community. People sometimes can help others for free.
> >
> > - Igor
>
> I agreed with you on this. But, there are many bugs that only QSSL
> could fix.
>
IMO, the latter is not true. Of course they have the source and therefore
they have an advantage... ;-)
It should be "should": they should fix their bugs themselves!
The developer base for QNX and Neutrino (Amiga!) should be broader.
To accomplish this, sell developer licenses as cheap as possible to
students and pupils.
I think the campaign with Waterloo-University is the right way.
QSSL earns its money with runtime-licenses. A company earning
money with the development tools can't afford it, though ...
I want to add that these statements are entirely my own. I think it
is obvious, but ...
BTW, in Germany the price would be over 600 DM, because in Germany
everything tends to be more expensive. Students won't spend this
amount of money... (e.g. Borland Delphi Standard for 289 DM)
Mikhail...@kelk.com
mphu...@qnx.com (Michael Hunter) wrote:
> Mikhail...@kelk.com wrote:
> : In article <782e2l$ckp$1...@gateway.qnx.com>,
> : mphu...@qnx.com (Michael Hunter) wrote:
> : > Mikhail...@kelk.com wrote:
> : ..
> : > huge snip
> : ..
> : Thank you for your reply.
> : I must say thank you very much for your attention and
> : I should appologi[s|z]e for misleading you.
>
> : I got all of you comments, but, please, let me point again to the
> : original contents.
>
> Unfortunately you snipped them. At the end of this article I'll
> include the parts that are relevant for context.
>
> : I was speaking about the Watcom C Compiler 10.6 bug (but not about the
> : makefile, sorry Michael).
>
> These two things are linked. You havn't proven yet that there is
> a compiler bug. You have shown that if you compile two different
> source modules with different calling conventions that they won't
> work together. How you compile (thus my comments on your makefile)
> is central to this.
>
> : You haven't tried to start the program. Please try it.
>
> (thus seeing it fault) and after I fixed the makefile and seeing
> it succeed. Did you try what I suggested?
>
> : ES is not equal to DS when you call the _strncpy() function!
>
Dear Michael Hunter, Mitchell Schoenbrun, Geoff Roberts!,
Thank you very much for your help in finding my oversight in the program.
As result of this entire exercise:
1. Does it not prove Tech Support incompetensy, as Michael spent may be
couple of seconds to find the problem, while Tech Support has yet to find
and repond to this topic in 2 weeks.
2. It is very bad that Michael DOES NOT work in the QNX Tech Support.
3. It is me opinion that Tech Support is incompetent.
4. Personally, I love the QNX OS, since QSSL is the parent of the
great kid (QNX OS), QSSL should be responsible for the childs behaviour.
5. If you are a "small fish" or not a former QSSL employee looking for
Sales of Tech Support you can expect (90%) little or no service from them.
Sincerely yours Mike.
raja...@qnx.com
> >> The biggest problem I
> >> have with QSSL is their not meeting promises on product delivery and their
> >> abandonment of the factory automation field.
> >
> >What do you mean with "their abandonment of the factory automation field"?
>
> similar technical rag. Find any product offerings based on QNX. Find anyone
> developing automation tools based on QNX. And, now the biggest problem - find
> a manufacturer of process I/O who advertises or offers driver support for QNX.
> you buy a USB driver from QNX? Can you get a USB driver for QNX from any of
> the process I/O manufacturers who are now offering products with USB interfaces
> insist on using QNX for your application because it is truely a real-time
> operating system and one of very high integrity and ask them if they have heard
> you won't buy their product without a QNX solution. I have done this many
> times. The answer you get is, "we will sell you the source code for our MS
> drivers for a nominal amount and you can take it from there".
Just a side note, QNX will be providing USB for both NTO and QNX4, this stated
you will still need the client driver for the specific device if it is not
one of the classes we support.
> There are only two approaches available and these turn away 99% of potential
> customers. 1) develop your own drivers (as we have done), 2) Search for 3rd
> party support. Sometimes you can find this - usually pretty expensive.
>
> I say QSSL has abandoned this field because they offer no visible support for
> it.
>
> This doesn't mean that QNX is not a good solution. I wouldn't know how to
> accomplish what we do with QNX using any other O/S and probably couldn't get
> the job done with twice the staff if I had to use NT or CE.
>
>
Mikhail...@kelk.com
> If you want to point fingers then you can point at me for one and not
> TS. They showed me a version of your problem and I told them you
> should be using cc and not passing the arguments directly to wcc and
> the linker. Since this was all verbal I did not correct the missing
> model argument to wcc which may of pointed you in the right
> direction.
Now I understand that TS went to you for the answer and all your
information wasn't relayed to me. I maintain my opinion....
Crash and burn, live and learn.
raja...@qnx.com
> Dear Michael Hunter, Mitchell Schoenbrun, Geoff Roberts!,
> Thank you very much for your help in finding my oversight in the program.
> As result of this entire exercise:
>
> 1. Does it not prove Tech Support incompetensy, as Michael spent may be
> couple of seconds to find the problem, while Tech Support has yet to find
> and repond to this topic in 2 weeks.
>
> 2. It is very bad that Michael DOES NOT work in the QNX Tech Support.
>
> 3. It is me opinion that Tech Support is incompetent.
>
> 4. Personally, I love the QNX OS, since QSSL is the parent of the
> great kid (QNX OS), QSSL should be responsible for the childs behaviour.
>
> 5. If you are a "small fish" or not a former QSSL employee looking for
> Sales of Tech Support you can expect (90%) little or no service from them.
>
> Sincerely yours Mike.
>
If you want to point fingers then you can point at me for one and not
Mikhail...@kelk.com
> As a member of the Tech Support department, I have made a point of
> staying out of this discussion until now. A few points:
>
> - We do _NOT_ support any use of the compiler that is not invoked
> using 'cc'. This is policy. There are many reasons for this.
> Consider also that the OS is built using 'cc'...
> The fault of the TS rep you spoke with may have been simply not
> making this clear to you.
It would be nice to have the "policy", just to know what to ask
what not to ask.
> - This is an open forum. If you had posted this on QUICS, it would
> have received a much faster response from us. If no TS people
> EVER posted here, I do not believe you would have cause to complain.
Hhh, I thought better to call TS.
>
> - If we are so incompetent, please remember that you also did not
> figure this out. Believe it or not, we are here to help you, and
> we always try our best to do just that. (Often our best and then
> some - I speak from experience on that. :-) ).
I beleave so, I guess it is just my bad luck.
>
> : 2. It is very bad that Michael DOES NOT work in the QNX Tech Support.
>
> - It makes sense to me that the people who are our best and brightest
> work on our products, and not spend their days answering telephones.
My comedic skills need some work.
Issue 2 is supposed to be a joke ;-(.
>
> : 3. It is me opinion that Tech Support is incompetent.
>
> - Fair enough. :-) It is my opinion that you are wrong.
no comments, I said what I wanted to say.
>
> : 4. Personally, I love the QNX OS, since QSSL is the parent of the
> : great kid (QNX OS), QSSL should be responsible for the childs behaviour.
>
> - Glad to here it. We love it too. :-)
>
> : 5. If you are a "small fish" or not a former QSSL employee looking for
> : Sales of Tech Support you can expect (90%) little or no service from
> : them.
>
> - Again, I strongly disagree with this. My opinion. We do, of course,
> make mistakes on occasion - we are human. But, honestly, I believe
> that we provide excellent service and support, and I am sorry you
> do not agree. Hopefully the next time you contact us, you will
> give us a chance to change your mind.
Promising.
>
> Regards,
> Graeme Peterson
> QSSL Technical Support.
Igor Kovalenko
>
> Dear Michael Hunter, Mitchell Schoenbrun, Geoff Roberts!,
> Thank you very much for your help in finding my oversight in the program.
I'm glad you are now in good mood :)
> As result of this entire exercise:
>
> 1. Does it not prove Tech Support incompetensy, as Michael spent may be
> couple of seconds to find the problem, while Tech Support has yet to find
> and repond to this topic in 2 weeks.
>
This also proves that you should double-double-double-double check for
your own errors before you blame a vendor, especially if you blame him
publically and in such a rough way.
> 2. It is very bad that Michael DOES NOT work in the QNX Tech Support.
>
Who should work on TCP/IP then? I'd prefer to see Michael in his current
job.
> 3. It is me opinion that Tech Support is incompetent.
>
> 4. Personally, I love the QNX OS, since QSSL is the parent of the
> great kid (QNX OS), QSSL should be responsible for the childs behaviour.
>
> 5. If you are a "small fish" or not a former QSSL employee looking for
> Sales of Tech Support you can expect (90%) little or no service from them.
>
I used to be very small fish in my previous life. So, from sales yes, I
agree. From support, it depends on a particular problem. Sometimes they
help you, sometimes not. But if you have found a real problem with
software, you almost always can find help directly from developers,
provided the problem is important not only for you. And provided _you_
can speak competently about the problem. They need qualified feedback,
not just complains. Lot of people there helped me on various subjects.
Thanks to all of them.
- Igor
Igor Kovalenko
>
> No. Be thankful if they fix the bug. Both parties have the same interest.
> I _believe_ that this model will work. Do you know about the discussions
> with Troll Tech and their product Qt which is the base of KDE?
> Modification and Redistribution of Qt were not allowed.
> This doen't prevent developers from reporting bugs.
> They were all fixed ASAP by Troll, because it is there inner interest.
> That's the way motivation works...
>
Yes! And I'd say, Qt is one of really outstanding quality products. I
can only imagine QSSL working this way. Source is open, so everyone can
find bugs & suggest fixes. It is ultimate 'documentation' as well.
However, they keep control over modifications.
> The next major release will be under a NPL-like license with modifications
> allowed...
>
The answer to Harmony I guess :)
> BTW, in Germany the price would be over 600 DM, because in Germany
> everything tends to be more expensive. Students won't spend this
> amount of money... (e.g. Borland Delphi Standard for 289 DM)
That means $600 in Russia :)
It is yet another issue. Price should be unified for the whole world.
- Igor
Graeme Peterson
: In article <78347l$nqp$1...@gateway.qnx.com>,
: mphu...@qnx.com (Michael Hunter) wrote:
: > Mikhail...@kelk.com wrote:
: > : In article <782e2l$ckp$1...@gateway.qnx.com>,
: > : mphu...@qnx.com (Michael Hunter) wrote:
: > : > Mikhail...@kelk.com wrote:
: > : ..
: > : > huge snip
: > : ..
: > : > --
: > : > * Michael Hunter (mphu...@qnx.com, http://www.qnx.com/~mphunter)
: >
: > : Dear Gentlemen!,
: > : Thank you for your reply.
: >
: Dear Michael Hunter, Mitchell Schoenbrun, Geoff Roberts!,
: Thank you very much for your help in finding my oversight in the program.
: As result of this entire exercise:
: 1. Does it not prove Tech Support incompetensy, as Michael spent may be
: couple of seconds to find the problem, while Tech Support has yet to find
: and repond to this topic in 2 weeks.
As a member of the Tech Support department, I have made a point of
staying out of this discussion until now. A few points:
- We do _NOT_ support any use of the compiler that is not invoked
using 'cc'. This is policy. There are many reasons for this.
Consider also that the OS is built using 'cc'...
The fault of the TS rep you spoke with may have been simply not
making this clear to you.
- This is an open forum. If you had posted this on QUICS, it would
have received a much faster response from us. If no TS people
EVER posted here, I do not believe you would have cause to complain.
- If we are so incompetent, please remember that you also did not
figure this out. Believe it or not, we are here to help you, and
we always try our best to do just that. (Often our best and then
some - I speak from experience on that. :-) ).
: 2. It is very bad that Michael DOES NOT work in the QNX Tech Support.
- It makes sense to me that the people who are our best and brightest
work on our products, and not spend their days answering telephones.
: 3. It is me opinion that Tech Support is incompetent.
- Fair enough. :-) It is my opinion that you are wrong.
: 4. Personally, I love the QNX OS, since QSSL is the parent of the
: great kid (QNX OS), QSSL should be responsible for the childs behaviour.
- Glad to here it. We love it too. :-)
: 5. If you are a "small fish" or not a former QSSL employee looking for
: Sales of Tech Support you can expect (90%) little or no service from
: them.
- Again, I strongly disagree with this. My opinion. We do, of course,
make mistakes on occasion - we are human. But, honestly, I believe
that we provide excellent service and support, and I am sorry you
do not agree. Hopefully the next time you contact us, you will
give us a chance to change your mind.
Regards,
Graeme Peterson
QSSL Technical Support.
: Sincerely yours Mike.
: -----------== Posted via Deja News, The Discussion Network ==----------
: http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
Graeme Peterson
QNX Technical Support
g...@qnx.com
A. Steinhoff
says...
>
[ clip .. ]
>>> Find any product offerings based on QNX.
>>
>>No problem ... visit e.g. the third party directory at the QSSL home page
>
>First, a potential customer would have to know that QNX existed or
>stumble onto one of these 3rd party suppliers.
Well, I'm sure that there are a lot of people not knowing Win CE :-))
[ clip .. ]
>True. We may even do some business someday if we can find a supplier of some
>good instrumentation-quality analog I/O on Profibus for under $200/channel.
See: http://www.gantner.com/DezPhilo_e.htm
>>There are a lot of big and small fieldbus installations running under
>>QNX in the field. [.......]
>>BTW, combine the fieldbus I/Os with network transparent IEC1131-3 graphical
>>programming and system independent GUI tools like TILCON and you will get a
>>great base for factory automation.
>
>We have a small number of installations on we we run TILCON developed GUIs.
>Most of our GUI development is done with PV-WAVE, a high level data analysis
>and visualization package that runs in X-Windows and for which we paid $200,000
>for porting to QNX and unlimited distribution within Cummins. Visual Numerics
>even came to a QNX conference to show it off and found zero interest from the
>QNX community.
They have only reached the 'QNX community' at the conference ... and the
attached exibition of the conference is not the best place to do marketing for
a QNX third party product, because these exibitions are not effective promoted
by the QSSL marketing.
[ clip ..]
>I had some discussions with Award about a year ago. They estimated about
>$50,000 to apply their driver to Keithley-Metrabyte's Smartlink I/O system.
>
>Maybe the situation has changed now. Who is offering it other than Award.
When I remember right it's Technology Rendezvous from California ..
>>>Can you get a USB driver for QNX from any of the process I/O manufacturers
>>>who are now offering products with USB interfaces (National, I/O Tech,
>>>Keithley-Metrabyte, etc.). etc. ??
>>
>>Why from the manufacturers??? USB is an OPEN STANDARD, that means their USB
>>products have to work with any USB compliant driver !!
>>
>>>Call them up. Tell them you insist on using QNX for your application
>>>because it is truely a real-time operating system and one of very high integrity
>>>and ask them if they have heard of it
>>
>>That means nothing ...
>
>It means that people shun an operating system for which there is little 3rd
>party support.
For M$ there is also only little 3rd party support in the fieldbus area
because there are only a few companies which are able to manufacture
that stuff. For most (or bests) of them is QNX support available ...
[clip ..]
>>Yes ... they will SELL their source code :-) Where's the problem ??
>
>The problem is that you still have to convert it to run on QNX. This always
>costs more than the source. The supplier of hardware is happy to sell or give
>you a driver if it means you will buy their hardware.
It's a common approach of hardware manufactures ... raw DOS driver code for
nothing in order to sell hardware which carries a lot of firmware (or VHDL
software) :-))
[ clip .. ]
>If I were running QSSL, I would hire 3rdparty companies to develop process I/O
>drivers and then give them to the hardware manufacturers.
That might be possible for more or less simple VGA drivers or drivers for
network interfaces. Fieldbus related process I/O handling is a TECHNOLOGY
of its own and not only a driver issue!
For instance ... the development of the configuration, management and diagnostic
tool for e.g. the INTERBUS took several man-years for Phoenix Contact!
I don't believe that this piece of software is a give away for hardware
manufacturers :-)
IMHO QSSL should take care about their RTOS technology ... there is enough to
do.
[ clip .. ]
>>You couldn't get the job done in the same quality with NT or CE.
>
>Hey, we agree on something. I wouldn't even want to try.
>
>Unfortunately, I have to continually argue and explain about why we aren't
>converting everything to NT, since it is obviously the way the world is going.
I don't believe that 'the world is going that way':
- the installation of LINUX servers was increased by ~200% in 1998.
(from 236.000 to 748.000 sold licenses ... the installed licenses are
at least 2(?) times higher )
- the increase rate of apache based Web servers is ~10% higher than for NT
- 59% of the high-tech management doesn't trust M$ regarding to a
survey of the Giga Information Group (QSSL marketing where are you ... )
>An interesting situation is also developing with Linux. It is officially
>verboten, but we use it as a web-server, database server, and Netscape browser
>server (running in a QNX xterm) to support our QNX test systems. Now the Linux
>community is beginning to push real-time. Meanwhile our corporate systems
>people view Linux as a virus.
It would be better that the usage of NT in critical applications would be
'verboten' :-)
Armin Steinhoff
Guy Macon
> 1. Does it not prove Tech Support incompetensy, as Michael spent may be
>couple of seconds to find the problem, while Tech Support has yet to find
>and repond to this topic in 2 weeks.
I don't buy this. A C compiler is a very complex thing, and you
shouldn't expect an operating system tech support tech to have a
lot of knowledge about stuff other than his operating system. You
seem to have had a problem that did not involve any bugs in QNX or
the C compiler. It is not QSSL's job to teach you how to write
correct programs.
Guy Macon
cr9...@aol.com wrote:
>First, a potential customer would have to know that QNX existed...
In the field of industrial automation, if you don't know about QNX,
you aren't qualified to do your job. QSSL had a booth at the latest
realtime show, and if nobody in your organization went, then you
are not a player in the field of industrial automation. You can't
spend a day searching the web about realtime software without finding
out about QNX. You can't read comp.realtime for two weeks without
finding out about QNX.
shawn...@my-dejanews.com
> > the
> > entire QNX development package and have absolutely NO SUPPORT for the
> > product.
> > (This includes no supports for compiler bugs, updates and any types
> > problem resolution).
> >
> > 90% of QNXers would vote YES!!!!!!!! (Including me!)
> >
> > You know what is going to happen? QSSL will sell thousands of these
> > development packages. But, very soon many QNXers will start discovering
> > bugs that hidden in these development packages. What would you do, if
> > you
> > discovered a very nasty compiler bug that stopped your application dead
> > in the water ?
> >
> > This is what I would do, I would call up QSSL and demand for
> > a quick fix. Ahh... Isn't this called "Technical Support" ?
> >
>
> Nope. This is called "feedback".
> If QSSL is interested in high quality software, they should fix
> the reported bug with the next release.
> If you demand a service (perhaps you don't understand TFM) or
> have questions that aren't covered in the docs, then I will
> call that support.
I feel much better that QNX is commited to customer's feedback.
I assume that the poster (pwaec...@qnx.de) was from QNX.
So, when can we, people from the newsgroup, expect the $300.00
development package ? Any time soon ? What is QNX's position
on this issue ?
Shawn Davis
Mitchell Schoenbrun
> Just a side note, QNX will be providing USB for both NTO and QNX4, this stated
> you will still need the client driver for the specific device if it is not
> one of the classes we support.
Hurrah! Now a few pertinent questions.
1) Is this an announcement? If not, can you guess when one
might be comming.
2) Will the interface specifications for the clients be available?
Mitchell Schoenbrun
> 1. Does it not prove Tech Support incompetensy, as Michael spent may be
> couple of seconds to find the problem, while Tech Support has yet to find
> and repond to this topic in 2 weeks.
Not in my opinion. Rather it points to someone else's. As wonderful
as it is when someone's tech support will solve this kind of thing
for you, it is not really their job. To be fair, some problems
only look like user error at the start, and so I believe it is in the
developers best interest to not be too quick to judgement.
> 2. It is very bad that Michael DOES NOT work in the QNX Tech Support.
Is that right Michael? It used to be that everyone had to take
a turn now and then.
> 3. It is me opinion that Tech Support is incompetent.
Very good. I think this also shows your survival instincts
leave a little to be desired. If you truly believe that
QNX's Tech Support will never be of use to you, then you
haven't anything to lose by making broad statements like
this. After 16 years of using QNX I still need, and get,
help from QNX with their product, and appreciate a company
that is good about providing it.
Mitchell Schoenbrun --------- masc...@pobox.com
Paul May
>sure, QSSL got a lot of money from Russia due to his job in past. And I
>bet, still getting due to his current job.
>> I agreed with you on this. But, there are many bugs that only QSSL
>> could fix.
>Let our fantasy fly without limits :)
>What about adopting Open Source development model? Huh?
>It may look scary, but in fact most their customers are corporate
>customers/develpers. They are required to have a vendor behind any used
>software by corporate policies. So, they will buy anyway, as long as
>they going to use it for anything serious. Thos who are not serious,
>will not buy anyway. But this single move would change the landscape of
>this business.
>In fact, I'm sure that earlier or later some player in this business
>will do it. Then it will be too late for others.
Hi Igor.
seeing as its fantasy ideas time, id just like to add that if Greg
could arrange for me to get Dan's private email address, i'd like
him to consider a KOSH/QNX/Nto initative, perhaps QSSL creating their
own derivative of the many Open Platform licenses around so
KOSH can use QSSL as a base for our possible ground breaking project.
for the people that missed my other KOSH posts, KOSH is basicly
a very high proportion of the classic AMIGA community including
the software and hardware developers comming together to create
the next step in the Open platform movement.
we are also getting vast amounts of interset from outside
the classic community as the word gets out about KOSH
and the people behind it.
we are planing on a cross platform HAL based, hosted (and later)
native KOSH OS, useing Dave Haynie's 'Object Sea' ideas he has
been kicking around since Commodore's dimise.
seeing as Dan hopes that the Ainc will help create vast new markets
for QSSL, it is my (and i see Daryl low's) hope, that Dan will see
that the AMIGA community and KOSH could be a GREAT asset that will
put all their tallent (including many Team AMIGA/ICOA/JMS/Owlnet
members and so on) and resources behind KOSH and QSSL should a
way be found to allow us to progress.
dan. please remember that it was the community that kept the
AMIGA alive before Gateway stepped in, so we are very GOOD
(if not he best) salemen/women at spreading the word and
keeping the dream alive, never underestimate the AMIGA community 8),
hopefully we can include QSSL as the *classic* communitys friend
as well as the commercial OS5/Nto project currently taking place.
greg if you could forward this post/request to Dan i'd be most happy 8)
PS.
if anyones interested in finding out more, the web site gives
a basic idea of how we want to progress, *BUT* you will get a far
better idea if you take the time to subscribe to the
kosh-general maing list (and others) you will find on the site
(see the URL below)
--
Paul May, UK
Team *AMIGA* , *KOSH* , *OwlNet*
KO...@reedsweb.net
--
http://www.KOSH.net
Kommunity Operating System and Hardware
http://www.owlnet.net Open Platform Support Services (Now Open)
covering KOSH, AMIGA, Linux, QNX/Nto, and any non M$ platforms and projects.
Ken Schumm
> In article <Voyager.99012...@www.qnx.de>,
> pwaec...@qnx.de wrote:
> > Previously, Nobody wrote in comp.os.qnx:
>
> I feel much better that QNX is commited to customer's feedback.
> I assume that the poster (pwaec...@qnx.de) was from QNX.
>
> So, when can we, people from the newsgroup, expect the $300.00
> development package ? Any time soon ? What is QNX's position
> on this issue ?
>
> Shawn Davis
support would be overwhelmed, causing the price to skyrocket. Developer
resources would be drained to help with support. And software that
we are all waiting for will either be unfinished or be further
delayed, further damaging competiveness with other OS vendors.
acell...@systems104.co.za
their advisors to remove the plastic from or to open a magazine
that's delivered to their desk, or to read the articles or to
look at the advertisements. No chance to attend a show either.
Too busy trying to get the work out the door to notice
all those neat solutions like QNX & third party products
waiting for a problem... Much easier to drift with the
main stream and follow upper management injunction to use
M$ whatever the quality, cost, technical integrity,
long term implications, etc etc
Thank heaven for the others who do a proper study before
arriving at a considered solution.
Speaking from experience...
In article <786656$5...@journal.concentric.net>,
-----------== Posted via Deja News, The Discussion Network ==----------
Igor Kovalenko
>
> IMHO, I hope they NEVER release a $300 development package. Their
> support would be overwhelmed, causing the price to skyrocket. Developer
> resources would be drained to help with support. And software that
> we are all waiting for will either be unfinished or be further
> delayed, further damaging competiveness with other OS vendors.
I'm wondering, why everyone who says this kind of things forget about
the simple fact, that to overwhelm QSSL by support requests people have
to buy software first. That means, they will overwhelm sales first and
QSSL bank account second, and only third - support.
With this in mind, don't you think that QSSL will be able to hire much
more people to support department? Of course, it will take some time to
educate them, but most of questions will be FAQ anyway.
- Igor
Ken Schumm
> Ken Schumm wrote:
> >
> > IMHO, I hope they NEVER release a $300 development package. Their
> > support would be overwhelmed, causing the price to skyrocket. Developer
> > resources would be drained to help with support. And software that
> > we are all waiting for will either be unfinished or be further
> > delayed, further damaging competiveness with other OS vendors.
>
> I'm wondering, why everyone who says this kind of things forget about
> the simple fact, that to overwhelm QSSL by support requests people have
> to buy software first. That means, they will overwhelm sales first and
> QSSL bank account second, and only third - support.
margins and make the profit in volume, gambling that the volume will be
there to cover costs. Another model is to charge more for products and be
satisfied with lesser volume.
The first model works well with very high volumes of product, such as
desktop computers. M$ currently owns this market, although with the huge
volume and correspondingly huge profits I don't see M$ support, or their
software products, of being very high quality.
The second model works well with smaller volumes of product in niche
markets - embedded computers, for example. QNX does very well in this
market with this business model.
Who would you rather get support from? M$ or QNX?
You might argue that there are millions and millions of embedded computers,
and the volume is there. The total embedded market is very large, but it is
comprised of many thousands of completely different products, not one
generic product like a desktop computer.
Now, you may feel that you are right and they are wrong, but that is your
opinion. It is their product, they can market it in any way they wish, and
they are free to succeed or fail on their own terms. They are not stupid
people, and those who disagree do not have a monopoly on enlightenment.
>
> With this in mind, don't you think that QSSL will be able to hire much
> more people to support department? Of course, it will take some time to
> educate them, but most of questions will be FAQ anyway.
Let's see. QNX sells 10,000 $300 development systems in the first month.
Once the checks have cleared they then have the money to hire and begin
the training process. Of course, the calls start coming in immediately,
but the new trainees might take 6-12 months to get up to speed. In the
meantime tech support is overwhelmed and the new QNX purchasers are
frustrated because they can't get their jobs done, so they start publicly
complaining in comp.realtime, damaging QNX's reputation.
Or, QNX can hire 200 new tech support people now, and start training them.
In 6-12 months, when they are trained, they can start selling $300
development systems, gambling that people will switch from M$ to QNX.
This may or may not work, but it's a big gamble. There is a lot of
MBMA (management by magazine article) in this world, and most managers
believe that M$ has a solution to every problem. No manager ever got
fired by buying M$. So, even if the programmers rush out to buy these
development systems, lots of unenlightened companies will never use it,
because PC Magazine, or Control Engineering, or Computer Telephony,
doesn't write about it.
Very often, people don't read the FAQ, the FAQ doesn't cover their problem,
their problem is a programming error that requires tech support to point it
out, they want to know why things don't work the way they did on the XXXX
os, etc.
If everyone was as self-sufficient as you, your strategy might work.
But you are probably more self-sufficient and talented than 80% of
the programmers working in the industry.
>
> - Igor
>
CR91LJL
>
>In the field of industrial automation, if you don't know about QNX,
>you aren't qualified to do your job. QSSL had a booth at the latest
>realtime show, and if nobody in your organization went, then you
>are not a player in the field of industrial automation. You can't
>spend a day searching the web about realtime software without finding
>out about QNX. You can't read comp.realtime for two weeks without
>finding out about QNX.
I was not refering to my own experience, but was criticizing the QSSL marketing
organization, because I don't think there is enough awareness of their
excellent products.
As for myself, I have been using QNX since 1989 and have been doing Industrial
Automation since 1968. I started with an SEL810A mini-computer, which used
discrete logic circuits (pre-integrated circuits). You were probably just a
snotty-nosed kid then.
Sorry, I wasn't at the "latest realtime show".
>
>
>
>
>
>
>
acell...@systems104.co.za
cr9...@aol.com (CR91LJL) wrote:
[...]
> I was not refering to my own experience, but was criticizing the QSSL
marketing
> organization, because I don't think there is enough awareness of their
> excellent products.
Any suggestions?
They do ads, articles, shows, talks. Demodisk download is a runaway
success (perhaps too successful ;^)
I would certainly appreciate any feedback to use in my market in South Africa.
How does one reach the decision makers?
[...]
Tim Anderson
to mention that I was contacted by Randy Hughs at QNX and they did send
me an evaluation copy of QNX. I feel that it is common courtesy to give
a company credit when they come through in responding to a posting about
a negative experience with their sales force.
Anyway, thanks to the folks at QNX for responding and I will definitely
consider buying the product if everything goes OK with my evaluation.
Tim Anderson
(Original poster of the "QNX Sales SUCKS"
posting)
qnx...@ibm.net wrote:
> Its unfortunate that certain terms of events have resulted in the
> problems
> outlined in this thread.
>
> Selling our products directly in North America is a strategic decision
> that
> is intended to better service our customers. This is not to say this
> was not
> the case when using other forms of distribution. However a direct
> presence,
> regional offices with sales and technical capabilities, together with
> the
> infrastructure here at QSSL corporate was put together for the benefit
> of
> you, our customers.
>
> This approach resulted in a restructuring within the North American
> sales
> force so we could handle the business previously covered by our
> distributors. This restructuring is ongoing, and feedback such as that
> given
> in this thread is invaluable. We don't claim to have everything right
> straight off the bat, but we are continuing to make appropriate
> changes so
> that we realize the goal we have set - so that customers like
> yourselves
> have a close working relationship with the representatives you deal
> with at
> QSSL.
>
> I know that sometimes we have to vent to reveal our frustrations.
> Thats
> fine, all of us need to do that sometimes, but that feedback also
> needs to
> get back to QSSL so that we can look at investigating and solving
> problems.
> Mr Anderson did just that and I believe we have come to an appropriate
>
> resolution of his problem. There were certainly misunderstandings and
> problems that contributed to his situation that we expect to improve
> considerably in the near future. These problems had already been
> identified
> by QSSL management and we are putting procedures in place to address
> them.
>
> Customer feedback is imperative to improving the way we deal with you.
> Feel
> free to send us email at in...@qnx.com detailing your problem, as did
> Mr
> Anderson, and we will look at taking appropriate steps to address your
>
> concerns. Of course, posting to this newsgroup is also an avenue for
> you to
> determine whether other members of the QNX community have experienced
> similar problems.
>
> I hope this helps address some of the concerns in this thread. We're
> here to
> help, so
> please feel free to contact us.
>
> Greg Bergsma
> Vice President, North American Sales
> ________________________________________________________
> QNX Software Systems Ltd | Phone: +1 (613) 591 0931
> 175 Terence Matthews Crescent| Fax: +1 (613) 591 3579
> Kanata, Ontario, Canada | Email: gber...@qnx.com
> K2M1W8 | WWW: http://www.qnx.com
> ________________________________________________________
yuji...@cmi-sts.com
Yujin
-----------== Posted via Deja News, The Discussion Network ==----------
CR91LJL
>They do ads, articles, shows, talks. Demodisk download is a runaway
>success (perhaps too successful ;^)
>I would certainly appreciate any feedback to use in my market in South
>Africa.
>
>How does one reach the decision makers?
>
I doubt that there is much you can do. If I were running QSSL, I would work on
a long term "awareness" campaign. People at QSSL and other QNX users often
says thing like, "QNX is used in a lot of things that you use every day and you
don't even know it." Okay, this is true, but certainly not an advantage to
QSSL. They should work hard when they make a deal with companies like Cisco,
Motorola, IBM, and even minor 3rd party customers to build into the deal a
"QNX-Inside" feature to the application that makes it clear to anyone who comes
near it that QNX is ubiquitous and not some fly-by-night O/S that will
disappear in a year or two.