This way it also works for derived classes like FXJPGImage.

Allow retrival of parts of the pixel data.

../../../../ext/fox16_c/FXRbApp.cpp: In static member function ‘static FXRbApp* FXRbApp::constructAndInit(const FXchar*, const FXchar*)’:
../../../../ext/fox16_c/FXRbApp.cpp:58:28: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
   static char* argv[]={"",0};
                            ^

This fixes issue #10.

Stacktrace was:
==4561== Invalid read of size 8
==4561==    at 0x4F726FF: st_lookup (st.c:414)
==4561==    by 0x4FCEAD6: rb_method_entry_get_without_cache (vm_method.c:182)
==4561==    by 0x4FD94E5: rb_funcall (vm_eval.c:315)
==4561==    by 0x810DAF2: FXRbCallVoidMethod(FX::FXObject*, unsigned long) (in /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/fxruby-1.6.28/lib/fox16_c.so)
==4561==    by 0x81AC98E: FXRbTreeList::recalc() (in /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/fxruby-1.6.28/lib/fox16_c.so)
==4561==    by 0x8FC78DC: FX::FXTreeList::removeItems(FX::FXTreeItem*, FX::FXTreeItem*, unsigned char) (FXTreeList.cpp:2340)
==4561==    by 0x8FC7916: FX::FXTreeList::removeItem(FX::FXTreeItem*, unsigned char) (FXTreeList.cpp:2347)
==4561==    by 0x829ED0F: FXRbTreeItem::freefunc(FX::FXTreeItem*) (in /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/fxruby-1.6.28/lib/fox16_c.so)
==4561==    by 0x4EBA505: finalize_list (gc.c:1415)
==4561==    by 0x4EC15A3: rb_gc_call_finalizer_at_exit (gc.c:1552)
==4561==    by 0x4EA8064: ruby_cleanup (eval.c:127)
==4561==    by 0x4EA8292: ruby_run_node (eval.c:307)
==4561==  Address 0x74fb894853ff8550 is not stack'd, malloc'd or (recently) free'd
==4561==
segfault_on_close.rb: [BUG] Segmentation fault

So we need to use it properly too.

See bug https://bugs.ruby-lang.org/issues/6504#change-38019

Update cross compilation tasks to build x64 and x86 targets.

Before commit af543822 loading order of fox16.so and fox16.rb was irrelevant.
But now fox16.rb must be called, in order to load ruby files to the C++
extension. Renaming the C++ extension ensures, that fox16.rb is called first.

The internal object allocated when calling FXSplashWindow.new was FXSplashWindow instead
of FXRbSplashWindow, so that no FXRbUnregisterRubyObj() was called. Therefore the object
was double free'd.

Stacktrace was:
==11529== Invalid read of size 8
==11529==    at 0x9265BBC: FX::FXObject::getClassName() const (FXObject.cpp:280)
==11529==    by 0x862EE55: FXRbObject::freefunc(FX::FXObject*) (markfuncs.cpp:77)
==11529==    by 0x4EA6254: finalize_list (gc.c:2944)
==11529==    by 0x4EAAFC2: rb_gc_call_finalizer_at_exit (gc.c:3075)
==11529==    by 0x4E9773B: ruby_cleanup (eval.c:101)
==11529==    by 0x4E979C4: ruby_run_node (eval.c:244)
==11529==    by 0x4007FA: main (main.c:38)
==11529==  Address 0x75e24c0 is 0 bytes inside a block of size 248 free'd
==11529==    at 0x4C2A4BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11529==    by 0x92B98AD: FX::FXSplashWindow::~FXSplashWindow() (FXSplashWindow.cpp:219)
==11529==    by 0x917C990: FX::FXComposite::~FXComposite() (FXComposite.cpp:304)
==11529==    by 0x929A5EF: FX::FXRootWindow::~FXRootWindow() (FXRootWindow.cpp:209)
==11529==    by 0x929A621: FX::FXRootWindow::~FXRootWindow() (FXRootWindow.cpp:211)
==11529==    by 0x9156DB9: FX::FXApp::~FXApp() (FXApp.cpp:4994)
==11529==    by 0x84912F3: FXRbApp::~FXRbApp() (FXRbApp.cpp:118)
==11529==    by 0x8491347: FXRbApp::~FXRbApp() (FXRbApp.cpp:127)
==11529==    by 0x862EF8E: FXRbObject::freefunc(FX::FXObject*) (markfuncs.cpp:92)
==11529==    by 0x4EA6254: finalize_list (gc.c:2944)
==11529==    by 0x4EAAFC2: rb_gc_call_finalizer_at_exit (gc.c:3075)
==11529==    by 0x4E9773B: ruby_cleanup (eval.c:101)

Don't include sys/time.h for cross compilation, this avoids the fix for incompatible types of gettimeofday()

Allow more consistent read/write access to image data, that is also
usable with derived classes like FXJPGImage.

Moreover much faster String based access to the pixel data is possible,
now.

FXImage#data and FXMemoryBuffer is now deprecated.

Calling other classes while garbage collection is generally dangerous and useless.

This happens with FXFileSelector.

FXWindow destructor calls recalc() and changeFocus() of it's parent windows.
Since these methods are routed back to Ruby code, but calling Ruby code from
GC isn't a good idea, we mark the parent window as "in_gc", so that it will
ignore recalc() and changeFocus() calls completely.

The parent window should also be scheduled to be free'd. In the other case,
the child window would have been marked as used.

Calling any Ruby code within the mark phase is generelly dangerous,
because it usually allocates some objects.
Since most of the methods of FX objects can be overloaded in Ruby,
the calls in markfuncs now call explizitly the C++ methods.

Also remove some double marking of objects.

The target objects stored in the accelerator table are currently
private. Therefore FXRbAccelTable::markfunc() doesn't mark them as used.
As a workaround the objects are additionally stored in @targets Hash.

fix retrieving of file handles, so that FXApp#addInput works with ruby 1.8.7, 1.9.2 and rubinius under Linux (win32 not tested yet)

support rubinius

add tasks for downloading and cross compilation of libfox, fxscintilla and depending libraries for win32

C++ source and header files.

I added -I/usr/local/include to $CFLAGS and -L/usr/local/lib to
$LDFLAGS for the Darwin build, so that it would find the jpeg and
tiff libs on my system.