Re: Pirates of Silicon Valley

[!smentzer@ecom.net (Steve Mentzer)]

>
>        The Mac OS has lagged behind on >technicalities<, it actually works
>much better than Windows does with its many "features" most of the time.
>Even this is gap is being filled quickly, though, as the Mac OS leaps
>forward into the future and leaves Windows FAR, FAR behind (Memory
>Protection: http://www.MacKiDo.com/Myths/memoryprotection.html,
>Multitasking: http://www.MacKiDo.com/Myths/mt.html)
>

I am so glad about you posting those links. I sent them to a couple of unix and 
NT programmers in my department. They are still reading them, but all of them 
said <in one way or another> "Where did you find this crap?"

I will just highlight one section of the document...

  "Much of windows messaging (like COM and OLE) just pass around pointers to 
  each others memory. So they are protected, except where they share - and they 
  have to share quite a bit"

This is a load of crap. The writer obviously has NO knowledge of Win32 
architecture, especially COM.

If you have a program which calls a COM component (ActiveX/OLE run on COM), the 
only way you can cause GPF's in the COM components address space is if that 
component runs INPROC (which means it runs in the same process, hence the same 
memory map/address space), and the only way to do that would be to know exactly 
what address space the member data resides at. COM objects do not expose member 
data. You can only access it via an interface method or property.

If the component is a Local or Remote server, it runs in it's own process 
(hence it gets it's own address space). When accessing methods on the 
component, a proxy-stub interface is called, which marshalls the data across 
the network (wire, cross-process).

It has never and will never be acceptance to pass pointers to non-standard type 
data across COM boundaries. And if you have non-standard data that you want 
to pass across a COM call, then you can write a custom marshalling routine 
to handle it for you...

Take this example (a property on a component)

STDAPI	CSampleObj::put_TestString(/*[in]*/ BSTR bstrVal)
{
	if (bstrVal)
	{
		m_bstrTestString = SysAllocString(bstrVal);
		return S_OK;
	}
	else
		return E_INVALIDARG;
	
};

STDAPI CSampleObj::get_TestString(/*[in,out]*/ BSTR *bstrVal)
{
	*bstrVal = SysAllocString(m_bstrTestString);
	return S_OK;
}


This code example simply allows you to put and get the value for the property 
"TestString" on a ActiveX/COM component.

If this component was running INPROC (in the creators process), you would be 
passing standard pointers of type (unsigned int*) to the method call (BSTR is 
of type unsigned int*). But since you are running INPROC, it doesn't matter, 
because it all shares the same address space..

If the component was running OUT OF PROC (in it's own process either on the 
local computer, or the remote computer), the proxy interface (which is created 
for you automatically by the SCM) would do the following.

	1 - Marshall all standard type data (BSTR) into a stream.
	2 - Pass that stream across an RPC to the remote object.
	3 - The remote object would then decode the stream and call the 
	    method locally.

You see, for an OUT OF PROC component, there is NO way to directly access or 
corrupt memory in it's address space. This is the beauty of COM.

Creating an object remotely (runs in a remote machine process), or locally 
inproc or locally outofproc) requires a simple change in calling sequence (and 
some additional keys in the registry when you register the component)...

To create this component in VB as a remote server requires no code changes, 
only registry changes...

	Dim objTest as Sample::SampleObj
	set objTest = new Sample::SampleObj
	msgbox Sample.TestString
	set objTest = nothing

A simple registry tweak will change the context of its run....

I know this was a long diatribe, but the author of that document doesn't have a 
clue...

smentzer@pacbell.net