Frequently Asked Questions

General questions:

Build questions:

Why when building within the MSVC environment things aren't found?

Behaviour questions:

FreeBSD questions:

General Questions:

What is this "Tn" I keep seeing mentioned everywhere?

TnFOX was forked from FOX to provide the portability library for Tn in May 2003. It was and is greatly hoped that TnFOX would find remit outside this core function.

As can be guessed by TnFOX's description - "TnFOX is a modern secure, robust, multithreaded, exception aware, internationalisable, portable GUI toolkit library designed for mission-critical work in C++ and Python" - Tn is also all those things, however it is also far, far more.

Tn came from the "Tornado" project, a name I had to drop thanks to Wind River Systems. I was most sorry to do so as it is a very apposite name - it engenders "revolution", "speed", "dynamism", "unpredictability" and it also means exactly the same thing in Spanish. All these things Tn will be.

I've still not answered the question, have I? Okay - Tn is a total rethink from the ground-up of how software should be structured. Inimical to this is a total rethink of how humans and computers should interface, as well as how computers should interface with each other. At an implementation level, Tn aims to be as good a quality of software as I know how to make it - secure, robust, scalable, internationalisable and portable.

To summarise:: The fundamental focus of the whole Tn project is to make your computing experience, whether it be using or programming, as productive as possible - both now and well into the future.

You can find out more about Tn at http://www.nedprod.com/Tn/

What are the differences in a no-FOX compatibility build?

Many of the more recent features added to FOX already have superior implementations in TnFOX and for native TnFOX code, it makes no sense to include the thunking code implementing the FOX feature. Disabling the FOX compatibility layer removes that code, reducing the size of your binary. It is automatically disabled when BUILDING_TCOMMON is defined.

Not compiled:

FX::fxDllOpen etc.
FX::FXBZStream
FX::FXGZStream

What are the differences in a no-GUI build?

As of v0.86, a no-GUI build can be set by editing config.py and setting the disableGUI variable to True. The no GUI build consists merely of the TnFOX extensions to FOX and virtually no FOX code at all. Here's what you do get:

All the FX::QIODevice classes
All the QTL thunk classes and all classes starting with 'Q'
All the FX::TnFXSQLDB classes
All the stuff in FX::Secure
FX::FXACL, FX::FXFSMonitor, FX::FXRollback, FX::FXProcess, FX::FXNetwork
And from FOX, FX::FXDir, FX::QFile, FX::fxfilematch(), FX::FXIO, FX::FXPath, FX::FXStat, FX::FXSystem, FX::FXString and FX::FXStream (the FOX compatibility API does nothing however). You also get the contents of fxutils (which is all the misc functions in fxdefs.h)

You should note that there is no FX::FXObject included in this build nor anything deriving from it.

At the time of writing, the no-GUI build shrinks the binary as follows:

On MSVC7.1 x86, from 3.08Mb to 1.06Mb.
On MSVC8.0 x64, from 4.59Mb to 1.7Mb.
On GCC v4.0.1 x64, from 11Mb to 1.9Mb. If you link statically, you can get executables less than 1.5Mb (not bad considering the clib is in there too)

TnFOX has a far bigger binary than FOX!

Well, TnFOX also comes with a lot of extra stuff! There is about a third extra code in TnFOX over normal FOX, and much of it is template heavy. Here are some figures:

                              msvc7.1 (x86)    gcc4.0.2 (x64)
    FOX v1.6 [1]            : 2.59Mb           4.1Mb
    TnFOX v0.86 (no GUI)    : 0.95Mb           1.6Mb
    TnFOX v0.86 (minimal)   : 2.97Mb (+15%)    5.7Mb (+39%)
    TnFOX v0.86 (everything): 4.40Mb (+70%)    6.3Mb (+54%)

[1]: This is FOX compiled with the same options on both platforms

