The Future of QNX

[Armin_Steinhoff1]

Martin Zimmerman wrote:

Previously, Armin Steinhoff wrote in qdn.public.qnxrtp.advocacy:
It has something to say with the lack of C++ support of PhAB …

Actually, it says that C++ support in PhAB has generated enough interest
for QSSL to work on it.

Hmm … could it be that this has to do with ignorance?
Would only be consistent after ignoring Ethernet, POSIX threads
and now C++ for years.

You can develop apps perfectly fine in C and
PhAB, and there are other things on the “to do” list that have higher
priority. Your preference for development is C++, that is not the case
for everyone.

What means everyone? The “Everyone’s” outsite of the QNX niche are
building GUI apps with C++ .

I talked about comparable desktop configurations of Photon and X.

The “desktop” is only supported for development environments,

Nice to see that QSSL is doing a great job just to please
developers

that is
the entire context that it exists in. There are MANY different
assumptions made when refering to a developer desktop vs. a user
desktop. You need to keep that in mind.

I’m just talking about the support of the so called tool chains …
we saw in the past too many broken product lines. I hope we will get
a consistent strategy with the Metaware tools … or is it just only
an additional trial??

What are you talking about? QSSL has always been very consistent in
it’s tool support. In QNX2 we had QNX’s own compiler, which was
supported until QNX2 was no longer sold.

First break …

In QNX4 we have the Watcom
compiler, it has been supported by QSSL and STILL IS supported by
them, even though Watcom no longer provides any support or updates.
QSSL is STILL supporting it and updating the libs as required.

It’s very quiet around the Watcom compiler. New updates? Nope.

Metrowerks was only ever offered as an ALTERNATIVE development
environment, the primary or baseline development environment of Watcom
was NEVER abandoned.

Watcom C/C++ is simply dead.

In QNX6, we have had gcc, consistenly throughout it’s life.

The point is that gcc isn’t eqal gcc … there are version numbers.

In Neutrino 1 (aka QNX5), gcc was supported on QNX4 to build
Neutrino 1 binaries in a cross-development mode.

The cross development of Neutrino 1 was based on Watcon C.

It continued to have
support as Neutrino 2 again in cross-development mode on QNX4.

Wrong … QSSL switched from Watcom C to one of the oldest ggc
versions for the cross development of Neutrino 2.0 .

With
Neutrio 2.1 the development environment was “upgraded” once again to be
self-hosted.

QSSL switched now from cross to self hoste development using a
more or less current gcc version.

Consistency? I call that a ‘zick-zack’ course

No where in there do I see ANY evidence of a broken product line.

Seriously ??

I’ve been developing on and using QNX for significantly longer than you.
If there had been a break in the development environment support, I’d
have noticed it. It simply has NEVER happened.

I don’t share your view.

QNET is unaccapptable for me as long as its concept(?) is so weired.

I don’t understand what you think is weird about QNET.

Name services, connection id, receive id, advertising of channels by
servers a.s.o

QNX 4 was using just a node id and PID.

You mention that
you have used QNX4, well… the concepts in QNET are identical to those
in FLEET. The only thing that might be considered different is how
“names” are resolved in QNX6 vs. QNX4. I agree that the resmgr
approach, although excellent makes this more confusing.

No, the resource manager concept is much clearer than the visible
concept of QNET!

Besides the weak resource manager docs … I have no difficulties
with the resource managers concept.

[ clip …]

As for threads, they can be a huge assistance,

I’m not interested to discuss that issue to dead … it’s good to
have POSIX thread NOW.

[ clip .]

The question is about the used features in such products …
download the Tilcon demo for Photon 2.0 and you will see problems
with off screen drawing and others, but don’t believe that this are
problems of the Tilcon software!

Heh heh… I’d wager they ARE problems with the Tilcnon software.

You are completely WRONG!! There were huge QNX and Photon problems
discovered and I hope they will be fixed…

[ clip …]

Tilcon is attempting to do something very difficult,

Attempting?? Sorry, that’s nonsense. They HAVE a product line which
WORKS accross different platforms (excluding PHOTON 2.0)!!

[ clip …]

