What is the difference between a Win32 or DirectX wrapper and a Win32 or DirectX framework?
A wrapper is typically a family of functions that contain the function calls for a library or API like win32, DirectX, etc., in some sort of abstracted way to the end-user. Many times they are customized so that the functions you call in the wrapper is not exactly the same as the original API, or some default parameters have been setup for you to make working with the API a bit easier. Also in the specific instance of a language wrapper, the functionality has been embedded in the language's run-time API, and then exposed to the end-user. For example, one could expose the win32 calls to a Python user by creating a C-library plug-in for python with the win32 API calls, and then creating a python library that may have customized python functions that call the win32 functions exposed by the C-library plugin. In this case the Python library "wraps" the native C-based win32 library.
A framework is like a wrapper, but in its most-typically used definition, it's a little different in that it works by creating some type of run-time environment that you create callbacks to plug into, so that when the frame-work wants to-do some task, you've written a function that is called for that task. This is called the "Hollywood Principal" of programming, which basically says, "don't call us, we'll call you". So in working with this model, you create functions, register them with the frame-work, and your function is called when the frame-work needs to call it, and the framework passes its own internal parameters as your function arguments. A good example is a GUI-framework, where you create callbacks for buttons and other events, and the GUI-framework calls those functions as it processes its runtime event-loop.
So I guess one way to think of the primary differentiation between the two is that wrappers tend to be static (i.e. exposing libraries and functions with customized function calls either that fill-in default values for you or translate them to a different language), whereas a framework tends to be dynamic (i.e. its a runtime system that you create callbacks for, and register it with the framework that are then called during some time of runtime event loop or kernel, etc., like a GUI toolkit).
Wrappers tend to make it possible (oftentimes easier) to access complex systems, complex code or combinations of calls from multiple classes and so forth. For example, you may create a Facebook wrapper in C# or Java to interact with getting user data from the Facebook API, which has many REST-based functions which return JSON. A framework is a set of related objects, functions, and so forth to provide a particular functionality, or enhance a particular functionality, so you wouldn't use either a wrapper or framework. Oftentimes you'll use a both, using a wrapper to access a framework. This is especially true with legacy systems :)
Related
The Cloud File Api from this Cloud Sync Engine Article is a Win32 Api. I've read that you can call C++ functions in C# using __declspec(dllexport)... and was wondering if that could be done for the cfapi.h header. It seems to have some deep underlying structs that it depends on, so I have no idea how complicated it would be. For example, CfCreatePlaceholders() takes in a CF_PLACEHOLDER_CREATE_INFO struct as a parameter, would I also need to dllexport a structure like that too? If so, then if that struct then takes another struct, it quickly becomes a very deep hole.
Is this even the best path to take? Are there alternative methods? Thanks in advance.
In its simplest form, COM allows you to instantiate C++-like classes from DLL in your application. Basically it's a glorified wrapper around LoadLibrary and some conventions regarding the interface. This is called using an in-process component.
But COM also supports out-of-process components. If you instantiate a class from such a component, COM starts a new process. Your objects live in said process, and are marshalled transparently over to you, so you don't care too much about where they live. They might even be on a different computer (DCOM). You can also fetch objects from already running applications. A well-known example is controlling MS Office via a script. This is called Automation (formerly OLE Automation, and there is a bit of confusion around what exactly this term encompasses).
There are a couple of nice articles explaining how (in-process) COM works low-level (e.g. COM from scratch. I'd like to know how it works when your component is out-of-process. Especially, what IPC does COM use beneath the hood to communicate between the processes? Window messages, shared memory, sockets, or something else? MSDN lists COM as an IPC method by itself, but I'm guessing it has to use something else underneath. Are different IPC methods used in different cases (instantiating an OOP component from C++, accessing an Excel document from VBScript, embedding a document in another via OLE)? It seems like it is all the same underlying technology. And lastly, how does marshalling fit in the picture? I believe it is neccessary to serialize method parameters for transmitting between processes, correct?
According to this MSDN article, it's RPC.
When you instantiate an OOP component, the COM subsystem generates an in-process proxy. This proxy is responsible for packing parameters and unpacking return values. It also generates a stub in the server process, which, expectably, unpacks parameters and packs return values.
Interestingly enough, the whole marshaling process can be customized, by implementing IMarshal.
DCOM was originally added as an extension to COM, precisely for cross apartment calls. Note cross apartment calls are not always from process to process. A process can have many apartments (0 or 1 MTA and/or 0 to n STAs, etc.) . There is at least one apartment per process, etc.
DCOM, some kind of a "middleware", needed a technology for all this low-level work: data representation, caller/callee convention, memory management, wire marshaling, session handling, security, error handling, etc. so Microsoft naturally used the in-house implementation of DCE/RPC: MSRPC. Note that as Microsoft says on its site,
"With the exception of some of its advanced features, Microsoft RPC is
interoperable with other vendors’ implementations of OSF RPC."
There was some tentative work to have all this implemented by other vendors, but they were basically killed by the rise of the internet and HTTP.
Also, note this RPC uses Windows Messages for STA apartement messages. I suggest you read carefully this document (not available any more on Microsoft site, shame on them :-) for more details:
DCOM Architecture by Markus Horstmann and Mary Kirtland - July 23, 1997 .
See also this interesting case study about a DCOM/RCP issue that should tell you a lot of how RPC over Windows message works under the scene: Troubleshooting a DCOM issue: Case Study
I need to call a RPC client which is implemented in C from a Java class.
The interaction is one way only(i.e) Java has to invoke specific functions in C, while C need not return anything to the calling Java code.
Can someone explain me the pros & cons in using either of the types (JNI/Runtime.exec)?? and which is the best option for my case?
Runtime.exec() will launch a separate process for each call. Your Java caller needs to consume the output of each process.
JNI would require a native, dynamically linked library. Depending on your operating system, you may need to explicitly export functions. You would define a Java class with "native" methods, generate a C header/stub file with javah, and implement the native methods by calling your C client functions.
Runtime.exec() probably consumes the most resources. I personally would use an in-process call to native code.
Instead of JNI, consider using JNA, which makes it easy to call C functions from Java without an ad hoc native glue layer. Your C functions would need to be in a native, dynamically linked library. In Java, you declare their signatures, load the library, and call the functions.
For Windows DLLs, be aware that you need to export functions for them to be available from outside the DLL.
When a COM+ application is created the wizard offers to choose between a library and a server application.
A server application is activated in a separate process and this can be used to cheaply interop 64-bit consumers with 32-bit in-proc COM components.
What's the use of library applications that are activated right in the caller process? Why use them instead of plain old in-proc COM servers?
There are several:
Performance - it is a bit faster as you don't have to go through the message automation (marshalling and unmarshalling)
Isolation - if many different Applications are using the Library, then each will have it's own copy. This point is most important when dealing with the differences between an MTA (Multi Threaded Apartment) and a STA (Single Threaded Apartment Model)
THE IN-PROC Server (which is really an out of processes, out of the caller's process) is shared by all different callers (this is a great way to have cheap IPC/RPC)
Ok I am editing with a few more definitions, and a bit more references:
Context is really all the state around the use of an object.
causality is really a thread like concept indicating the use of an object in a context. ("A causality is a distributed chain of COM method calls that spans any number of contexts in any number of processes" - from ISBN: 0-201-61594-0)
Those to concepts are discussed in about 30 pages of chapter 2 from Tim Ewald's excellent book "Transactional COM+" ISBN: 0-201-61594-0
So taking a direct quote from the summary of chapter 2:
"An object can interact with its context using object context and with a given causality using call context. These two objects provide interfaces for interacting with COM+ runtime services. This style of coding, 'reaching into context' makes COM+ development very different from classic COM development."
Finally, Chapter 2 has a discussion "Why Library Applications?",
(which is different from your question, Why not just plain old COM?)
His arguments mainly indicate the same reasons from using a COM object,
1. Each application has it's own instance.
2. Load into non- DLLhost.exe process.
3. Much Less Overhead.
4. Simple Deploy of common Objects.
So the bottom line is that if you are not Distributed, and Not Transactional In Nature, there may be no real advantage to using COM+ over COM. But if you write a COM+ application and deploy it as a LIBRARY application, it will behave a little bit more like a COM component.
Hope that helps.
The main purpose is to benefit from COM+ application contexts.
CoGetObjectContext for IObjectContext or IObjectContextActivity will return E_NOTINTERFACE from pure in-process component, while it will successfully work in a COM+ library application (and a server application of course).
The security context is also available through CoGetCallContext for ISecurityCallContext.
It has nothing to do with performance or isolation.
As a site note, one way to check what's available to COM+ library applications is to run dcomcnfg.exe navigate to Component Services, Computers, My Computer, COM+ application, create a new library application and check what's still enabled (as opposed to a server application).
We maintain a system that has over a million lines of COBOL code. Does someone have suggestions about how to migrate to a GUI (probably Windows based) without losing all the business logic we have written in COBOL? And yes, some of the business logic is buried inside the current user interface.
If it was me I would look into something like this:
NetCobol for Windows
It should be fairly easy to wrap your COBOL with an interface that exposes the functionality (if it isn't already written that way) and then call it from a .NET application.
It took us about 15 years to get off of our mainframe, because we didn't do something like this.
Writing a screen scraper is probably your best bet. Some of the major ERP systems have done this for years during a transition from server based apps to 3-tier applications. One i have worked with had loads of interesting features such as drop down lists for regularly used fields, date pop ups and even client based macro languages based on the scraping input.
These weren't great but worked well for the clients and made sure the applications still worked in a reliable fashion.
There is a lot of different ways to put this together, but if you put some thought into it you could probably use java or .net to create a desktop based application and with a little extra effort make a web based implementation.
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.
And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.
You could use an ESB to expose the back-end legacy services, and then code your GUI to invoke the services via the ESB.
Then you can begin replacing the legacy services with implementations on your new platform of choice.
The GUI need not be aware of the cut-over of back-end service implementation, as long as the interface to the service does not change - minor changes may hidden from the GUI by the ESB.
Business logic that resides in the legacy user interface layer will need to be refactored by extracting the business logic and exposing it as new services on the new platform to be consumed by the new GUI via the ESB.
As for the choice of platform for the new GUI, why not consider a web-based UI rather than a native windows platform, then at least updates to the UI will only need to be applied to the web-server rather than having to roll-out changes to each individual work-station.