Steve:
all I can say is.... "Wow, you know you're shit!" :)
someone who knows the inner-workings of the Win32 API as you do, and even
posts example code has credibility in my book... hats off to ya...
Glad to see someone here has some real knowledge and doesn't spout stuff
off of the top of their head such as Mike O'Malley...
Mike
Steve Mentzer (!smentzer@ecom.net) wrote:
: >
: > 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
:
:
:
:
:
:
:
:
:
:
: