US20050076340A1 - Method of porting software - Google Patents

Method of porting software Download PDF

Info

Publication number
US20050076340A1
US20050076340A1 US10/390,121 US39012103A US2005076340A1 US 20050076340 A1 US20050076340 A1 US 20050076340A1 US 39012103 A US39012103 A US 39012103A US 2005076340 A1 US2005076340 A1 US 2005076340A1
Authority
US
United States
Prior art keywords
application
class
operating environment
code
computer
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
US10/390,121
Other versions
US7185344B2 (en
Inventor
Rejeev Grover
John Nolan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
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 Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Priority to US10/390,121 priority Critical patent/US7185344B2/en
Assigned to HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. reassignment HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GROVER, RAJEEV, NOLAN, JOHN
Priority to JP2004043854A priority patent/JP2004280794A/en
Priority to GB0404073A priority patent/GB2399433A/en
Publication of US20050076340A1 publication Critical patent/US20050076340A1/en
Application granted granted Critical
Publication of US7185344B2 publication Critical patent/US7185344B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management

Definitions

  • Embodiments of the present invention relate to porting an application between a first operating environment and a second operating environment, and more particularly to porting open source code to operation in a VxWorks operating environment.
  • Various operating systems differ in their implementation of multi-tasking. Such differences may necessitate re-writing of an application when moving an application from one operating system to another.
  • One such difference is whether a task namespace, for variable, is private to a task or is shared among all active tasks in the operating system.
  • FIG. 1 a block diagram of a Unix operating system 110 providing multitasking according to the conventional art is shown.
  • a plurality of instances of an open source application 120 , 130 , task, process, or the like may be executing simultaneously with each other.
  • Each instance of the application 120 , 130 will have a private namespace 140 , 150 .
  • the highest scope of a variable and/or function is limited to the application, task, or process level.
  • a plurality of users can each run an instance of an application simultaneously.
  • Each instance of the application will have a namespace associated with the particular instance of the application.
  • each user will receive back the result corresponding to their respective input.
  • FIG. 2 a block diagram of a VxWorks operating system 210 providing multitasking according to the conventional art is shown.
  • a plurality of instances of an open source application 220 , 230 , task, process, or the like may be executing simultaneously with each other.
  • Each instance of the application 220 , 230 will share a common namespace 240 .
  • the highest scope of a variable can be the whole operating system.
  • an application written in open source for Unix will not run properly if simply compiled to operate in VxWorks.
  • VxWorks a global variable, function and the like, are visible to all applications, tasks, processes and the like running on the system, even if it is a copy of the same task (e.g., two copies of a telnet protocol, a secure shell protocol, or the like). Multiple copies of a variable and/or function are not created. Therefore, multiple instances of the application all use the same variable and/or function, and hence the same namespace. The memory space, providing for the namespace, is rewritten over by each user.
  • FIG. 3 a flow diagram of a method of porting an open source application to a VxWorks operating environment, according to the conventional art, is shown.
  • the method comprises receiving an open source application, at step 310 .
  • the open source application is partially or full re-written, at step 320 .
  • the application is operable in a VxWorks operating system environment, at step 330 .
  • Porting code from a Unix operating system to a VxWorks operating system is problematic.
  • the prior art method of changing a program in order to run it in a different operating environment, such as from Unix to VxWorks is disadvantageous in that the software code of the application needs to be fully or partially re-written. As a result, most of the application has to be rewritten to conform to VxWorks. All the code to be ported from Unix to VxWorks has to be re-written resulting in extensive changes. Hence, a large number of man-hours are spent re-coding. Deficiencies in the re-coding may also result in failure of certain features.
  • Embodiments of the present invention provide a method of porting software.
  • the method of porting software comprises receiving a set of code operable in a first operating environment.
  • the method further comprises converting the set of code into a class.
  • the method further comprises providing the converted set of code operable in a second operating environment.
  • FIG. 1 shows a block diagram of a Unix operating system 110 providing multitasking according to the conventional art.
  • FIG. 2 shows a block diagram of a VxWorks operating system 210 providing multitasking according to the conventional art.
  • FIG. 3 shows a flow diagram of a method of porting an open source application to a VxWorks operating environment according to the conventional art.
  • FIG. 4 shows a flow diagram of a method of porting an application, task, process or the like, in accordance with one embodiment of the present invention.
  • FIGS. 5A and 5B show an exemplary open source code ported for operation in a VxWorks operating environment, in accordance with one embodiment of the present invention.
  • FIG. 6 shows a block diagram of an exemplary communication network, in accordance with one embodiment of the present invention.
  • FIG. 7 shows an exemplary computer system for performing embodiments of the present invention.
  • FIG. 4 a flow diagram of a method of porting an application, task, process or the like, in accordance with one embodiment of the present invention, is shown.
  • the method comprises receiving an application, task, process or the like, operable in a first operating system, at step 410 .
  • the application, task, process, or the like is written in open source code.
  • the variables and functions of the application, task, process or the like are then converted into a class, at step 420 .
  • the class is an object-oriented construct, such as a C++ programming language construct.
  • an application, process, task or the like is put inside a class, visibility of global variables and functions are limited to within the class.
  • variables and functions which would share a namespace (e.g., been public), have been privatized, to a corresponding application, by use of the class namespace.
  • the application, task, process or the like is operable in a second operating system environment, at step 430 .
  • the second operating environment comprises VxWorks.
  • Each instance of an application, task, process or the like now has its own copy of an instance of class variables or functions. Hence, a particular class variable or function is only visible to the application that declared it.
  • Applications are not allowed to read or write to the class namespace of another application. For example, a plurality of users can each run an instance of an application in a VxWorks operating environment simultaneously. Each user will receive back the result corresponding to their respective input.
  • Embodiments of the present invention advantageously increase the number of applications that operate in VxWorks to include application written in Unix open source. Embodiments of the present invention also reduce the extent of changes to the application code. Embodiments of the present invention also reduce software revision time. Therefore, if changes are made in the corresponding open source, such as reference changes, such revisions are more readily incorporated.
  • FIGS. 5A and 5B an exemplary open source code ported for operation in a VxWorks operating environment, in accordance with one embodiment of the present invention, is shown.
  • an exemplary open source code wherein a first number (e.g., variable) and a second number are input by a user. The first and second numbers are added and returned as a result (e.g., function).
  • the fork( ) system call is utilized to spawn each instance of the process.
  • the variables and function are provided for by non-shared namespace.
  • the exemplary Unix code has been ported to be operable in a VxWorks operating environment in accordance with one embodiment of the present invention.
  • a first number and second number are input by a user.
  • the first and second numbers are added and returned as a result.
  • the taskspawn( ) system call is utilized to spawn each instance of the process.
  • the variables and function are provided by shared namespace.
  • Porting code, according to the present embodiment, from a non-shared namespace operating system to the shared namespace of VxWorks comprises encapsulate the code from the non-shared name space operating system into a class.
  • Each instance of the process creates a class instance, which is called an object.
  • Each object for each instance of the application has its own copy of the variables and function.
  • the class namespace is not visible across multiple applications, tasks, processes, and the like. Hence, multiple applications can be run in parallel, without confusion among the variables. When multiple instances of the application are initiated, distinct results for each instance are returned.
  • the communication network comprises a plurality of user devices, a communication channel, and a VxWorks server.
  • the plurality of user devices are communicatively coupled to the VxWorks server via the communication channel.
  • the users may connect to the VxWorks server utilizing a telnet protocol.
  • the telnet provides for logon with a password.
  • the telnet connection is not secure. Someone snooping on the network can see anything that goes on the wire.
  • VPN virtual private network connection
  • a VPN client application is run on a user device (e.g., personal computer) and a VPN server application is run on a server.
  • the VPN client application and VPN server application communicate with each other following the VPN protocol, which is an internet protocol.
  • VPN is a relatively heavy application in that it requires a lot of setup and the like.
  • a secure shell may be utilized.
  • the secure shell is a relatively lightweight application.
  • An SSH client application is run on a user device (e.g., personal computer) and an SSH server application is run on a server.
  • the SSH client application and the SSH server application communicate with each other following the secure shell protocol, which is a session protocol.
  • the SSH is a session-by-session security feature.
  • the telnet protocol is then run over the secure shell protocol.
  • OpenSSH is one implementation of the SSH protocol written in open source code which utilizes features provided for by a Unix operating environment, but not supported by a VxWorks operating environment.
  • VxWorks is a primitive operating system as compared to Unix. VxWorks was designed to be as light as possible, and therefore does not implement all the features of a full operating system like Unix.
  • VxWorks differs from the Unix operating system in a number of ways. First, there is no memory protection between different programs in VxWorks. Secondly, all global variables are visible to all the tasks running in the system. In Unix, the global variable is only visible to the process that declares the given global variables.
  • OpenSSH can be ported to be operable in a VxWorks operating system without having to substantially re-write the software code of OpenSSH.
  • the OpenSSH code is converted into a class.
  • multiple instances of the ported OpenSSH protocol may be provided by the VxWorks server.
  • the exemplary computer system comprises an address/data bus 720 for communicating information and instructions.
  • One or more processors 730 are coupled with the bus 720 for processing information and instructions.
  • a memory unit 740 is also coupled to the bus 720 for storing information and instructions for the processor(s) 730 .
  • the memory unit 740 may include volatile memory (e.g. random access memory, static RAM, dynamic RAM, and the like), non-volatile memory (e.g. read only memory, programmable ROM, flash memory, EPROM, EEPROM, and the like), mass data storage (e.g. hard disk, optical disk, floppy disk, and the like), and the like.
  • the computer system 710 may include peripheral devices 750 (e.g. display, keyboard, pointing device, speaker, and the like) coupled to the bus 720 .
  • Certain processes and steps of the present invention are realized as a series of instructions (e.g. code) that reside on a computer-readable medium, such as the memory unit 740 , and are executed by the processor 720 .
  • the instructions When executed, the instructions cause the processor 720 to port an application, process, or the like operable in a first operating environment into code operable in a second operating environment.
  • the application, process, or the like, operable in a first operating environment is communicated from a computer-readable medium, such as the memory unit 740 , across the bus 720 to the processor 730 .
  • the application, process, or the like is written in open source code operable in a Unix operating environment.
  • the open source application, process, or the like is ported, in accordance with the present invention, for operation in a VxWorks operating environment.
  • the processor in response to the series of instruction, encapsulate the code of the application, process, or the like is into a class.
  • the class is an object-orientated programming construct.
  • the object-orientated programming construct is a C++ construct.
  • the non-shared namespace of the application, process or the like is converted into a class namespace.
  • the class namespace is limited to an instance of the class and is not shared among different tasks, classes, instances, or the like.
  • the ported code may then be transmitted from the processor 730 over the bus 720 to the computer-readable medium, such as the memory unit 740 .
  • the computer-readable medium stores the ported code encapsulated into a class, for subsequent loading and/or use in a VxWorks operating environment.

Abstract

Embodiments of the present invention provide a method of porting software. The method of porting software comprises receiving a set of code operable in a first operating environment. The method further comprises converting the set of code into a class. The method further comprises providing the converted set of code operable in a second operating environment.

Description

    FIELD OF THE INVENTION
  • Embodiments of the present invention relate to porting an application between a first operating environment and a second operating environment, and more particularly to porting open source code to operation in a VxWorks operating environment.
  • BACKGROUND OF THE INVENTION
  • Various operating systems differ in their implementation of multi-tasking. Such differences may necessitate re-writing of an application when moving an application from one operating system to another. One such difference is whether a task namespace, for variable, is private to a task or is shared among all active tasks in the operating system.
  • Referring to FIG. 1, a block diagram of a Unix operating system 110 providing multitasking according to the conventional art is shown. As depicted in FIG. 1, a plurality of instances of an open source application 120, 130, task, process, or the like, may be executing simultaneously with each other. Each instance of the application 120, 130 will have a private namespace 140, 150. Thus, the highest scope of a variable and/or function is limited to the application, task, or process level.
  • In Unix, a namespace is created for each application, which is separate from other application namespaces. As a result, each instance of an application has its own copy of a global variable. A particular global variable is only visible to the process that declared it. Applications are not allowed to read or write to the namespace of another application.
  • Therefore, a plurality of users can each run an instance of an application simultaneously. Each instance of the application will have a namespace associated with the particular instance of the application. Thus, for example, each user will receive back the result corresponding to their respective input.
  • Referring now to FIG. 2, a block diagram of a VxWorks operating system 210 providing multitasking according to the conventional art is shown. As depicted in FIG. 2, a plurality of instances of an open source application 220, 230, task, process, or the like, may be executing simultaneously with each other. Each instance of the application 220, 230 will share a common namespace 240. Thus, the highest scope of a variable can be the whole operating system. As a result, an application written in open source for Unix will not run properly if simply compiled to operate in VxWorks.
  • In VxWorks, a global variable, function and the like, are visible to all applications, tasks, processes and the like running on the system, even if it is a copy of the same task (e.g., two copies of a telnet protocol, a secure shell protocol, or the like). Multiple copies of a variable and/or function are not created. Therefore, multiple instances of the application all use the same variable and/or function, and hence the same namespace. The memory space, providing for the namespace, is rewritten over by each user.
  • Hence, multiple instances of unmodified open source code will not run properly in VxWorks. For example, each user will receive the result corresponding to the most recently entered input, even though there is distinct results for each user's input.
  • Referring now to FIG. 3, a flow diagram of a method of porting an open source application to a VxWorks operating environment, according to the conventional art, is shown. As depicted in FIG. 3, the method comprises receiving an open source application, at step 310. The open source application is partially or full re-written, at step 320. Thereafter, the application is operable in a VxWorks operating system environment, at step 330.
  • Porting code from a Unix operating system to a VxWorks operating system is problematic. The prior art method of changing a program in order to run it in a different operating environment, such as from Unix to VxWorks, is disadvantageous in that the software code of the application needs to be fully or partially re-written. As a result, most of the application has to be rewritten to conform to VxWorks. All the code to be ported from Unix to VxWorks has to be re-written resulting in extensive changes. Hence, a large number of man-hours are spent re-coding. Deficiencies in the re-coding may also result in failure of certain features.
  • Thus, there is a need for an improved method of porting an open source application to work in a VxWorks operating environment. The method should substantially reduce the amount of code that needs to be re-written.
  • SUMMARY OF THE INVENTION
  • Embodiments of the present invention provide a method of porting software. In one embodiment, the method of porting software comprises receiving a set of code operable in a first operating environment. The method further comprises converting the set of code into a class. The method further comprises providing the converted set of code operable in a second operating environment.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention is illustrated by way of example and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
  • Prior Art FIG. 1 shows a block diagram of a Unix operating system 110 providing multitasking according to the conventional art.
  • Prior Art FIG. 2 shows a block diagram of a VxWorks operating system 210 providing multitasking according to the conventional art.
  • Prior Art FIG. 3 shows a flow diagram of a method of porting an open source application to a VxWorks operating environment according to the conventional art.
  • FIG. 4 shows a flow diagram of a method of porting an application, task, process or the like, in accordance with one embodiment of the present invention.
  • FIGS. 5A and 5B show an exemplary open source code ported for operation in a VxWorks operating environment, in accordance with one embodiment of the present invention.
  • FIG. 6 shows a block diagram of an exemplary communication network, in accordance with one embodiment of the present invention.
  • FIG. 7 shows an exemplary computer system for performing embodiments of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • Reference will now be made in detail to the embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it is understood that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.
  • Referring now to FIG. 4, a flow diagram of a method of porting an application, task, process or the like, in accordance with one embodiment of the present invention, is shown. As depicted in FIG. 4, the method comprises receiving an application, task, process or the like, operable in a first operating system, at step 410. In one embodiment the application, task, process, or the like is written in open source code.
  • The variables and functions of the application, task, process or the like are then converted into a class, at step 420. The class is an object-oriented construct, such as a C++ programming language construct. When an application, process, task or the like is put inside a class, visibility of global variables and functions are limited to within the class. Hence, variables and functions, which would share a namespace (e.g., been public), have been privatized, to a corresponding application, by use of the class namespace.
  • Thereafter, the application, task, process or the like, is operable in a second operating system environment, at step 430. In one embodiment the second operating environment comprises VxWorks. Each instance of an application, task, process or the like, now has its own copy of an instance of class variables or functions. Hence, a particular class variable or function is only visible to the application that declared it. Applications are not allowed to read or write to the class namespace of another application. For example, a plurality of users can each run an instance of an application in a VxWorks operating environment simultaneously. Each user will receive back the result corresponding to their respective input.
  • Embodiments of the present invention advantageously increase the number of applications that operate in VxWorks to include application written in Unix open source. Embodiments of the present invention also reduce the extent of changes to the application code. Embodiments of the present invention also reduce software revision time. Therefore, if changes are made in the corresponding open source, such as reference changes, such revisions are more readily incorporated.
  • Referring now to FIGS. 5A and 5B, an exemplary open source code ported for operation in a VxWorks operating environment, in accordance with one embodiment of the present invention, is shown. As depicted in FIG. 5A, an exemplary open source code wherein a first number (e.g., variable) and a second number are input by a user. The first and second numbers are added and returned as a result (e.g., function). The fork( ) system call is utilized to spawn each instance of the process. The variables and function are provided for by non-shared namespace.
  • As depicted in FIG. 5B, the exemplary Unix code has been ported to be operable in a VxWorks operating environment in accordance with one embodiment of the present invention. A first number and second number are input by a user. The first and second numbers are added and returned as a result. The taskspawn( ) system call is utilized to spawn each instance of the process. Normally, the variables and function are provided by shared namespace.
  • Porting code, according to the present embodiment, from a non-shared namespace operating system to the shared namespace of VxWorks comprises encapsulate the code from the non-shared name space operating system into a class. Each instance of the process creates a class instance, which is called an object. Each object for each instance of the application has its own copy of the variables and function. The class namespace is not visible across multiple applications, tasks, processes, and the like. Hence, multiple applications can be run in parallel, without confusion among the variables. When multiple instances of the application are initiated, distinct results for each instance are returned.
  • Referring now to FIG. 6, a block diagram of an exemplary communication network, in accordance with one embodiment of the present invention, is shown. As depicted in FIG. 6, the communication network comprises a plurality of user devices, a communication channel, and a VxWorks server. The plurality of user devices are communicatively coupled to the VxWorks server via the communication channel.
  • In one implementation, the users may connect to the VxWorks server utilizing a telnet protocol. The telnet provides for logon with a password. However, the telnet connection is not secure. Someone snooping on the network can see anything that goes on the wire.
  • One solution is to utilize a virtual private network connection (VPN) to provide for a secure transaction. A VPN client application is run on a user device (e.g., personal computer) and a VPN server application is run on a server. The VPN client application and VPN server application communicate with each other following the VPN protocol, which is an internet protocol. However, VPN is a relatively heavy application in that it requires a lot of setup and the like.
  • Alternatively, a secure shell (SSH) may be utilized. The secure shell is a relatively lightweight application. An SSH client application is run on a user device (e.g., personal computer) and an SSH server application is run on a server. The SSH client application and the SSH server application communicate with each other following the secure shell protocol, which is a session protocol. Hence, the SSH is a session-by-session security feature. The telnet protocol is then run over the secure shell protocol.
  • OpenSSH is one implementation of the SSH protocol written in open source code which utilizes features provided for by a Unix operating environment, but not supported by a VxWorks operating environment. VxWorks is a primitive operating system as compared to Unix. VxWorks was designed to be as light as possible, and therefore does not implement all the features of a full operating system like Unix.
  • VxWorks differs from the Unix operating system in a number of ways. First, there is no memory protection between different programs in VxWorks. Secondly, all global variables are visible to all the tasks running in the system. In Unix, the global variable is only visible to the process that declares the given global variables.
  • However, OpenSSH can be ported to be operable in a VxWorks operating system without having to substantially re-write the software code of OpenSSH. In accordance with one embodiment of the present invention, the OpenSSH code is converted into a class. As a result, multiple instances of the ported OpenSSH protocol may be provided by the VxWorks server.
  • Referring now to FIG. 7, an exemplary computer system for performing embodiments of the present invention, is shown. As depicted in FIG. 7, the exemplary computer system comprises an address/data bus 720 for communicating information and instructions. One or more processors 730 are coupled with the bus 720 for processing information and instructions. A memory unit 740 is also coupled to the bus 720 for storing information and instructions for the processor(s) 730. The memory unit 740 may include volatile memory (e.g. random access memory, static RAM, dynamic RAM, and the like), non-volatile memory (e.g. read only memory, programmable ROM, flash memory, EPROM, EEPROM, and the like), mass data storage (e.g. hard disk, optical disk, floppy disk, and the like), and the like. Optionally, the computer system 710 may include peripheral devices 750 (e.g. display, keyboard, pointing device, speaker, and the like) coupled to the bus 720.
  • Certain processes and steps of the present invention are realized as a series of instructions (e.g. code) that reside on a computer-readable medium, such as the memory unit 740, and are executed by the processor 720. When executed, the instructions cause the processor 720 to port an application, process, or the like operable in a first operating environment into code operable in a second operating environment.
  • In one embodiment, the application, process, or the like, operable in a first operating environment, is communicated from a computer-readable medium, such as the memory unit 740, across the bus 720 to the processor 730. In one implementation, the application, process, or the like is written in open source code operable in a Unix operating environment. The open source application, process, or the like is ported, in accordance with the present invention, for operation in a VxWorks operating environment.
  • The processor, in response to the series of instruction, encapsulate the code of the application, process, or the like is into a class. The class is an object-orientated programming construct. In one implementation, the object-orientated programming construct is a C++ construct. As a result, the non-shared namespace of the application, process or the like, is converted into a class namespace. The class namespace is limited to an instance of the class and is not shared among different tasks, classes, instances, or the like. The ported code may then be transmitted from the processor 730 over the bus 720 to the computer-readable medium, such as the memory unit 740. The computer-readable medium stores the ported code encapsulated into a class, for subsequent loading and/or use in a VxWorks operating environment.

Claims (20)

1. A method of porting software comprising:
receiving a set of code operable in a first operating environment;
converting said set of code into a class; and
providing said converted set of code operable in a second operating environment.
2. The method according to claim 1, wherein said set of code consist of one of an application, a process, and a task.
3. The method according to claim 1, wherein said first operating environment comprises a Unix operating environment.
4. The method according to claim 1, wherein said second operating environment comprises a VxWorks operating environment.
5. The method according to claim 1, wherein said set of code comprises a set of open source software code written for a non-shared namespace environment.
6. The method according to claim 1, wherein said class comprises an object-oriented construct.
7. The method according to claim 6, wherein said object-oriented construct comprises a C++ programming language construct.
8. A computer-readable medium having instructions which when executed by a computer system implement a process of converting an application operable in a first operating environment to a second operating environment comprising encapsulating said application into a class.
9. The computer-readable medium according to claim 8, wherein encapsulating an application into a class comprises converting a variable into a class variable.
10. The computer-readable medium according to claim 8, wherein encapsulating an application into a class comprises converting a function into a class function.
11. The computer-readable medium according to claim 8, wherein encapsulating an application into a class comprises converting a non-shared namespace into a class namespace.
12. The computer-readable medium according to claim 8, wherein said application comprises open source code.
13. The computer-readable medium according to claim 8, wherein said first operating environment comprises a Unix operating environment.
14. The computer-readable medium according to claim 8, wherein said second operating environment comprises a VxWorks operating environment.
15. A computer system comprising:
a bus, for communicating information and instruction associated with an application and a porting method;
a processor communicatively coupled to said bus, for processing said information and instructions associated with an application and a porting method, wherein processing said information and instructions encapsulates said application into a class; and
a memory unit communicatively coupled to said bus, for storing information and instructions associated with said application said porting method and said encapsulated application.
16. The computer system according to claim 15, wherein said class comprises an object-oriented construct.
17. The computer system according to claim 15, wherein said object-oriented construct comprises a C++ programming language construct.
18. The computer system according to claim 15, wherein said encapsulating comprises converting a non-shared namespace of said application into a class namespace.
19. The computer system according to claim 15, wherein said application comprises an open source application.
20. The computer system according to claim 15, wherein said encapsulating comprises converting a variable and a function of said application into a class of said variable and said function.
US10/390,121 2003-03-14 2003-03-14 Method of porting software Expired - Fee Related US7185344B2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US10/390,121 US7185344B2 (en) 2003-03-14 2003-03-14 Method of porting software
JP2004043854A JP2004280794A (en) 2003-03-14 2004-02-20 Method for implanting software
GB0404073A GB2399433A (en) 2003-03-14 2004-02-24 A method of porting software

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/390,121 US7185344B2 (en) 2003-03-14 2003-03-14 Method of porting software

Publications (2)

Publication Number Publication Date
US20050076340A1 true US20050076340A1 (en) 2005-04-07
US7185344B2 US7185344B2 (en) 2007-02-27

Family

ID=32069623

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/390,121 Expired - Fee Related US7185344B2 (en) 2003-03-14 2003-03-14 Method of porting software

Country Status (3)

Country Link
US (1) US7185344B2 (en)
JP (1) JP2004280794A (en)
GB (1) GB2399433A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070044098A1 (en) * 2005-08-19 2007-02-22 Sony Corporation Information processing apparatus and method, recording medium, and program
JP2011501852A (en) * 2007-10-18 2011-01-13 ジーイー・インテリジェント・プラットフォームズ・インコーポレイテッド Method and system for converting automation software
CN102801777A (en) * 2012-06-06 2012-11-28 烽火通信科技股份有限公司 Method for realizing telnet of shell for vxWorks system
CN104601619A (en) * 2013-10-30 2015-05-06 上海斐讯数据通信技术有限公司 Method for safely and remotely logging in shell of vxWorks system

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2563786A1 (en) * 2004-04-28 2005-11-10 Openlogic, Inc. Tools for stacking uncoordinated software projects
US8498982B1 (en) 2010-07-07 2013-07-30 Openlogic, Inc. Noise reduction for content matching analysis results for protectable content
US9348568B2 (en) 2011-08-24 2016-05-24 Accenture Global Services Limited Software application porting system
KR102439456B1 (en) * 2018-10-24 2022-09-02 삼성에스디에스 주식회사 Apparatus and method for compiling partial source code

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6018628A (en) * 1998-06-16 2000-01-25 Sun Microsystems, Inc. Method of implementing parameterized types to be compatible with existing unparameterized libraries
US6356957B2 (en) * 1997-04-03 2002-03-12 Hewlett-Packard Company Method for emulating native object oriented foundation classes on a target object oriented programming system using a template library
US20030145123A1 (en) * 2002-01-31 2003-07-31 Sun Microsystems, Inc. Method, system, and program for providing access to an application on an end user computer
US20040064826A1 (en) * 2002-09-30 2004-04-01 Timothy Lim Method and system for object system interoperability
US6832214B1 (en) * 1999-12-07 2004-12-14 International Business Machines Corporation Method, system, and program for converting code to executable code using neural networks implemented in a software program
US6957439B1 (en) * 2000-05-09 2005-10-18 International Business Machines Corporation Method, system, and program for mapping objects in different language formats
US6964053B2 (en) * 2002-12-04 2005-11-08 International Business Machines Corporation Type descriptor language (TDLanguage) metamodel

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6356957B2 (en) * 1997-04-03 2002-03-12 Hewlett-Packard Company Method for emulating native object oriented foundation classes on a target object oriented programming system using a template library
US6018628A (en) * 1998-06-16 2000-01-25 Sun Microsystems, Inc. Method of implementing parameterized types to be compatible with existing unparameterized libraries
US6832214B1 (en) * 1999-12-07 2004-12-14 International Business Machines Corporation Method, system, and program for converting code to executable code using neural networks implemented in a software program
US6957439B1 (en) * 2000-05-09 2005-10-18 International Business Machines Corporation Method, system, and program for mapping objects in different language formats
US20030145123A1 (en) * 2002-01-31 2003-07-31 Sun Microsystems, Inc. Method, system, and program for providing access to an application on an end user computer
US20040064826A1 (en) * 2002-09-30 2004-04-01 Timothy Lim Method and system for object system interoperability
US6964053B2 (en) * 2002-12-04 2005-11-08 International Business Machines Corporation Type descriptor language (TDLanguage) metamodel

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070044098A1 (en) * 2005-08-19 2007-02-22 Sony Corporation Information processing apparatus and method, recording medium, and program
JP2011501852A (en) * 2007-10-18 2011-01-13 ジーイー・インテリジェント・プラットフォームズ・インコーポレイテッド Method and system for converting automation software
CN102801777A (en) * 2012-06-06 2012-11-28 烽火通信科技股份有限公司 Method for realizing telnet of shell for vxWorks system
CN104601619A (en) * 2013-10-30 2015-05-06 上海斐讯数据通信技术有限公司 Method for safely and remotely logging in shell of vxWorks system

Also Published As

Publication number Publication date
US7185344B2 (en) 2007-02-27
GB2399433A (en) 2004-09-15
JP2004280794A (en) 2004-10-07
GB0404073D0 (en) 2004-03-31

Similar Documents

Publication Publication Date Title
US9934005B2 (en) Dynamically building locale objects or subsections of locale objects based on historical data
US7636699B2 (en) Processing transactions using graph-based computations including instances of computation graphs associated with the transactions
JP2569092B2 (en) Address resolution method for I / O device control program
US9075646B1 (en) System and method for application isolation
EP0855056B1 (en) Object-oriented method maintenance mechanism that does not require cessation of the computer system
US10496602B1 (en) System and method for maintaining mappings between application resources inside and outside isolated environments
US20080052711A1 (en) Highly componentized system architecture with loadable virtual memory manager
CA2171601A1 (en) Methods and apparatus for providing transparent persistence in a distributed object operating environment
US7185344B2 (en) Method of porting software
US9141353B2 (en) Dynamically building locale objects at run-time
CN115543549B (en) Container with application running effect consistent with host machine
US7418713B2 (en) Component processing system and component processing method
US7246135B2 (en) Sharing classes between programs
AU2007202782B2 (en) Startup and control of graph-based computation
CN114201751A (en) Service data processing method based on intelligent contract
US9792093B2 (en) Dynamically building subsections of locale objects at run-time

Legal Events

Date Code Title Description
AS Assignment

Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GROVER, RAJEEV;NOLAN, JOHN;REEL/FRAME:014474/0125

Effective date: 20030314

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Expired due to failure to pay maintenance fee

Effective date: 20150227