Actually, I agree with Bill on this one, and if you talk to the folks at
QSSL they too will give the same advice. DON’T RELY ON REALTIME CODE
WITHIN THE GUI.

OK … then forget PHOTON and use Windows )

Armin

[Jutta_Steinhoff1]

Igor Kovalenko wrote:

This is classical dialog of a blind and a deaf, LOL >

Armin seems to be so unsatisfied with QNX that can’t see how anyone can
be satisfied (I’m wondering why he’s still doing any business with it
though).

Hey Igor,
ever heard that it makes sense to choose the lesser one of evils?
Do you know a better alternative for real-time control?

As nothing is perfect, QNX can (hopefully) only become improved,
so let’s go on to hate and to love it

Cheers,
Jutta

[Xiaodan_Tang1]

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

QNET is unaccapptable for me as long as its concept(?) is so weird.

I don’t understand what you think is weird about QNET.

Name services, connection id, receive id, advertising of channels by
servers a.s.o

QNX 4 was using just a node id and PID.

First of call, the channel/connection/receive id is Neutrino Message
Passing, nothing to do with QNET. Only QNET using a “node name” to
identify a node instead of nid.

I have heard of this complain several times, “why is neutrino message
passing so different with QNX4?” I remember at the early time when I
just switched from QNX4 to NTO1.0, I have the same feeling. “Why do I
need to do all those work (create channel, connection) to send messages?”
QNX4 is dead simple, “the server Receive, the client Send, the server
Reply, finish”

But now I was convinced that the Neutrino Message Passing is well fit
into the “Multi-threads” world.

QNX4 is simple is because as a single thread process, you can only have
one single block point. Now in neutrino, while you can have multiple
threads in one process, you started thinking “why can’t my threads
serves different needs, they all can block right?” This leaves the
client have to send to “pid/tid” pair if we still using QNX4 model.
But that’s not just it, if I have multi threads serves a name space,
how can a client know which tid is free to serve me?

The “Channel” hide the “pid/tid” detail, client only “connect” to
a channel, and send to it, the server then choose have multipul
threads receiving on channel, and once a message coming in, “which”
thread will got the data, is totally transparent from client.

Does this make you feel better Armin?

You mention that
you have used QNX4, well… the concepts in QNET are identical to those
in FLEET. The only thing that might be considered different is how
“names” are resolved in QNX6 vs. QNX4. I agree that the resmgr
approach, although excellent makes this more confusing.

No, the resource manager concept is much clearer than the visible
concept of QNET!

Besides the weak resource manager docs … I have no difficulties
with the resource managers concept.

I would say that’s because you’ve already wrote those big loop in
QNX4 and probably have an idea what’s the lower resource manager
doing

Believe me, I also have new comers asking “this resmgr this is
so wired, who is calling all my functions? where comes the ctp?”…
But if you’ve been there, you already know the answer, right.

-xtang

[Martin_Zimmerman]

Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.advocacy:

Camz seems to be so satisfied that he can’t hear anything critical about
it at all (he must be living in an ideal world where customers are so
happy with QNX they just keep buying licenses and don’t even want to
hear about anything else).

I am indeed, quite satisfied, that doesn’t cloud my judgement. I have
been very vocal about flaws or bugs at times, I think I even had code
sent to me to shut me up… I had fixed the bug in it and returned it
before QSSL realized that they hadn’t asked me to sign an NDA

I have a high confidence in QSSL, their products, and their staff. I
consider myself a very loyal (and satisfied) customer. As I said, I’m
not satisfied all the time, and I do bitch when I see the need. I
don’t always to that in public. QSSL has had to work very hard to EARN
my loyalty. I honestly beleive that I have not been let down by them.
We’ve had our differences, there are times when I wish they’d move
faster on something, but all in all they tend to do the Right Thing™
at least 95% of the time.

At the very least, Dan Dodge has tolerated me even when I’ve been annoying…
Mind you, they never did T-shirts about me, but they did joking comment
about Guido paying me a visit. [no way, I never exploited a security
bug in the original quics to view that message… no way].

I must say, Camz position is a lot more enjoyable, it’s almost unfair.
‘Ignorance is a bliss’, I want it too >

