How to boot with -ptcpip [was: netstat and route]

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
81

If none of the fixes/enhancements in Patch C are of interest, can I skip it?
What I’m asking is when subsequent patches/releases come out, will they
presuppose I have installed patch C or will they pick up from my current
installation (patch B)?

Brian Northgrave wrote:

QNX RTP Patch C & Language Supplement Patch B (Beta Release Candidate)
now available for download!!!

Patch C is now available as a beta download from:

http://betas.qnx.com/beta

Just point your package installer at the url.

This distribution must be installed over a Patch B system.

Release Notes for this distribution:

QNX RTP - Patch C (Based on QNX RTOS v6.0.0 Patch C)


Fixes & errata

Note: If you have an earlier release of QNX RTP, you should recompile
ALL your existing QNX RTP code with this distribution.

This section covers the following:

  • New input (devi-*) drivers
  • Photon Library
  • phs-to-ps
  • PtOSContainer
  • PxLoadImage()
  • Render Library

New input (devi-*) drivers

  • Improved touchscreen support.

Photon Library

  • Fixed crash problem re: PtFileSelection.
  • Fixed unknown symbol replacement in translation lib routines.
  • Fixed buffer overflow problem in translation routines – the
    helpviewer can now display Japanese help pages correctly.

phs-to-ps

  • Fixed segment violation problem when processing draw streams with
    large images.
  • Added enhancements/improvements to the output of phs-to-ps and
    phs-to-escp2.
  • Fixed the behavior of offscreen contexts when used within a
    widget’s draw function (Pt_ARG_RAW_DRAW_F() of PtRaw widget).

PtOSContainer

  • Fixed problems with translation, blit, and render operations.
  • Added support for rendering images and rep-images (repeating
    images) with transparency into offscreen contexts or memory
    contexts that didn’t work correctly.

PxLoadImage()

  • Fixed segment violation problem when loading GIFs with a
    transparent color.

Render Library

  • Improved support for rendering and printing wide chars (UTF-16).
  • Updated to better support image rendering, translations, polygons,
    etc.

QNX RTP - Language Supplements (2.0 Patch B)


Fixes & errata

vpim (Japanese Input Method)

  • Added new options:

-F font
Specify default font.

-@ x,y
Specify the default position for the input window.

Note: The -F and -@ options are applied when no FEP
(Front End Processor) rectangle is defined.

  • Fixed the input window size.

cpim (Chinese Input method)

  • ESC will cancel current input sequence.
  • Fixed a bug caused by changing the default font with the selection
    list.
  • Selection list is always on the screen.

Happy beta testing!!!

thanx
ben
QA
QSS

82

Dean Douthat <ddouthat@faac.com> wrote:

If none of the fixes/enhancements in Patch C are of interest, can I skip it?
What I’m asking is when subsequent patches/releases come out, will they
presuppose I have installed patch C or will they pick up from my current
installation (patch B)?

Don’t worry too much, I think you’ll be alright if you want to skip it.
If they are any issues with future upgrades they will be taken care of
at the time.

thanx

ben



Brian Northgrave wrote:

QNX RTP Patch C & Language Supplement Patch B (Beta Release Candidate)
now available for download!!!

Patch C is now available as a beta download from:

http://betas.qnx.com/beta

Just point your package installer at the url.

This distribution must be installed over a Patch B system.

Release Notes for this distribution:

QNX RTP - Patch C (Based on QNX RTOS v6.0.0 Patch C)


Fixes & errata

Note: If you have an earlier release of QNX RTP, you should recompile
ALL your existing QNX RTP code with this distribution.

This section covers the following:

  • New input (devi-*) drivers
  • Photon Library
  • phs-to-ps
  • PtOSContainer
  • PxLoadImage()
  • Render Library

New input (devi-*) drivers

  • Improved touchscreen support.

Photon Library

  • Fixed crash problem re: PtFileSelection.
  • Fixed unknown symbol replacement in translation lib routines.
  • Fixed buffer overflow problem in translation routines – the
    helpviewer can now display Japanese help pages correctly.

phs-to-ps

  • Fixed segment violation problem when processing draw streams with
    large images.
  • Added enhancements/improvements to the output of phs-to-ps and
    phs-to-escp2.
  • Fixed the behavior of offscreen contexts when used within a
    widget’s draw function (Pt_ARG_RAW_DRAW_F() of PtRaw widget).

PtOSContainer

  • Fixed problems with translation, blit, and render operations.
  • Added support for rendering images and rep-images (repeating
    images) with transparency into offscreen contexts or memory
    contexts that didn’t work correctly.

