Announcement

Collapse
No announcement yet.

So why can't PB create Out-of-Process servers?

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

  • So why can't PB create Out-of-Process servers?

    Apparently can be done in VB (but who wants the load).

    Is there a way to do it?

    Thanks,
    Paul
    Paul

  • #2
    You can do it using low-level COM not PB9 COM.
    Dominic Mitchell
    Phoenix Visual Designer
    http://www.phnxthunder.com

    Comment


    • #3
      Thanks for the reply..

      Do you know of an example somewhere?
      Paul

      Comment


      • #4
        Serious question...

        Are there any particular advantages or disadvantages to using an in-process versus an out-of-process COM server?

        Enquiring Minds Want to Know!
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          The difficulties involve the 'marshalling' of data between different processes on either the same machine or across machine boundaries. Naturally, there are additional layers of software involved in making this happen, so there will be the inevitable performance hit.

          When using the midl compiler if programming in C or C++ the compiler automatically generates proxy and stub dlls that facilitate the necessary parameter and return value marshalling. My take on this is that there is a good deal of boilerplate code involved. In looking at the various outputs of these files I can tell you its rather ugly. Network programming isn't really something I know very much about.

          I believe the advantages are pretty much a commonsence thing. If you have an exe that does something useful, it might be automated by some other application - just like Word or Excel for example.

          I'm just guessing here, but it doesn't look to me like the PowerBASIC compiler makes use of the midl compiler, unless it does so behind the scenes somehow. The midl compiler also creates type libs very handily, but these can be created in code also, which I believe is how the PowerBASIC compiler makes them. So if a future version of PB were to support out of process COM servers they would have to implement the marshalling code themselves or somehow integrate the midl compiler into the code outputs. That's about all I know about the issue.
          Last edited by Fred Harris; 3 May 2009, 12:36 PM. Reason: fix spelling
          Fred
          "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            Serious question...

            Are there any particular advantages or disadvantages to using an in-process versus an out-of-process COM server?

            Enquiring Minds Want to Know!
            Michael,

            Basic difference. Out of Process is an EXE that contains a COM server.
            InProcess is a DLL.

            As fred said, Word, etc are Out of Process COM servers....
            Paul

            Comment


            • #7
              More RAM

              ...Out of process would give us an easy way to access more RAM. Each out-of-process COM Object would have its own memory space. This would be a very welcome advantage for me. I would also love to see PB 10 able to create 64bit executables of course.

              Comment


              • #8
                Originally posted by Colin Schmidt View Post
                ...Out of process would give us an easy way to access more RAM. Each out-of-process COM Object would have its own memory space. This would be a very welcome advantage for me. I would also love to see PB 10 able to create 64bit executables of course.
                Not my objective - didn't know that was how you'd do it - but a welcome side effect..
                Paul

                Comment


                • #9
                  I'll take the 'body of work' here to mean, "There is no real advantage or disadvantage to in-process vs. out-of-process COM servers unless you really really want to use a lot (and I mean a lot) of virtual memory"

                  MCM
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Originally posted by Michael Mattias View Post
                    I'll take the 'body of work' here to mean, "There is no real advantage or disadvantage to in-process vs. out-of-process COM servers unless you really really want to use a lot (and I mean a lot) of virtual memory"

                    MCM
                    Why must someone explain to the public that he wants a feature?
                    Especially the replies of non com experianced users is troublesome.

                    Remember dcom? another good reason (or choice)

                    The man asks a question and now we are gonna discourage that?
                    Sounds similar to oop versus non oop coding techniques.

                    If it's not your area... (figure it out)
                    hellobasic

                    Comment


                    • #11
                      > If it's not your area... (figure it out)

                      You will note, sir, 'twas I who asked the question vis-a-vis in-process vs out-of-process servers precisely because I did not know and wished to.

                      Then having received multiple answers - none directly addressing my inquiry - I stated what I had inferred from all those non-answers.

                      And since I was not -and still am not - qualified to answer the original question, I have made no attempt to do so.

                      MCM
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        I may have misunderstood then.
                        Sorry.
                        hellobasic

                        Comment


                        • #13
                          Hi Michael,

                          Sorry, I should have elaborated... I wasn't talking about virtual memory, I was talking about physical memory.

                          My example case would be a larger server system, with say 16GB or more of RAM running a 64bit OS. Each 32bit process may make use of up to 2GB or 4GB of RAM. So, with out-of-process COM you could have a single server gateway be in charge of multiple child-server processes. This is about scalability for very large systems dealing with very large amounts of data. This is not the only solution, it would just be a convenient one.

                          Another advantage I would hope (but cannot test since PB does not do out-of-process COM) is that this type of architecture would protect the calling process from crashing if a GPF occurred in the called procedure.

                          Regards,
                          Colin

                          Comment


                          • #14
                            >protect the calling process from crashing if a GPF occurred in the called [server]procedure

                            Now that is one I did not think of... and that at least sounds useful. Seems it would also be true the other way, too.

                            BTW:
                            >I wasn't talking about virtual memory, I was talking about physical memory

                            Under Windows, an application is never dealing with physical memory. All memory is virtual.

                            MCM
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              If you like, this discussion is similar to using a cgi exe or isapi dll.
                              Same idea.
                              Last edited by Edwin Knoppert; 9 May 2009, 04:35 PM.
                              hellobasic

                              Comment


                              • #16
                                Under Windows, an application is never dealing with physical memory. All memory is virtual.
                                Yep! Sorry, I thought it was clear enough that I was talking about being able to make use of such large amounts of physical RAM. In hindsight, my comment was based on incorrect-interpretation of your comment and I was over-explaining it. I am probably doing so again right here... so I'll leave it at that

                                Regards,
                                Colin

                                Comment


                                • #17
                                  Well, you might be overexplaining it a tad...

                                  Left to its own devices, the Windows operating system is very good about using the physical resources provided to efficiently support the virtual memory model it works with.

                                  Not that it means anything special, but I don't recall any system commands or API functions you can use to tell Windows how it should use those physical resources, either... except that perhaps fiddling with thread and/or process priorities automatically does this.. that is, when Windows sees a higher priority, it is more reluctant to swap out that process and will tend to keep it in RAM more so than other processes/threads.

                                  For what it's worth, you might want to try including the code from this demo....
                                  Add Process Memory Usage Report to any program 1-12-04

                                  .. in one of your applications.

                                  The "page fault" counter is how many times your program requested memory which was not currently in RAM and the operating system had to go to the page file to get it ("Swap it in").

                                  I know the first couple times I ran some applications with this I was surprised at how often this happens... and very pleasantly surprised that I would never have noticed except for the inclusion of this report.

                                  MCM
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment

                                  Working...
                                  X