mc/doc/README.QNX

Midnight Commander for QNX (not QNX Neutrino)
---------------------------------------------

1. Compiling
2. Running 'mc' under QNX
3. List of modifications on mc-4.1.33
4. TODO
5. Contact information

1. Compiling
------------

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.]

1.2 Configuring
---------------

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...]

1.3 Compiler
------------

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
missing prototypes...]

1.5 Tested configuration
------------------------

QNX 4.24
Watcom C 10.6 (release version, no newer beta patches)
Photon 1.12
no TCP/IP development kit (-> VFS: tarfs only!)
mc-4.1.33, mc-4.1.34

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
  network:

        mkdir /net
        ln -sf //1/ /net/1
        ...

Extension and menu files:

  Default 'tar' uses 'stderr' (and not 'stdout' as its 'normal' output with
  '-t' option.
  
  Default 'tar' is not a GNU 'tar', so does not understand '-z' option.

Special key-mappings:

  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

'qansi*' terminals:

  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!

other terminals:

  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
-----------------------------------------------

edit/

 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*/; }".

lib/

  mc.menu:

    'Z' on 'tar.Z' and 'tar.z' files: '%f' -> '$1'.

  mc.ext.in.qnx.diff:

    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
    only QNX-specific...) 

  Makefile.in:

    'mc.ext.in.qnx.diff' added to DISTLIB.

slang/

  sldisply.c:

    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
    (->SLTT_TRANSP_ACS_PATCH).
  
    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).
   
    Remark:

    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:

        #ifdef SLTT_TRANSP_ACS_PATCH
        # if defined(__QNX__) && defined(QNX_QANSI_SLANG_COMPAT_ACS)
        #  undef SLTT_TRANSP_ACS_PATCH
        # endif
        #else
        # if defined(__QNX__) && !defined(QNX_QANSI_SLANG_COMPAT_ACS)
        #  define QNX_QANSI_SLANG_COMPAT_ACS 1
        # endif
        #endif

  slutty.c:

    "newtty.c_iflag &= ~(ECHO | INLCR | ICRNL);"

    ECHO(0x08) is a c_lflag bit, it means PARMRK(0x08) in c_iflag. (!?!)

src/

  file.c:

    'do_reget' can be extern if (ENABLE_VFS && USE_NETCODE), not if (ENABLE_VFS).

  find.c:

    search_content():
    
    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'.]
    
  key.c:

    init_key():

    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...)

  key.h:

    Declare load_xtra_key_defines().

  keyxdef.c:

    Provides a method to define some platform-specific additional key
    mappings. (e.g. QNX terminals can handle most of META-? combinations as
    ALT-?...)
    
    (Currently not listed in doc/FILES...)

  layout.c:

    TIOCGWINSZ must be available (<sys/ioctl.h> included), because window-
    resizing code doesn't work, if not defined.

  main.c:

    print_usage(): reserved name in the QNX run-time library!
    print_usage() -> print_mc_usage()

  mouse.c:

    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).

  slint.c:

    QNX: 'qansi*' terminals added to the color_terminals[] list.
    
  subshell.c:
  utilunix.c:

    QNX: include <unix.h> to get prototype for exec*()!!!
    [See README.QNX/Section 1.4!]
    
  Makefile.in:

    'keyxdef' module added to SRCS and OBJS.

vfs/

<mc-src-root>/

  README.QNX:

    QNX-specific notes...
  
  configure (line 3369):
  configure.in (line 88):

    (mc-4.1.34 only)
    'test x$CCOPTS = x;' => 'test "x$CCOPTS" = x;'

  Makefile.in:

    README.QNX added to DISTMAIN.
    
4. TODO
-------

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: gt_cosy@usa.net


-------------
Tamasi Gyorgy
-------------