PxLoadImage()

  • Fixed segment violation problem when loading GIFs with a
    transparent color.

Render Library

  • Improved support for rendering and printing wide chars (UTF-16).
  • Updated to better support image rendering, translations, polygons,
    etc.

QNX RTP - Language Supplements (2.0 Patch B)


Fixes & errata

vpim (Japanese Input Method)

  • Added new options:

-F font
Specify default font.

-@ x,y
Specify the default position for the input window.

Note: The -F and -@ options are applied when no FEP
(Front End Processor) rectangle is defined.

  • Fixed the input window size.

cpim (Chinese Input method)

  • ESC will cancel current input sequence.
  • Fixed a bug caused by changing the default font with the selection
    list.
  • Selection list is always on the screen.

Happy beta testing!!!

thanx
ben
QA
QSS

83

Thanks Igor
(Perhaps the the on-line docs should mention this? All the examples there have everything in the boot image).

On Mon, 11 Jun 2001 16:51:38 -0500, Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

It is called ‘init’, just like in Unix. In fact earlier versions even
used ‘getty’ instead of QNX-ish ‘tinit’ for terminal initialisation.

What I do is run my own pre-init shell script from boot image, which
takes care about our custom stuff first, then starts ‘init’ takes care
about getty/login stuff. I use SYSV-like convention for custom scripts
(i.e., everything in directory X what has execute permission gets
executed in the alphabetical order). That way you can plug things in and
out without editing any existing files and that saves LOT of trouble.
Customers tend to screw startup scripts miserably using vi in hyperterm
and if everything is in one script the system gets unbootable right away
:wink:

84

6.1.0 PatchA Now Available & Online !!!

Patch A for QNX 6.1.0 is now generally available and installable from
the QNX WWW Repository in the Package Installer.

The Release Notes are also available online at →

http://qdn.qnx.com/news/releases/releasenotes_A.html

Please read the release Notes if you have any questions.
The problem with Package Installer & Proxy Servers is also
fixed and the documented upgrade path is in the Release Notes.

thanx
ben

85

Hello,
I accept Keyboard events in my application. Basically
i open up a region in the application that accepts Keyboard events. But i
want to accept keyboard events only if the Application is in FRONT of all
the other processes and not otherwise. Is there a way to do this?

Thanks,
Shashank

86

Hi,
These signals are not declared in signal.h . Can someone
tell me where the 16 User defined signals are declared?

Thanks,
Shashank

87

Shashank <sbalijepalli@precitech.com> wrote:

Hi,
These signals are not declared in signal.h . Can someone
tell me where the 16 User defined signals are declared?

Hm… this conference is for QNX Neutrino 6, you didn’t
state what operating system you are using, so I assumed
QNX6. They have been in signal.h since the days of (at least)
Neutrino 2.0.

If you’re using QNX4, you only have the 2 user defined
signals (SIGUSR1, SIGUSR2). The Posix spec that extended
the number of signals wasn’t around when QNX4 was designed.

For QNX4 questions, you’re better to post them in
qdn.public.qnx4

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

88

Hey ed1k,

Why i need this? Well, as i’ve told before in other post, i’m porting
some
programs from the old DOS that use this feature.

Usualy DOS programs used INT 0x1c or INT 0x08 to take control every 55ms
(handle IRQ 0 or to be in
long train of handlers). But you don’t need use it anymore in QNX. You
have much more safe timers.

The timers in QNX are very safe to do this kind of work right? Every
time-interval i need to gather some hardware information and make some
decisions… i CAN thrust in the timers right? That’s what i see until now.
A little thing… In my program i try to configure the timer to repeat every,
for example, 100ms, my osciloscope shows me that i’m getting an accuracy of
80 ms, when i try to use 1ms is see that this accuracy is 0.8ms.
I’ve set the thread priority to 63, just for minimize the interferece with
other programs, and do some tests using and QNX build image too (As is
explain in Programmers Guide Manual) and again i get this 20% difference…

What makes this 20% difference?


What i want to do now is to test the InterruptAttach routines. I’m trying to
simulate an Paralel Interrupt to see if my program is working well, but it’s
more complicated then just send a 5v signal to the ACK pin of the port.

So, i just want to see if my InterruptAttach code is working, how can i
simulate an Interrupt ?

I’ve done a lot of sucessful tests using timer (Thanks to Rob again),
and
now i want the timer to generate an interrupt for my tests with
interrupt
routines.

You can use messages and pulses in QNX instead of users’ vectors and soft
INT in DOS. Ideology of
DOS and QNX is quite different. You’re able to use all your DOS background
but don’t copy
everything from one OS to another.

