Watcom and QNX [Repost from news.scitechsoft.com]

at least give us poor QNX4 slobs a break :wink:

regards,
rick

Kendall Bennett <KendallB@scitechsoft.com> wrote:

Ulrich Schemmel wrote:

does the current Watcom compiler supports QNX?
I’ve read it on many pages but on the watcom feature
page > http://www.openwatcom.org/product/features_content.html
there is no word about QNX.

No, we do not support QNX in 11.0c or Open Watcom 1.0. I have requested
repeatedly since early 2000 that QNX work with us to get support for QNX
4 and QNX 6 into Open Watcom, but to no avail. In order to support QNX
with Open Watcom, we need the QNX specific C runtime library components
that were owned wholly by QNX. Without that, it cannot be supported and
to date QNX has not responded to any of my requests about whether they
will consider releasing this code (no response either yes or not actually).

Perhaps someone at QNX or who has better contact at QNX can mention that
Open Watcom 1.0 is out, and that we would very much like to support QNX
with this compiler (QNX4 initially, but QNX6 would be nice also)?

Rick Lake <rwlake@spamfree.domain.invalid> wrote:

at least give us poor QNX4 slobs a break > :wink:

regards,
rick

Kendall Bennett <> KendallB@scitechsoft.com> > wrote:
Ulrich Schemmel wrote:

does the current Watcom compiler supports QNX?
I’ve read it on many pages but on the watcom feature
page > http://www.openwatcom.org/product/features_content.html
there is no word about QNX.

No, we do not support QNX in 11.0c or Open Watcom 1.0. I have requested
repeatedly since early 2000 that QNX work with us to get support for QNX
4 and QNX 6 into Open Watcom, but to no avail. In order to support QNX
with Open Watcom, we need the QNX specific C runtime library components
that were owned wholly by QNX. Without that, it cannot be supported and
to date QNX has not responded to any of my requests about whether they
will consider releasing this code (no response either yes or not actually).

Perhaps someone at QNX or who has better contact at QNX can mention that
Open Watcom 1.0 is out, and that we would very much like to support QNX
with this compiler (QNX4 initially, but QNX6 would be nice also)?

WOW!

Thanks Rick for this cross post.

We all know that there have been many arguments about the inferiority
of the GNU compiler compared to the QNX4/Watcom compiler. I understand
that QSSL is now multi-platform and that supporting that is a big
concern. BUT . . . .

Having worked for so long in the QNX4 environment and now working with
QNX6 and seeing the performance difference (granted, on X86 only
platforms), I’d like to beg QSSL to reconsider helping the porting
effort. Really I have no doubt that after they got the QNX6/X86
version working they would love to also support the other hardware
platforms.

Let me start the ball rolling. I’d like to donate $500.00 US out of
my own pocket for starters to anyone that can make this port happen. If
we can get 1000 other sponsors to do the same, that’s a half a million
dollar incentive to whoever the powers-that-be are to start this project.

Look at it this way. I’ll bet, that recompiling the whole OS with
Watcom will instantly improve system performance by 20%. (Personally
I would anticipate closer to 100%).


Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net

I’ve read multilple places that QNX is NOT an open source
OS. Asking for the C runtime lib source, especially for QNX4,
is probably not going anywhere.

Rick Lake <rwlake@spamfree.domain.invalid> wrote:

at least give us poor QNX4 slobs a break > :wink:

regards,
rick

Kendall Bennett <> KendallB@scitechsoft.com> > wrote:
Ulrich Schemmel wrote:

does the current Watcom compiler supports QNX?
I’ve read it on many pages but on the watcom feature
page > http://www.openwatcom.org/product/features_content.html
there is no word about QNX.

No, we do not support QNX in 11.0c or Open Watcom 1.0. I have requested
repeatedly since early 2000 that QNX work with us to get support for QNX
4 and QNX 6 into Open Watcom, but to no avail. In order to support QNX
with Open Watcom, we need the QNX specific C runtime library components
that were owned wholly by QNX. Without that, it cannot be supported and
to date QNX has not responded to any of my requests about whether they
will consider releasing this code (no response either yes or not actually).

Perhaps someone at QNX or who has better contact at QNX can mention that
Open Watcom 1.0 is out, and that we would very much like to support QNX
with this compiler (QNX4 initially, but QNX6 would be nice also)?