I will admit that I have yet to undertake a commercial project in QNX6,
all of my commerical work so far has been in QNX2 or QNX4. I’ve
embarked on some “learning” projects in QNX6 & Photon 2.0, and so far I
have not come up against anything that’s REALLY wrong. I will admit
that resmgr’s did present a huge mental challenge for me, I’d attempted
to write one in QNX4 and the complexity left me intimidated by the move
to that model in QNX6. Once again, the support from QSSL showed it’s
true colors, and Chris McKillop helped walk me through the process in
IRC. He answered all my questions, and I’ll be damed, I dug into the
docs and actually had a working example in a couple hours.

Now I said enough to spice up this flame and shall prepare to get flamed
by both men.

No flame, and the only regret I have is that I missed the opportunity to
introduce myself to you @ QNX’2000… At least I (breifly) met
Jean-Hughes ROYER.

Cheers,
Camz.

–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting

[Igor_Kovalenko2]

“Martin Zimmerman” <camz_AT_passageway_DOT_com@wooga.passageway.com> wrote
in message news:Voyager.010422224620.12754A@wooga.wooga.passageway.com…

I have a high confidence in QSSL, their products, and their staff. I
consider myself a very loyal (and satisfied) customer. As I said, I’m
not satisfied all the time, and I do bitch when I see the need. I
don’t always to that in public. QSSL has had to work very hard to EARN
my loyalty. I honestly beleive that I have not been let down by them.
We’ve had our differences, there are times when I wish they’d move
faster on something, but all in all they tend to do the Right Thing™
at least 95% of the time.
At the very least, Dan Dodge has tolerated me even when I’ve been
annoying…

There’s nothing wrong with your beliefs except may be that they’re really
out of business realm. I don’t mean any offense here, just trying to point
out where the difference in perception comes from. You talk almost in terms
of emotional relationship, while Armin talks from rather dry business
perspective.

If you think about it, when it comes to business decisions the loyalty is
not highly valued stock. You don’t change your wife every quarter just
because another girl got better merchandise, but one might very well change
vendors for that reason without much deliberation.

From that perspective Armin has valid points. He’s not excited about Dan
tolerating him, he might as well think that Dan should be excited about
Armin tolerating QNX, lol Beauty is in eyes of beholder …

Mind you, they never did T-shirts about me, but they did joking comment
about Guido paying me a visit.> > [no way, I never exploited a security
bug in the original quics to view that message… no way].

They still might
People who came up with the idea of T-shirt are relatively new in QNX I
believe, so they might not have been around for all those good old years…

I must say, Camz position is a lot more enjoyable, it’s almost unfair.
‘Ignorance is a bliss’, I want it too >

I will admit that I have yet to undertake a commercial project in QNX6,
all of my commerical work so far has been in QNX2 or QNX4. I’ve
embarked on some “learning” projects in QNX6 & Photon 2.0, and so far I
have not come up against anything that’s REALLY wrong.

I have rather opposite experience
Most of stuff I done with QNX4 was ‘educational’ while with NTO it is rather
serious commercial stuff. And yep there was wrong stuff, especially in 2.0
release. There’s still some.

I will admit
that resmgr’s did present a huge mental challenge for me, I’d attempted
to write one in QNX4 and the complexity left me intimidated by the move
to that model in QNX6. Once again, the support from QSSL showed it’s
true colors, and Chris McKillop helped walk me through the process in
IRC. He answered all my questions, and I’ll be damed, I dug into the
docs and actually had a working example in a couple hours.

I did mine, but again I never did real (devil is in details man) resmgr in
QNX4 so I was not intimidated by changes. It was not huge mental challenge
and if not insufficient docs it would be rather straightforward (but I spent
good time reading several good books about threading before that). QNX
helped me as well by letting to see some of their code… their opening of
some parts of code is real good thing. Code is ultimate docs after all

Now I said enough to spice up this flame and shall prepare to get flamed
by both men.

No flame, and the only regret I have is that I missed the opportunity to
introduce myself to you @ QNX’2000… At least I (breifly) met
Jean-Hughes ROYER.

We might have chance yet, night is young

• Igor

[David_Gibbs1]

Martin Zimmerman <camz_AT_passageway_DOT_com@wooga.passageway.com> wrote:

Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.advocacy:
Camz seems to be so satisfied that he can’t hear anything critical about
it at all (he must be living in an ideal world where customers are so
happy with QNX they just keep buying licenses and don’t even want to
hear about anything else).

