» Content »pkg://mc_22.214.171.124.orig.tar.gz:4036549
/ info downloads
Midnight Commander for QNX (not QNX Neutrino)
2. Running 'mc' under QNX
3. List of modifications on mc-4.1.33
5. Contact information
1.1 Make utility
Use 'gmake'. (This is the default 'make' under QNX 4.23+). [The old 'qmake'
cannot handle the makefiles in the mc-source.]
If you don't have an installed TCP/IP development kit, you have to 'hide'
the library file 'socket3r.lib' (can be installed by e.g. Watcom C 10.6)
in /usr/lib or /usr/watcom/10.6/usr/lib, because the existence of this file
will confuse 'configure': it will erroneously assume you have the complete
TCP/IP development kit (with headers) and will enable compiling of the
network-related VFS code (not only tarfs).
[A patch would be required in the configure-script to check the existence
of the TCP/IP-related headers also...]
Use '--disable-nls' option, if you don't have the binary utilities of
GNU 'gettext' package (e.g. 'msgfmt'). ['--with-included-gettext' doesn't
really work in 4.1.33, there are configuration/compiling problems...]
It is advised to use Watcom C 10.6+ to compile the source, because older
compilers (e.g. 9.52) do not support some convenient/required features.
[e.g. 'ar'-compatible 'wlib',...]
1.4 "No prototype found for '<function>'" warnings
It is advised to use high warning level (e.g. 'CFLAGS="-w4" ./configure'),
when compiling the source, because Watcom C uses a special parameter passing
convention for functions with fixed number of arguments only. So if the
compiler doesn't see the correct prototype of a function with variable
number of arguments (like printf()), it will produce a warning about the
missing prototype, but generates function call code according to the special
parameter passing convention, not the required CDECL convention (it is used
by default for functions with variable number of arguments). So the calling
convention of the function call code and the function code itself will not
match! So you MUST provide the correct prototype for function with variable
number of arguments! (Or you can force using the stack-based calling
convention as a default, if you have the stack-call-conv version of all of the
required libraries ('<name>3s.lib')...[Watcom C 10.6 required!])
[The latest release version (4.1.33/qnx) is checked against these types of
1.5 Tested configuration
Watcom C 10.6 (release version, no newer beta patches)
no TCP/IP development kit (-> VFS: tarfs only!)
2. Running 'mc' under QNX
Using 'qnx*' terminals:
You cannot use your keyboard correctly, if you disable the "Full 8 bits
input" feature in the 'Options|Display bits...' dialog.
On 'qnx*' terminals 'mc' will run in black and white mode by default,
because these types of terminals use non-ANSI-compatible color sequences.
Accessing remote nodes via the native QNX-network:
[The problem exists under the older versions of 'mc' only...]
If directory panels cannot handle '//<node-id>' prefix in directory names,
use directory links in order to access remote nodes on the native QNX
ln -sf //1/ /net/1
Extension and menu files:
Default 'tar' uses 'stderr' (and not 'stdout' as its 'normal' output with
Default 'tar' is not a GNU 'tar', so does not understand '-z' option.
Restrictions of the META-? as Alt-? functionality:
[META-? as ESC-? will always work!!!]
Alt-TAB -> Ctrl-TAB (Alt-TAB reserved in Photon [1.12+])
Alt-ENTER -> Ctrl-ENTER ('qnx*' terminals only)
Alt-<uppercase letter>: doesn't work
Problem [QNX 4.23+ only]: screen corruption (strange line-drawing character
set handling) on 'qansi*' terminals, if linked with mc/Slang/terminfo
terminal management. (Older versions of QNX and Slang/termcap not affected.)
This problem is solved, see the comments in slang/sldisply.c about
SLTT_TRANSP_ACS_PATCH and QNX_QANSI_SLANG_COMPAT_ACS!
I have tested 'mc' under QNX on 'qnx*' and 'qansi*' terminals only.
toggle panels on/off (CTRL-o):
Currently not supported, but could be implemented later...
3. List of modifications on mc-4.1.33/mc-4.1.34
syntax.c: (4.1.33 only, fixed in 4.1.34)
line 100,191: WCC 10.6 doesn't like "<label>: }" construct ("no statement
after the label"), modified to "<label>: /*nop*/; }".
'Z' on 'tar.Z' and 'tar.z' files: '%f' -> '$1'.
QNX: modified 'mc.ext.in'. [tar -t: output to stderr,...]
(No automatic install implemented: patch must be applied before
running 'configure' [->mc.ext.in.qnx.diff!]; this patch can be not
'mc.ext.in.qnx.diff' added to DISTLIB.
SLTT_TRANSP_ACS_PATCH dependent code:
The problem: some terminals (e.g. QNX/qansi*) map the whole upper half of
the ASCII table to the lower half, when alt-char-set is activated with
the smacs/as string-sequence. This means, that if 0 <= ch < 128 written
to the terminal, it will be translated to (ch+128) automatically by the
terminal: so not only the line-drawing characters can be written, when
the alt-char-set is activated. It implicitly means, that space, NL, CR,
etc. characters (exactly: anything besides the "standard" line drawing
characters) cannot be written directly to the terminal, when the
alt-char-set is activated, because writing these characters doesn't cause
an implicit/temporary switching-back to the standard char-set!
The original code in SLang assumes that space, NL, CR, etc. can be
printed when alt-char-set is activated. If SLTT_TRANSP_ACS_PATCH is
defined, the modified code will not use this assumption.
[Remark: the patch-code is not the most exact solution, but works...]
QNX_QANSI_SLANG_COMPAT_ACS_PATCH dependent code:
A more OS/terminal-specific solution for the problem mentioned above
If QNX_QANSI_SLANG_COMPAT_ACS is defined, the default smacs/sa, rmacs/ae,
acsc/ac [and sgr/sa, if it would be used!] command sequences will be
replaced internally with the "old style" (pre-QNX 4.23) sequences in case
of QNX/qansi terminals. Using these optional command sequences the terminal
remains compatible with the original SLang code (without using the
workaround-code enabled by defining SLTT_TRANSP_ACS_PATCH).
Currently SLTT_TRANSP_ACS_PATCH is not auto-configured by 'configure'.
(Must be manually defined...)
There is some (QNX-specific) auto-configuration hand-coded in the source:
# if defined(__QNX__) && defined(QNX_QANSI_SLANG_COMPAT_ACS)
# undef SLTT_TRANSP_ACS_PATCH
# if defined(__QNX__) && !defined(QNX_QANSI_SLANG_COMPAT_ACS)
# define QNX_QANSI_SLANG_COMPAT_ACS 1
"newtty.c_iflag &= ~(ECHO | INLCR | ICRNL);"
ECHO(0x08) is a c_lflag bit, it means PARMRK(0x08) in c_iflag. (!?!)
'do_reget' can be extern if (ENABLE_VFS && USE_NETCODE), not if (ENABLE_VFS).
variable 'i' "must be" 'int', not 'char'. ["i == -1": (buggy?) WCC 10.6
doesn't convert automatically (int)(-1) to (char)(-1) (GCC does), so
"comparison result always 0" warning produced. It is cleaner to define
'i' as 'int', than cast '-1' to 'char', because 'read()' returns 'int'.]
Call load_xtra_key_defines() and clear 'use_8th_bit_as_meta' by default
under QNX, if a 'qnx*' terminal detected. (A saved config file (mc.ini)
can override it later...)
Provides a method to define some platform-specific additional key
mappings. (e.g. QNX terminals can handle most of META-? combinations as
(Currently not listed in doc/FILES...)
TIOCGWINSZ must be available (<sys/ioctl.h> included), because window-
resizing code doesn't work, if not defined.
print_usage(): reserved name in the QNX run-time library!
print_usage() -> print_mc_usage()
QNX: ncurses 1.9.8a ported to QNX doesn't provide the 'SP' pointer as a
global symbol in the library, so the keyok() emulation currently cannot
be used under QNX (4.24 & Watcom C 10.6 release version).
QNX: 'qansi*' terminals added to the color_terminals list.
QNX: include <unix.h> to get prototype for exec*()!!!
[See README.QNX/Section 1.4!]
'keyxdef' module added to SRCS and OBJS.
'install' target: 'mcserv' not installed, if net-code not enabled
configure (line 3369):
configure.in (line 88):
'test x$CCOPTS = x;' => 'test "x$CCOPTS" = x;'
README.QNX added to DISTMAIN.
Because of limited time and resources now I can define a 'wish list' only:
(maybe somebody in the QNX community can help...)
subshell support with panel switch on/off ?
mouse under Photon (with qnxm, qansi-m terminals) ?
5. Contact information
Please report QNX-specific bugs and comments via e-mail to: email@example.com