Re-Engineering Graphical User Interfaces based on their Resource Files with UsiResourcer Jean Vanderdonckt 1 , Óscar Sánchez Ramón 1,2 , Jesús García Molina 2 1 Louvain Interaction Laboratory, Louvain School of Management (LSM)  Place des Doyens, 1 Université catholique de Louvain (UCL)  B-1348 Louvain-la-Neuve, Belgium 2 University of Murcia, Facultad de Informática, 30100 - Campus de Espinardo – Murcia (Spain) {oscar.sanchez, jean.vanderdonckt}@uclouvain.be – {osanchez,jmolina}@um.es Abstract—This paper addresses the problem of modernizing graphical user interfaces of interactive applications by re- engineering their resource files in four phases: resource decompi- lation, which extracts resource files from the executable code of an interactive application; resource recovery, which transforms extracted resources into a Concrete User Interface model based on static analysis and derivation rules; model editing, which ap- plies requested changes on the model, and resource recompilation, which produces a new interactive application or generation, which re-generates a new graphical user interface. The paper motivates and details this re-engineering approach by focusing on methods and algorithms implemented in UsiResourcer, a software that reverse engineers MS Windows resource files into a Con- crete User Interface Model for further process. A discussion on the generalization of the approach is also provided. Index Terms— User Interfaces, Modernization, Model Driven Engineering, Reverse Engineering, Reengineering. I. INTRODUCTION The life duration of an interactive application is an impor- tant, yet challenging, aspect. The code we write for an interac- tive application is expected to run for a long time. It is not de- sired that it becomes outdated after a few years. A same inter- action application could be also produced for a vast range of product lines (i.e., multiple versions) [1] and contexts of use (i.e., user, platform, and environment) [2] and not just one line or context. The Graphical User Interface (GUI) of an interac- tive application is subject to an intrinsic complexity that goes beyond merely programming algorithms [3]. GUIs are submit- ted to continual changes in their development life cycle. Organ- izations devote significant resources to their maintenance and evolution [1]. The problem is to quickly adapt a GUI to these changes [1]. As the technologies evolve, the requirements evolve too (e.g., additional versions [4], migration to the web [5], retargeting to other platforms [6]). The constant evolution of computing platforms and their associated Integrated Devel- opment Environments (IDEs) requires more efforts to cope with portability of interactive applications and their associated GUI. Different cases of GUI evolution may occur:  Specifications and/or models exist that are of enough ex- pressiveness to turn a legacy GUI [4] (e.g., using an old- fashioned technology like Character User Interfaces) into a modern GUI (e.g., using today’s technology).  Specifications and/or models are no longer accessible, but the code of the interactive application still exists. When the source code exists, transcoding technologies [7] could re- verse engineer the GUI code into a new one; when the source code is lost, but the executable one is not, a critical case appears where these techniques are no longer applica- ble. This paper falls in this case. Extreme cases also occur when only the executable code is accessible, in some old or still accessible format, mostly without any documentation or model of any kind. Consequently, re-engineering GUIs remains a challenging concern when modernizing [8], adaptation GUIs [9] of existing interactive applications, whether they are legacy or not. The task of GUI revamping [7] is also difficult: widgets need to be modified without changing the underlying functional core. Reengineering GUIs to a new platform [10] requires dealing with intricate issues in each stage (reverse engineering, restruc- turing and forward engineering). In some IDEs such as the na- tive applications for Windows that use the Windows API (for- merly Win32 API), applications use Resource Files that define some GUI resources to be used, such as menus, dialogs, icons, or key accelerators. A resource file is a text file which defines resources for structural or behavioral aspects of GUIs. Re- source files are compiled to machine code and are loaded into memory at runtime only when they are required in the execu- tion, thus inducing file swapping when needed. In this paper, resource files are an expressive starting point for performing GUI reverse engineering to feed a re- engineering process in four phases: (i) decompile resource files in textual format from the executable files, (ii) parse the re- sources defined in the resource files and instantiate a resource model reflecting the resources’ contents, (iii) transform the platform-dependent resource model in a platform-independent Concrete User Interface (CUI) model as defined in the Cameleon Reference Framework (CRF – a commonly used framework for user interface engineering) [2], and (iv) edit this model for obtaining a new GUI or for reusing it for another in- teractive application. The remainder of this paper is organized as follows. The next section shows that this approach is original with respect to the related work. Section 3 defines a resource file and its con- tents while motivating the conceptual differences between tra- ditional GUI reverse engineering and our approach based on resource files. Section 4 explains the four phases of the re- engineering process based on resource files exemplified on a running example. Section 5 presents UsiResourcer, the soft- ware that supports resource recovery, illustrates some real- world cases, and also discusses how to extend the approach to various formats of resources files and its generalization. Sec- tion 6 concludes the paper by discussing existing shortcomings and presenting some future avenues.