BeOS versus QNX RTOS

[Armin_Steinhoff1]

Markus,

I’m not surprised about your experiences with RT-Linux
I wouldn’t use RT-Linux because I dislike its base concept.

However, the core of my statements was not that RT-Linux XY is
better than QNX … I did some conclusion about the future of closed
proprietary operating systems under impression that the big players
of the IT industry are supporting very strong the DEVELOPMENT of
open source REAL-TIME KERNELS. (e.g. L4 / IBM)

It’s clear for me that none of the so called free/open RT kernels is
an alternative to QNX TODAY!

Armin


Markus Loffler wrote:

Armin,
let me tell you a little about our own experience… I don’t know about the
MontaVista product, but this is about RT-Linux. Here at my department we do
real-time development for RT-Linux and QNX. I happy every day that I’m on
the QNX side.
This is not really all about speed or responsiveness of the operating
system. QNX just has a design that is so much better to use. For example,
you can use OS function calls only very limited in your RT Linux real-time
task. Debugging is limited. If the real-time task crashes the whole system
crashes. And what is most important: Whenever there is a new version of
Linux, a new version of Linux or RT-Linux, problems start… Our RT Linux
guy just had to reinstall an older version of Linux from scratch because the
versions of RT-Linux and Linux didn’t work together. Often, our software
needs to be adapted to new versions of RT-Linux. The is no real standard…
people can just change stuff in a new version and your software doesn’t work
anymore. Sure you can look into the sources… but you really wanna look
through thousands of lines of code to find your problem…?
Finally, we develop our RT software in C++… What do you think about Linux
header files defining global variables with the name “private” (or was it
something similar), so that compiling C++ doesn’t work?

Sure you are still able to develop solutions, I just wanted to point out the
disadvantages…
Markus

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3AC06E8A.5F24AF0A@web_.de…


Igor Kovalenko wrote:

Armin Steinhoff wrote:

Rennie Allen wrote:

[clip…]
Yes SawMill is intersting project. And it is not the only project based
on L4 u-kernel. There is half dozen of others and they are all
interesting but none of them yet reached the level of completeness and
stability to compete seriously.

Yes … it has not yet reached the level of completeness and
stability to compete seriously. It’s only a question of time …

Yes … you can clip it away, you can close your eyes … but the
development goes on as demonstrated by
http://www.mvista.com/products/realtime.html


That is pathetic. Penguins do not fly. They are fat and slow.

Yes they are today fat and slow > > … but read the article down
to its end. A fat but preemptive Linux kernel has the potential to
become much faster.

BTW … how fat is actually the process manager together with the
kernel of QNX6? Would be interesting to see how deep that animal
‘procnto’ must fly …

The URL you mention explains that too and then offers ‘realtime
scheduler’ which
will make penguin move his wings faster but still will not let it fly.

I also think Rennie mentioned ‘new economy’ and RedHat because it is
closely related to ‘Linux syndrome’. Everything with word ‘Linux’ in it
was so hot that it immediately gave companies tickets into ‘new
economy’. Look at your Montavista example. A company which claims it has
years of experience with realtime & embedded systems decides to make
money by trying to hack Linux into something usable for realtime. They
should know that it would be much better to use a system designed for
realtime, but nevertheless they stick to the ‘Linux’ buzzword despite
all obvious design deficiences. Why not, it is hot and it is free, who
cares about ‘architecture makes the difference’…

Well, it is free and you will get all information and the sources
of the OS … that means no one can stop you and screw you up by
‘information hiding’… and our day by day experience is that
companies hate more and more being dependent because of hided
information by OS vendor.

IMHO … this is the core of the ‘LINUX syndrom’ and not the ‘new
economy hypes’.

Russians used to say ‘Even vinegar is sweet when it is free’ >

Igor, free of charge is not very important for our customer base,
but free access for own developments and customising what ever is
needed w/o custom engineering and dependency from the OS vendor is
what “open” means today…

So most guys here don’t prefer vinegar, even when it’s free >

Armin

[Armin_Steinhoff1]

Rennie Allen wrote:

Well … at first let them use C++ for e.g. the Photon library
and you will see what better software they will produce >

Huh ? Since when did a language create better programmers ?

I didn’t say that …
but C++ well used leads to better software