Yes… That’s what i’m trying to do… Porting not just the code from DOS to
QNX, but adapting the code to work better!

Thanx
Leandro

P.S. I’m posting this message in the qdn.public.qnxrtp.os too … I think
that newsgroup is better to do this kind of questions and discussions. I
will stop posting this in this group (qdn.public.qnxrtp.devtools)

89

Leandro Colen <lcrocha@yahoo.com> wrote in article <acgbdg$rpd$1@inn.qnx.com>…

Hey ed1k,



Why i need this? Well, as i’ve told before in other post, i’m porting
some
programs from the old DOS that use this feature.

Usualy DOS programs used INT 0x1c or INT 0x08 to take control every 55ms
(handle IRQ 0 or to be in
long train of handlers). But you don’t need use it anymore in QNX. You
have much more safe timers.

The timers in QNX are very safe to do this kind of work right? Every
time-interval i need to gather some hardware information and make some
decisions… i CAN thrust in the timers right?

Yes, you can trust to the timer :wink: Be warned though, the timer should give you the time not less
than you want, thus you get biggest time interval. There is good article at qdn.qnx.com “Concept of
Time” or something.
In QNXRTP 6.1A the better time resolution is 0.5 milisecond, but by default it’s setted to 1.0
millisecond. See ClockPeriod().

That’s what i see until now.
A little thing… In my program i try to configure the timer to repeat every,
for example, 100ms, my osciloscope shows me that i’m getting an accuracy of
80 ms, when i try to use 1ms is see that this accuracy is 0.8ms.
I’ve set the thread priority to 63, just for minimize the interferece with
other programs, and do some tests using and QNX build image too (As is
explain in Programmers Guide Manual) and again i get this 20% difference…

Very odd. Did you try the another osciloscope?

–
Eduard.
ed1k at ukr dot net



What makes this 20% difference?


What i want to do now is to test the InterruptAttach routines. I’m trying to
simulate an Paralel Interrupt to see if my program is working well, but it’s
more complicated then just send a 5v signal to the ACK pin of the port.

So, i just want to see if my InterruptAttach code is working, how can i
simulate an Interrupt ?

I’ve done a lot of sucessful tests using timer (Thanks to Rob again),
and
now i want the timer to generate an interrupt for my tests with
interrupt
routines.

You can use messages and pulses in QNX instead of users’ vectors and soft
INT in DOS. Ideology of
DOS and QNX is quite different. You’re able to use all your DOS background
but don’t copy
everything from one OS to another.

Yes… That’s what i’m trying to do… Porting not just the code from DOS to
QNX, but adapting the code to work better!

Thanx
Leandro

P.S. I’m posting this message in the qdn.public.qnxrtp.os too … I think
that newsgroup is better to do this kind of questions and discussions. I
will stop posting this in this group (qdn.public.qnxrtp.devtools)



\

90

[Moving this to .os]

Plus, this method relies totally on the fact that the name has appeared in
/net. In my experience the ndp is not 100% reliable in this respect and it
doesn’t work at all over QNet+TCP/IP+PPP+serial link. I terms of QNX4 vs
QNX6 gripes, setting up QNX4 networking to run over a serial link is a walk
in the park. OTOH QNet over a serial link is a tar pit for a beginner (and
it isn’t documented properly, if at all).

You can try using devn-fd.so to make a direct connection. I have not tried
this recently but I will be doing so very shortly (for the qPaq project).

OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over a
networked system? So we are urged to use a resource manager, but how? Should
we write a QNX6 version of nameloc?

I think the idea is to find the processes by always using /net. In the
local case you can use “/net/localhost/” and if you need to talk to a remote
machine you can use “/net/machinename”. This doesn’t cover global names
but the reality is you generally know the name of the machine you want to
talk to anyways. At least this is true in a semi-fixed system. Lots of
cases where this isn’t true though, I will admit. And, to head off
people, if you open “/net/localhost/dev/ser1” qnet will only be involved
in the open() - once you have the fd it will all be local.

One of the issues that I personally didn’t like about how naming worked on
QNX4 was the fact that you where basically forced to use the global name
space to communicate between two nodes and when there where mulitple
registrations of the same global name sometimes things worked out kinda funny.
You could use the nd param to qnx_name_lookup() but even the docs told you
not to do so. :wink: So I think you will find when global naming does come to
QNX6 it will be alot more complex of a system so you will be able to handle
the case of multiple machines with the same named resource. Perhaps using
an open standard like LDAP or some other open scheme.