I am indeed, quite satisfied, that doesn’t cloud my judgement. I have
been very vocal about flaws or bugs at times, I think I even had code
sent to me to shut me up… I had fixed the bug in it and returned it
before QSSL realized that they hadn’t asked me to sign an NDA >

I can confirm that camz (we always thought of him as camz, not Martin) has
been very vocal about flaws and problems in the past.

-David

QNX Training Services
dagibbs@qnx.com

[Steve_Munnings_Corma]

David Gibbs <dagibbs@qnx.com> wrote in message
news:9c1i9d$hhq$2@nntp.qnx.com…

Martin Zimmerman <> camz_AT_passageway_DOT_com@wooga.passageway.com> > wrote:
Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.advocacy:
Camz seems to be so satisfied that he can’t hear anything critical
about
it at all (he must be living in an ideal world where customers are so
happy with QNX they just keep buying licenses and don’t even want to
hear about anything else).

I am indeed, quite satisfied, that doesn’t cloud my judgement. I have
been very vocal about flaws or bugs at times, I think I even had code
sent to me to shut me up… I had fixed the bug in it and returned it
before QSSL realized that they hadn’t asked me to sign an NDA >

I can confirm that camz (we always thought of him as camz, not Martin) has
been very vocal about flaws and problems in the past. >

And not just problems from QSSL !!

-David

QNX Training Services
dagibbs@qnx.com

[Rennie_Allen2]

You’ve seen the code, and you didn’t sign an NDA ? Don’t open any
packages from eastern Canada, and have someone else start your car in
the morning

-----Original Message-----
From: Martin Zimmerman
[mailto:camz_AT_passageway_DOT_com@wooga.passageway.com]
Posted At: Sunday, April 22, 2001 9:46 PM
Posted To: advocacy
Conversation: The Future of QNX
Subject: Re: The Future of QNX


Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.advocacy:

Camz seems to be so satisfied that he can’t hear anything critical
about
it at all (he must be living in an ideal world where customers are so
happy with QNX they just keep buying licenses and don’t even want to
hear about anything else).

I am indeed, quite satisfied, that doesn’t cloud my judgement. I have
been very vocal about flaws or bugs at times, I think I even had code
sent to me to shut me up… I had fixed the bug in it and returned it
before QSSL realized that they hadn’t asked me to sign an NDA

[Ivan_Bannon1]

Bill Caroselli <Bill@Sattel.com> wrote in message
news:9bfcbk$124$1@inn.qnx.com…

I have written many QNX apps. Multi-process, now multi-threaded and with
Photon support. I believe that one probelm many developers have is this:

The Photon app should NOT be the work horse app. All of the applications
that need to be real-time and do the work need to support transaction
based
API and not a GUI. The GUI app can then send messages to the workhorse
app
to do whatever and receive message when status changes so that it can
render
new information onto the screen.

This philosophy has many advantages. The GUI app can be stopped and
restarted without interrupting te work horse app. Also, you can very
easily
have several/many instances of the GUI app.

A great big ditto to this!

–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Rennie Allen” <> rennieallen@earthlink.net> > wrote in message
news:9b7vo4$mnq$> 1@inn.qnx.com> …
Fact is that e.g. Photon 2.0 is still very unstable …
and it’s impossible to realize a stable 24/7 application.

It is not impossible to realize a stable 24/7 application in Photon.
There
might be certain applications that aren’t stable in Photon, and it isn’t
as
stable as 1.14 on QNX 4 yet, but the statement above is a massive
overstatement.

Must be fun to develop multi threaded GUI apps with the
non-thread-safe Photon library.

Threads and Photon don’t go well together, OTOH, I have written dozens
of
non-trivial applications in Photon, and I have never a the slightest
twinge
of desire to write a multi-threaded GUI client application. So just
maybe
it just ain’t that big a deal…






\

[Martin_Zimmerman]

Previously, Xiaodan Tang wrote in qdn.public.qnxrtp.advocacy:

I have heard of this complain several times, “why is neutrino message
passing so different with QNX4?” I remember at the early time when I
just switched from QNX4 to NTO1.0, I have the same feeling. “Why do I
need to do all those work (create channel, connection) to send messages?”
QNX4 is dead simple, “the server Receive, the client Send, the server
Reply, finish” >

The concept remained the same, the details changed a little bit. I too
will admit that initially the QNX6 method seemed more complex than
required at first. Once you realize that you now have threads and that
you might want to distribute work between them… well, then the extra
little bits start to make sense. Once I dove into the resmgr stuff too,
I realized that the resmgr libs too care of all that stuff for me, and
from the client side… fd = fopen(); MsgSend( fd, …); was pretty
easy, I like it better actually.

QNX4 is simple is because as a single thread process, you can only have
Believe me, I also have new comers asking “this resmgr this is
so wired, who is calling all my functions? where comes the ctp?”…
But if you’ve been there, you already know the answer, right.

There are some intimidating things to learn with the resmgr library.
The docs could be improved with more comprehensive details on the actual
structures being used, and what all their fields are used for. Luckly
for most of the simple resmgrs you probably don’t have to worry about
most of that. It isn’t until you get into the more complex resmgr stuff
that those details become important. I’ll admit that I’m not yet
comfortable with digging through the header files trying desperately to
find the appropriate structure member to use for something. I’d
definitely like to see better docs on that. There are many aspects of
resmgrs that need more explanation… how to make one that properly
“unions” with others in the same space, making directories work,
redirecting incoming messages to a lower layer (ie. taking over
something like /dev/con1 and filtering some messages).

There is time for that to improve, and I’ve been pleased with the
willingness of the documentation group to update and improve the areas
of the docs that we highlight as requiring more “depth”. I have also
found that IRC has been invaluable, there are several members of the
QSSL staff, Chris McKillop, Sean B, Bill Bull, Steve Tomkins, Xiodan
Tang and many others. They hava all been more than happy to provide
assistance, answer questions, debug system and code problems, etc.
They’ve done that even outside of their normal work hours.

I was probably as vocal or more vocal than Igor in the past… but, I’m
older now, I’ve mellowed, and I have more patience that I did before.

–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting

[Martin_Zimmerman]

Previously, David Gibbs wrote in qdn.public.qnxrtp.advocacy:

I can confirm that camz (we always thought of him as camz, not Martin) has
been very vocal about flaws and problems in the past. >

Thanks David. :>

–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting

[Mitchell_Schoenbrun]

Previously, Martin Zimmerman wrote in qdn.public.qnxrtp.advocacy:

The concept remained the same, the details changed a little bit. I too
will admit that initially the QNX6 method seemed more complex than
required at first.

Well here’s the crux of the matter. It has gotten a lot
more complex. Once you’ve figured it all out and have
templates that you understand the complexity is no longer a
problem. I’ve been struggling with this for a couple of
months myself. I’ve also been wondering if there isn’t a
way to encapsulate all the levels to create a simple way to
do message passing for a simple application with a one
thread manager. For new users this could be a stepping
stone.

I suspect that one reason this hasn’t been done already is
the strong push from QSSL for users to provide standardized
POSIX interfaces to their managers. This issue has been
debated quite a bit. My opinion is that for very simple
applications the programming overhead is just not worth it.
This applied for QNX2 and QNX4, and I haven’t seen anything
in QNX 6 to change it. This in spite of the fact that QSSL
has done a laudible job of making the development of full POSIX
interface resource managers accesable.

I suppose I’m up to speed enough at this point to create an API
that would look like this.


// Client

main()
{
id = simple_locate("/name/server");

send_data.cmd = CMD1
simple_send(id,send_data,send_data_size,reply_data,reply_data_size);

send_data.cmd = CMD2
simple_send(id,send_data,send_data_size,reply_data,reply_data_size);

}

// Server
main()
{
simple_attach("/name/server",max_data_size);

while(1)
{
id = simple_receive(recieve_data,receive_data_size);
switch(receive_data.cmd)
{
case CMD1:
simple_reply(id,reply_data,reply_data_size);
break;
case CMD2:
simple_reply(id,reply_data,reply_data_size);
break;
}
}
}


}






Mitchell Schoenbrun --------- maschoen@pobox.com

