Evaluation Project
The Evaluation Project is a MSVS VC++ project that contains the Front End Module in a DLL along with the Demonstration Application , OS interface and Device Driver - GDI - files . It also contains a Windows executable along with the script files and the test files . A script compiler project is also supplied .

This allows the features and capabilities of the Front End Module to be evaluated . It provides the means to develop Application side Functional Modules and their User Interface side scripts . The scripts are developed using the Applications Scripts Project . When the project is compiled it produces the selected script binary file . The script file can then be executed ( displayed ) by using the executable or via the VS project . A full description of the binary script - IDF - commands is contained in the Manual and within the Application Scripts Project files . The application and script files supplied provide examples of how to construct the scripts and to link to the application .


zip file containing the Demonstration Application project , the GuiFrontEndModule Windows DLL , Windows executeables and the associated test script and text files and the script compiler project .

Extract the files from gui_front_end_module_evaluation.zip - these will place the files within a Projects directory . WinZip may also create some empty directories - these can be ignored and can be deleted .

Then extract the files from gui_front_end_module_evaluation_stand_alone_executable.zip - this will place a FrontEnd_Module.exe executeable in the D:\Projects\FrontEnd\FrontEnd_Module\Release directory . You should be able to execute the program from there .

If you don't have a D drive then extract the files onto a USB drive ( eg. a USB memory stick ) and mount this as a D drive .

Last Updated :- 27-07-11 15:07 GMT .




Linux Port Status   A Linux port is included . Please Note :- the port is not fully complete - there is still a few things that need doing that I am fitting in in between many diversions .

It is compiling fully on the GNU GCC compiler - no warnings , no errors . All major problems have been sorted out . All associated work is complete . The port is progressing well . The OS File Services are basically ported - with the exception of directory file attributes such as date and time not being returned from extended directory searches . The scripts are being successfully loaded and executed . The main window frame is being displayed . The graphics functions - blank area , rectangle , line - are being operated ok. . Frame rendering is ok. . Text is being displayed . The font characteristics - height , ascent & character width are being obtained . The text font setting - font selection and size and type ( bold , italic etc. ) setting are set up . There is a discrepancy between the Windows and the Linux font characteristics - hence some of the display is different . The keyboard and mouse button and movement events are interfaced . The time tick still has to be ported - this drives the event messaging system .


The zip file contains the evaluation files for the GUI Front End Module . Files are present for evaluation of the project by both non technical and by technical people .

The following are contained within the zip file :-

  1. the Application code project in the gui_front_end_module_application.zip file .
  2. the Application Scripts compile project in the gui_front_end_module_application_scripts.zip file . This contains the ApplicationScripts compile project . This is used to compile the User Interface binary scripts from their macro'd version . Application.hxx contains the compile switches which determine which script file is to be compiled . The main script file is ApplicationScripts.cxx - this contains links to the other script files . When each script file is compiled the binary script project ( ApplicationScripts ) then needs to be executed to produce the resulting binary script file - it will display the name of the file being stored as a binary script file and will wait for a key to be pressed to exit .
    The script commands are defined in ScriptCommands.hxx and the associated macros for storing the script commands in the scripts are defined in ScriptStoreMacros.hxx .
    These enum & macro based script files - the source files - have associated header header files with enum's defining paratmeters such as script numbers and data numbers .
    Please Note :- all the binary and text script files are contained within the frontend_application_scripts.zip file - these are required - ie. they must be extracted - for the executeable to run .
    The text scripts use the same commands as the binary scripts , with a few exceptions , within basically an XML format .
  3. the demonstration application and the Front End Module DLL in the gui_front_end_module_evaluation_EXE_&_DLL.zip file . The executeable is located in /Projects/FrontEnd/Libraries/FrontEnd_Module_App_EXE_Release/Release/FrontEnd_Application.exe . The DLL is in the same diorectory - GUIFrontEndModule.dll .
  4. the stand alone executable in the gui_front_end_module_evaluation_stand_alone_executable.zip file . The executeable is located in /Projects/FrontEnd/FrontEnd_Module/Release/FrontEnd_Module.exe .
  5. the manual . Please Note :- the manual has not kept completely up with the project . Extra features have been added . These can be referred to in the example files in the script compiler project in the evaluation package - in files - ApplicationScripts.cxx etc. and in the ScriptCommands.hxx & ScriptStoreMacros.hxx files . The priority is the next stage - the construction of an editor . The editor will contain full help files and , as such , will replace the manual .

    The files should be unpacked starting from the root directory on the selected drive area . The paths - where everything is located - have to be correct in order for it to work . The file extraction directory is "Projects" and sub directories contained within "Projects" . As such - if on drive "D" - create an empty folder called "Projects" and extract the files to the drive - D: - ie. to the root . If you don't have a drive D then mount and map a drive in on D . On Linux place the Projects directory into the user home directory - /home/user_name - eg. /home/kim/Projects .

If you are extracting it to the C drive and then compiling it on the C drive under MS VS - then running it the MS VS might protest that it cant find MSDEV.EXE on the D drive - just cancel this and the module will run - alternatively - do a full clean and rebuild and this should solve the problem . You may need to do a substitution of 'D:' drive path references for 'C:' references in the project files . If you are compiling it you will need to set up the include directories . All the files in all the zip files will need to be extracted .

If you do not have a full WinZip program installed and you are just relying on MS Windows Explorer for the extraction it may display a confused directory layout , however you should still be able to successfully extract all the files .