Not even the
most ardent proponent of engineered languages (of which C++ is not a set
member) will claim that using a language (such as Eiffel or Ada) will
somehow create good programmers from bad. Languages like Ada will
completely frustrate bad programmers, perhaps causing them to choose a
different line of work (usually as C++ programmers, unfortunately).

Photon is written in ‘C’ in order to be as small, and efficient as
possible, so that it would be appropriate for deeply embedded systems.
I am currently writing a C++ library for Photon, and I can guarantee you
that small size and efficient execution are not in its set of positive
attributes (economy of syntax, maintainability, and consiseness are).

It’s much easier and more efficient to archive maintainability and
consistency with C++ … IMHO.
And students coming from University are very familiar with it

Markus … what’s your opinion?

Armin

[Armin_Steinhoff1]

Rennie Allen wrote:

Well, it is free and you will get all information and the sources
of the OS … that means no one can stop you and screw you up by
‘information hiding’… and our day by day experience is that

One of the bedrock principles of good software engineering, is
information hiding. You don’t get “screwed up” by information hiding,
you are freed to think at a different level of abstraction.

That’s true as long as all methods applicable on that hidden
information are documented

companies hate more and more being dependent because of hided
information by OS vendor.

Of course this has nothing to with the term “information hiding” as it
applies to software engineering.

Igor, free of charge is not very important for our customer base,
but free access for own developments and customising what ever is
needed w/o custom engineering and dependency from the OS vendor is
what “open” means today…

Well, we would qualify as one of your “customer base”, and we have
absolutely no problems whatsoever with having another reliable
organization maintaining the code on the other side of an abstract
interface which is highly modular, and
in no way restricts us from doing anything we would ever want to do.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Would you say this is the case for QNX or any other OS ?

The cost to us for this maintenance
is many orders of magnitude less than it would be for us to do it
ourselves (and far less than it would cost another organization to do
with Linux since Linux isn’t designed from the ground up to do the job
at hand).

The existence of a well documented interface for e.g. the process
manager doesn’t mean that everybody must use it … but it must be
possible to have and use it besides other higher level interfaces.

Such low level interfaces should be offered only in a bundle with
a training package just to make sure that it will be used by well
trained developers.

Hmm … isn’t it a good idea to make money with a well documented OS?

If QSSL has to go up against a company that is trying to shoe horn
Linux [clip …]

easily on the return trip, due to the improved Linux compatibility).

Your view is far too static … the ‘RT Linux’ systems are under
heavy development and QNX is based on a development history of

20 years.

There is no fair comparison possible today …

Armin

[Rennie_Allen2]

I’m not surprised about your experiences with RT-Linux >
I wouldn’t use RT-Linux because I dislike its base concept.

However, the core of my statements was not that RT-Linux XY is
better than QNX … I did some conclusion about the future of closed
proprietary operating systems under impression that the big players

The idea of openness is not necessarily black or white. QNX has
always been more open than just about any commercial OS. Based on
what QNX has announced wrt QNX6, it is still going to be one of the most
open commercial systems around. The fact of the matter is that QNX is
years ahead of anyone else on the core technologies of a memory
protected real-time operating system. Why should they give away this
lead. For every single open operating system I have seen to date, the
code is nothing special. They are nothing more than continual on-going
re-hashes of things that have been done a thousand times before (so is a
great deal of QNX, and I think that QSSL will open source all of this
everyday type stuff). However, there are some very special unique
things that QSSL done that are the result of many man years of hard work
and experience in the development of rt microkernels; stuff that no one
else has. Why should they give away this hard earned intellectual
property ?