[Martin_Zimmerman]

Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.advocacy:

Well here’s the crux of the matter. It has gotten a lot
more complex. Once you’ve figured it all out and have
templates that you understand the complexity is no longer a
problem.

I agree, it has gotten more complex. The interesting thing is that if
you use the resmgr model and the library functions to create it, it is
pretty easy. I typed in the resmgr example, and got it running. The
only trick was understanding how I could make the resmgr run a handler
for the messages I wanted to send it. That isn’t clearly shown in the
docs, luckily, I had Chris McKillop on IRC to help me out. Turns out
to be pretty darn easy. Here it is:

// we want to handle our own private message, of type 0x5000 to 0x5FFF
if( -1 == message_attach( dpp, NULL, 0x5000, 0x5FFF, &message_handler, NULL ) ) {
fprintf( stderr, “Unable to attach to private message range\n” );
exit( EXIT_FAILURE );
}

Just stick that in the example source, just after the regmgr_attach()
code block. Message handler looks like this:

int
message_handler( message_context_t *ctp, int code, unsigned flags, void *handle )
{
int x = 42; // just some data for demo/testing

fprintf( stderr, “DBG: private message %d\n”, code );
MsgReply( ctp->rcvid, EOK, &x, sizeof(x) );

return( 0 );
}

You can put the “traditional” switch( code ) { case 0x5000: … } stuff
in there just like you used to do in QNX4. The only caveat is that the
messages start with a 16bit int, and there are a set of reserved codes,
you can use anything above that reserved value. That might sound like
a restriction, but most QNX4 developers fell into the habit of starting
their message structures with a 16bit int anyhow.

You can optionally register a seperate handler for each code type and
then provide multiple functions instead of one with a switch. You can
also combine the two approaches.

I suspect that one reason this hasn’t been done already is
the strong push from QSSL for users to provide standardized
POSIX interfaces to their managers.

I agree. The libraries for resmgr things makes this quite easy.

My opinion is that for very simple
applications the programming overhead is just not worth it.
This applied for QNX2 and QNX4, and I haven’t seen anything
in QNX 6 to change it.

On this, I disagree. QNX6 have us shared libs & dlls, something we
never had in the QNX2/QNX4 days (okay we had shared libs, but makeing
our own was a bitch). They allow for considerable savings in code
size. Why am I mentioning this? Well, the majority of the work for
most simple resmgr’s is in the library… A SHARED LIBRARY. And since
most other resmgrs make use of these functions, it’s already loaded and
in memory. The “hit” for using those libs is tiny. The default behaviour
is that of /dev/null, which is ideal for a simple client/server that
uses IPC natively rather than the posix open/read/write/close calls.

Now, the nice thing about this is that all that complex stuff on
channels instead of pids, and such just plain doesn’t matter because the
fd IS the channel.

Here is the code to send a message to the sample resmgr with the above
mentioned modification for messages:

main( int argc, char *argv[] )
{
int fd;
int msg, rmsg;

fd = open( “/dev/camz”, O_RDONLY );
msg = 0x5000;
MsgSend( fd, &msg, sizeof(msg), &rmsg, sizeof(rmsg) );
printf( “reply = %d\n”, rmsg );
close( fd );
exit( EXIT_SUCCESS );
}

I suppose I’m up to speed enough at this point to create an API
that would look like this.

This example from the client side pretty much matches what you are
suggesting.

The only thing preventing you from getting to this point is that the
message stuff is only hinted at and now fully explained with decent
examples.

I’ll admit the FIRST thing I did was put that in and test it before
I even tried to do anything to /dev/camz. I was more interesting in
sending a message to the damned thing and couldn’t give a damn about
the posix stuff at first.

Cheers,
Camz.

–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting

[Mitchell_Schoenbrun]

Previously, Martin Zimmerman wrote in qdn.public.qnxrtp.advocacy:

On this, I disagree. QNX6 have us shared libs & dlls, something we
never had in the QNX2/QNX4 days (okay we had shared libs, but makeing
our own was a bitch).

Well I’m not going to disagree with your opinion as I see
there is a lot of room here for differing views. I’m sure
that as I use QNX 6 more and more I’ll like it more and
more. This won’t really change things that much for the
newbies however. Documenation may however.