The following file extensions are used :-

1) .idf Interactive Document Format - binary scripts . The idea , eventually , is to produce an Interactive Document Processor - editor - and to provide the means to link together different 'document' forms - data sets - into a single interactive - intelligent - document . Integration of data in all it's forms .
2) .ids Interactive Document Script - text scripts - script commands .
3) .ihs Interactive Header Script - text script defines - enums .

All the files necessary to evaluate the project and to compile and link the individual MSVS VC++ projects should be present . The project has been thoroughly tested during development - it should work fully at your end . If the evaluation package has somehow got out of sync with the development , or there is a missing header file , then I will need to put in these files - if anything doesn't work or doesn't compile please contact me .

Please Note

the scripts used by the evaluation copy have been set up to test the functionality of the GUI Front End Module - ie. they test the development . They have not been set up to display beautifully laid out and well presented User Interfaces . When designing a UI it is just a matter of constructing the scripts such that the UI is beautifully laid out and well presented - the GUI Front End Module provides all the facilities to do this .

Please Note :- the purpose of the Front End Module is to handle the Layout and the Data Input and to Define the Rendering but not to handle the rendering . The rendering is handled by the GDI functions . As such the quality of the rendering is dependent on the quality of these functions . The Display Device Driver - GDI - supplied with this project is just a basic GDI designed to provide a means to test and demonstrate the operation of the Front End Module . In an embedded environment a high quality platform specific GDI would be needed - this can be provided - developed by us - or ported by us .
The Module is written in C++ and is designed for PC and Embedded Platforms . It is supplied in dynamic library form .

In a Software on Silicon situation - UI on a Chip - the memory requirements - stages 2 and 3 - are :-

  1. Flash :- 1MB . The code currently uses 660KB but additional code area would be required for a small OS and for the GDI and for Multimedia codecs etc. . If the requirement is being met by over design - future proofing - then a minimum of 1MB to a maximum of 2MB should be made available .
  2. RAM :- 256KB - depends on usage - can be as small as 64KB but if the directory facility is being used and if multimedia playing is being used then 256KB should be made available . If the requirement is being met by over design - future proofing - then a maximum of 512KB should be made available . The module is RAM intensive .
A huge amount of work has been carried out on both the overall design and development of the module and the design and development of what's 'under the hood' - ie. it has been heavily architectured . In structural terms it is highly componentised and extensively featured . It has been designed to be easily expanded and upgraded .
If there are any questions or problems at all - whatever they may be - please contact me .

The State of the Development

The state of the development is that it is fully completed to the first stage with the exception of the date and time handling and display - which will be completed at a later date - it's essentially low priority at the moment . The effects have not been tested for a long time so might , quite likely , need some updating . They also need to be expanded and to be integrated in with the GDI to provide smoother transitions - again all a low priority at the moment . The second stage - construction of a text to binary script assembler - is complete . The third stage - construction of a script editor - has not commenced . However the existing binary script compiler can be used for script development .

The aim - for the first 2 stages - is to provide a system where complete UI's and UI portions can be developed in the same manner as a componentised program . The binary scripts are interpreted like a program . The difference is that the interpretations put UI objects on the screen and allow interaction with the user and , on the other end , send event messages to other native code components . Thus this allows a separate componentised approach to UI's to be taken . It's rather like the skins approach - UI's separate from the underlying code .

The nature of the project is that it has a lot of potential and , as such , a lot of ongoing development as it's abilities are expanded and added to . Consequently this site is updated as the latest version comes available and the associated date and time updated .

Please Note

although the GUI Front End Module is being put forward as a PC based , embedded and Software on Silicon solution to the design and handling of User Interfaces , the module has been designed with a much wider market area in mind . Hence why the module is so extensively designed and developed as far as it's structure and it's method of operation .

Current Work

I have completed the testing and tidying up of the current stage . I have commenced looking at :-

  1. additional bullet proofing . Putting in friendly failure to accommodate low RAM memory , mistakes in script writing , etc. . Putting in release version problem fixes - ie. if an error condition occurs an in situ fix is put in to ensure that the module does not collapse . In the debug version this problem is picked up by the asserts and is fixed . There is already bullet proofing at critical points , this just needs to be expanded .
  2. the construction of the text based script editor / word processor and the integration of it with the existing text script to binary script assembler .
  3. the construction of a microkernel . This will be in a similar vein to Linux \ UNIX but will be designed on a more encompassing basis and using more strictly applied rules - ie. not using a POSIX interface as this is far too restrictive . All data will be accessed and processed within a common virtual environment irrespective of it's source , format or destination . Much of this has already been completed - it just requires the basic components .
  4. integration of the microkernel access methods into the GUI Front End Module . This will allow all data to be declared , defined , accessed and handled within the microkernel environment - ie. fully virtualised and fully integrated .
  5. minor updates on the use of #define style command in the text based scripts - this is on the back burner .

The project has a lot of potential - initially as a Software on Silicon UI solution - but there are also much larger business opportunities in some closely associated areas . The project is very unique in it's design - it is more than sufficiently differentiated from anything currently available - in architectural and functional design , in application and in quality and coverage of coding . There are distinct unexplored market areas where it can gain a strong foothold if it is given the required development .

If there are any questions or problems at all - please contact me .
We use AVG FireWall and Virus detection and protection software to ensure that our security is not compromised and to , likewise , ensure that any executables supplied to you are not compromised .