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

[Paul MacFarlane]

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

Is there a way to do it?

Thanks,
Paul

[Dominic Mitchell]

You can do it using low-level COM not PB9 COM.

[Paul MacFarlane]

Thanks for the reply..

Do you know of an example somewhere?

[Michael Mattias]

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!

[Fred Harris]

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.

[Paul MacFarlane]

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....

[Colin Schmidt]

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.

[Paul MacFarlane]

...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..

[Michael Mattias]

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

[Edwin Knoppert]

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)

[Michael Mattias]

> 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

[Edwin Knoppert]

I may have misunderstood then.
Sorry.

[Colin Schmidt]

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

[Michael Mattias]

>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

[Edwin Knoppert]

If you like, this discussion is similar to using a cgi exe or isapi dll.
Same idea.

[Colin Schmidt]

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

[Michael Mattias]

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