WO2004088508A2 - Procede de creation d'un logiciel transferable entre differents systemes d'exploitation - Google Patents

Procede de creation d'un logiciel transferable entre differents systemes d'exploitation Download PDF

Info

Publication number
WO2004088508A2
WO2004088508A2 PCT/GB2004/001392 GB2004001392W WO2004088508A2 WO 2004088508 A2 WO2004088508 A2 WO 2004088508A2 GB 2004001392 W GB2004001392 W GB 2004001392W WO 2004088508 A2 WO2004088508 A2 WO 2004088508A2
Authority
WO
WIPO (PCT)
Prior art keywords
symbian
application
interface
apis
applications
Prior art date
Application number
PCT/GB2004/001392
Other languages
English (en)
Other versions
WO2004088508A3 (fr
Inventor
Anatoly Kardash
Original Assignee
Intuwave Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intuwave Limited filed Critical Intuwave Limited
Publication of WO2004088508A2 publication Critical patent/WO2004088508A2/fr
Publication of WO2004088508A3 publication Critical patent/WO2004088508A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering

Definitions

  • the invention relates to a method of creating software that is portable across different operating systems (OSs').
  • the method enables source code written for a first OS to be used to generate a first and a second software application, each compatible with different operating systems.
  • a method of creating software that is portable across different operating systems, in which a first and a second software application are generated from source code written for a first OS, and both the first and the second software applications can run on a second OS when each referencing interface libraries that (a) mimic the APIs for the first OS and (b) also interface to APIs that are native to the second OS; wherein the first and the second applications are each tightly integrated with different interface libraries, or instances of those interface libraries, and the different interface libraries or their instances are not shared between the first and second applications.
  • the first application references its own tightly integrated interface libraries (or a related instance) in order to run on the, second OS
  • the second application independently and simultaneously references its own tightly integrated interface libraries (or a related instance) in order to run on the second OS.
  • the interface libraries (or their instances) are hence each tightly integrated to a specific application; further each provides some of the functionality of the mimicked or emulated first OS and hence constitute a 'distributed' first OS kernel.
  • the binary components are typically modular software elements, that each (i) encapsulate functionality required by an application and provided by a wireless mobile device and (ii) share a standard interface structure and (iii) execute on the device, using a high level language program. In a specific implementation called MRIX (see Appendix 1), they are referred to as 'pipe processors'.
  • the first and the second application are generated from first and second source code; these can in fact be the same source code.
  • a different interface library (or related instance) can be referenced to allow the first and the second applications to interface with a different OS.
  • the or each interface library may support several versions of the first OS.
  • the or each interface library may implement functionality of APIs of the first OS by using APIs of the second OS.
  • the first OS is Symbian OS.
  • the or each interface library provides definitions and implementations of one or more versions of Symbian OS APIs, in which the definitions provide the definitions of native Symbian OS APIs and are compatible with a second operating system, and the implementation implements native Symbian OS API functionality and is compatible with the second operating system.
  • the portable software may originally reference Symbian OS APIs (Symbian OS interface libraries), provided by the Symbian OS operating system.
  • Symbian OS interface libraries provided by the Symbian OS operating system.
  • the software When running on a Microsoft Windows-like OS, the software instead references a plurality of interface libraries (Symbian OS API Emulation), each of which mimics the Symbian OS APIs and interfaces to native Microsoft Windows APIs (Win32). While in any given situation the Symbian OS API Emulation is implemented as close to Win32 methods as possible (i.e. they are tightly integrated together within a block), the overhead of carrying this extra Symbian OS API Emulation is minimal.
  • a separate version of the Symbian OS API Emulation interface libraries is created for each specific Windows-like operating system.
  • Each separate version of the Symbian OS API Emulation interface libraries supports a variety of Symbian OS versions, thus allowing the porting of applications created originally for different versions of Symbian OS using the same version of the Symbian OS API Emulation.
  • a mobile computing device programmed with first and second software applications that are obtained from source code written for a first OS, in which both the first and the second software applications can run on a second OS used by the device when each referencing interface libraries that (a) mimic the APIs for the first OS and (b) also interface to APIs that are native to the second OS, wherein the first and the second applications are each tightly integrated with different interface libraries, or related instances, that are not shared between the first and second applications.
  • FIG. 1 is a block diagram of one embodiment of the invention, in which several different operating systems are supported for a single software application;
  • FIG.2 shows how several applications written for a first OS conventionally access a shared emulator in order to run on a different OS
  • FIG. 3 shows a run-time implementation of the present invention with 'distributed kernel' emulation
  • FIG. 4 shows a software application for a native Symbian OS platform that uses the original Symbian OS API
  • FIG. SA and 5B shows the software application of FIG. 4 referencing Symbian OS API Emulation on a Microsoft Windows-like platform
  • FIG. 6 shows the design flow used to build the software application of FIG. 4, so that it can work on a Microsoft Windows-like operating system with the use of the Symbian OS API Emulation shown in FIG. 5.
  • E2W is an application-porting platform that enables application software developers to write for Symbian OS and deploy simultaneously on Symbian OS and PocketPC. Not an emulator, E2W is a complete cross-platform solution from development to deployment. It actually recompiles Symbian OS source code with the PocketPC compilers to create native PocketPC applications. Today, E2W is the only technology allowing developers to use single C++ source across both 'Symbian OS and PocketPC devices.
  • E2W provides, for the first time, automatic source code maintenance.
  • companies can finally avoid: (1) rewriting of hard code; (2) use of multiple development and maintenance teams; (3) the need to learn new development environments.
  • Leveraging the advanced development environment of Symbian API developers can now target simultaneously Symbian and Microsoft platforms, while still working within a single source code.
  • E2W enables a method of the development of code that simultaneously supports two or more operating systems. It also provides a run-time.
  • FIG. 1 is a high-level diagram showing the method of the invention for supporting different operating systems by an application.
  • a C++ application (101) supports five operating systems (102, 103, 104, 105, 106) referencing operating systems' APIs. Procedures for referencing the APIs are described below.
  • FIG 2 there is a central emulator 204 that several applications 201, 202, each written for OS of type 1, interact with via APIs 203.
  • the emulator 204 appears to applications 201, 202 to be a type 1 OS, but in fact converts requests from applications 201, 202 to a form that OS of type 2, 205, can respond to.
  • a failure in the central, OS emulator 204 accessing OS kernel 205 shared across several applications will however cause an overall failure in all applications 201 and 202 using the shared emulator 204.
  • E2W is based on a unique run-time architecture approach - "Distributed-Kernel Emulation", where the Symbian OS Kernel emulation is a part of the API itself for each application. E2W does not perform simulation of the Symbian OS internal behavior, rather it uses direct mapping of Symbian OS external functionality to the MS Windows API. E2W retains high performance while providing unprecedented stability since there are no bottlenecks. As opposed to traditional approaches (see above), a single failure does not affect other applications. In essence, in E2W (see FIG 3) we tightly integrate a Symbian emulator API 303 with each single ported application 301, rather than having a central broker intermediary layer API that serves multiple applications. The E2W approach is better for resource constrained devices because if results in fewer interactions, and hence is faster and less power hungry. It is also more robust since a fault in one emulator API affects only the single application it is integrated with, rather than all applications.
  • FIG. 4 shows an exemplary C++ application for a native Symbian OS platform that uses the original Symbian OS API.
  • the application 403 in FIG. 4 uses the functionality of the Symbian OS operating system 401 using its APIs 402.
  • the operating system vendor provides the API 402. This design is used by the application 403 to support native Symbian OSs, i.e. as represented by relationship pairs 101-102, 101-103, and 101-104 in FIG. 1.
  • application 501 A written for Symbian OS but actually running on a Microsoft Windows-like OS, references a set of E2W's interface libraries 502A, which mimic Symbian OS APIs and interface to native Microsoft Windows APIs (Win32) 503A and hence to Windows Pocket PC OS 504A.
  • Symbian OS API Emulation 502A While in any given situation the Symbian OS API Emulation 502A is implemented as close to Win32 503A methods as possible (through merging/ tight integration together within a single block), the overhead of carrying this extra Symbian OS API Emulation is minimal.
  • Each and every ported E2W application 501A requires its own E2W DLL 502A, loaded into memory according to the common rules of handling DLLs: common binary executable code segment (meaning: loaded once into memory and shared/used by ALL processes) and per-process data segments.
  • the DLL's memory overhead is minimal - for 1 application: ⁇ 340KB; for 5 applications: ⁇ 700KB.
  • FIG. 5B shows an exemplary C++ application 501B (e.g. equivalent to the application 501A of FIG. 5A) for a native Symbian OS platform that uses the Symbian OS Emulation API 502B to run on a Microsoft Windows-like operating system 504B.
  • each emulation API 502B can support several versions of the Symbian OS, such as ER5 or Symbian OS 6.x or other.
  • the application 501B in FIG. 5B uses the functionality of a Symbian OS API (either ER5 or Symbian OS 6.x or other), which is provided by Symbian OS Emulation API 502B.
  • the Symbian OS Emulation API 502B implements the functionality of the variety of Symbian OS APIs (ER5, Symbian OS 6.x and so forth) using a Microsoft Windows-like OS API (Win32) (503B in FIG. 3).
  • the application 501B uses the functionality provided by the Microsoft Windows-like OS 504B.
  • the operating system vendor provides the Win32 API. This design is used by the application 501 B to support Microsoft Windows-like OSs, i.e. as represented by relationship pairs 101-105 and 101- 106 in FIG. 1.
  • E2W enables source code from several different Symbian OS versions to generate Win binaries because source code written for, e.g. Symbian OS version ER5, uses the functionality provided by ER5 headers and ER6 libraries and source code written for Symbian OS version ER6 uses the functionality provided by ER6 headers and ER6 libraries. This approach may be better understood in the context of how an E2W application is developed, as explained in the following section.
  • FIG. 6 shows how an application running on a Microsoft Windows-like OS is generated according to one embodiment of the invention.
  • FIG. 6 shows the workflow for the simplest application, which is generated from a single C++ source file 601.
  • an application MyApp.exe 605 is generated.
  • the MyApp.exe application uses functionality provided by Symbian OS Emulation API.
  • the MyApp.exe application is created from a single C++ source file MyApp.cpp 601.
  • the source file MyApp.cpp 601 was originally created for a native Symbian OS (ER5 or Symbian OS 6;x or other), and references functionality provided by the correspondent original Symbian OS API.
  • the C++ compiler is used to generate a binary object file MyApp.obj 603 from the source file MyApp.cpp 601.
  • Symbian OS Emulation API provides header files 606 with the Symbian OS (ER5 and Symbian OS 6.x and so forth) APIs definitions required by the source file 601 to be compiled.
  • the result of the step 602 is an object file referencing binary implementation of the functionality of the required Symbian OS API.
  • step 604 of FIG. 6 the C++ linker is used to generate the binary executable file MyApp.exe 405, which is the application runnable on the Microsoft Windows-like OS.
  • the inputs for the step 604 are: the binary object file MyApp.obj 603 and the libraries 607 with the binary implementation of Symbian OSs APIs (ER5 and Symbian OS 6.x and so forth) functionality provided by the Symbian OS Emulation API.
  • an application compatible with the Microsoft Windows-like OS is generated from a source file, which was originally created for a Symbian OS (ER5 or Symbian OS 6.x or other).
  • Such applications may comprise more than one source file (.cpp, .h), the final application may be either EXE-file or DLL-file or some other binary executable file according to the requirements of a specific Microsoft Windows-like OS.
  • E2W consolidates the burdens of automatic application porting and source code maintenance wlender providing the following:
  • E2W enables developers to use a single C++ development environment for dozens of mobile appliances thus substantially shortens development cycles, lowering maintenance cost, lowering training costs, increasing developer productivity. As a result, the total cost of multi-platform application development is reduced substantially.
  • a data storage medium comprising a software application supporting a plurality of operating systems, the application comprising: a computer code device including a C++ source code originally written for a native Symbian OS (ER5 or Symbian OS 6.x or other) operating system for communicating with the correspondent original Symbian OS APIs.
  • the data storage may further comprising a second computer code device representing Symbian OS Emulation API for providing Symbian OSes APIs (ER5 and Symbian OS 6.x and so forth) definitions and implementation for a Microsoft Windows-like operating system, wherein: Symbian OSes APIs (ER5 and Symbian OS 6.x and so forth) definitions provide the definitions of native Symbian OSes APIs and are compatible with the Microsoft Windows-like operating system, and
  • Symbian OSes APIs (ER5 and Symbian OS 6.x and so forth) implementation implements the native Symbian OSes APIs functionality and is compatible with the Microsoft Windows-like operating system.
  • a method for generating a software application supporting a plurality of operating systems comprising the steps of: a) defining Symbian OSes APIs (ER5 and Symbian OS 6.x and so forth) functionality; b) implementing Symbian OSes APIs (ER5 and Symbian OS 6.x and so forth) functionality; and c) generating from C++ source code referencing a Symbian OS API (ER5 or
  • Symbian OS 6.x or other a software application that is compatible with a Microsoft Windows-like operating system.
  • Symbian OS Emulation API provides C++ header files that comprise the necessary native Symbian OSes APIs (ER5 and Symbian OS
  • Symbian OS Emulation API provides C++ libraries that implement the necessary native Symbian OSes APIs (ER5 and Symbian OS 6.x and so forth) functionality and are compatible with the
  • the above method further comprising the step of generating binary object file that is compatible with the Microsoft Windows-like operating system defined above by compiling the C++ source code of claim 1 using the C++ header files defied above.
  • the above method further comprising the step of generating binary executable file that is compatible with the Microsoft Windows-like operating system defined above by linking the C++ source code defined above using the C++ libraries defined above.
  • the present invention enables an application (that can run natively on a first OS, such as the C++ based SymbianOS) to call, use or deploys an instance of an object based component; that instance references the tightly integrated interface libraries associated uniquely with the first application when the first application runs on a second OS (e.g. a Windows-type OS); as noted above, these libraries (a) mimic the APIs for the first OS and (b) also interface to APIs that are native to the second OS. Similarly, if a second application calls, uses or deploys a further instance of the same object based component, then that further instance references the tightly integrated interface libraries associated with the second application when the second application runs on the second OS.
  • a second application calls, uses or deploys a further instance of the same object based component, then that further instance references the tightly integrated interface libraries associated with the second application when the second application runs on the second OS.
  • the object based components can be modular software elements, that each (i) encapsulate functionality required by a wireless mobile device and (ii) share a standard interface structure and (iii) execute on the device, using a high level language program.
  • These modular software elements are, in one implementation called MRIX, called 'pipe processors'. MRIX is described in more detail below.
  • MRIX The purpose of MRIX is to facilitate rapid develop of networked application software for mobile devices.
  • An implementation comprises software resident on the different computing devices connected to the network, including mobile device, such as a smartphone, desktop PC and server.
  • Software components are required on all of the different elements in the network to facilitate rapid application development and deployment. This is illustrated by the following example for developing a networked application on the mobile device that enables a user to make full use of an enterprise CRM system for better customer relationships. To do this, software must be developed on the mobile device that can connect to an enterprise server, that implements the CRM system and manages all of the customer interactions for the enterprise. The mobile device must be able to connect both over a wide area connection to the server (such as over GPRS) as well as through a faster local connection through a broadband wireless link through the PC.
  • the limited user interface of the mobile device also means that the mobile device must connect easily with the desktop PC to allow the user to take advantage of the large screen and keyboard of the desktop PC when the user is sitting at his or her desk.
  • the traditional means of developing such an application would be to develop the software on the desktop PC using appropriate development tools, such as an IDE, and to run and test the application on an emulator on the desktop PC. Once the software is successfully running on the emulator then it can be transferred to the mobile device, where it needs to be debugged again. This approach is often fine for non-networked application as there is little difference between the emulator and PC. However, for networked applications the emulator does not have the range of network connections available on the mobile device so development is much more difficult.
  • a simple script can be put together to put these together into a complete application running on the phone, again running remotely from the desktop PC.
  • Connectivity components on the PC such as mRouter, which may be part of mrix, are used if networked connectivity is required to, or routing through, the desktop PC from the mobile device. See PCT//GB2002/003923, the contents of which are incorporated by reference, for more details on mRouter. 5.
  • Connectivity components on the server are used if the server needs to connect to the phone. This is required as the phone's IP address is not visible to the outside world so cannot be contacted by the server. Hence, the Relay server is required that is visible by both the phone and back-office server, to enable networked communication to the server.
  • mrix is a wireless software platform designed to significantly reduce the time to market in producing solutions involving smartphones by:-
  • mrix includes a platform agnostic remote command execution environment for smartphones.
  • a command interpreter interfaces to a smartphone through a set of commands or "pipe processors".
  • These are small stand-alone modules written in C++ or scripting languages that encapsulate a range of smartphone functionality.
  • Device resident mrix pipe processors (prefixed with "mi") are provided which facilitate the control and management of multiple bearers (GPRS, SMS, Bluetooth, MMS, WiFi etc); device peripherals (such as barcode readers, pens, printers, GPS etc); other devices and servers; and network billing. Pipe processors can be "chained” together to build more functionality. These building blocks allow fast and iterative development of mobile solutions. The use of scripting languages opens up development to a much broader community of developers.
  • mrix Architecture mrix is designed around a command interpreter running on a smartphone and a command execution shell running on a remote PC or other suitable platform.
  • Pipe processors can be invoked remotely (like Unix commands) from a desktop PC via m-RouterTM or a remote server via a Relay. This not only allows development and debugging of an mrix solution to be carried out from the convenience of a desktop PC but also allows smartphone components to be shared at runtime over networks.
  • Some pipe processors are mandatory and are considered core to the system. Examples include mrEvent or mrAt which are used to start and stop processes based on events.
  • a set of optional pipe processors are also supplied which can be removed from the runtime, if required, to minimise the memory footprint.
  • Custom pipe processors can also be built in C++ or LUA Script and templates are provided for this.
  • mrix Solution mrBluetooth is used to easily manage the connectivity between a smartphone and a bluetooth enabled barcode pen.
  • the engineer needs a part, he/she "swipes" the product barcode from a parts catalogue.
  • a persistent inventory of parts is maintained on the device using mrStorage.
  • the smartphone indicates to the engineer the available stock on the van. If the part is not available, an SMS is created via mrMessage and sent to other engineer's smartphones.
  • mrWatchFile on the recipient's smartphones to trigger on receipt of a specific SMS message, the inbound SMS causes an inventory check to be carried out. If the remote engineer's phone indicates that the part is available on the van, an SMS is automatically sent back to the original engineer.
  • a prompt automatically displays on the smartphone (mrPrompt) which informs the engineer that the part is available and supplies the phone number of the engineer with that part.
  • the process can be further enhanced to only inquire of stock availability from engineers who are local using mrSim and the current cell-id.
  • the core mrix system contains a number of elements some of which are deployed on the smartphone:
  • mrcmd mrcmd consists of two elements, a command interpreter for smartphones and a remote command execution shell.
  • the command interpreter currently runs on Symbian.
  • the remote command execution shell runs on Windows, Mac OS X and Linux.
  • m-Router® Command-line interface to Intuwave's existing m-Router® product which handles local connection management on Symbian OS smartphones.
  • m-Router® operates over Serial, Bluetooth, USB and IrDA bearers.
  • mrElay mrElay consists of both a command-line interface to Intuwave's remote relay server and the relay server itself.
  • Pipe processors are small self-contained modules that encapsulate smartphone functionality. A small number of pipe processors that manage event handling and file access are in the mrix core.
  • script engine A powerful and compact (60k) LUA 5.0 scripting engine is included on the smartphone to allow a developer to readily combine pipe processor functionality directly using scripts. Included with the scripting engine are a number of core mrix scripts that powerfully combine existing pipe processor functionality.
  • mrix Reference Manual HTML pages that explains how to use all the existing core pipe processors. There are also instructions on writing new pipe processors as well as m- Router® and mrcmd functionality, documentation and example scripts detailing is included.
  • mrix enables full automation of system, functional, acceptance, regression and interoperability tests.
  • mrix enables rapid development of PC Connectivity PIM applications through script-accessible toolkits.
  • mrix offers numerous benefits to smartphone manufacturers and phone network operators.
  • mrix development is done in rapid iterations by evolving scripts rather than coding against APIs. This significantly speeds up the development lifecycle.
  • Cost Since mrix functionality is script-based, the cost of development as well as the cost of maintenance and enhancement of functionality is significantly reduced.
  • Cross-platform mrix offers full cross-platform support for smartphones. When combined with a cross-platform toolkit, server applications can be built to run across different PC Operating Systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

La présente invention concerne une technique de production d'un logiciel qui soit 'transférable'', c'est-à-dire compatible avec au moins deux systèmes d'exploitation (OS) différents. Des première et deuxièmes applications logicielles sont générées à partir d'un code source écrit pour un premier système d'exploitation, les deux applications logicielles pouvant cependant fonctionner sur un deuxième système d'exploitation lorsque chacune des bibliothèques d'interface de référence (a) imitent les API du premier système d'exploitation et (b) servent également d'interface aux API qui sont originaires du deuxième système d'exploitation. Les applications sont chacune étroitement intégrées avec des instances différentes des bibliothèques d'interface qui ne sont pas partagées entre les première et deuxième applications.
PCT/GB2004/001392 2003-04-04 2004-03-31 Procede de creation d'un logiciel transferable entre differents systemes d'exploitation WO2004088508A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0307805A GB0307805D0 (en) 2003-04-04 2003-04-04 A method of enabling source code to be used to generate a first and a second software application,each compatible with a different operating system
GB0307805.2 2003-04-04

Publications (2)

Publication Number Publication Date
WO2004088508A2 true WO2004088508A2 (fr) 2004-10-14
WO2004088508A3 WO2004088508A3 (fr) 2004-12-29

Family

ID=9956183

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2004/001392 WO2004088508A2 (fr) 2003-04-04 2004-03-31 Procede de creation d'un logiciel transferable entre differents systemes d'exploitation

Country Status (2)

Country Link
GB (2) GB0307805D0 (fr)
WO (1) WO2004088508A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005045667A2 (fr) * 2003-11-06 2005-05-19 Intuwave Limited Procede d'elaboration rapide d'application logicielle pour dispositif mobile sans fil
US8612947B2 (en) 2009-07-31 2013-12-17 Adobe Systems Canada Inc. System and method for remotely compiling multi-platform native applications for mobile devices
CN103678099A (zh) * 2012-09-10 2014-03-26 国网电力科学研究院 一种实现硬件平台与软件平台通讯的方法以及装置
CN112272820A (zh) * 2018-07-30 2021-01-26 欧姆龙株式会社 支持装置以及支持程序

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2391717A1 (fr) * 2002-06-26 2003-12-26 Ibm Canada Limited-Ibm Canada Limitee Transfert de donnees et stockage de metadonnees sur un reseau
GB0516438D0 (en) * 2005-08-10 2005-09-14 Symbian Software Ltd Adding functionality to a computing device using thread call tables
TWI352909B (en) * 2007-09-05 2011-11-21 Htc Corp Method and system for supporting network sharing a
GB2471484A (en) * 2009-06-30 2011-01-05 Nokia Corp A software framework for creating new software components in compliance with an existing multimedia application programming interface

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0755003A2 (fr) * 1995-07-19 1997-01-22 Sun Microsystems, Inc. Procédé et dispositif pour réarranger des modules de programme d'ordinateur
EP0798637A1 (fr) * 1996-03-29 1997-10-01 Sun Microsystems, Inc. Conversion transparente des appels de programme entre interfaces
US5724590A (en) * 1988-12-06 1998-03-03 Lucent Technologies Inc. Technique for executing translated software
WO2001016730A2 (fr) * 1999-09-01 2001-03-08 Microsoft Corporation Reparation d'applications incompatible par mise en place de module de remplacement pour api
US20020004854A1 (en) * 2000-04-26 2002-01-10 Hartley Peter Darren Computer systems
US6463582B1 (en) * 1998-10-21 2002-10-08 Fujitsu Limited Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026238A (en) * 1997-08-18 2000-02-15 Microsoft Corporatrion Interface conversion modules based upon generalized templates for multiple platform computer systems

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5724590A (en) * 1988-12-06 1998-03-03 Lucent Technologies Inc. Technique for executing translated software
EP0755003A2 (fr) * 1995-07-19 1997-01-22 Sun Microsystems, Inc. Procédé et dispositif pour réarranger des modules de programme d'ordinateur
EP0798637A1 (fr) * 1996-03-29 1997-10-01 Sun Microsystems, Inc. Conversion transparente des appels de programme entre interfaces
US6463582B1 (en) * 1998-10-21 2002-10-08 Fujitsu Limited Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method
WO2001016730A2 (fr) * 1999-09-01 2001-03-08 Microsoft Corporation Reparation d'applications incompatible par mise en place de module de remplacement pour api
US20020004854A1 (en) * 2000-04-26 2002-01-10 Hartley Peter Darren Computer systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DAN AMIR, ANATOLY KARDASH: "E2w White Paper "Standardizing C++ Mobile Programming"" 25 June 2003 (2003-06-25), PEROON , XP002300236 Retrieved from the Internet: URL:http://www.peroon.co.il/WP/E2W_White_P aper_1.pdf> [retrieved on 2004-10-07] the whole document *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005045667A2 (fr) * 2003-11-06 2005-05-19 Intuwave Limited Procede d'elaboration rapide d'application logicielle pour dispositif mobile sans fil
WO2005045667A3 (fr) * 2003-11-06 2005-07-28 Intuwave Ltd Procede d'elaboration rapide d'application logicielle pour dispositif mobile sans fil
US8612947B2 (en) 2009-07-31 2013-12-17 Adobe Systems Canada Inc. System and method for remotely compiling multi-platform native applications for mobile devices
CN103678099A (zh) * 2012-09-10 2014-03-26 国网电力科学研究院 一种实现硬件平台与软件平台通讯的方法以及装置
CN112272820A (zh) * 2018-07-30 2021-01-26 欧姆龙株式会社 支持装置以及支持程序
CN112272820B (zh) * 2018-07-30 2023-09-08 欧姆龙株式会社 支持装置以及支持程序的记录介质

Also Published As

Publication number Publication date
GB2400211A (en) 2004-10-06
WO2004088508A3 (fr) 2004-12-29
GB0307805D0 (en) 2003-05-07
GB0407337D0 (en) 2004-05-05

Similar Documents

Publication Publication Date Title
US8291375B2 (en) Attribute-based component programming system and methodology for object-oriented languages
EP2368189B1 (fr) Pipeline de débogage
JP4950454B2 (ja) テスト自動化のスタック階層化
US7155381B2 (en) Module for developing wireless device applications using an integrated emulator
KR101246967B1 (ko) 어플리케이션 호스트 환경에서 유닛 테스트를 실행하기 위한 방법 및 장치
US20070220494A1 (en) A Method of Rapid Software Application Development for a Wireless Mobile Device
US20030236657A1 (en) Method of developing wireless device applications using an integrated emulator and an IDE
CN100492387C (zh) 基于Keil C51的软件保护开发的方法和系统
US20080120595A1 (en) System and method for hot code replace
Mahmoud Learning wireless java
KR20030036736A (ko) 내장형 오퍼레이팅 시스템을 가진 디바이스를 위한 기능및 사용자 인터페이스를 형성하기 위한 방법 및 장치
CN112148278A (zh) 可视化的区块链智能合约框架及智能合约开发部署方法
CN115629971A (zh) 一种应用的开发系统和开发方法
US20070180433A1 (en) Method to enable accurate application packaging and deployment with optimized disk space usage
CA2341114C (fr) Langage de definition de donnees
CN112631915B (zh) 一种pcie设备软件仿真的方法、系统、设备及介质
WO2004088508A2 (fr) Procede de creation d'un logiciel transferable entre differents systemes d'exploitation
US7707593B2 (en) Object models enabling hosting content in a plurality of environments
CN117813586A (zh) 对具有未保存的源代码更改的正在运行的应用进行热重载
CN101593257B (zh) 基于.Net虚拟机的软件保护系统和方法
US8135943B1 (en) Method, apparatus, and computer-readable medium for generating a dispatching function
Kiss Build automation systems against CI lock-in-A comparative study of Dagger and Mage
Studio Getting Started Guide
WO2019164036A1 (fr) Procédé de développement d'application sur le web
Kotlyarov et al. Testing Automation for system core kJava applications

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
122 Ep: pct application non-entry in european phase