With a microkernel architecture, I can bend and shape the OS any way I
want (hey that sounds like a good marketing line , I have no desire
whatsoever to “look inside” (well I have intellectual curiosity but no
business need whatsoever).

It’s clear for me that none of the so called free/open RT kernels is
an alternative to QNX TODAY!

Well, when they are an alternative I am sure that people will use them,
oh unless of course, they have a piece of hardware that they must have a
driver for, and the hardware developer insists on an NDA for the
interface specs… not a whole bunch of mega corps out there that like
to ship a product with a reverse engineered driver in it.

Armin

[Markus_Loffler1]

It’s much easier and more efficient to archive maintainability and
consistency with C++ … IMHO.
Markus … what’s your opinion?

I’d say first its application dependent. Some applications don’t benefit so
much from C++, some tremendously (e.g., GUI programming).
Second, there is much more to a good C++ design than to a C design. I mean
the programmers have to be more advanced. I have been programming C++ for 6
years now and I’m still learning…

And students coming from University are very familiar with it >

I think this statement is a little too general. It depends on the
university, the major, the students themselves. My personal opinion is that
people often know the language ok, but that can’t replace experience,
especially in big projects.

Markus

[Armin_Steinhoff1]

Markus Loffler wrote:

BTW … how fat is actually the process manager together with the
kernel of QNX6? Would be interesting to see how deep that animal
‘procnto’ must fly …

I looked at my /.boot file. It is about 550K.
Looking at /boot/build/qnxbasedma.build, you see it contains the kernel,
process manager, a couple of file systems, standard C library, some drivers,
as far as I understand.
Markus

please see a new thread in qdn.public.qnxrtp.os:
“Size of the QNX6 kernel”

Armin

[Tony_Mantler]

Previously, Armin Steinhoff wrote in qdn.public.qnxrtp.advocacy:

but C++ well used leads to better software

Nothing makes or breaks software qucker than the relative skills of the programmers involved.

The language rarely enters into the picture except in the context of “A programmer who is more skilled in language X will generally write code better in language X”.

Maybe C++ makes more complex projects easier to manage, but at the same time maybe it stops you from asking the question ‘should this project be this complex?’. Applying C++ to a project as a silver bullet is at most a null-sum gain.

There are appropriate languages for appropriate problems. Saying ‘C++ makes better software’ (or any language) is a naieve and foolish view of programming.


Cheers - Tony ‘Nicoya’ Mantler

\

Tony Mantler | Proud ---- Days since the last
QNX Consulting | of our | 27 |
tony@astra.mb.ca | Record ---- “Gerbil Incident”

[Igor_Kovalenko2]

I still think that appropriate language coupled with appropriate coding
discipline can make difference in overall quality of software. C++ is double
sided sword. It can be abused to horrible extents and it can be used to
enforce discipline and provide better abstraction layer.

“The language you think defines what you can think about” [Bjarn
Stroustrup].

• igor

“Tony Mantler” <tony@astra.mb.ca> wrote in message
news:Voyager.010328095446.516123F@napkin.astra…

Previously, Armin Steinhoff wrote in qdn.public.qnxrtp.advocacy:
but C++ well used leads to better software

Nothing makes or breaks software qucker than the relative skills of the
programmers involved.

The language rarely enters into the picture except in the context of "A
programmer who is more skilled in language X will generally write code

better in language X".

Maybe C++ makes more complex projects easier to manage, but at the same
time maybe it stops you from asking the question 'should this project be

this complex?’. Applying C++ to a project as a silver bullet is at most a
null-sum gain.

There are appropriate languages for appropriate problems. Saying ‘C++
makes better software’ (or any language) is a naieve and foolish view of

programming.

Cheers - Tony ‘Nicoya’ Mantler >

\

Tony Mantler | Proud ---- Days since the last
QNX Consulting | of our | 27 |
tony@astra.mb.ca > | Record ---- “Gerbil Incident”

[Randy_Martin]

what? where do you get this info?

okay, i’m not a kernel developer but i have been here for over 10 years now
at qnx and have seen the transition.
the core kernel architects are the same and have been onboard for all that
time plus.

i’m talking: Dan Dodge, Peter Van Der Veen, Brian Stecher as the core
kernel group.
we’ve added over the past 5 years excellent resources to the kernel team.
some specific to non-x86 processors, some specific to market segment
(telecom/datacom)

the core filesystem team is now the same. jgarvey has rejoined us … who
was one of the original architects. we’ve also added many more specialists
to that group (flash etc.)

qnx is now structured with specialists and generalists. the generalists
are the architects who know the kernel inside and out as well as many other
issues about the qnx model. and they help the specialists (like a tcpip
guru for example) to design best for qnx.

i personally feel the resources and R&D design we have in place now is the
best it has ever been.

the above comments are my own… i just hope to clear the waters a bit here
and not let an incorrect statement go unrefuted.
what i find now is that qnx is hig

ian zagorskih <ianzag@novosoft-us.com> wrote:

thank you igor, you answered a lot of potential questions related to
qnx4/nto2 line >

“Igor Kovalenko” <> kovalenko@home.com> > wrote in message
news:99h2tf$3k$> 1@inn.qnx.com> …
Heh, I still remember the joke (about pilot in hell) accompanied release
of
3c509 driver >

Part of problem with Neutrino is that pretty much all of ‘original’ guys
who
wrote major parts of QNX4 are gone. So, when someone asks now ‘hey, why
don’t you just port you QNX4 stuff’ is it almost the same as to ask ‘port
Linux stuff’, might be even harder in fact >

For those who don’t know, keep in mind that people responsible for
original
design of filesystem, native networking, TCP/IP stack, Photon and
practically all drivers have left QSSL. There are very few real ‘last
mohicans’ left and bulk of Neutrino was designed by new generation of
developers. I suspect that at some point they had sort of internal ‘camps
conflict’ like Apple had once, which eventually resulted in exodus of most
senior developers of older generation. Nobody likes to be a dynosaur and
feel breath of young tigers on their neck …

The latter was purely my speculation of course, but I happen to be in very
speculative mood today >

• igor
  
  
  // wbr

–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

[Igor_Kovalenko2]

Randy Martin wrote:

what? where do you get this info?

One gipsy told me …

okay, i’m not a kernel developer but i have been here for over 10 years now
at qnx and have seen the transition.

Hey 10 years is 1991 and by that time QNX4 was out already

the core kernel architects are the same and have been onboard for all that
time plus.

i’m talking: Dan Dodge, Peter Van Der Veen, Brian Stecher as the core
kernel group.

AFAIK, Brian came from Watcom by the time QNX4 was already out.

we’ve added over the past 5 years excellent resources to the kernel team.
some specific to non-x86 processors, some specific to market segment
(telecom/datacom)

the core filesystem team is now the same. jgarvey has rejoined us … who
was one of the original architects. we’ve also added many more specialists
to that group (flash etc.)

I think Bill Flowers was original and jgarvey used to do some
fonts-related work for Photon before he became original architect.
Granted, he did some improvements of filesystem for NTO, but some
features of QNX4 were lost on the way.

qnx is now structured with specialists and generalists. the generalists
are the architects who know the kernel inside and out as well as many other
issues about the qnx model. and they help the specialists (like a tcpip
guru for example) to design best for qnx.

I think this is great idea.

i personally feel the resources and R&D design we have in place now is the
best it has ever been.

the above comments are my own… i just hope to clear the waters a bit here
and not let an incorrect statement go unrefuted.

Mine were not statements. They were speculations and I explicitly noted
that in the first place. See Randy, my “fishing” method still works

Regards,

• Igor

what i find now is that qnx is hig

ian zagorskih <> ianzag@novosoft-us.com> > wrote:

thank you igor, you answered a lot of potential questions related to
qnx4/nto2 line >

“Igor Kovalenko” <> kovalenko@home.com> > wrote in message
news:99h2tf$3k$> 1@inn.qnx.com> …
Heh, I still remember the joke (about pilot in hell) accompanied release
of
3c509 driver >

Part of problem with Neutrino is that pretty much all of ‘original’ guys
who
wrote major parts of QNX4 are gone. So, when someone asks now ‘hey, why
don’t you just port you QNX4 stuff’ is it almost the same as to ask ‘port
Linux stuff’, might be even harder in fact >

For those who don’t know, keep in mind that people responsible for
original
design of filesystem, native networking, TCP/IP stack, Photon and
practically all drivers have left QSSL. There are very few real ‘last
mohicans’ left and bulk of Neutrino was designed by new generation of
developers. I suspect that at some point they had sort of internal ‘camps
conflict’ like Apple had once, which eventually resulted in exodus of most
senior developers of older generation. Nobody likes to be a dynosaur and
feel breath of young tigers on their neck …

The latter was purely my speculation of course, but I happen to be in very
speculative mood today >

• igor
  
  
  // wbr

–
Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

[Rennie_Allen2]

Rennie Allen wrote:

Well … at first let them use C++ for e.g. the Photon library
and you will see what better software they will produce >

Huh ? Since when did a language create better programmers ?

didn’t say that …
but C++ well used leads to better software

My definition of better programmer is synonymous with “a programmer that
produces better software”. How does your definition differ ?

Photon is written in ‘C’ in order to be as small, and efficient as
possible, so that it would be appropriate for deeply embedded systems.
I am currently writing a C++ library for Photon, and I can guarantee
you
that small size and efficient execution are not in its set of positive
attributes (economy of syntax, maintainability, and consiseness are).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



It’s much easier and more efficient to archive maintainability and
consistency with C++ … IMHO.

I’d say we agree, on this point. So the widget library is more
difficult to maintain, since it is written in ‘C’ but it is smaller, and
more efficient. QSSL absorbs the cost of this extra maintainance,
funded by the premium price those who need deeply embedded GUIs are
willing pay (since nothing of Photon capabilities in the given footprint
is available anywhere else).

[Rennie_Allen2]

I still think that appropriate language coupled with appropriate
coding
discipline can make difference in overall quality of software. C++ is
double
sided sword. It can be abused to horrible extents and it can be used
to
enforce discipline and provide better abstraction layer.

Appropriate coding discipline is perhaps 99% of the equation, the
language perhaps 1%.

btw: speaking of linguistics, I think you meant “doubled edged sword”
(all swords have two sides, some have two functional edges

“The language you think defines what you can think about” [Bjarn
Stroustrup].

I wish Bjarn could explain to the rest of the world just what it is he
was thinking about when he created C++. Steve McPolin had a great
response when another engineer was explaining how Bjarn had apologized
for creating C++; Steve’s response was “that’s not good enough”

[Igor_Kovalenko2]

Rennie Allen wrote:

I still think that appropriate language coupled with appropriate
coding
discipline can make difference in overall quality of software. C++ is
double
sided sword. It can be abused to horrible extents and it can be used
to
enforce discipline and provide better abstraction layer.

Appropriate coding discipline is perhaps 99% of the equation, the
language perhaps 1%.

Language can help to enforce a discipline. And discipline itself can be
abused as well. This equation also has “common sense”, “skills” and
“experience” in it and that’s where I’d put 80%, with 20% for language
and discipline

btw: speaking of linguistics, I think you meant “doubled edged sword”
(all swords have two sides, some have two functional edges >

yes, tnanks.

“The language you think defines what you can think about” [Bjarn
Stroustrup].

I wish Bjarn could explain to the rest of the world just what it is he
was thinking about when he created C++. Steve McPolin had a great
response when another engineer was explaining how Bjarn had apologized
for creating C++; Steve’s response was “that’s not good enough” >

Keep in mind, when you don’t understand what somebody was thinking
about, it might be due to 2 reasons: somebody was not thinking well or
you simply are unable to grasp it. Never underestimate the second
possibility. If you or Steve McPolin came up with a language even
remotely as useful as C++ then I’d consider quoting you guys, instead of
Bjarn. Otherwise you’re not impressing me much with such statements.

• igor

[Colin_Burgess1]

Bill Caroselli <Bill@sattel.com> wrote:

“Rennie Allen” <> RAllen@csical.com> > wrote in message
news:> D4907B331846D31198090050046F80C9039060@exchangecal.hq.csical.com> …
I wish Bjarn could explain to the rest of the world just what it is he
was thinking about when he created C++. Steve McPolin had a great
response when another engineer was explaining how Bjarn had apologized
for creating C++; Steve’s response was “that’s not good enough” >



Can you reference this quote from Bjarn about apologizing for creating C++?

It was a joke (although a good one).

Checkout http://www.gate.net/~ddata/Funny/Stroustrup.htm

–
cburgess@qnx.com

[ian_zagorskih2]

That is pathetic. Penguins do not fly. They are fat and slow. The URL
you mention explains that too and then offers ‘realtime scheduler’ which
will make penguin move his wings faster but still will not let it fly.

i’m really not sure exactly about penguins but probably this can
illustrate in some way Linux → RT Linux transformations

http://www.anekdot.ru/an/an0103/e010328.html

• igor

[John_Doe]

“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:3AC25725.AD62EA5F@motorola.com…

Keep in mind, when you don’t understand what somebody was thinking
about, it might be due to 2 reasons: somebody was not thinking well or
you simply are unable to grasp it. Never underestimate the second
possibility. If you or Steve McPolin came up with a language even
remotely as useful as C++ then I’d consider quoting you guys, instead of
Bjarn. Otherwise you’re not impressing me much with such statements.

Well, you need to separate useful from good. I think that C++ is a very
useful language. I use it everyday, and develop almost all of my code in
it. The reasons for its utility however, has little to do with it being a
particularly good object oriented language. The primary reason that C++ is
so useful, is simply that it is a functional O-O language that everybody
uses; therefore there are lot’s of pre-written libraries for it, lot’s of
books about it, lot’s of tools that work with it, etc. etc… Windows is a
very useful operating system for the same types of reasons; however, I don’t
think anyone here would claim that it is a particularly good operating
system. C++ was a marketing success more than a technical success (again
much like Windows).

Don’t take my word for it though, I think if you consult with experts in the
field (linguists, language designers, compiler designers at the post
doctoral level) the vast majority of them will agree that C++ is not a
particularly well engineered object oriented language. Few (probably none)
will deny its utility though…

While I am not a language designer, I definately have a good grasp of C++,
and O-O design principles, and I wasn’t trying to “impress you” with my
statements (I was simply relating, what I thought was a humorous anecdote).
Since your in the mood for taking things literally, I must emphasize that I
don’t really know that Bjarn Stroustroup apologized for creating C++ (I do
know that he has acknowledged that C++ is very complicated, but remains,
justifiably, proud of his achievement given the design constraints), I was
simply relating what somebody else said, and how Steve responded to it (I
don’t think Steve was being literal either, although I can’t speak for him).

[John_Doe]

“Bill Caroselli” <Bill@Sattel.com> wrote in message
news:99t1ea$g44$1@inn.qnx.com…

OK. I want to jump in here. If footprint in embedded applications is an
important issue, then I don’t see the C vs. C++ as being the real problem.
That fact, as I see it, is that ANY PhAB application is fat compared to
the
same application that is written strictly in executable code.

What on earth makes you say that ? A phab application is practically
identical in size to the same application written directly using the widget
toolkit. I have a O-O GUI library that I have written in C++, and
applications are considerably bigger than the equivalent done in phab
(exceptions, RTTI, and all that useful but piggy stuff being used).

Yes, PhAB is a wonderful tool that I love using. but if I were writing a
Photon app for a memory constrained embedded application I would not be
using PhAB.

Why not ? Phab is the perfect tool, for quickly developing a lightweight
GUI app.

Having established the choice to write all executable code as opposed to
the
Photon data base techniques, I would absolutely prefer to be using a good
class library to do most of my Photon work. And it would still be much
small then the equivlant application written using PhAB and C.

Sorry. I have what I consider to be a very nice (so far - not finished yet)
class library (functional GUI spreadsheet in 250 lines of code), but it is a
total pig relative to the same thing done in phab. The phab version would
be considerably more than 250 lines of code, and it would be more difficult
to extend, and maintain though.

I agree, that for developing large desktop type apps a class library is the
way to go, but for resource constrained environments I would most definately
use phab (relieves alot of the burden of doing a GUI in C without costing
anything at runtime).

Rennie

[John_Doe]

“Bill Caroselli” <Bill@Sattel.com> wrote in message
news:99tehb$pm0$1@inn.qnx.com…

OK. I guess the joke was on me. I thought there was some earth
shattering
new developments that I wasn’t aware of.

Also, you evidently did not read my post very closely, because in my text, I
mentioned that Steve was responding to a third party, who had related the
statement in question. The part that was (supposed) to be funny was the
response… sheeesh… I promise I won’t relate any more anecdotes…

Rennie

[Bill_Caroselli1]

“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C9038F7F@

I’d say we agree, on this point. So the widget library is more
difficult to maintain, since it is written in ‘C’ but it is smaller, and
more efficient. QSSL absorbs the cost of this extra maintainance,
funded by the premium price those who need deeply embedded GUIs are
willing pay (since nothing of Photon capabilities in the given footprint
is available anywhere else).

OK. I want to jump in here. If footprint in embedded applications is an
important issue, then I don’t see the C vs. C++ as being the real problem.
That fact, as I see it, is that ANY PhAB application is fat compared to the
same application that is written strictly in executable code.

Yes, PhAB is a wonderful tool that I love using. but if I were writing a
Photon app for a memory constrained embedded application I would not be
using PhAB.

Having established the choice to write all executable code as opposed to the
Photon data base techniques, I would absolutely prefer to be using a good
class library to do most of my Photon work. And it would still be much
small then the equivlant application written using PhAB and C.

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

[Bill_Caroselli1]

“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C9039060@exchangecal.hq.csical.com…

I wish Bjarn could explain to the rest of the world just what it is he
was thinking about when he created C++. Steve McPolin had a great
response when another engineer was explaining how Bjarn had apologized
for creating C++; Steve’s response was “that’s not good enough” >

Can you reference this quote from Bjarn about apologizing for creating C++?

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