Another thing I found light-years ahead of QNX4 was the push to use resmgrs
so that all applications can use the POSIX APIs to communicate to the
managers over the network. Using a global name is pretty much useless if
you want to use perl to talk to your service. Also, the //#/ stuff was
really painful for non-QNX applications since the rules for path space
expansion takes //#/ and turns it into /#/, which isn’t what you want at all.
This was a pain with bash and emacs and anything else that did any sort of
internal path-name expansion.

</kinda off topic>

So I am not so sure if the baby was tossed with the bathwater or if the baby
just grew up and a new baby came along.

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

91

“Chris McKillop” <cdm@qnx.com> wrote in message
news:acst3j$nq6$1@nntp.qnx.com…

[Moving this to .os]
The real beauty of QNX4’s network transparency
was that you did things IDENTICALLY whether then network
was involved or not.

Not entirely true, for some operation you had to use qnx_proxy_rem_attach()
over qnx_proxy_attach()

OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over
a
networked system? So we are urged to use a resource manager, but how?
Should
we write a QNX6 version of nameloc?

I think Cogent has a name server for QNX4 and QNX6 and LINUX.

The QNX4 version of nameloc isn’t that great you know. There are lots
of situation where it creates problem. Over the year I beleive people
learn to deal with them hence over time forget that it’s not that great.

Another thing I found light-years ahead of QNX4 was the push to use
resmgrs
so that all applications can use the POSIX APIs to communicate to the
managers over the network.

I agree Chris, but what was never made clear anywhere is the cost in
overhead.
Resmgr are expensive and slow down messaging by a factor of ~3 over non
resmgr. True resmgr do more so that’s to be expected and I am using them
all over the place :wink: But when I was told to use read/write instead of
MsgSend
I was never told it would be 3 times slower.

So I am not so sure if the baby was tossed with the bathwater or if the
baby
just grew up and a new baby came along.

Or if the parent though their baby was the greatest ever and wouldn’t
even consider some other parents baby would be better than theirs!

chris

–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

92

Thought I should join the party.

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:acst3j$nq6$> 1@nntp.qnx.com> …
[Moving this to .os]
The real beauty of QNX4’s network transparency
was that you did things IDENTICALLY whether then network
was involved or not.

The idea of “walking under /net”, could easily put in “name_open()”,
so that the application API (name_open()) is consistent in local/global
case.

For “QNET over serial”, our thoughts is we’ve put QNET over IP, so
as long as the IP network could reach, it doesn’t metter it is through
a “serial line”, “ppp over ethernet”, or “ip over atm”… QNET just
use the TCP/IP network.

It might be the case that we didn’t document enough samples how to
use QNET over IP.

The “ndp” is a protocol based on broadcasting, since PPP is not
“broadcastable”, that’s why you don’t get informations from the
otherside.

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is “nameloc” on QNX 4 is also not 100% reliable.
(it also based on a broadcast to populate the name space)

A “nameloc” on Qnx6 is very easy to write, the story is how
reliable it could be, and weather we should move that part
into QNET (or leave it a stand along process).

OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over a
networked system? So we are urged to use a resource manager, but how? Should
we write a QNX6 version of nameloc?

We difinitly don’t want to abandon the “name location” concept.

I will let others comment how to improve resmgr performance.

-xtang

93

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is “nameloc” on QNX 4 is also not 100% reliable.

(it also based on a broadcast to populate the name space)

Are you sure about this??? I’m very confident it’s NOT using broadcast.

A “nameloc” on Qnx6 is very easy to write, the story is how
reliable it could be, and weather we should move that part
into QNET (or leave it a stand along process).

OK, so if we are to abandon the QNX4 concept of name location, then
what
is/are the recommended method(s) whereby processes can make contact
over a
networked system? So we are urged to use a resource manager, but how?
Should
we write a QNX6 version of nameloc?

We difinitly don’t want to abandon the “name location” concept.

I will let others comment how to improve resmgr performance.

-xtang

94

Mario Charest wrote:

I think Cogent has a name server for QNX4 and QNX6 and LINUX.

Since you bring it up … :wink:

Yes, we do have a name server that works across the
network. You have to use our API in order to use it,
but the underlying facility is still the QNX networking,
not a crazy kluge on TCP. The upside of using our
API is that your code will port to QNX4 and Linux without
modifications (at least none related to message passing).

Cheers,
Andrew

95

Mario Charest <goto@nothingness.com> wrote:

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is “nameloc” on QNX 4 is also not 100% reliable.

(it also based on a broadcast to populate the name space)

Are you sure about this??? I’m very confident it’s NOT using broadcast.

You are right. (Guess I should check more careful of the source)