I will however disagree with your reasoning. I think you
are trying to suggest that the amount of memory saved in
each process by sharing this common code is somehow
significant. Let’s say you have a small by todays standards
system of 32Meg. Now lets say you are running a relatively
large number of processes on this system, say 100. Ok, so
how much code is being saved? Well let me exagerate and
suggest that the code you will not have to write is 5K each
time. I’m talking about the code that you would write, not
what QSSL has in their libraries. So we have about 1/2 Meg
saved total. This is 1/64th of the memory in the system.
The cost of this memory is about 15 cents today.

No doubt there are interesting systems whose characteristics
will prove me wrong.

Mitchell Schoenbrun --------- maschoen@pobox.com

[Johan_Bjork1]

Mitchell Schoenbrun wrote:

Previously, Martin Zimmerman wrote in qdn.public.qnxrtp.advocacy:


The concept remained the same, the details changed a little bit. I too
will admit that initially the QNX6 method seemed more complex than
required at first.


Well here’s the crux of the matter. It has gotten a lot
more complex. Once you’ve figured it all out and have
templates that you understand the complexity is no longer a
problem. I’ve been struggling with this for a couple of
months myself. I’ve also been wondering if there isn’t a
way to encapsulate all the levels to create a simple way to
do message passing for a simple application with a one
thread manager. For new users this could be a stepping
stone.

I suspect that one reason this hasn’t been done already is
the strong push from QSSL for users to provide standardized
POSIX interfaces to their managers. This issue has been
debated quite a bit. My opinion is that for very simple
applications the programming overhead is just not worth it.
This applied for QNX2 and QNX4, and I haven’t seen anything
in QNX 6 to change it. This in spite of the fact that QSSL
has done a laudible job of making the development of full POSIX
interface resource managers accesable.

I suppose I’m up to speed enough at this point to create an API
that would look like this.


// Client

main()
{
id = simple_locate("/name/server");

send_data.cmd = CMD1
simple_send(id,send_data,send_data_size,reply_data,reply_data_size);

send_data.cmd = CMD2
simple_send(id,send_data,send_data_size,reply_data,reply_data_size);

}

// Server
main()
{
simple_attach("/name/server",max_data_size);

while(1)
{
id = simple_receive(recieve_data,receive_data_size);
switch(receive_data.cmd)
{
case CMD1:
simple_reply(id,reply_data,reply_data_size);
break;
case CMD2:
simple_reply(id,reply_data,reply_data_size);
break;
}
}
}


}






Mitchell Schoenbrun --------- > maschoen@pobox.com

Hmm, not sure if i’m thinking of the same thing (hey, i havn’t been
here since QNX2 and therefor have no acess to this newsgroup! ), but
exactly as u wrote this example is already possbible with QSSL’s api!
It won’t be a full res-mgr, but well, your ‘idea of api’ wasn’t suppose
to be either i guess…


//server

name_attach(…“name”,…);
while(1)
MsgReceive(attachedname->chid,data,size,…);
switch(data);
…blaha… reply etc


and with the client just nmae_open(“name”,…);
MsgSend…
name_close

…


from what i understand, this is about exact the easy and simple api you
are asking for already implented

/Johan

[David_Gibbs1]

Mitchell Schoenbrun <maschoen@pobox.com> wrote:

Well here’s the crux of the matter. It has gotten a lot
more complex. Once you’ve figured it all out and have
templates that you understand the complexity is no longer a
problem. I’ve been struggling with this for a couple of
months myself. I’ve also been wondering if there isn’t a
way to encapsulate all the levels to create a simple way to
do message passing for a simple application with a one
thread manager. For new users this could be a stepping
stone.

I suspect that one reason this hasn’t been done already is
the strong push from QSSL for users to provide standardized
POSIX interfaces to their managers. This issue has been
debated quite a bit. My opinion is that for very simple
applications the programming overhead is just not worth it.
This applied for QNX2 and QNX4, and I haven’t seen anything
in QNX 6 to change it. This in spite of the fact that QSSL
has done a laudible job of making the development of full POSIX
interface resource managers accesable.

I suppose I’m up to speed enough at this point to create an API
that would look like this.