Fair enough. But Kendall is only asking for the QNX specific RTL stuff.
Not the whole OS. Hell, maybe they can work something out without having
to release any code. Like a detailed description of what certain routines
do and the kernel calls needed to interface with the rest of the OS. (Just
brainstorming here, tho…) Incidently, I think that’s more or less what
they (Open Watcom Team) did to get Linux supported: Since the gcc RTL code
was too complicated, they built there own RTL just using the Linux trap
calls.

regards,
rick

liug <liug@mama.indstate.edu> wrote:

I’ve read multilple places that QNX is NOT an open source
OS. Asking for the C runtime lib source, especially for QNX4,
is probably not going anywhere.

Rick Lake <> rwlake@spamfree.domain.invalid> > wrote:
at least give us poor QNX4 slobs a break > :wink:

regards,
rick

Kendall Bennett <> KendallB@scitechsoft.com> > wrote:
Ulrich Schemmel wrote:

does the current Watcom compiler supports QNX?
I’ve read it on many pages but on the watcom feature
page > http://www.openwatcom.org/product/features_content.html
there is no word about QNX.

No, we do not support QNX in 11.0c or Open Watcom 1.0. I have requested
repeatedly since early 2000 that QNX work with us to get support for QNX
4 and QNX 6 into Open Watcom, but to no avail. In order to support QNX
with Open Watcom, we need the QNX specific C runtime library components
that were owned wholly by QNX. Without that, it cannot be supported and
to date QNX has not responded to any of my requests about whether they
will consider releasing this code (no response either yes or not actually).

Perhaps someone at QNX or who has better contact at QNX can mention that
Open Watcom 1.0 is out, and that we would very much like to support QNX
with this compiler (QNX4 initially, but QNX6 would be nice also)?

“Rick Lake” <rwlake@spamfree.domain.invalid> wrote in message
news:b2ecup$2v2$1@inn.qnx.com

at least give us poor QNX4 slobs a break > :wink:

regards,
rick

[snip]

I’v tested OpenWatcom both source code and binary runtimes under win2k and
found the following:

  1. Released OpenWatcom v1.0 Beta used with headers and libs from Watcom
    10.6B can produce fine QNX4 ELF executables. And they really works under QNX
    4.25. I bet this was the reason why folks told about “QNX4.25 support ELFs
    now”. Though i couldn’t make a workable ELF executables with Watcom 10.6 but
    wlink from OpenWatcom works perfect.

  2. It’s quite portable under QNX4 using Watcom 10.6. Some stuff already
    ported.

Mine conclusion is:

If you have libraries and headers from Watcom 10.6 for QNX4, you can always
freely download runtimes for OpenWatcom and build a custom cross-platform
development environment for QNX4. Choose Windows NT or OS/2 or DOS or
whatever you like and OpenWatcom RT support. From this POV you don’t need
Watcom 10.6 executables anymore.

Well, that is all. Personally i’v dropped porting OpenWatcom under QNX4 just
dut to luck of time [and actuall need].
Cannot say atm anything about pair OpenWatcom + QNX6 but i guess it’s
possibly.

// wbr

“liug” <liug@mama.indstate.edu> wrote in message
news:b2eedp$437$1@inn.qnx.com

I’ve read multilple places that QNX is NOT an open source
OS. Asking for the C runtime lib source, especially for QNX4,
is probably not going anywhere.

I agree, and do not forget that “watcom 11” would become a competitor to the
version 105. that QSS sells… I\m not sure QSS is ready to give up on that
source of income what ever that maybe :wink:

Rick Lake <> rwlake@spamfree.domain.invalid> > wrote:
at least give us poor QNX4 slobs a break > :wink:

regards,
rick

Kendall Bennett <> KendallB@scitechsoft.com> > wrote:
Ulrich Schemmel wrote:

does the current Watcom compiler supports QNX?
I’ve read it on many pages but on the watcom feature
page > http://www.openwatcom.org/product/features_content.html
there is no word about QNX.

No, we do not support QNX in 11.0c or Open Watcom 1.0. I have requested
repeatedly since early 2000 that QNX work with us to get support for
QNX
4 and QNX 6 into Open Watcom, but to no avail. In order to support QNX
with Open Watcom, we need the QNX specific C runtime library components
that were owned wholly by QNX. Without that, it cannot be supported and
to date QNX has not responded to any of my requests about whether they
will consider releasing this code (no response either yes or not
actually).