As you can see, GCC produces code between 68% and 91% larger for the same source. Newer versions of GCC should catch up with MSVC over time (indeed, it's already 50-60% better than with v3.3!)

The optional parts are as follows:

Embedded copy of OpenSSL. To remove, edit sconslib.py
Embedded copies of zlib, libpng, libjpeg, libtiff. To remove, edit sconslib.py
Embedded copy of sqlite3. To remove, edit sconslib.py or delete src/sqlite3
FOX compatibility layer. To remove, edit config.py
All the GUI code. To remove, edit config.py

Build Questions:

Why when building within the MSVC environment things aren't found?

The MSVC7.x series have a really annoying feature of overriding your environment variables when running a build - thus scons and other utilities can't find things they normally find when run in a command box plus executables don't find their DLL's.

To fix, go to

	C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\VisualStudio\7.1

and open the file VCComponents.dat in a text editor. Replace with the following:

    [VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories]
    Path Dirs=$(PATH)
    Include Dirs=$(INCLUDE)
    Reference Dirs=$(FrameWorkDir)$(FrameWorkVersion)
    Library Dirs=$(LIB)
    Source Dirs=$(VCInstallDir)atlmfc\src\mfc;$(VCInstallDir)atlmfc\src\atl;$(VCInstallDir)crt\src

Restart MSVC and you'll now find things work as expected.

Behaviour Questions:

Why do files created by my TnFOX application have weird permissions?

As you'll quickly notice, default permissions for files created by TnFOX give read and write access only to the owner of the file. On POSIX umask() is completely ignored and on NT this is very different to the default of granting Everyone full control. Quite simply, this behaviour is by default much more secure for both you and your users. If it's a problem, you can always use the QFile::setPermissions() method to alter the permissions of a created file or indeed via the static method any arbitrary file.

What does the warning "Unable to lock memory pages" mean?

This typically happens on POSIX as only root may prevent memory being paged out. To solve, you must set the owner of the relevent process to root and set the suid and sgid bits. To do this (as root):

    chown root:root <executable name>
    chmod a+s <executable name>

Now your TnFOX based application runs with root privileges. Isn't this unsafe? Partially yes - however, TnFOX does set the correct ownership of things it creates and on Linux restricts its filing system access to that of the real user so it still can't access things the owning user couldn't. For all intents and purposes the process runs as though it were a typical process though obviously if it's an untrusted application it could easily abuse these powers to do anything at all. If you don't mind your unencrypted secrets getting written to the swap file or have implemented an encrypted swap file, feel free to ignore the warning.

FreeBSD Questions:

What does "Disabling FXFSMonitor due to FAMOpen() throwing error" mean?

On POSIX, FX::FXFSMonitor is implemented using the FAM library for portable file system monitoring behaviour. On RedHat and many Linux installations, the FAM daemon famd is always running as GNOME and KDE use it - however on FreeBSD to which it only became part of the main distribution recently, it is not running by default. TnFOX based applications will print the above warning at startup and will retry opening a FAM connection on first use of FX::FXFSMonitor but if it fails again, an exception will be returned.

The solution is to enable famd. On FreeBSD v5.x, it gets more complicated as first you must create a port mapping in /etc/rpc, get the port mapper daemon running (called rpcbind), then get inetd configured and running and in theory, famd will get invoked on demand. You should consult the documentation for FAM at http://oss.sgi.com/projects/fam/ and bear in mind that sysinstall can do most of the hard work for you in its post-install configure section (though you should manually tidy up /etc/rc.conf regularly). If running inetd is too risky for you (even with a configure file devoid of anything except famd), it is possible to run famd standalone - again, see the SGI documentation for more info.

Just to help you get going quicker:

For /etc/rpc (already present on 5.x):

    sgi_fam 391002 fam # file alteration monitor

For /etc/inetd.conf:

    sgi_fam/1-2 stream  rpc/tcp wait    root    /usr/local/bin/fam    fam

I'm getting the error "Spinlock called when not threaded" when running executables?

FreeBSD is generally cleaner, better laid out and better thought through than other Unices. One area this is definitely not the case is POSIX threads support - this error results from the right pig's breakfast that is pthreads support on the 5.x series. I greatly look forward to the day they fix this once and for all by permanently retiring libc_r.

What is happening is that the newer kernel scheduled (kse) POSIX threads is conflicting with the previous POSIX threads implementation in libc_r - they cannot coexist within the same process space. TnFOX uses the newer kind exclusively but if you're getting this error then some dependent library has linked against libc_r.

There are two solutions: (i) The slow solution is to use ldd to find what shared object is importing libc_r and recompile it to link against libpthread or libkse depending on your FreeBSD version. (ii) The fast solution is to permanently prevent libc_r from ever being used again on your system no matter what - to do this, open /etc/libmap.conf and map libc_r.so to libpthread.so or libkse.so - see man libmap.conf for more.