Native API

Abstract: A system and method for porting a software application from a native object oriented programming system to a target object oriented programming system is presented. The native object oriented programming system includes an application framework layer built on a set of defined native foundation classes and an operating system layer running a native operating system. The target object oriented programming system also includes an application framework layer and an operating system layer. However, the application framework layer is built on a different set of foundation classes and the target operating system is different than the native operating system. A software application that has been implemented to interface with the native object oriented programming system via an application programming interface (API) built on the defined native foundation classes may be ported to run on the target operating system in a functionally equivalent manner as if running on the native object oriented programming system using the method of the invention. The method includes defining a set of target object oriented programming system data types in terms of the native object oriented programming system data types, and then emulating the defined native foundation classes by mapping the native API method invocations to template library calls.

Abstract: From the Publisher: The Windows NT native application programming interface is the set of system services provided by the Windows NT executive to both user mode and kernel mode programs. These API routines are the equivalent of Unix system calls or VMS system services. The Windows NT/2000 Native API Reference provides the first comprehensive look at these so-far undocumented services. A unique tool for software developers who need to create or maintain utility applications under Windows NT 4.0 and 2000, this reference includes: documentation of the over 200 routines included in the native API, detailed description of those routines either not directly accessible via the Win32 API or that offer substantial additional functionality; example library routines and utility programs to demonstrate functionality of particular routines; coverage of kernel functions to support the debugging of user mode applications; and pointers to relevant documented functionality within the DDK. Because of its distance from the Windows NT operating system internals, the Win32 API does not allow access to the full functionality of operating system itself. The APIs native to Windows NT and 2000 provide a long-sought foothold into this functionality. This reference will help you to: write user mode code to interact with kernel mode applications; develop critical tools and technologies such as real-time systems, debuggers, analysis tools and device drivers; deepen your understanding of Windows NT internals; and learn what API changes are made with the release of Windows 2000. About the Author: Gary Nebbett first started working with operating systems when he joined the MultiMIRTOS development team at Standard Telecommunication Laboratories immediately after graduating from London University in 1982. (MultiMIRTOS was a real-time embedded operating system for the Intel 8086 processor.) Gary has served as a Senior Research Engineer in various organizations, since that time. He has focused on developing kernel-mode code for operating systems including Unix, VMS and Windows NT, and is practiced in modifying the behavior of applications for which only binary code is available. Through his investigation of system internals, he has developed applications not typically possible for a given operating system, including tools to trace system calls, reconstruct deleted files, and capture network traffic. Gary holds a BSc (Engineering) from Queen Mary College, University of London and lives in Basel, Switzerland. In his free time he enjoys squash, cross-country skiing, walking in the Alps, mountain biking in the Black Forest.

Abstract: A modeler allows definition of batch services that may include applications/services executing externally from the batch processing environment. The modeler may provide access to applications/services hosted on other platforms either in SOA or native API processing using TCPIP or other connection methods. The modeling or flow processing interface may provide the ability to create composite applications than can be changed and modified in real-time. The user defines the batch service using an interface provided via a graphical display. A system processor receives information from user input and updates the provided interface accordingly. The graphical definition of the batch service is stored at least ephemerally in a system data store. Once defined, the graphical definition is converted into a programmatic implementation executable by an appropriate server. This programmatic implementation can then be transmitted to a server accessible by an intended user community.

Abstract: A virtual application creating system, a virtual application installing method, a native API calling method and a virtual application executing method are disclosed. The virtual application creating system comprises a virtual environment library block including a plurality of modules that process native application program interfaces (APIs) of an operating system such that the native application APIs are suited to a virtual environment, finding a module capable of processing a specific native API from the plurality of modules when the specific native API is called and operating the found module; a virtual application installation block receiving position information of an application to be virtualized and information on an installation place where the application will be virtualized and installed from a user and inserting the virtual environment library block into a memory to install a virtual application in the installation place; and a virtual application execution block executing the virtual application installed in the installation place. Accordingly, an application selected by a user can be virtualized and installed in a position designated by the user, for example, an external storage unit, and the installed virtual application can be executed in a virtual environment independent from a host.