Perhaps someone at QNX or who has better contact at QNX can mention
that
Open Watcom 1.0 is out, and that we would very much like to support QNX
with this compiler (QNX4 initially, but QNX6 would be nice also)?

Actually I did this using Watcom 11.0 on a win95 system. (Before the
Open-Watcom days.) The executables ran OK on the target QNX4 system. The
biggest drawback, however, is that you’re not self-hosted. So you either
have to boot back and forth or use two computers to develope.

regards,
rick

Ian Zagorskih <ianzag@megasignal.com> wrote:

“Rick Lake” <> rwlake@spamfree.domain.invalid> > wrote in message
news:b2ecup$2v2$> 1@inn.qnx.com> …
at least give us poor QNX4 slobs a break > :wink:

regards,
rick


[snip]

I’v tested OpenWatcom both source code and binary runtimes under win2k and
found the following:

  1. Released OpenWatcom v1.0 Beta used with headers and libs from Watcom
    10.6B can produce fine QNX4 ELF executables. And they really works under QNX
    4.25. I bet this was the reason why folks told about “QNX4.25 support ELFs
    now”. Though i couldn’t make a workable ELF executables with Watcom 10.6 but
    wlink from OpenWatcom works perfect.

  2. It’s quite portable under QNX4 using Watcom 10.6. Some stuff already
    ported.

Mine conclusion is:

If you have libraries and headers from Watcom 10.6 for QNX4, you can always
freely download runtimes for OpenWatcom and build a custom cross-platform
development environment for QNX4. Choose Windows NT or OS/2 or DOS or
whatever you like and OpenWatcom RT support. From this POV you don’t need
Watcom 10.6 executables anymore.

Well, that is all. Personally i’v dropped porting OpenWatcom under QNX4 just
dut to luck of time [and actuall need].
Cannot say atm anything about pair OpenWatcom + QNX6 but i guess it’s
possibly.

// wbr

Mario Charest postmaster@127.0.0.1 wrote:

“liug” <> liug@mama.indstate.edu> > wrote in message
news:b2eedp$437$> 1@inn.qnx.com> …

I’ve read multilple places that QNX is NOT an open source
OS. Asking for the C runtime lib source, especially for QNX4,
is probably not going anywhere.

I agree, and do not forget that “watcom 11” would become a competitor to the
version 105. that QSS sells… I\m not sure QSS is ready to give up on that
source of income what ever that maybe > :wink:

I have two issues with that. First, how much QNX4 anything is QSSL
still selling? I’m guessing that you can buy the stuff on E-Bay for
pennies on the dollar. (No, I haven’t looked. But I do remember the
post last week about QNX2 on E-Bay.)

Secondly, if that were an issue for QSSL, why don’t they get behind the
new Open Watcom and finagle a way to sell it. I’m sure they can find
some legal loophole.

Third, (OK, I never said I could count), what I really want to see is
Watcom for QNX6!!!


Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net

Bill Caroselli <qtps@earthlink.net> wrote:

Mario Charest postmaster@127.0.0.1 wrote:

“liug” <> liug@mama.indstate.edu> > wrote in message
news:b2eedp$437$> 1@inn.qnx.com> …

I’ve read multilple places that QNX is NOT an open source
OS. Asking for the C runtime lib source, especially for QNX4,
is probably not going anywhere.

I agree, and do not forget that “watcom 11” would become a competitor to the
version 105. that QSS sells… I\m not sure QSS is ready to give up on that
source of income what ever that maybe > :wink:

I have two issues with that. First, how much QNX4 anything is QSSL
still selling? I’m guessing that you can buy the stuff on E-Bay for
pennies on the dollar. (No, I haven’t looked. But I do remember the
post last week about QNX2 on E-Bay.)

Secondly, if that were an issue for QSSL, why don’t they get behind the
new Open Watcom and finagle a way to sell it. I’m sure they can find
some legal loophole.

Third, (OK, I never said I could count), what I really want to see is
Watcom for QNX6!!!

Maybe Eric should say something here? :slight_smile:

Watcom is x86-only, so that would severly limit the general applicability
of the work – right now, QSSL has to support one compiler with two
libraries (as I understand the GCClib vs Dinkum stuff). Let’s not
throw in a third library and a second compiler!

Cheers,
-RK


Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net


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.

Mario Charest postmaster@127.0.0.1 wrote:

“liug” <> liug@mama.indstate.edu> > wrote in message
news:b2eedp$437$> 1@inn.qnx.com> …

I’ve read multilple places that QNX is NOT an open source
OS. Asking for the C runtime lib source, especially for QNX4,
is probably not going anywhere.

I agree, and do not forget that “watcom 11” would become a competitor to the
version 105. that QSS sells… I\m not sure QSS is ready to give up on that
source of income what ever that maybe > :wink:

This is a perfectly valid strategy of QSS. But my point is that the
release is stuck at 10.6 on QNX4. There are two options for progress:
either release the source or continue to support it.

OK, there’s a third option: push QNX6. But unfortunately our management
has dropped QNX in favor of Solaris and/or Linux, and is slowly fasing out
the 160+ QNX OS licenses we bought. So for me, being a big fan of QNX,
it’s either keep developing QNX4 programs, or switch to another OS.

regards,
rick

Robert Krten <nospam84@parse.com> wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:
Third, (OK, I never said I could count), what I really want to see is
Watcom for QNX6!!!

ducking>Maybe Eric should say something here? > :slight_smile:> </ducking

Watcom is x86-only, so that would severly limit the general applicability
of the work – right now, QSSL has to support one compiler with two
libraries (as I understand the GCClib vs Dinkum stuff). Let’s not
throw in a third library and a second compiler!

Why the *&%# NOT?!?! Better yet, Why should they?

I don’t see why the Watcom compiler can’t support the same libraries
that exist now. However, I do believe that it was their register
calling convention that gained them so much of their speed. SO it
would be nice it they support/offered a (yes) third set of libraries
that used the register calling conventions.

Also, I don’t think that the Watcom compiler is strictly married to
the X86 architecture. Sure the QNX one was, but Watcom has written
compilers for mainframes long before they got into the PC compiler
business.

Rick Lake <rwlake@spamfree.domain.invalid> wrote:

at least give us poor QNX4 slobs a break > :wink:

regards,
rick

While I agree (see my other post), I do have a question.

With Watcom V11.0 you could not code a line like:
char buffer[1000], *cp;
The compiler would barf about trying to define two different data types
in the same statement. That P&##ed me off to no end, and it completely
invalidated all of QSSL’s header files.

Is that still not allowed in the Open Watcom version?

I see no symantical reason for this to be the case.

Bill Caroselli <qtps@earthlink.net> wrote:

Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
Third, (OK, I never said I could count), what I really want to see is
Watcom for QNX6!!!

ducking>Maybe Eric should say something here? > :slight_smile:> </ducking

Watcom is x86-only, so that would severly limit the general applicability
of the work – right now, QSSL has to support one compiler with two
libraries (as I understand the GCClib vs Dinkum stuff). Let’s not
throw in a third library and a second compiler!

Why the *&%# NOT?!?! Better yet, Why should they?

I don’t see why the Watcom compiler can’t support the same libraries
that exist now. However, I do believe that it was their register
calling convention that gained them so much of their speed. SO it
would be nice it they support/offered a (yes) third set of libraries
that used the register calling conventions.

Are you going to support the libraries? Remember, for the normal
libraries, like open(), you still have to do all the client-side
resource manager magic. That’s not something you can just guess
at, so someone who controls both ends of the open() (i.e., the resmgr
library as well as open()) needs to do the maintenance of both.

If you want to use the same libraries as GCC, then it’s a licensing
issue, and I will politely decline to comment :slight_smile:

Also, I don’t think that the Watcom compiler is strictly married to
the X86 architecture. Sure the QNX one was, but Watcom has written
compilers for mainframes long before they got into the PC compiler
business.

Excellent! I just knew the PDP-10 / IBM-370 version of Neutrino
was just around the corner!

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.

Although an interesting issue, if it’s a fact, your question is a little
OT in this thread. (Perhaps you can bring this up on the
news.scitechsoft.com newsserver where the OW team lives?)

Unless your point was that moving on to V11.0 introduces new bugs? In that
case, I’d assume this would eventually get resolved, since we would be
moving on anyway (in the hypotetical case). (And very quickly too, since
that particular statement seems perfectly legal to me.)

regards,
rick

[If I didn’t quite catch your drift, please clarify]

Bill Caroselli <qtps@earthlink.net> wrote:
[…]

While I agree (see my other post), I do have a question.

