Announcement

Collapse
No announcement yet.

Exe com server to protect the application

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Exe com server to protect the application

    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?
    hellobasic

  • #2
    once you experiance these poor drivers you'll cover yourself as well.
    Once I experience poor drivers I get new drivers.
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      That's another answer no one can work with.
      Think before you answer.
      hellobasic

      Comment


      • #4
        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. )
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          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.
          hellobasic

          Comment


          • #6
            If your "users" are programmers using one of your libraries....well, that provides the ultimate target-rich environment for memory corruption.
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


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

              Comment


              • #8
                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
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  >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.
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    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.
                    hellobasic

                    Comment


                    • #11
                      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
                      Code:
                      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
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        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.
                        hellobasic

                        Comment


                        • #13
                          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.
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            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.
                            hellobasic

                            Comment


                            • #15
                              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"
                              Engineer's Motto: If it aint broke take it apart and fix it

                              "If at 1st you don't succeed... call it version 1.0"

                              "Half of Programming is coding"....."The other 90% is DEBUGGING"

                              "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                              Comment


                              • #16
                                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.
                                Michael Mattias
                                Tal Systems (retired)
                                Port Washington WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  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.
                                  Dominic Mitchell
                                  Phoenix Visual Designer
                                  http://www.phnxthunder.com

                                  Comment


                                  • #18
                                    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.
                                    hellobasic

                                    Comment


                                    • #19
                                      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.
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        Originally posted by Dominic Mitchell View Post
                                        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).
                                        Bernard Ertl
                                        InterPlan Systems

                                        Comment

                                        Working...
                                        X