Exe com server to protect the application

[Edwin Knoppert]

I really could use me a exe com server nowadays.

Let me explain:
I have this importtool making contact with all kind of databases.
Some of these drivers have the habbit to crash the appication in some cases.
This can be due an incorrect statement (solvable) but also due (unpredictable) memory issues etc etc..

I have the feeling such a com server may crash while it won't drag the application along.

We have a separate executable right now but with a poor communication interface.

Maybe i am wrong that such an exe com server will not collapse the calling application.

And no, please no discussion how i should prevent the crashes by writing 'better' code.., once you experiance these poor drivers you'll cover yourself as well.


Is it possible with some alternative code to extend the current com support?

[Michael Mattias]

once you experiance these poor drivers you'll cover yourself as well.

Once I experience poor drivers I get new drivers.

[Edwin Knoppert]

That's another answer no one can work with.
Think before you answer.

[Michael Mattias]

Well, Edwin, to call your description of your current challenge "vague" would be kind.

However, I will hazard a guess that changing the server/EXE would be no more than the modern-day equivalent of rearranging the deck chairs on Titanic, since it's obvious some portion of this application considered as a unitary entity has a large hole in its hull and it's going to sink sooner or later anyway.

However, changing to a new server may solve the problem... if the current hole is in the current server. But memory corruption can come from anywhere so the problem could be in the "importing tool" or in the form of "contact" with the database, or in the DBMS itself, or in the drivers.

(Code not shown. )

[Edwin Knoppert]

Sigh.. this is something the end users does.
It simply imports using my app, i have no way to improve their situation and don't want to.

[Michael Mattias]

If your "users" are programmers using one of your libraries....well, that provides the ultimate target-rich environment for memory corruption.

[Edwin Knoppert]

..And still no answer if a com server may crash and leaves the app intact

[Michael Mattias]

Well, how are you "calling" this EXE?

There is absolutely no reason, ever, to have the callling (parent) process go belly-up ("belly-up" is at least as technically accurate as is "crash") if the called (child) process EXE somehow fails. You simply have to interrogate the status of that EXE and proceed accordingly.

Unless of course you are sharing memory, but that cannot be done by accident. (A terrific feature of Win/32). Code not shown.

MCM

[Michael Mattias]

>You simply have to interrogate the status of that EXE and proceed accordingly.

Typically done with the return code. No muss, no fuss, no bother.

[Edwin Knoppert]

You misunderstood the subject.
I am talking about a com *exe* server.

With native PB com support you can not create such a com server.
(Out of process)

1) Will such an instance still crash the calling app.

2) Will it be possible with some modifications to create such an object.

[Michael Mattias]

Ok, I think I see now...

You currently have an application / library which exposes a COM interface; said library uses a DLL, resulting in an 'in-process' server.

Said library does something requiring some two-bit drivers; when said drivers fail, they evince a protection fault in a function (class, method) in that DLL.

Because the server is 'in-process', the protection fault occurs within the process, hence halting the entire application.

It is thought that by changing the server to a separate process, failures in that process will allow the 'main' application to continue.

Is that correct?

Given these conditions...
> Will such an instance still crash the calling app.
Of course not, it's in a separate process.

> Will it be possible with some modifications to create such an object.
Not with PB/Win 9.0.0 it isn't.

Unless you are intimating you might not be averse to using Ye Olde Handye Dandye Binary File Editor or the programmatic equivalent thereof, in which case I believe the format of said *.EXE COM server is documented and you are welcome to try.

OR, you could write your own EXE which does nothing more than

DECLARE class or whatever in mydll.dll
FUNCTION PbMain  () 
  Params  = <obtain from some source> 
  CALL COMFunction/Method/Property in DLL  (params) 
  FUNCTION = some meaningful return code
END FUNCTION

[Edwin Knoppert]

Yes, the main app should not crash.
We solve it by communicating via sendmessages, a bit cumbersome.

> Will such an instance still crash the calling app.
>>Of course not, it's in a separate process.
Maybe not since the com interface is no longer available after the crash and may terminate the calling app, this aspect is unknown to me.

Anyway, the tweaking to make the com interface available in a out of process exe is unknown to me.

The GPF.. i could test with VB6 for a moment.
At this time not a serious issue but nowadays i do so much oop coding it is more readable and extendable to me this way.

[Michael Mattias]

Maybe not since the com interface is no longer available after the crash and may terminate the calling app, this aspect is unknown to me.

What com interface? Being in a separate process, there is no COM interface available in the "main" EXE. Basically, you have created an API, which just happens to use an EXE and just happens to use COM internally.

"Maybe" you could use shared memory to expose your objects in the 'main' exe.

Maybe.

But it sure sounds a whole lot easier to write better code and use decent drivers.

[Edwin Knoppert]

It exposes a com interface which is instantiated in the calling process.
Is that so difficult?
So a reference exists in the calling app while the exe may be dead.

[Cliff Nichols]

I think I get where this is going

AKA...My app is in charge (Objects or otherwise), and some app under me misbehaves.

Do I need to crash? or can I smack them as being the crasher, and stop the crash because all the other kids behaved?

Hmmm now that I read it...am I borderline child abuse? or just correcting mis-behaved children???

(Bad analogy, but if you read it as I did, then you know why the analogy)


Very good question though...but hazzard to guess the answer is..."It Depends"

[Michael Mattias]

It exposes a com interface which is instantiated in the calling process.
Is that so difficult?

You'd have to ask the compiler publisher.

However, I am certain they chose the "DLL" packaging for a reason.

[Dominic Mitchell]

If the server crashes, you should get the following error when trying to access outstanding interfaces:
0x800706BA: The RPC server is unavailable.

There are proxy and stub DLLs sitting between the two servers, therefore, the client(calling exe) should
not crash.

I mentioned proxies and stubs because it appears Michael is unfamiliar with the concept of marshaling
because of this comment by him

What com interface? Being in a separate process, there is no COM interface available in the "main" EXE.

[Edwin Knoppert]

I wasn't sure but the com reference is local memory so even if the interface is no longer available something else may happen, like you said, an exception.

For future development of my tool i hopefully find me a way to extend the current com support.
It's not that important but by using sendmessages you can not have synchronized messages.

For example, App1 calls App2 and during the request app2 makes a request to App1.
This will lock up everything.
Understandable, synchronizing different 'threads' is not simple imo.

I could use TCP but i have experiance that even for example wininet being loaded (not used) may trigger firewall warnings.
And the overhead of using free ports and so on.

RPC, yes i read a little about out of process servers, sounds like soap to me.

[Michael Mattias]

True, I don't know from marshalling; as I've said, I'm not a COM guy.

Matter of fact right now my interest is limited to knowing how to use COM libraries created by others; and if you want to get really picky, my interest in in learning to use ADO and use it well.

However I do have at least a little experience dealing with processes, memory management and other Windows' fundamentals; and just as a matter of style, when I want to "do something" I never look outside the bounds of the compiler's documented capabilities without fully understanding that if I do I am on my own.

In this case, the question was "can I make an 'EXE' COM server?" with the unstated portion being "using the PB compilers."

Answer: No.

[Bern Ertl]

If the server crashes, you should get the following error when trying to access outstanding interfaces:
0x800706BA: The RPC server is unavailable.

There are proxy and stub DLLs sitting between the two servers, therefore, the client(calling exe) should
not crash.

This assumes the server application crashes between calls. If the server application crashes while processing a client call to it, the client app might hang while waiting for a reply. At least, that's what I seem to remember from the development work I did a few years ago while exploring a few buggy COM servers (I was building client interfaces).