With Watcom V11.0 you could not code a line like:
char buffer[1000], *cp;
The compiler would barf about trying to define two different data types
in the same statement. That P&##ed me off to no end, and it completely
invalidated all of QSSL’s header files.

Is that still not allowed in the Open Watcom version?

I see no symantical reason for this to be the case.

Robert Krten <nospam84@parse.com> wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
I don’t see why the Watcom compiler can’t support the same libraries
that exist now. However, I do believe that it was their register
calling convention that gained them so much of their speed. SO it
would be nice it they support/offered a (yes) third set of libraries
that used the register calling conventions.

Are you going to support the libraries? Remember, for the normal
libraries, like open(), you still have to do all the client-side
resource manager magic. That’s not something you can just guess
at, so someone who controls both ends of the open() (i.e., the resmgr
library as well as open()) needs to do the maintenance of both.

cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c

-David

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

David Gibbs <dagibbs@qnx.com> wrote:

Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
I don’t see why the Watcom compiler can’t support the same libraries
that exist now. However, I do believe that it was their register
calling convention that gained them so much of their speed. SO it
would be nice it they support/offered a (yes) third set of libraries
that used the register calling conventions.

Are you going to support the libraries? Remember, for the normal
libraries, like open(), you still have to do all the client-side
resource manager magic. That’s not something you can just guess
at, so someone who controls both ends of the open() (i.e., the resmgr
library as well as open()) needs to do the maintenance of both.

cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c

As I said, I defer the legal questions to the experts – can I publish
this as anything other than “free for noncommercial”? :slight_smile:

Cheers,
-RK

-David

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


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.

“Rick Lake” <rwlake@spamfree.domain.invalid> wrote in message
news:b2gq1j$qv9$1@inn.qnx.com

Actually I did this using Watcom 11.0 on a win95 system. (Before the
Open-Watcom days.) The executables ran OK on the target QNX4 system. The
biggest drawback, however, is that you’re not self-hosted. So you either
have to boot back and forth or use two computers to develope.

Sure, but the one difference between Watcom 11 and OpenWatcom is that first
is a commercial product (at least was) and the second is free and open
sourced now.

Sure, Watcom 11 could produce a workable ELFs for QNX4.25 same as OpenWatcom
does now. And would be odd if things had changed just due to the fact that
OpenWatcom is a continuation of v11 line :slight_smile:

// wbr

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b2gq9d$opq$3@inn.qnx.com

Mario Charest postmaster@127.0.0.1 wrote:

“liug” <> liug@mama.indstate.edu> > wrote in message
news:b2eedp$437$> 1@inn.qnx.com> …

I’ve read multilple places that QNX is NOT an open source
OS. Asking for the C runtime lib source, especially for QNX4,
is probably not going anywhere.

I agree, and do not forget that “watcom 11” would become a competitor to
the
version 105. that QSS sells… I\m not sure QSS is ready to give up on
that
source of income what ever that maybe > :wink:

I have two issues with that. First, how much QNX4 anything is QSSL
still selling? I’m guessing that you can buy the stuff on E-Bay for
pennies on the dollar. (No, I haven’t looked. But I do remember the
post last week about QNX2 on E-Bay.)

Severay days ago i saw a package “Watcom 10.6 C/C++ Compiler” on E-Bay.
Price was… 9.95$USD :slight_smile: And no additional bids…

// wbr

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:b2h9t9$9h8$1@nntp.qnx.com

Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
I don’t see why the Watcom compiler can’t support the same libraries
that exist now. However, I do believe that it was their register
calling convention that gained them so much of their speed. SO it
would be nice it they support/offered a (yes) third set of libraries
that used the register calling conventions.

Are you going to support the libraries? Remember, for the normal
libraries, like open(), you still have to do all the client-side
resource manager magic. That’s not something you can just guess
at, so someone who controls both ends of the open() (i.e., the resmgr
library as well as open()) needs to do the maintenance of both.

cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c

David, isn’t this CVS old as a dinosaur ? Is it propertly been maintained,
updated and so on ?

// wbr

Ian Zagorskih <ianzag@megasignal.com> wrote:

cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c


David, isn’t this CVS old as a dinosaur ? Is it propertly been maintained,
updated and so on ?

Yes it is old. But, it might still give someone making a QNX compatible
C library a good start. (And indication of how some of that “magic”
works.)

-David

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