It is “reliable” in the sense that “attach()” and “query()” are
all goes to the master. It is not “reliable” to sync the masters
so if you have multiple nameloc running, things COULD goes wrong.
(or I am still not correct on this part?)

Anyway, we realized the “server/client” model could greatly improve
the reliability, but it sort of against the “pure distributed” idea,
and of cause, sync/re-elect master could be another headache.

-xtang

96

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:actoap$cm2$1@nntp.qnx.com…

Mario Charest <> goto@nothingness.com> > wrote:

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is “nameloc” on QNX 4 is also not 100% reliable.

(it also based on a broadcast to populate the name space)

Are you sure about this??? I’m very confident it’s NOT using broadcast.

You are right. (Guess I should check more careful of the source)

You had me worry I had to go tell everyone I told QNX4
is not using broadcast I was wrong :wink:

It is “reliable” in the sense that “attach()” and “query()” are
all goes to the master. It is not “reliable” to sync the masters
so if you have multiple nameloc running, things COULD goes wrong.
(or I am still not correct on this part?)

Master (nameloc) are not synchronising with each other.
A node may use different master from time to time giving
different behavior depending on which master it’s using.

Anyway, we realized the “server/client” model could greatly improve
the reliability, but it sort of against the “pure distributed” idea,
and of cause, sync/re-elect master could be another headache.

-xtang

97

Mario Charest <goto@nothingness.com> wrote:

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:acst3j$nq6$> 1@nntp.qnx.com> …
[Moving this to .os]
The real beauty of QNX4’s network transparency
was that you did things IDENTICALLY whether then network
was involved or not.

Not entirely true, for some operation you had to use qnx_proxy_rem_attach()
over qnx_proxy_attach()

QNX4 stuff:

Actually, in both local and remote, you had to use qnx_proxy_attach().
In the remote case, you had the additional step of needing to use
qnx_proxy_rem_attach(). BUT, if you coded for the remote case,
using qnx_proxy_rem_attach(), it would work transparently in the
local case as well. So, it was not (quite) identical in the
remote case to the local case, but the local case could be
identical to the remote case. (A fine distinction.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

98

Just as an aside, there might (will) hopefully be an article
coming out on this topic, but in the mean time you can fiddle
with the following:

http://www.gweebo.com/~thomasf/
http://www.gweebo.com/~thomasf/Docs/name-example.tar.gz

Thomas

Xiaodan Tang <xtang@qnx.com> wrote:

Thought I should join the party.

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:acst3j$nq6$> 1@nntp.qnx.com> …
[Moving this to .os]
The real beauty of QNX4’s network transparency
was that you did things IDENTICALLY whether then network
was involved or not.

The idea of “walking under /net”, could easily put in “name_open()”,
so that the application API (name_open()) is consistent in local/global
case.

For “QNET over serial”, our thoughts is we’ve put QNET over IP, so
as long as the IP network could reach, it doesn’t metter it is through
a “serial line”, “ppp over ethernet”, or “ip over atm”… QNET just
use the TCP/IP network.

It might be the case that we didn’t document enough samples how to
use QNET over IP.

The “ndp” is a protocol based on broadcasting, since PPP is not
“broadcastable”, that’s why you don’t get informations from the
otherside.

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is “nameloc” on QNX 4 is also not 100% reliable.
(it also based on a broadcast to populate the name space)

A “nameloc” on Qnx6 is very easy to write, the story is how
reliable it could be, and weather we should move that part
into QNET (or leave it a stand along process).

OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over a
networked system? So we are urged to use a resource manager, but how? Should
we write a QNX6 version of nameloc?

We difinitly don’t want to abandon the “name location” concept.

I will let others comment how to improve resmgr performance.

-xtang

–

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/

99

Hi,
We have developed a real-time application in QNX 4.25.
But, I guess QNX will stop supporting QNX 4.25 from 2005. Where can we find
some information on how to
port code from 4.25 to RTP if in the future we decide to
move to QNX RTP.

Thank you,
Shashank

100

Shashank <sbalijepalli@precitech.com> wrote:

Hi,
We have developed a real-time application in QNX 4.25.
But, I guess QNX will stop supporting QNX 4.25 from 2005. Where can we find
some information on how to
port code from 4.25 to RTP if in the future we decide to
move to QNX RTP.

Wow, today is “shameless plug day” :slight_smile:

Visit www.parse.com, and look at the “Getting Started with QNX Neutrino book”
on that site. There’s a table of contents, as well as a sample chapter.
One of the latter chapters in the book talks about QNX 4 → Neutrino
migration…

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.