On 13 Feb 2003 19:24:54 GMT, Bill Caroselli wrote:
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.
I just tried the following program with Openwatcom, and it compiled and ran
fine, so I guess it is OK.
#include <stdio.h> #include <string.h>
int main(int argc, char *argv[]);
int main(int argc, char *argv[])
{
char buffer[1000], *cp;
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.)
To make OpenWatcom able to produce code for a new target (OS / CPU
combination), the following things are needed:
CPU support. Intel etc is OK, Alpha probably OK, PPC not complete I think,
IBM 370 very old.
OS support. In order to port (not make, 90% is OS-independent) Watcom libs
for an OS the OS interface has to be known, e.g in DOS INT21 and BIOS calls,
in Linux int 80 etc. This interface needs to be documented, but freely
available code might do. This is what is being done for Linux. Additionally,
the executable format has to be supported by the linker. If QNX runs ELF
executables this might be OK already. And finally and importantly, the
debugger interface is needed.
If the libs are OK, then cross-compiling will work for non-GUI programs,
such as the basic compilers/make/linker/character based debugger; hence you
can produce QNX versions of these on DOS\OS/2\Win32 and run them on QNX : you
then have native tools which can compile themselves.
GUI support requires more work, the Watcom GUI library needs to be adapted
to the platform’s GUI interface. Once that is done, graphical tools (GUI
debugger, IDE, profiler, installer) will also run natively.
One thing to keep in mind is the license; OW is NOT GPL’d and will not accept
GPL code. However, if information is publicly available, header files can be
constructed (typed in) from these, like the MinGW project’s win32 API headers
which are used in OW.
There was a link to a cvs. Is that information public? If that contains
enough of the OS interface to port the OW libs that may be all that is
needed. Is that QNX4? If so, is the OS interface for QNX6 more or less the
same?
If someone is willing to undertake or contribute to the port, please visit news.openwatcom.org, the openwatcom.contributors group. We’ll help you on
your way as best as we can. A very quick starter: a) get the OW for your
platform, install and build some samples to make sure it is installed OK; b)
get and install the OW source, read some of the readme in the root dir, set
the vars, in bld run “builder build os_nt” (or whatever platform you want to
build) to make sure all is OK; c) in bld, do a “clean”, then do a 'builder
build os_qnx" , and start fixing the errors (mostly missing headers).
Just a comment on the register calling convention. I believe that
this big speed advantage has decreased in the later processors, PIII
and PIV so there might not be as big an advantage as you think.
There was a link to a cvs. Is that information public?
Yes. Released under ‘QNX community license’ I believe.
If that contains
enough of the OS interface to port the OW libs that may be all that is
needed.
Yes. The QNX equivalent to the ‘int80’ is a message to process manager, most
of the time. Plus about 40 kernel calls, which are implemented by assembler
code autogenerated from kercalls.h by mkkercalls.c (also in CVS). The libc
code is for QNX6.1 and while that is a bit old, is still perfectly enough to
see how to format the messages and how to interpret the replies.
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.
The QNX specific portions of the C runtime library are actually quite
small. Most of the Watcom runtime library works as is with QNX, but it
relies upon calling into QNX specific code that needs to interface to
the kernel etc (QNX’s message passing mechanism).
Hence there is really not that much code in the QNX specific runtime
library I don’t think, and certainly nothing that is rocket science and
doesn’t already exist in other forms on other Open Source platforms (ala
Linux and FreeBSD).
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 >
When we were in the process of Open Sourcing the Watcom compilers with
Sybase, I tried to involve QNX in this so that they would have the
option of distributing their own ‘commercial’ variants of the compiler
but got no response. Even with the current Open Source license there is
no reason why Open Watcom for QNX 4 and QNX 6 cannot be sold and
supported by QSSL for their customer - the only requirement is that all
the source code be available for the compiler.
Considering that they are currently using GCC which has an even more
restrictive license (GNU GPL), they already have to release the source
code for the compiler tools they use anyway!
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.
I had a v11.0b compile environment set up, and it mostly worked. I had
trouble with some of the C runtime library stuff myself, so I gave up on
the whole idea and stuck to 10.6 for our development.
For me though I always cross compile from a separate machine to my test
machine (usually Windows XP these days, but I am considering a Linux or
FreeBSD platform when we get Open Watcom running there ), so cross
compiling QNX apps for me was always a benefit
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!
Actually Watcom is not x86-only. There is already a complete DEC Alpha
compiler that was going into alpha testing status right when Sybase
cancelled the compiler. There are also initial ports of MIPS and PowerPC
compilers in the Open Watcom code base already, both ports of which were
started but never completed by Watcom/PowerSoft/Sybase.
One point worth mentioning also is that Watcom never was an x86
compiler. It existed long ago on non-x86 platforms before it was ever
ported to the PC platform, so it has always had a clean non-CPU specific
structure internally. Hence doing ports of the Open Watcom compiler to
support other CPU targets is not a pipe dream!
Although I gather this is old code, I assume this for QNX 6 and not QNX
4? But it could be used to build a QNX 6 C runtime library for Open
Watcom, right?
BTW, is there somewhere I can get a tarball of this code from to play
around with? I don’t know how to use the CVSWeb stuff much (I prefer
Perforce).
Although I gather this is old code, I assume this for QNX 6 and not QNX
4? But it could be used to build a QNX 6 C runtime library for Open
Watcom, right?
BTW, is there somewhere I can get a tarball of this code from to play
around with? I don’t know how to use the CVSWeb stuff much (I prefer
Perforce).
Considering that they are currently using GCC which has an even more
restrictive license (GNU GPL), they already have to release the source
code for the compiler tools they use anyway!
Although I gather this is old code, I assume this for QNX 6 and not QNX
4? But it could be used to build a QNX 6 C runtime library for Open
Watcom, right?
This is QNX 6.1 code. (Definitely not QNX 4.) I expect it would give
a mostly compatible library for 6.2 – there may be bug fixes since it
was posted, but the core message and kernel calls should be pretty
consistent.
Although I gather this is old code, I assume this for QNX 6 and not QNX
4? But it could be used to build a QNX 6 C runtime library for Open
Watcom, right?
This is QNX 6.1 code. (Definitely not QNX 4.) I expect it would give
a mostly compatible library for 6.2 – there may be bug fixes since it
was posted, but the core message and kernel calls should be pretty
consistent.
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.
I’v tested OpenWatcom both source code and binary runtimes under win2k
and
found the following:
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.
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.
I think Ian’s follow-up gives you more hope that mine. Sorry. All I did
then was produce a qnx binary just to see if It’s possible. Didn’t do much
sophisticated work in that area. But perhaps the OpenWatcom guys can give
you more tips.
what’s abaout cross debugging from the ms box the qnx target?
I do that all the time with Watcom 10.6 from Windows to QNX. All you
need to do is copy across the QNX runtime libraries and headers from
your QNX development machine to your Windows box, and then you can
compile QNX apps. Using the tcp.dll for NT will allow you to connect to
tcpserv under QNX.
what’s abaout cross debugging from the ms box the qnx target?
I do that all the time with Watcom 10.6 from Windows to QNX. All you
need to do is copy across the QNX runtime libraries and headers from
your QNX development machine to your Windows box, and then you can
compile QNX apps. Using the tcp.dll for NT will allow you to connect to
tcpserv under QNX.
When i use wd + tcp.dll, wd displays an error dialog “Incorrect version of
debugger server” and stops.
Versions are: OpenWatcom 1.0 released distribution under Windows2000 SP2,
tcpserv from Watcom 10.6 PatchB, QNX 4.25 PatchG
When i use wd + tcp.dll, wd displays an error dialog “Incorrect version
of
debugger server” and stops.
Versions are: OpenWatcom 1.0 released distribution under Windows2000
SP2,
tcpserv from Watcom 10.6 PatchB, QNX 4.25 PatchG
That is the expected behaviour. You can’t mix 10.6 and OW 1.0 (or
Watcom 11.0x) in this way. You’d need 10.6 on the Windows side.
I just wanted to say that ATM i cannot use OpenWatcom 1.0 for Win32 to debug
QNX4 applications remotely across TCP/IP. Guess same’s with serial and
parallel servers.
But it can be used to build QNX4 executables [with libraries and header
files from Watcom 10.6].
