Hi, I have access to some live QNX4 systems (original hardware from 20 years ago) and I wanted to compile/install some more software on them. I have two questions:
(1) from old posts, it looks like there used to be some free software (GNU, etc.) hosted on ftp.qnx.com. Are those files still available somewhere else. Or does the openqnx community have something similar available today?
(2) Does anybody have a drop-in stdint.h that I could use with watcom compiler on QNX4? I have some modern POSIX compatible software that would compile if I could provide a stdint.h.
Thank you, I’ve downloaded that template and will look at that. For the other links, I don’t have qnx.com login yet, but will look into that.
As to your question: I’m mainly interested in what additional development tools like editors, compilers, interpreters, and scripting languages might be available. Ideally free-software (GNU, etc). Vedit is not too bad, actually, but I read in an old post here that there was a build of Emacs for QNX4 available, which would be cool
The other day I tried to compile PForth on one of the boxes, and I got pretty close I think except that there was no stdint.h on the QNX system.
WRT (1) I have a working QNX 4 system. If there is something specific you are looking for I would be happy to send it to you.
If you try to demo some simple codes, you should use “vedit” ultility for editting in command line.
If you have Photon (QNX GUI), you should use “ped”, it has friendly GUI for editting.
QNX4 has PhAB, which is a good GUI application builder, including design and build (compile via WCC, and not include editting, debuging, etc ).
For me, I compose source codes in Notepad++ (in Windows host), then transfer them to QNX4 machine and compile there later.
maschoen, these are things I’m interested in at the moment:
- what C compilers do you have? I was wanting to compile some modern software but need something with C99 and POSIX support. The watcom I have provide POSIX stuff but is pre-C99.
- Do you have a stdint.h that works on QNX4?
- If you have any Forth or Lisp systems that runs on QNX4, I’d be interested in that.
- an Emacs or an Emacs-like editor (e.g., Mg) built for QNX4
I only have the Watcom compiler. I don’t remember any other C compiler for QNX 4.
I will take a look for stdint.h. I don’t think there is one. I’ve dealt with this kind of porting issue all the time and never had much troubling building that kind of include file by just compiling and seeing what is missing. There is another minor issue. QNX4 ran both 16 and 32 bit executables. I suspect that stdint.h would be different for each of them. Unlike 64bit where ints are still 32 bit, In 16 bit you get 16 bit ints and in 32bit you get 32. I think both of them have 32bit for longs.
I don’t know of any Forth or Lisp for QNX4. As far as Lisp goes, I’ll bet there is open source around somewhere but it might be a serious project to get it ported. The Forth’s I knew of were usually written in assembler so not very likely to port at all.
I don’t know about Emacs or vi. There is no doubt open source for them, but the port might be another big project.
A lot of people liked the editor that came with Watcom. There was also ped (I think) if you are using Photon. It also supported my favorite editor, qed. Qed was around for QNX6. QNX had a port to Windows that I’d love to get my hands on. I have a port of it to QNX 7.1 and a somewhat shaky version that runs on Linux.
I’m going to have some free time in the next month or so. Tell me which of those programs, Emacs, Lisp, etc. you would most like to see. While you are at it, maybe send me an email at email@example.com.
Post googling, wow there are a lot of different Lisp implementations:
I found Emacs source easily.
If you are interested in Forth, take a look here:
Isn’t JED available for QNX 4?
It has an EMACS emulation mode and even if it’s not currently available it might be a lot easier to port than EMACS.
maschoen, I’ve put a few hours of work into trying to port pForth, the portable Forth implementation. It has been difficult though. The main problem is pForth assumes lots of C99 stuff, including the presence of stdint.h, whereas my watcom is pre-C99. I dropped in pstdint.h from the Internet, but still ran into a bunch of issues related to uint64_t. Also some issues with compiler syntax, modern termios extensions, and select() versus poll(). Was able to make progress by commenting out some pForth functionality, but I still haven’t succeed yet in getting it to fully compile.
I’ll send you an e-mail. Check your spam folder, though, as my address has the word “hacker” in it.
I got your email. I guess you know this but I can confirm that the Watcom compiler did not have a stdint.h
This reminds me of a period in history that I lived through. The original intention of the developers of C was that int would be the standard register size of a processor. There existed system with lots of different sizes of registers, The idea of stdint.h came about gradually. Initially if you wrote code that required a specific sized int you just used the right primitive, eg. char, int, long. If you were porting between different width systems you just bit the bullet and changed everything you needed to. The idea have a uint16_t or uint32_t made a lot of sense (to me) where it was needed. But then it started showing up as some kind of standard. I saw code that had nothing but typedef’d ints. Sorry if I offend anyone but I found this stupid.
The only issue until 64 bit arrived was 16 vs. 32 bit. In a 16 bit system an int was 16 bit and a long was 32 bit. In a 32 bit system 16 bit was a short int and 32 was an int. That was it. With 64 bit and Microsoft throwing its weight around making an int still 32 bit the only need for attention is when you really want 64 bits.
If you want some help with compiling Fourth, send me a link to the source you are interested in. Also, let me know if there is a specific Lisp you would like ported.
I do a lot of driver writing and there are circumstances when you want to be explicit about the width of a variable if just for clarity. If you are using structures that need to be passed between programs or systems it might also make sense. One does have to pay attention to packing issues. That said, I’m hard pressed to remember a situation since we went to 32 bit where this is needed or valuable in an application.
OK, I’m just ranting. Typed ints are so ubiquitious that there’s no going back.
Hi, maschoen, I spent a few hours trying to get pforth to compile:
It seemed like a good starting place since it was aiming to be portable and to use C and POSIX on the backend. I made lots of progress but didn’t quite pull off a successful compile yet. The main problem is it is pforth assumes a lot of C99 stuff, plus also some modern extensions or substitutions to the POSIX stuff. It needs a provided stdint.h. Ran into a lot of trouble with uint64 but was able to get around it by commenting out a few pforth words (functions). It also needs libm but only for one or two forth words which are not critical.