// Client

main()
{
id = simple_locate("/name/server");

coid = name_open()

send_data.cmd = CMD1
simple_send(id,send_data,send_data_size,reply_data,reply_data_size);

MsgSend( coid, … )

send_data.cmd = CMD2
simple_send(id,send_data,send_data_size,reply_data,reply_data_size);

}

// Server
main()
{
simple_attach("/name/server",max_data_size);

attach = name_attach( … );

while(1)
{
id = simple_receive(recieve_data,receive_data_size);

rcvid = MsgReceive( attach->chid, … );

switch(receive_data.cmd)
{
case CMD1:
simple_reply(id,reply_data,reply_data_size);

MsgReply( rcvid, … );

break;
case CMD2:
simple_reply(id,reply_data,reply_data_size);
break;
}
}
}

Sure looks about the same. Of course, name_attach() & name_open() weren’t
in Neutrino 2.0 – so you may not be familiar with them.

-David

QNX Training Services
dagibbs@qnx.com

[Mitchell_Schoenbrun]

Previously, David Gibbs wrote in qdn.public.qnxrtp.advocacy:

Sure looks about the same. Of course, name_attach() & name_open() weren’t
in Neutrino 2.0 – so you may not be familiar with them.

I’ve heard about them. My first impression was that they were a
convience only put in for QNX4 porting, ie a hack for loud mouths like
me. Strangely enough I’d rather use the stuff QSSL was promoting, even
though there is more learning curve pain involved.

Mitchell Schoenbrun --------- maschoen@pobox.com

[Jutta_Steinhoff1]

Miguel Simon wrote:

Hi…

There’s nothing wrong with your beliefs except may be that they’re really
out of business realm. I don’t mean any offense here, just trying to point
out where the difference in perception comes from. You talk almost in terms
of emotional relationship, while Armin talks from rather dry business
perspective.

culture induced syndrome?

I like sweets made with condense milk, and my wife despise them. I grew
up in the mist of sugar cane fields back in Cuba, my wife grew up in
Dexter, MI. Our difference in taste is, we both agree, due to 'culture
induced syndrome. >

I’m not sure you can compare something to eat with an OS
For technical/physical issues you have facts… and facts can’t be
discussed!

e.g. you may perceive a temperature as warm or cold, but the thermometer
tells you the degrees quite independent of your culture. Differences can
be degrees in Fahrenheit or Celsius, but the taken temperatur is exactly
the same…

Jutta

[Miguel_Simon1]

Hi…

There’s nothing wrong with your beliefs except may be that they’re really
out of business realm. I don’t mean any offense here, just trying to point
out where the difference in perception comes from. You talk almost in terms
of emotional relationship, while Armin talks from rather dry business
perspective.

culture induced syndrome?

I like sweets made with condense milk, and my wife despise them. I grew
up in the mist of sugar cane fields back in Cuba, my wife grew up in
Dexter, MI. Our difference in taste is, we both agree, due to 'culture
induced syndrome.

–
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/

[Igor_Kovalenko2]

“Jutta Steinhoff” <j-steinhoff@web.de> wrote in message
news:3AFEFA4E.A198A7DD@web.de…

Miguel Simon wrote:

Hi…

There’s nothing wrong with your beliefs except may be that they’re
really
out of business realm. I don’t mean any offense here, just trying to
point
out where the difference in perception comes from. You talk almost in
terms
of emotional relationship, while Armin talks from rather dry business
perspective.

culture induced syndrome?

I like sweets made with condense milk, and my wife despise them. I grew
up in the mist of sugar cane fields back in Cuba, my wife grew up in
Dexter, MI. Our difference in taste is, we both agree, due to 'culture
induced syndrome. >

I’m not sure you can compare something to eat with an OS >
For technical/physical issues you have facts… and facts can’t be
discussed!

Oh, they sure can be! Many facts are relative to an observer.

e.g. you may perceive a temperature as warm or cold, but the thermometer
tells you the degrees quite independent of your culture. Differences can
be degrees in Fahrenheit or Celsius, but the taken temperatur is exactly
the same…

I think same temperatures might not be really same if you take pressure into
consideration. So Armin and Camz probably live in areas of different
pressure

Cheers,

• igor