This document describes the issues to be considered when using Fenestra with the supported Eiffel compilers. It contains information on particular issues and caveats -- the more stable information on how to setup the library with each compiler is covered in the regular manual.
Supported compilers:
Unsupported compilers: Tower's compiler is not supported since Tower stopped selling it. Support code is still in the distribution but not actively maintained. Object Tools' Eiffel/S 2.0 is not supported, the last beta available to us had problems preventing the use of Pylon with it -- later versions, when available, may work but have not been tested and are only available for the Macintosh at the time of writing.
No specific issues with this compiler.
(This section is somewhat out of date and will be updated later.)
The garbage collector is disabled during callbacks, that is, most of the time in a Windows application. To be fixed in a later release.
This compiler is unable to link an application whose root procedure is not implemented by the root class (that is, it is inherited), while this is what all applications with this library are supposed to do: using the creation procedure inherited from APPLICATION as root. A temporary fix is to write a wrapper root class such as:
class VE_WRAPPER creation make feature make is local app : MY_APPLICATION -- inherits from APPLICATION do !!app.make end end
Another issue is that the linker automatically includes, for `windows' applications, the libraries corresponding to user32.dll, kernel32.dll, gdi32.dll,advapi32.dll, comdlg32.dll, but leaves out wsock32.dll, shell32.dll and winmm.dll which are required. A solution is to use the three corresponding .lib from Microsoft Visual C++ in the link section (including the path if using SIG's linker). These object files are believed to be available free from Microsoft's site
(This section is somewhat out of date and should be updated).
ISE Eiffel comes with its own GUI library and sort of assumes it is the one that is going to be used. The version used during testing only provided a precompiled version of WEL+Kernel+EiffelBase, while it would make sense to use only a precompiled kernel with a third party GUI library.
The compiler provides its own emulated text console in applications instead of letting the user use the standard Win32 console -- which can be used from GUI programs for debugging purposes -- so all io output goes to the emulated console, which stops working when an exception occurs...
A program is automatically frozen because the library includes calls to the external C runtime. This makes sense as interpreting (melted mode) the whole library would be quite slow. When `freezing' with version 4.0, the compiler generates a makefile that includes bogus dependency clauses for external objects like the runtime, so the C compilation fails with "do not know how to make <external-object-file>". The easy way to fix this is to change the makefile template in bench/spec/w32msc/config/config.eif (removing $EXTERNAL from the appl.lnk: line).
Other problems were encountered like minor parsing glitches and problems with invariant checking in some `frozen' samples (forcing the problem class to be melted solved the problem).
Concerning resources, the compiler automatically compiles <appname>.rc and links the resulting resources file, after adding compiler-provided resources for exception dialog boxes and the like. Therefore, it is not necessary to include a compiled resource file manually.
A bug was introduced in version -0.80 does not work with the library because of a problem handling callbacks in modes other than -boost. This is fixed from version -0.79beta-3.
The type inference system sometimes gets confused, the compiler complains of a missing type at a later stage of compilation. It generally possible to hack the problem away by adding creations of the corresponding type in a routine reached by the compiler (recursively from the root procedure), for instance:
feature fill_typehole is local a : MISSING_TYPE do if false then -- ensure never actually reached during execution !!a.make(Void) end end
Probably due to a problem like that, some of the samples cannot be compiled with -boost with the current version of Smalleiffel.